keith/Portfolio-2026
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Add onboarding documentation for new developers

Browse Source 
Add four comprehensive guides to help new developers get started
with the VDI-Starter-v5 WordPress theme:

- docs/getting-started.md: Setup from zero, local WordPress options,
  env config, theme activation warnings, troubleshooting
- docs/architecture.md: Bootstrap flow, 7 architectural layers,
  namespace conventions, WP hooks cleanup, enqueue system, theme.json
- docs/creating-blocks.md: Step-by-step ACF block creation tutorial,
  helper functions, parent-child patterns, Tailwind integration
- docs/reference.md: Hooks/filters tables, design tokens, CSS import
  tree, JS module graph, class reference, CLI commands, deployment

Update README.md: trim deep-dive API docs (moved to reference),
add documentation links section, fix CSS paths (views/styles/ →
styles/), add missing contact-info block, fix deployment filename
typo (wpengine,yml → wpengine.yml), add backToTop.js and
enqEditorAssets(), add namespace conventions table.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Keith Solomon
2026-05-03 17:41:32 -05:00
co-authored by Claude Opus 4.7
parent bcc701120b
commit b3cc21a860
5 changed files with 2616 additions and 424 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture.md
+421
View File
@@ -0,0 +1,421 @@
# Architecture
A deep dive into how VDI-Starter-v5 is organized, how it boots, and the conventions it uses.
## Table of Contents
- [Bootstrap Flow](#bootstrap-flow)
- [Architectural Layers](#architectural-layers)
- [Namespace Conventions](#namespace-conventions)
- [Global Variables](#global-variables)
- [WordPress Hooks Cleanup](#wordpress-hooks-cleanup)
- [Enqueue System](#enqueue-system)
- [theme.json Design System](#themjson-design-system)
## Bootstrap Flow
When WordPress loads a theme, it starts with `style.css` (for theme metadata) and `functions.php` (for logic). Here's exactly what happens in VDI-Starter-v5:
```
WordPress loads the theme
│
├─ style.css → Theme declaration (name, description, version)
│
└─ functions.php → Entry point
│
├─ namespace BasicWP
│
├─ glob(__DIR__ . '/lib/*.php') → Autoloads every PHP file in lib/
│ ├─ activation.php → Theme activation handler (runs once)
│ ├─ class-acf.php → ACF JSON sync paths
│ ├─ class-breadcrumbs.php → Breadcrumb generation
│ ├─ class-enqueue.php → Asset loading (CSS, JS, fonts)
│ ├─ class-menuitems.php → Nav menu rendering
│ ├─ class-resources.php → Custom post type
│ ├─ extras.php → Sidebar, page header, Owner role, etc.
│ ├─ helpers.php → Utility functions, globals, ACF options page
│ ├─ hooks.php → WordPress hooks, cleanup, SVG support
│ ├─ search-features.php → Enhanced search
│ └─ show-template.php → Debug template path display
│
└─ regACFBlocks() → Registers ACF blocks (init hook, priority 5)
└─ Scans views/blocks/*/block.json (skips 'boilerplate')
```
The glob autoload means every file in `lib/` is loaded on every request. This is intentional — it keeps the architecture flat and predictable. If you add a new file to `lib/`, it's automatically available without modifying `functions.php`.
When the `init` hook fires (priority 1), `hooks.php::init()` runs its cleanup routine and adds theme supports. Then at priority 5, `regACFBlocks()` registers all ACF blocks. The `Enqueue` class constructor hooks into `wp_enqueue_scripts`, `admin_enqueue_scripts`, and `enqueue_block_editor_assets`.
## Architectural Layers
The theme is organized into seven distinct layers, each with a clear responsibility:
### 1. Entry Layer
The two files WordPress needs to recognize the theme:
| File | Purpose |
|------|---------|
| `functions.php` | Autoloads `lib/*.php`, registers ACF blocks on `init` |
| `style.css` | Theme declaration — name, description, version, author |
**Why it matters:** `functions.php` is the only file you should never edit directly. All logic lives in `lib/`.
### 2. Service Layer
PHP classes and utility functions in `lib/` that provide core functionality:
| File | Class/Function | Purpose |
|------|---------------|---------|
| `class-enqueue.php` | `Enqueue` | Loads all frontend CSS, JS, and fonts with cache-busting |
| `class-menuitems.php` | `MenuItems` | Resolves WordPress nav menus into renderable item trees |
| `class-breadcrumbs.php` | `Breadcrumbs` | Context-aware breadcrumb trails with Schema.org markup |
| `class-acf.php` | `ACF` | Configures ACF JSON save/load paths for version control |
| `class-resources.php` | `Resources` | Registers the "Resources" custom post type with URL rewriting |
| `class-resources.php` | `ShowTemplate` | Adds HTML comment to footer showing active template (debug) |
| `hooks.php` | `init()` | Aggressive WordPress cleanup, theme supports, SVG uploads |
| `helpers.php` | Various | `getFieldValue()`, `blockWrapperAttributes()`, `blockCategories()`, etc. |
| `extras.php` | Various | `createOwnerRole()`, `hasSidebar()`, `hasPageHeader()`, `divWrapper()` |
| `search-features.php` | Various | `pageSearch()`, `dedupe()`, `postSort()`, `searchResultFilter()` |
| `activation.php` | Various | Auto-installs plugins, creates pages, configures settings on theme activation |
### 3. UI Templates and Components
WordPress template hierarchy files, ACF blocks, reusable components, and icons:
**Template Hierarchy:**
| File | WordPress Template For |
|------|----------------------|
| `front-page.php` | The front page |
| `index.php` | Blog posts listing (fallback for all) |
| `single.php` | Individual posts |
| `page.php` | Static pages (with optional sidebar) |
| `search.php` | Search results |
| `404.php` | Page not found |
| `header.php` | Site header (included by other templates) |
| `footer.php` | Site footer (included by other templates) |
| `sidebar.php` | Primary sidebar |
| `sidebar-page.php` | Page-specific sidebar |
**ACF Blocks (in `views/blocks/`):**
Each block follows a consistent three-file pattern: `block.json` (registration) + `{name}.php` (template) + `{name}.css` (styles).
| Block | Purpose |
|-------|---------|
| `accordion` | Collapsible content sections |
| `boilerplate` | Starting template for new blocks (not registered) |
| `button` | Single configurable button element |
| `buttons` | Container that restricts children to `button` blocks |
| `contact-info` | Contact information display |
| `grid` | Flexible grid layout (restricts children to `grid-cell`) |
| `grid-cell` | Individual grid item |
| `homepage-hero` | Hero section for the front page |
| `media-text` | Image/video with accompanying text |
| `media-text-innerblocks` | Media-text with nested block support |
| `page-children` | Displays child pages of the current page |
| `section` | Container with background and width options |
**Components (in `views/components/`):**
| Component | Purpose |
|-----------|---------|
| `nav-aux.php` | Auxiliary navigation bar (social links + search) |
| `nav-main.php` | Primary navigation menu |
| `nav-main__toggle.php` | Mobile menu toggle button |
| `menu-items/` | Recursive menu item rendering (index, has-children, single) |
**Partials (in `views/partials/`):**
| Partial | Purpose |
|---------|---------|
| `page-hero.php` | Page hero section |
| `social-media.php` | Social media links |
**Icons (in `views/icons/`):**
SVG icon partials for Facebook, Instagram, LinkedIn, Pinterest, Twitter, YouTube, and others. Each is a minimal PHP file that outputs an SVG element.
### 4. Styling
CSS is organized as a layered cascade, managed through Tailwind CSS v4:
```
styles/theme.css ← Entry point (imports everything below)
├── @import "tailwindcss" ← Tailwind CSS v4 base
├── @import "./base/index.css" ← Base styles barrel file
│ ├── break-out.css ← Container break-out utilities
│ ├── colors.css ← Color custom properties
│ ├── forms.css ← Form element styles
│ ├── global.css ← Global resets and base styles
│ ├── misc.css ← Miscellaneous utilities
│ ├── prose.css ← Prose/typography styles
│ ├── skip-link.css ← Accessibility skip link
│ └── typography.css ← Typography scale and fonts
├── @import "./navigation/index.css" ← Navigation barrel file
│ ├── nav-aux.css ← Auxiliary nav
│ ├── nav-footer.css ← Footer nav
│ ├── nav-functional.css ← Functional nav styles
│ ├── nav-main-default.css ← Default main nav
│ ├── nav-main-mega.css ← Mega menu nav
│ ├── nav-mobile-accordion.css ← Accordion mobile nav
│ └── nav-mobile-sliding.css ← Sliding mobile nav
├── @import "./fonts/lineicons.css" ← Icon font (600+ glyphs)
├── @import "./base/break-out.css" ← Break-out utilities (loaded after nav)
├── @import "./components/index.css" ← Components barrel file
│ ├── breadcrumbs.css ← Breadcrumbs
│ ├── pagination.css ← Pagination
│ ├── post-list.css ← Post listings
│ ├── sidebar.css ← Sidebar
│ ├── site-footer.css ← Footer
│ └── site-header.css ← Header
└── @import "./blocks/index.css" ← Block styles barrel file
├── buttons.css ← Button styles with CSS custom properties
└── core.css ← Core block overrides
```
**Why this structure?** The barrel files (`index.css`) make it easy to add or remove stylesheets without modifying `theme.css`. Navigation styles are grouped because you typically only use one variant (default vs mega menu, accordion vs sliding mobile). Block-specific CSS lives alongside each block in `views/blocks/` and is auto-loaded by WordPress when the block renders.
**Important:** There is no `tailwind.config.js`. Tailwind CSS v4 uses CSS-first configuration via `@import "tailwindcss"` and `@plugin` directives in `theme.css`. Custom colors, fonts, and spacing are defined in `theme.json` and `styles/base/colors.css`.
### 5. Client Scripts
JavaScript modules loaded via WordPress's `wp_enqueue_script_module()` API (requires WordPress 6.5+):
```
static/js/theme.js (entry point for frontend)
├── Navigation.js → Mobile menu, sliding viewport, keyboard nav
├── backToTop.js → BackToTopButton custom element
├── button.js → ButtonComponent custom element (<x-button>)
├── GetHeaderHeight.js → Sets --header-height CSS variable
└── TagExternalLinks.js → Adds target="_blank" rel="noopener" to external links
static/js/admin.js (entry point for editor)
└── button.js → ButtonComponent for editor context
```
**How script modules work:** WordPress's `wp_enqueue_script_module()` creates proper ES module dependencies. The `Enqueue` class registers `basicwp-theme` (theme.js) as a root module, and `basicwp-button` (button.js) declares a dependency on it. This means button.js won't load until theme.js has loaded — no more manual script ordering.
**Passive event listener polyfill:** `theme.js` includes a polyfill that makes scroll, touch, and mouse event listeners passive by default. This improves scrolling performance without requiring `addEventListener(..., { passive: true })` on every listener.
**Custom elements:** The `ButtonComponent` (`<x-button>`) and `BackToTopButton` (`<back-to-top>`) are Web Components registered via `customElements.define()`. They accept attributes for styling, URL, target, and behavior.
### 6. Data Layer
ACF field group JSON files in the `acf/` directory:
| File | Block/Feature |
|------|-------------|
| `group_5f7f85a2a3e13.json` | Accordion block fields |
| `group_5fd3e006e5da5.json` | Global Fields (site-wide contact, social, footer settings) |
| `group_600f5a9e242c3.json` | Grid block fields |
| `group_60106ed700da3.json` | Button block fields |
| `group_60bfb84ae973c.json` | Media Text block fields |
| `group_60bfdb328901d.json` | Section block fields |
| `group_6261bc658dd80.json` | Homepage Hero and Section fields |
| `group_645e51f721207.json` | Grid Cell block fields |
| `group_645e7cf448e66.json` | Contact Info block fields |
**Why JSON sync?** The `ACF` class in `class-acf.php` sets custom save/load paths so that field groups created in the WordPress admin are automatically saved as JSON files. This means:
- Field group configurations are version-controlled in Git
- Field groups survive database resets
- Multiple environments stay in sync
- You can edit field groups in code or in the admin UI
### 7. Infrastructure
Build, CI/CD, and configuration files that support development and deployment:
| File | Purpose |
|------|---------|
| `bin/.build.js` | Production build script — compiles Tailwind CSS with `--optimize` |
| `bin/.watch.js` | Development server — BrowserSync with live reload |
| `bin/.utils.js` | Shared utilities for build scripts (`tailwindToCSS`, debounce) |
| `.github/workflows/wpengine.yml` | Deploys to WP Engine via rsync on manual trigger |
| `.github/workflows/phpcs.yml` | Runs PHP CodeSniffer on pull requests |
| `.github/workflows/todos.yml` | Syncs code TODOs to GitHub Issues |
| `package.json` | Node dependencies and build/watch scripts |
| `composer.json` | PHP dependencies (PHP_CodeSniffer, WordPress coding standards) |
| `theme.json` | WordPress block editor configuration (colors, fonts, spacing) |
| `.phpcs.xml` | PHP CodeSniffer ruleset |
| `.env.example` | Environment variable template (`LOCALHOST_URL`, `BROWSERSYNC_PORT`) |
| `playwright.config.js` | Playwright accessibility test configuration |
| `tests/site-a11y.spec.js` | Accessibility test suite using @axe-core/playwright |
## Namespace Conventions
The project uses several naming conventions that can be confusing at first:
| Convention | Value | Where Used |
|-----------|-------|-----------|
| PHP namespace | `BasicWP` | All PHP files use `namespace BasicWP;` |
| Text domain | `basicwp` | WordPress translation functions (`__()` , `_e()`) |
| Block category | `vdi-blocks` | Groups custom blocks in the editor (defined in `helpers.php::blockCategories()`) |
| Script module IDs | `basicwp-theme`, `basicwp-button`, `basicwp-admin` | JavaScript module registration in `class-enqueue.php` |
| WP Engine folder | `vdi-v5` | Deployment target in `.github/workflows/wpengine.yml` |
| Git repo name | `VDI-Starter-v5` | The repository and theme directory name |
**The story:** "VDI" is Vincent Design Inc., the agency. "BasicWP" was the original internal code name. "vdi-blocks" and "vdi-v5" are deployment-facing names that align with the client's branding. They all refer to the same theme — just used in different contexts.
## Global Variables
Two global variables are defined in `helpers.php`:
```php
global $theme, $views;
$theme = get_template_directory(); // e.g., /var/www/wp-content/themes/VDI-Starter-v5
$views = $theme . '/views'; // e.g., /var/www/wp-content/themes/VDI-Starter-v5/views
```
**`$theme`** — Absolute path to the theme directory. Used when including files that need the full server path.
**`$views`** — Absolute path to the views directory. Used by `MenuItems::render()` to include navigation templates:
```php
include $views . '/components/menu-items/index.php';
```
These are available everywhere because `helpers.php` is loaded early via the glob autoload in `functions.php`.
## WordPress Hooks Cleanup
The `init()` function in `hooks.php` runs on every page load at priority 1. It performs aggressive cleanup of default WordPress output for performance and security reasons:
**What gets removed:**
| What | Why |
|------|-----|
| Emoji detection scripts & styles | Most sites don't use WordPress emojis; they add ~10KB to every page |
| `wp-block-library` styles | Theme provides its own block styles; core defaults add ~100KB |
| `global-styles` & `core-block-styles` | Theme overrides these via `theme.json` and custom CSS |
| `core-block-supports` | Duplicate of styling already handled by the theme |
| WordPress generator meta tag | Security — hides WordPress version from page source |
| RSD link | Rarely used XML-RPC discovery |
| WLW manifest | Windows Live Writer support (deprecated) |
| Shortlink | Removes `<link rel="shortlink">` from head |
| REST API link in head | The API still works; only the discoverable link is removed |
| oEmbed discovery links | Removes auto-embed discovery from head |
| Canonical URL | Theme handles SEO via The SEO Framework plugin |
| DNS prefetch hints | Removes unused `<link rel="dns-prefetch">` tags |
| XML-RPC | Disabled via `xmlrpc_enabled` filter — prevents brute-force attacks |
| Intrinsic image sizes | Prevents WordPress from adding width/height to img tags |
| Auto sizes | Prevents automatic `sizes` attribute on images |
**What gets added:**
| Feature | Why |
|---------|-----|
| `post-thumbnails` | Featured image support |
| `title-tag` | WordPress manages `<title>` tag |
| `html5` (caption, comment-form, comment-list, gallery, search-form, script, style) | Modern HTML5 markup |
| `align-wide` | Wide/full alignment for blocks |
| `editor-styles` | Theme styles appear in the block editor |
| `responsive-embeds` | Embeds respond to container width |
| `customize-selective-refresh-widgets` | Widget changes update without full page reload |
| SVG upload support | Allows SVG files in the media library |
**Important:** This cleanup is aggressive. If a plugin requires one of the removed features (like oEmbed discovery or XML-RPC), you'll need to comment out the corresponding `remove_action` line in `hooks.php`.
## Enqueue System
The `Enqueue` class (in `class-enqueue.php`) manages all asset loading:
### Frontend (`enqFEAssets()`)
| Asset | Method | Notes |
|-------|--------|-------|
| `static/dist/theme.css` | `wp_enqueue_style()` | Compiled Tailwind CSS, cache-busted with `filemtime()` |
| Raleway font | `wp_enqueue_style()` | Google Fonts with `preconnect` hint |
| `basicwp-theme` (theme.js) | `wp_enqueue_script_module()` | Frontend entry point |
| `basicwp-button` (button.js) | `wp_enqueue_script_module()` | Depends on `basicwp-theme` |
| jQuery | `wp_enqueue_script()` | Needed by downstream scripts; modules can't depend on classic scripts |
### Admin (`enqBEAssets()`)
| Asset | Method | Notes |
|-------|--------|-------|
| Raleway font | `wp_enqueue_style()` | Same Google Fonts |
| `styles/backend/admin.css` | `wp_enqueue_style()` | Admin-specific overrides |
| `basicwp-admin` (admin.js) | `wp_enqueue_script_module()` | Admin entry point |
| `basicwp-button` (button.js) | `wp_enqueue_script_module()` | Depends on `basicwp-admin` |
### Block Editor (`enqEditorAssets()`)
| Asset | Method | Notes |
|-------|--------|-------|
| Raleway font | `wp_enqueue_style()` | Same Google Fonts |
| `styles/backend/editor.css` | `wp_enqueue_style()` | Editor-specific styles, scoped to block editor |
**Cache busting:** All enqueued files use `filemtime()` as the version number. This means the browser cache is automatically busted whenever a file changes — no manual version bumps needed.
**Script modules:** The theme uses `wp_enqueue_script_module()` (WordPress 6.5+) instead of traditional `wp_enqueue_script()` for frontend and admin JavaScript. This creates proper ES module dependencies where `basicwp-button` won't load until `basicwp-theme` has loaded.
## theme.json Design System
The `theme.json` file (WordPress block editor v3 schema) defines the design system for both the block editor and the frontend:
### Colors
Colors are defined as CSS custom properties and mapped to WordPress editor slugs:
| Editor Slug | CSS Variable | Purpose |
|------------|-------------|---------|
| `black` | `#000` | Pure black |
| `white` | `#fff` | Pure white |
| `theme-bg` | `var(--color-background)` | Page background |
| `theme-text` | `var(--color-text)` | Body text |
| `theme-primary` | `var(--color-primary)` | Primary brand color |
| `theme-secondary` | `var(--color-secondary)` | Secondary brand color |
| `theme-bodylinks` | `var(--color-bodylinks)` | Body link color |
| `theme-footerlinks` | `var(--color-footlinks)` | Footer link color |
| `theme-success` | `var(--color-success)` | Success/positive |
| `theme-warning` | `var(--color-warning)` | Warning/caution |
| `theme-danger` | `var(--color-danger)` | Danger/error |
| `theme-info` | `var(--color-info)` | Informational |
The actual color values for the CSS variables are defined in `styles/base/colors.css`.
### Typography
One font family (`var(--font-sans)`) and 15 size presets:
| Slug | Variable | Typical Use |
|------|----------|-------------|
| `base` | `var(--text-base)` | Body text |
| `text-14px` | `var(--text-14px)` | Small text |
| `text-16px` | `var(--text-16px)` | Standard text |
| `text-18px` | `var(--text-18px)` | Large text |
| `text-20px` | `var(--text-20px)` | Subheadings |
| `text-22px` | `var(--text-22px)` | H4 |
| `text-25px` | `var(--text-25px)` | H3 |
| `text-30px` | `var(--text-30px)` | H2 |
| `text-35px` | `var(--text-35px)` | Large heading |
| `text-38px` | `var(--text-38px)` | H1 (small) |
| `text-40px` | `var(--text-40px)` | H1 |
| `text-45px` | `var(--text-45px)` | Hero heading |
| `text-50px` | `var(--text-50px)` | Large hero |
| `text-70px` | `var(--text-70px)` | Display size |
| `text-75px` | `var(--text-75px)` | Maximum display |
### Layout
| Property | Value | Meaning |
|----------|-------|---------|
| `contentSize` | `100%` | Default content width (full-width by default) |
| `wideSize` | `1536px` | Wide-alignment max width |
### Spacing
Available units: `px`, `em`, `rem`, `vh`, `vw`, `%`
### Global Styles
| Property | Value |
|----------|-------|
| Background | `var(--wp--preset--color--background)` |
| Text color | `var(--wp--preset--color--text)` |
| Link color | `var(--wp--preset--color--theme-bodylinks)` |
| Font family | `var(--wp--preset--font-family--theme-sans)` |
| Line height | `1.5` |
**Why `theme.json` matters:** Changes to this file immediately affect the block editor UI — colors appear in the palette, font sizes in the typography controls, and spacing in the spacing panel. This is the single source of truth for the design system, and CSS custom properties cascade from here into the frontend styles.
docs/creating-blocks.md
+941
View File
@@ -0,0 +1,941 @@
# Creating Blocks in VDI-Starter-v5
## Table of Contents
- [Overview](#overview)
- [How Block Registration Works](#how-block-registration-works)
- [Block Anatomy: The Three-File Pattern](#block-anatomy-the-three-file-pattern)
- [block.json -- The Registration Manifest](#blockjson----the-registration-manifest)
- [The PHP Template -- Rendering the Block](#the-php-template----rendering-the-block)
- [The CSS File -- Scoped Styles](#the-css-file----scoped-styles)
- [Helper Functions](#helper-functions)
- [blockWrapperAttributes()](#blockwrapperattributes)
- [getFieldValue()](#getfieldvalue)
- [escEmbeds()](#escembeds)
- [ACF Field Groups](#acf-field-groups)
- [Parent-Child Block Patterns (InnerBlocks)](#parent-child-block-patterns-innerblocks)
- [Tailwind CSS in Blocks](#tailwind-css-in-blocks)
- [Step-by-Step: Creating a New Block](#step-by-step-creating-a-new-block)
- [1. Create the Block Directory](#1-create-the-block-directory)
- [2. Create block.json](#2-create-blockjson)
- [3. Create the PHP Template](#3-create-the-php-template)
- [4. Create the CSS File](#4-create-the-css-file)
- [5. Create ACF Field Groups in WordPress Admin](#5-create-acf-field-groups-in-wordpress-admin)
- [6. Build and Verify](#6-build-and-verify)
- [Real-World Examples from This Theme](#real-world-examples-from-this-theme)
- [Simple Block: Homepage Hero](#simple-block-homepage-hero)
- [Parent Block with InnerBlocks: Section](#parent-block-with-innerblocks-section)
- [Restricted Parent Block: Buttons](#restricted-parent-block-buttons)
- [Dynamic Parent Block: Grid](#dynamic-parent-block-grid)
- [Block Using Global Fields: Contact Info](#block-using-global-fields-contact-info)
- [Common Pitfalls and Best Practices](#common-pitfalls-and-best-practices)
---
## Overview
VDI-Starter-v5 uses Advanced Custom Fields (ACF) blocks to build page content. ACF blocks are a type of WordPress Gutenberg block where the editing interface comes from ACF field groups and the rendering is handled by a PHP template (instead of React). This approach lets you build rich, structured content blocks using familiar PHP templating and Tailwind CSS, without writing JavaScript.
Every block in this theme follows the same three-file pattern inside `views/blocks/{block-name}/`, and new blocks are automatically discovered and registered -- no manual registration required.
---
## How Block Registration Works
Block registration is handled by the `regACFBlocks()` function in `functions.php`. You never need to register a block manually; the function handles discovery for you.
```php
// functions.php
function regACFBlocks() {
define( 'BLOCKS_DIR', get_stylesheet_directory() . '/views/blocks' );
if ( is_dir( BLOCKS_DIR ) ) {
foreach ( scandir( BLOCKS_DIR ) as $folder ) {
if ( ( '.' !== $folder && '..' !== $folder && 'boilerplate' !== $folder ) && is_dir( BLOCKS_DIR . '/' . $folder ) ) {
register_block_type( BLOCKS_DIR . '/' . $folder );
}
}
}
}
add_action( 'init', __NAMESPACE__ . '\\regACFBlocks', 5 );
```
Here is what happens:
1. `BLOCKS_DIR` is defined as `get_stylesheet_directory() . '/views/blocks'`, pointing to the `views/blocks/` directory inside the theme.
2. The function scans every subdirectory inside `views/blocks/`.
3. It skips `.` (current dir), `..` (parent dir), and the `boilerplate` directory (the boilerplate is a template for creating new blocks, not a real block).
4. For every remaining directory, it calls WordPress's `register_block_type()`, which reads the `block.json` file inside that directory and registers the block.
5. The function runs on the `init` hook at priority 5, ensuring blocks are registered before the editor needs them.
**What this means for you:** To create a new block, you only need to add a new subdirectory under `views/blocks/` with a valid `block.json` file. WordPress discovers and registers it automatically the next time the theme loads.
---
## Block Anatomy: The Three-File Pattern
Every ACF block in this theme consists of exactly three files inside `views/blocks/{block-name}/`:
```
views/blocks/
boilerplate/ <-- Template for creating new blocks (not registered)
block.json
boilerplate.php
boilerplate.css
section/
block.json
section.php
section.css
homepage-hero/
block.json
homepage-hero.php
homepage-hero.css
...
```
The naming convention is consistent: the directory name, the PHP file, and the CSS file all share the same slug (e.g., `homepage-hero`). The `block.json` file always uses the literal name `block.json`.
### block.json -- The Registration Manifest
The `block.json` file tells WordPress and ACF everything they need to know about the block. Here is the boilerplate version:
```json
{
"name": "acf/boilerplate",
"title": "Block Boilerplate",
"description": "Boilerplate code to create ACF blocks.",
"style": ["file:./boilerplate.css"],
"category": "vdi-blocks",
"icon": "block-default",
"keywords": ["boilerplate"],
"acf": {
"mode": "preview",
"renderTemplate": "boilerplate.php"
},
"supports": {
"align": true,
"anchor": true,
"color": true,
"html": false,
"jsx": false,
"mode": true,
"multiple": false
}
}
```
**Field-by-field explanation:**
| Field | Purpose |
|---|---|
| `name` | The unique block identifier. **Must be prefixed with `acf/`** for ACF blocks. This becomes the machine name WordPress uses internally (e.g., `acf/testimonial`). |
| `title` | The human-readable name shown in the block editor inserter (e.g., "Testimonial"). |
| `description` | A short description shown in the block editor to help editors understand what the block does. |
| `style` | An array of CSS files to load when this block renders. Use the `file:./` prefix for block-relative paths. WordPress only loads these stylesheets when the block is actually present on the page. |
| `category` | Determines which section of the inserter the block appears under. **Always use `vdi-blocks`** in this theme -- this is the custom category registered in `helpers.php` that groups all theme blocks together under "VDI Custom Blocks". |
| `icon` | A Dashicon name (without the `dashicons-` prefix) shown next to the block in the inserter. Browse available icons at https://developer.wordpress.org/resource/dashicons/. |
| `keywords` | Additional search terms that help editors find the block in the inserter. For example, a "Testimonial" block might include `["testimonial", "quote", "review"]`. |
| `acf.mode` | Controls how the block appears in the editor. `preview` shows the rendered block output; `edit` shows the ACF field inputs directly. Most blocks use `preview`. |
| `acf.renderTemplate` | The PHP file that renders the block on the frontend and in preview mode. This filename must match the actual file in the directory. |
| `supports.align` | Whether editors can choose alignment (left, center, right, wide, full). |
| `supports.anchor` | Whether editors can set an HTML anchor (id attribute) for linking. |
| `supports.color` | Whether editors can set text and background colors via the block editor. |
| `supports.html` | Whether the block supports HTML editing mode in the editor. Set to `false` for ACF blocks since the template controls the markup. |
| `supports.jsx` | Whether the block supports InnerBlocks (nesting other blocks inside it). Set to `true` if your block uses `<InnerBlocks />`. |
| `supports.mode` | Whether editors can toggle between preview and edit mode in the editor. |
| `supports.multiple` | Whether the block can be inserted more than once per post. Set to `false` for blocks that should be unique (e.g., a homepage hero). |
**Special field for parent blocks:** If your block restricts which blocks can be inserted as children, you can add an `allowedBlocks` key at the top level of `block.json` (not inside `supports`). The Buttons block does this:
```json
{
"name": "acf/buttons",
"title": "Buttons (VDI)",
"description": "A button or group of buttons.",
"allowedBlocks": ["acf/button"],
"category": "vdi-blocks",
...
}
```
### The PHP Template -- Rendering the Block
The PHP template is responsible for outputting the block's HTML. Every template follows the same structure:
```php
<?php
/**
* Block Name: Boilerplate
*
* This is the template for building your own custom blocks.
*
* @package BasicWP
*/
namespace BasicWP;
$classes = 'boilerplate';
/**
* NOTE: DO NOT remove this function call - it is required to avoid editor issues.
* $is_preview is a WordPress global when in the editor.
*/
$wrapper = blockWrapperAttributes( $classes, $is_preview );
?>
<section <?php echo wp_kses_post( $wrapper ); ?>>
<!-- Your block code will go here -->
</section>
```
**Key elements explained:**
1. **`namespace BasicWP;`** -- Every block template must declare this namespace. It gives you access to the theme's helper functions (`blockWrapperAttributes`, `getFieldValue`, etc.) without needing fully-qualified class names.
2. **`$is_preview`** -- This is a WordPress global variable that is `true` when the block is being rendered inside the block editor, and `false` on the frontend. You can use it to conditionally show editor-only content or adjust markup for the editor.
3. **`blockWrapperAttributes()`** -- This helper function (defined in `lib/helpers.php`) generates the wrapper attributes for the block's root element. It handles the difference between editor preview mode and the frontend:
- In preview mode (`$is_preview` is `true`): returns a simple `class="my-class"` string, which avoids rendering issues in the editor.
- On the frontend (`$is_preview` is `false`): returns the full `get_block_wrapper_attributes()` output, which includes WordPress-generated classes and attributes for alignment, anchor, custom class names, etc.
**Always use `blockWrapperAttributes()` instead of calling `get_block_wrapper_attributes()` directly.** The direct call can cause rendering problems in the editor.
4. **`wp_kses_post()`** -- Always wrap the wrapper attributes output with `wp_kses_post()` for security. This sanitizes the output while preserving the HTML attributes that `blockWrapperAttributes()` generates.
5. **Semantic HTML wrapper** -- Use a semantic element like `<section>`, `<article>`, `<aside>`, or `<div>` as the outermost element. The block's wrapper attributes (classes, anchor, alignment) must go on this outermost element.
### The CSS File -- Scoped Styles
Each block has its own CSS file that is loaded automatically by WordPress when the block is present on the page. This means styles are only loaded when needed, keeping page weight minimal.
The CSS filename must match the block slug and be referenced in `block.json` using the `file:./` prefix:
```json
"style": ["file:./testimonial.css"]
```
You can use Tailwind utility classes directly in your PHP templates (e.g., `class="flex gap-4 p-6"`), and they will work as long as the Tailwind build process can detect them. For complex or block-specific styles that are not expressible as utility classes, write them in the block's CSS file using the BEM-like naming convention:
```css
/* testimonial.css */
.testimonial {
/* Block-level styles */
}
.testimonial__quote {
/* Element styles */
}
.testimonial__quote--large {
/* Modifier styles */
}
```
The file can be empty initially and filled in as needed.
---
## Helper Functions
The theme provides several helper functions in `lib/helpers.php`, all under the `BasicWP` namespace. Because every block template declares `namespace BasicWP;`, you can call these functions directly without any prefix.
### blockWrapperAttributes()
```php
function blockWrapperAttributes( $classes, $is_preview )
```
**Purpose:** Generates the HTML attributes string for a block's root element, handling the difference between the editor and the frontend.
**Parameters:**
- `$classes` (string) -- A space-separated list of CSS class names to apply to the block wrapper.
- `$is_preview` (bool) -- Whether the block is being rendered in the editor. Always pass the global `$is_preview` variable.
**Returns:** A string of HTML attributes ready to echo inside an HTML tag.
**How it works:**
- When `$is_preview` is `true` (in the editor), it returns `class="my-class"`. This is a simplified output that avoids rendering issues caused by WordPress's `get_block_wrapper_attributes()` in the editor context.
- When `$is_preview` is `false` (on the frontend), it calls WordPress's `get_block_wrapper_attributes()` with your classes merged in, producing the full set of attributes including alignment classes, anchor IDs, custom class names from the editor, and more.
**Usage pattern:**
```php
$classes = 'my-block some-tailwind-class';
$wrapper = blockWrapperAttributes( $classes, $is_preview );
?>
<section <?php echo wp_kses_post( $wrapper ); ?>>
<!-- block content -->
</section>
```
**Important:** Never call `get_block_wrapper_attributes()` directly. Always use `blockWrapperAttributes()` instead. Direct calls can cause the block to render incorrectly in the editor.
### getFieldValue()
```php
function getFieldValue( $field_path )
```
**Purpose:** Retrieves nested values from ACF option fields (Global Fields) using dot notation.
**Parameters:**
- `$field_path` (string) -- A dot-notated path to the value. For example, `'contact_info.phone'` retrieves the `phone` subfield from the `contact_info` options page field.
**Returns:** The value at the specified path, or an empty string if the path does not exist.
**How it works:** The function splits the path on `.`, calls `get_field()` with the first segment and `'option'` as the second parameter (which tells ACF to look in the options table), then traverses the remaining segments through the nested array.
**Usage example:**
```php
// Instead of:
$phone = get_field( 'contact_info', 'option' )['phone'];
// You can write:
$phone = getFieldValue( 'contact_info.phone' );
```
This is cleaner and avoids "undefined index" errors when subfields are missing.
### escEmbeds()
```php
function escEmbeds()
```
**Purpose:** Returns an array of allowed HTML elements and attributes for safely outputting embed content (like YouTube or Vimeo iframes). Use this with `wp_kses()` when rendering embed blocks.
**Usage example:**
```php
echo wp_kses( $video_embed_html, escEmbeds() );
```
---
## ACF Field Groups
After creating your block's three files, you need to create an ACF field group in the WordPress admin. This defines the fields that editors fill in when editing the block.
### Creating a Field Group
1. In WordPress admin, go to **Custom Fields > Add New**.
2. Give the field group a descriptive name (e.g., "Testimonial Fields").
3. Add your fields using the ACF interface. Common field types include:
- **Text** -- Single-line text input (for headings, names, etc.)
- **Textarea** -- Multi-line text (for body copy, quotes, etc.)
- **Image** -- Image selector (returns an array with `url`, `alt`, `sizes`, etc.)
- **Select** -- Dropdown menu for predefined options
- **True/False** -- Checkbox toggle (useful for conditional display logic)
- **Repeater** -- Repeatable groups of fields (for lists, slides, etc.)
- **Link** -- URL + title + target picker
- **WYSIWYG** -- Rich text editor
4. Set the **location rule** to: **Block > is equal to > [Your Block Name]**. This tells ACF to show these fields when editing your block.
5. Click **Save** or **Publish**.
### JSON Sync
The theme's `ACF` class (in `lib/class-acf.php`) configures custom save and load paths for ACF JSON:
```php
class ACF {
public $path;
public function __construct() {
$this->path = get_stylesheet_directory() . '/acf';
add_filter( 'acf/settings/load_json', array( $this, 'loadJson' ) );
add_filter( 'acf/settings/save_json', array( $this, 'saveJson' ) );
}
public function saveJson( $path ) {
return $this->path;
}
public function loadJson( $paths ) {
return array( $this->path );
}
}
```
This means:
- When you save a field group in the admin, ACF writes a JSON file to the `acf/` directory in the theme root.
- When ACF loads field groups, it reads from the same `acf/` directory.
- These JSON files are version-controlled, so field group configurations travel with the codebase and sync across environments.
**Important:** After saving a field group, you will see a new JSON file appear in the `acf/` directory. Commit this file to version control so other environments receive the field group definition.
---
## Parent-Child Block Patterns (InnerBlocks)
Some blocks act as containers that hold other blocks. WordPress provides `<InnerBlocks />` for this purpose, and ACF blocks can use it too.
### Basic InnerBlocks
To allow any block to be inserted inside your block, simply add `<InnerBlocks />` to your template:
```php
<section <?php echo wp_kses_post( $wrapper ); ?>>
<InnerBlocks />
</section>
```
This is what the Section block does -- it wraps its children in a container div:
```php
<section <?php echo wp_kses_post( $wrapper ); ?> style="<?php echo esc_attr( $styles ); ?>">
<?php if ( $contentWidth === 'full' ) : ?>
<InnerBlocks />
<?php else : ?>
<div class="container content-wrapper">
<InnerBlocks />
</div>
<?php endif; ?>
</section>
```
### Restricted InnerBlocks
You can restrict which blocks are allowed inside your block using the `allowedBlocks` prop on `<InnerBlocks />`. This creates a parent-child relationship where only specific block types can be inserted.
The Buttons block only allows Button blocks:
```php
<div id="<?php echo esc_attr( $block['id'] ); ?>" <?php echo esc_attr( $wrapper ); ?>>
<InnerBlocks className="<?php echo esc_attr( $ibClasses ); ?>" />
</div>
```
And its `block.json` enforces this at the registration level:
```json
{
"allowedBlocks": ["acf/button"],
...
}
```
The Grid block restricts children to Grid Cell blocks:
```php
$allowedBlocks = array( 'acf/grid-cell' );
```
### Enabling InnerBlocks in block.json
For InnerBlocks to work, you must enable JSX support in your block's `supports` configuration:
```json
"supports": {
"jsx": true,
...
}
```
Without `"jsx": true`, the block editor will not render the InnerBlocks area.
### Adding Classes to InnerBlocks
You can pass a `className` prop to `<InnerBlocks />` to style the inner block container:
```php
<InnerBlocks className="<?php echo esc_attr( $ibClasses ); ?>" />
```
Or with allowedBlocks:
```php
<InnerBlocks allowedBlocks={['acf/button']} className="flex gap-4" />
```
---
## Tailwind CSS in Blocks
This theme uses Tailwind CSS v4 with the `@tailwindcss/cli` package. The configuration is handled entirely through CSS, not through a `tailwind.config.js` file.
### How Tailwind is Set Up
The entry point is `styles/theme.css`, which imports Tailwind and all the theme's stylesheets:
```css
/* Tailwind setup */
@import "tailwindcss";
/* Base styles */
@import "./base/index.css";
@import "./navigation/index.css";
/* ... more imports ... */
/* Blocks */
@import "./blocks/index.css";
/* Import Tailwind typography plugin */
@plugin "@tailwindcss/typography";
```
### Using Tailwind Classes in Blocks
You can use Tailwind utility classes directly in your block PHP templates. The build process scans PHP files for class names and includes the corresponding CSS.
For example, the Homepage Hero block uses Tailwind classes extensively:
```php
$classes = 'homepage-hero mx-break-out bg-black bg-cover bg-no-repeat text-light py-12 lg:py-16 overflow-hidden';
```
And the Buttons block:
```php
$ibClasses = 'flex flex-wrap gap-4 w-full justify-center sm:justify-start';
```
### Whitelisting Editor-Only Classes
Some Tailwind classes are used only in the WordPress block editor (for example, classes applied through the editor's UI that do not appear anywhere in the theme's PHP or CSS source files). Because Tailwind's content scanning only finds classes in source files, these editor-applied classes would be purged from the final CSS.
To prevent this, add editor-only classes to `whitelist.php`. This file contains HTML `<span>` elements with the classes that Tailwind should always include:
```php
<!-- whitelist.php -->
<span class="grid"></span>
<span class="grid-cols-1"></span>
<span class="grid-cols-2"></span>
<!-- ... more classes ... -->
```
The whitelist is primarily used for grid and layout classes that the Grid block applies dynamically through ACF field values (since those class names are generated at runtime, not hardcoded in templates).
### Block-Specific CSS Files
Each block's CSS file (referenced in `block.json` via `"style": ["file:./block-name.css"]`) is loaded automatically by WordPress only when that block is present on the page. This keeps the CSS payload minimal. You can write both custom CSS and use Tailwind's `@apply` directive in these files.
Additionally, some blocks share styles that are imported globally. The `styles/blocks/index.css` file imports styles for blocks that need to be available more broadly (such as button styles that apply across multiple blocks).
---
## Step-by-Step: Creating a New Block
This walkthrough demonstrates creating a "Testimonial" block from scratch.
### 1. Create the Block Directory
Create a new folder under `views/blocks/` using a lowercase, hyphenated slug:
```
views/blocks/testimonial/
```
The directory name becomes the block's slug and must match the filenames of the PHP and CSS files inside it.
### 2. Create block.json
Create `views/blocks/testimonial/block.json`:
```json
{
"name": "acf/testimonial",
"title": "Testimonial",
"description": "A customer testimonial with quote, name, and role.",
"style": ["file:./testimonial.css"],
"category": "vdi-blocks",
"icon": "format-quote",
"keywords": ["testimonial", "quote", "review"],
"acf": {
"mode": "preview",
"renderTemplate": "testimonial.php"
},
"supports": {
"align": true,
"anchor": true,
"color": true,
"html": false,
"jsx": false,
"mode": true,
"multiple": true
}
}
```
**Checklist for `block.json`:**
- `name` starts with `acf/`
- `category` is set to `vdi-blocks`
- `style` references the CSS file with the `file:./` prefix
- `acf.renderTemplate` matches the PHP filename exactly
- `supports.html` is `false` (ACF blocks should not support HTML editing)
- `supports.jsx` is `false` unless the block uses InnerBlocks
### 3. Create the PHP Template
Create `views/blocks/testimonial/testimonial.php`:
```php
<?php
/**
* Block Name: Testimonial
*
* A customer testimonial with quote, name, and role.
*
* @package BasicWP
*/
namespace BasicWP;
$classes = 'testimonial';
$wrapper = blockWrapperAttributes( $classes, $is_preview );
// Retrieve ACF fields
$quote = get_field( 'quote' );
$name = get_field( 'name' );
$role = get_field( 'role' );
$image = get_field( 'image' );
?>
<section <?php echo wp_kses_post( $wrapper ); ?>>
<blockquote class="testimonial__quote">
<?php echo wp_kses_post( $quote ); ?>
</blockquote>
<div class="testimonial__author">
<?php if ( $image ) : ?>
<img
src="<?php echo esc_url( $image['url'] ); ?>"
alt="<?php echo esc_attr( $image['alt'] ); ?>"
class="testimonial__image"
>
<?php endif; ?>
<div class="testimonial__info">
<cite class="testimonial__name"><?php echo esc_html( $name ); ?></cite>
<?php if ( $role ) : ?>
<span class="testimonial__role"><?php echo esc_html( $role ); ?></span>
<?php endif; ?>
</div>
</div>
</section>
```
**Checklist for the PHP template:**
- Always start with `namespace BasicWP;`
- Always call `blockWrapperAttributes( $classes, $is_preview )` and assign it to `$wrapper`
- Always echo `$wrapper` inside the root element with `wp_kses_post()`
- Use `get_field()` to retrieve ACF field values
- Use `getFieldValue()` for nested option fields
- Escape all output: `wp_kses_post()` for HTML content, `esc_html()` for plain text, `esc_url()` for URLs, `esc_attr()` for HTML attributes
- Use semantic HTML elements (`<section>`, `<blockquote>`, `<cite>`, etc.)
- Follow BEM-like naming for CSS classes: `.block`, `.block__element`, `.block__element--modifier`
### 4. Create the CSS File
Create `views/blocks/testimonial/testimonial.css`. It can start empty or with basic structure:
```css
/* Testimonial block styles */
.testimonial {
/* Block-level styles */
}
.testimonial__quote {
/* Quote styles */
}
.testimonial__author {
/* Author layout */
}
.testimonial__image {
/* Avatar styles */
}
.testimonial__info {
/* Author info layout */
}
.testimonial__name {
/* Name styles */
}
.testimonial__role {
/* Role styles */
}
```
If you are using Tailwind utility classes in the PHP template, you may not need much custom CSS. The file still needs to exist and be referenced in `block.json` so WordPress can load it.
### 5. Create ACF Field Groups in WordPress Admin
1. Log in to the WordPress admin dashboard.
2. Go to **Custom Fields > Add New**.
3. Enter a title: "Testimonial Fields".
4. Add the following fields:
| Field Label | Field Name | Field Type | Notes |
|---|---|---|---|
| Quote | `quote` | Textarea | The testimonial text |
| Name | `name` | Text | The customer's name |
| Role | `role` | Text | The customer's role or title (optional) |
| Image | `image` | Image | The customer's photo (optional) |
5. Under **Location**, set the rule: **Block is equal to Testimonial**. ACF will auto-detect the block name from your `block.json`.
6. Click **Save** or **Publish**.
After saving, ACF will write a JSON file to the `acf/` directory in the theme root. This file should be committed to version control.
### 6. Build and Verify
If you used Tailwind utility classes in your block template, run the build process:
```bash
npm run build
```
Then verify the block appears in the editor:
1. Edit a page in the WordPress block editor.
2. Open the inserter and look under **VDI Custom Blocks**.
3. You should see "Testimonial" with the quote icon.
4. Insert the block and fill in the fields.
5. Save and preview the page on the frontend to confirm rendering works correctly.
---
## Real-World Examples from This Theme
### Simple Block: Homepage Hero
The Homepage Hero is a straightforward block that retrieves ACF fields and renders them with Tailwind classes. It does not use InnerBlocks.
**Key patterns:**
- Retrieves multiple ACF fields with `get_field()`
- Conditionally renders sections only when fields have values (`! empty( $heading )`)
- Uses Tailwind classes extensively for layout and styling
- Handles editor vs. frontend differences for link URLs
```php
// Retrieve ACF fields
$heading = get_field( 'heading' );
$intro = get_field( 'intro' );
$ctas = get_field( 'calls_to_action' );
$classes = 'homepage-hero mx-break-out bg-black bg-cover bg-no-repeat text-light py-12 lg:py-16 overflow-hidden';
$wrapper = blockWrapperAttributes( $classes, $is_preview );
?>
<section <?php echo wp_kses_post( $wrapper ); ?>>
<div class="container content-wrapper">
<div class="max-w-lg sm:text-center lg:text-left lg:items-center ml-0">
<?php if ( ! empty( $heading ) ) : ?>
<h1 class="text-4xl lg:text-5xl font-bold leading-tight mb-4">
<?php echo esc_html( $heading ); ?>
</h1>
<?php endif; ?>
<!-- ... more content ... -->
</div>
</div>
</section>
```
### Parent Block with InnerBlocks: Section
The Section block is a container that wraps its child blocks with optional background styling. It demonstrates conditional rendering based on ACF fields.
**Key patterns:**
- Builds CSS class strings dynamically based on field values
- Builds inline `style` strings from field values
- Conditionally renders an overlay div
- Conditionally wraps InnerBlocks in a container div based on the `content_width` field
- Uses `blockWrapperAttributes()` with dynamic classes
```php
// Retrieve ACF fields
$contentWidth = get_field( 'content_width' );
$isDark = get_field( 'is_dark' );
$bgColor = get_field( 'background_color' );
$bgImage = get_field( 'background_image' );
// Build classes dynamically
$classes = 'section';
if ( $contentWidth === 'full' ) {
$classes .= ' mx-break-out';
}
if ( $isDark ) {
$classes .= ' dark text-light';
}
if ( $bgColor || $bgImage ) {
$classes .= ' has-background bg-no-repeat';
}
// Build inline styles
$styles = '';
if ( $bgColor ) {
$styles .= "background-color: $bgColor;";
}
if ( $bgImage ) {
$styles .= ' background-image: url(' . esc_url( $bgImage['url'] ) . ');';
}
$wrapper = blockWrapperAttributes( $classes, $is_preview );
?>
<section <?php echo wp_kses_post( $wrapper ); ?> style="<?php echo esc_attr( $styles ); ?>">
<?php if ( $ovlColor || $ovlImage ) : ?>
<div aria-hidden="true" class="section-overlay absolute inset-0" style="<?php echo esc_attr( $overlayStyles ); ?>"></div>
<?php endif; ?>
<?php if ( $contentWidth === 'full' ) : ?>
<InnerBlocks />
<?php else : ?>
<div class="container content-wrapper">
<InnerBlocks />
</div>
<?php endif; ?>
</section>
```
### Restricted Parent Block: Buttons
The Buttons block is a container that only allows Button blocks as children. It enforces this restriction through both `block.json` and the template.
**Key patterns:**
- Uses `allowedBlocks` in `block.json` to restrict children to `acf/button`
- Sets `"jsx": true` in `supports` to enable InnerBlocks
- Passes Tailwind classes to InnerBlocks via the `className` prop
- Sets `"align": false` and `"color": false` since styling comes from child Button blocks
```json
{
"name": "acf/buttons",
"allowedBlocks": ["acf/button"],
"supports": {
"align": false,
"jsx": true
}
}
```
```php
$ibClasses = 'flex flex-wrap gap-4 w-full justify-center sm:justify-start';
$classes = 'align-with-content my-[1.2em]';
$wrapper = blockWrapperAttributes( $classes, $is_preview );
?>
<div id="<?php echo esc_attr( $block['id'] ); ?>" <?php echo esc_attr( $wrapper ); ?>>
<InnerBlocks className="<?php echo esc_attr( $ibClasses ); ?>" />
</div>
```
Note: The Buttons block uses `esc_attr()` instead of `wp_kses_post()` for the wrapper because the `<div>` tag is not inside a `<section>` -- both approaches are valid, but `wp_kses_post()` is preferred for the main block wrapper.
### Dynamic Parent Block: Grid
The Grid block builds CSS classes dynamically from ACF field values (columns, breakpoints, gaps). This is a case where runtime-generated class names need to be whitelisted.
**Key patterns:**
- Dynamically constructs Tailwind class names from field values (e.g., `'grid-cols-' . get_field( 'columns' )`)
- Uses `$block['anchor']` and `$block['className']` for editor-set attributes
- These dynamic class names are added to `whitelist.php` so Tailwind includes them in the build
```php
$allowedBlocks = array( 'acf/grid-cell' );
$gridClasses = 'grid grid-cols-' . get_field( 'columns' );
// Add breakpoint-specific column classes
if ( $colBPs ) {
foreach ( $colBPs as $bp ) {
$gridClasses .= ' ' . $bp . ':grid-cols-' . get_field( 'columns_' . $bp );
}
}
// Add gap classes
if ( $gapX ) {
$gridClasses .= ' gap-x-' . $gapX;
}
if ( $gapY ) {
$gridClasses .= ' gap-y-' . $gapY;
}
$classes = trim( $className . ' ' . $gridClasses );
?>
<div id="<?php echo esc_attr( $anchor ); ?>">
<InnerBlocks className="<?php echo esc_attr( $classes ); ?>" />
</div>
```
Because the class names like `grid-cols-3` and `md:grid-cols-4` are generated at runtime from field values (not hardcoded in PHP templates), Tailwind cannot detect them through content scanning. That is why `whitelist.php` explicitly lists all possible grid column and gap classes.
### Block Using Global Fields: Contact Info
The Contact Info block demonstrates how to access ACF options page data (Global Fields) using `getFieldValue()`.
**Key patterns:**
- Uses `get_field( 'contact_info', 'option' )` to retrieve the options page field group, then accesses sub-fields with array syntax
- Alternatively, could use `getFieldValue( 'contact_info.phone' )` for the same result
- Combines static content from Global Fields with dynamic InnerBlocks content (a contact form)
```php
namespace BasicWP;
$classes = 'contact-info';
$wrapper = blockWrapperAttributes( $classes, $is_preview );
?>
<section <?php echo esc_attr( $wrapper ); ?>>
<div class="flex flex-col lg:flex-row">
<div class="w-full lg:w-1/2 p-6">
<h2 class="text-2xl font-bold mb-4">Contact Information</h2>
<p><?php echo wp_kses_post( get_field( 'contact_info', 'option' )['address'] ); ?></p>
<p><a href="mailto:<?php echo esc_html( get_field( 'contact_info', 'option' )['email'] ); ?>">
<?php echo esc_html( get_field( 'contact_info', 'option' )['email'] ); ?>
</a></p>
<p><a href="tel:<?php echo esc_html( get_field( 'contact_info', 'option' )['phone'] ); ?>">
<?php echo esc_html( get_field( 'contact_info', 'option' )['phone'] ); ?>
</a></p>
</div>
<div class="w-full lg:w-1/2 p-6">
<InnerBlocks />
</div>
</div>
</section>
```
---
## Common Pitfalls and Best Practices
### Do
- **Always use `namespace BasicWP;`** at the top of every block PHP template. Without it, helper functions like `blockWrapperAttributes()` and `getFieldValue()` will not be available.
- **Always use `blockWrapperAttributes()`** for the root element's attributes. Never call `get_block_wrapper_attributes()` directly.
- **Always escape output.** Use `wp_kses_post()` for HTML content, `esc_html()` for plain text, `esc_url()` for URLs, and `esc_attr()` for HTML attribute values.
- **Always set `category` to `vdi-blocks`** in `block.json` so your block appears under "VDI Custom Blocks" in the editor.
- **Always prefix `name` with `acf/`** in `block.json` (e.g., `"acf/testimonial"`, not just `"testimonial"`).
- **Always set `supports.html` to `false`** in `block.json` for ACF blocks. ACF blocks use PHP templates, not HTML editing.
- **Always set `supports.jsx` to `true`** if your block uses `<InnerBlocks />`. Without this, the InnerBlocks area will not render.
- **Commit ACF JSON files** from the `acf/` directory to version control after creating field groups.
- **Use semantic HTML elements** as block wrappers (`<section>`, `<article>`, `<aside>`, `<nav>`, etc.) instead of generic `<div>` elements where appropriate.
- **Use BEM-like naming** for custom CSS classes: `.block-name`, `.block-name__element`, `.block-name__element--modifier`.
- **Add dynamic Tailwind classes to `whitelist.php`** if they are generated from ACF field values rather than hardcoded in templates.
### Do Not
- **Do not call `get_block_wrapper_attributes()` directly.** Always use `blockWrapperAttributes()` instead. Direct calls cause rendering issues in the editor.
- **Do not edit the `boilerplate` directory.** It is excluded from registration and serves as a reference template. Copy its files to a new directory instead.
- **Do not forget to create the CSS file** referenced in `block.json`. Even if the file is empty, WordPress needs it to exist. If the file is missing, WordPress may throw an error when loading the block.
- **Do not use `'option'` directly with `get_field()` for nested values without null checking.** Prefer `getFieldValue()` which handles missing values gracefully.
- **Do not set `supports.multiple` to `false`** unless the block truly must be unique per page (like a homepage hero). Most blocks should allow multiple instances.
- **Do not hardcode editor-only Tailwind classes in PHP templates** without adding them to `whitelist.php`. If a class only appears in the editor's UI (like grid column classes set via ACF fields), Tailwind will not include it in the build.
- **Do not use the `style` attribute on the block's root element alongside `blockWrapperAttributes()` for background colors** unless the block specifically needs it. WordPress's built-in color supports (enabled via `supports.color`) handle this automatically.
### Debugging Tips
- If a block does not appear in the editor, check that `block.json` is valid JSON and that the `name` field starts with `acf/`.
- If ACF fields do not show up when editing a block, verify the field group's location rule is set to "Block is equal to [Your Block Name]".
- If styles are not loading, confirm the `style` array in `block.json` uses the `file:./` prefix and the CSS filename matches exactly.
- If Tailwind classes are not applying on the frontend, run `npm run build` and check that the classes are either in your templates or in `whitelist.php`.
- If InnerBlocks are not rendering, confirm `"jsx": true` is set in the block's `supports` configuration.
docs/getting-started.md
+589
View File
@@ -0,0 +1,589 @@
# Getting Started with VDI-Starter-v5
This guide walks you through setting up a local development environment for the VDI-Starter-v5 WordPress theme from scratch. It covers prerequisites, installation, configuration, and common development workflows.
---
## Table of Contents
1. [Overview](#overview)
2. [Prerequisites](#prerequisites)
3. [Setting Up a Local WordPress Environment](#setting-up-a-local-wordpress-environment)
4. [Installing the Theme](#installing-the-theme)
5. [Environment Configuration](#environment-configuration)
6. [Building Assets](#building-assets)
7. [Activating the Theme](#activating-the-theme)
8. [Development Workflow](#development-workflow)
9. [Project Architecture](#project-architecture)
10. [Creating Custom ACF Blocks](#creating-custom-acf-blocks)
11. [Testing](#testing)
12. [Code Quality](#code-quality)
13. [Troubleshooting](#troubleshooting)
---
## Overview
VDI-Starter-v5 is a minimal WordPress theme designed as a starting point for custom theme development. It uses a modern stack:
- **Tailwind CSS v4** for utility-first styling, compiled via the Tailwind CLI
- **ACF Pro** for custom field management and block registration
- **WordPress Script Modules** (`wp_enqueue_script_module`) for JavaScript, requiring WordPress 6.5+
- **BrowserSync** for live-reloading during development
- **Playwright** for end-to-end accessibility testing
- **PHP_CodeSniffer** with WordPress coding standards for linting
The theme intentionally avoids heavyweight frameworks. Every PHP file in `lib/` is loaded automatically via `functions.php`, which means you add a new file to `lib/` and it is included -- no manual `require` statements needed.
---
## Prerequisites
Before you begin, make sure the following tools are installed on your machine.
| Tool | Minimum Version | Why It Is Needed |
|-------------|-----------------|------------------------------------------------------------------------------------------------------|
| Node.js | 22+ | Tailwind CSS v4 CLI requires a modern Node runtime. Older versions will fail during `npm run build`. |
| npm | Latest (bundled with Node) | Package management for JavaScript dependencies and build scripts. |
| PHP | 8.0+ | WordPress core requirement and theme compatibility. |
| Composer | 2.x | Installs PHP_CodeSniffer with WordPress coding standards for linting. |
| WordPress | 6.5+ | The theme uses `wp_enqueue_script_module()`, which was introduced in WordPress 6.5. |
| ACF Pro | Latest | All custom blocks depend on ACF Pro. Blocks will not register without it. |
### Checking Your Versions
Run these commands to verify your environment:
```bash
node --version # Should be v22 or higher
npm --version # Any recent version is fine
php --version # Should be 8.0 or higher
composer --version # Should be 2.x
```
If any of these commands fail, install the missing tool before proceeding.
---
## Setting Up a Local WordPress Environment
You need a running WordPress instance before you can activate or test the theme. Choose one of these options based on your preference and operating system.
### Option A: Local by Flywheel (Recommended for macOS/Windows)
Local by Flywheel (often just called "Local") is the easiest way to get a WordPress site running on macOS or Windows.
1. Download and install [Local](https://localwp.com/).
2. Click **Create a new site** and follow the prompts.
3. Choose **Preferred** environment (NGINX, PHP 8.x, MySQL 8.x).
4. Once the site is created, note the local URL (e.g., `https://vdi-starter.local`).
5. Click **WP Admin** to open the WordPress dashboard.
The site URL from Local is what you will put in your `.env` file as `LOCALHOST_URL`.
### Option B: DevKinsta (Windows/macOS/Linux)
DevKinsta is Kinsta's free local development tool. It is a good choice if your production site is hosted on Kinsta because you can push/pull databases directly.
1. Download and install [DevKinsta](https://kinsta.com/devkinsta/).
2. Create a new custom WordPress site.
3. Note the local URL (typically `http://localhost:xxxxx`).
### Option C: Docker (Any OS)
Docker gives you the most control and works on any operating system, but it requires more manual setup.
1. Install [Docker Desktop](https://www.docker.com/products/docker-desktop/).
2. Use the official `wordpress` Docker image with a custom theme mount. A minimal `docker-compose.yml` might look like:
```yaml
version: '3.8'
services:
db:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
volumes:
- db_data:/var/lib/mysql
wordpress:
image: wordpress:latest
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
- ./themes/vdi-starter-v5:/var/www/html/wp-content/themes/vdi-starter-v5
depends_on:
- db
volumes:
db_data:
```
3. Run `docker compose up -d` and visit `http://localhost:8080` to complete the WordPress installation wizard.
---
## Installing the Theme
### Step 1: Clone the Repository
```bash
git clone https://github.com/Vincent-Design-Inc/VDI-Starter-v5.git
cd VDI-Starter-v5
```
If you are contributing to an existing project, clone it into your local WordPress `wp-content/themes/` directory so WordPress can detect it:
```bash
cd /path/to/your/local-wp-site/wp-content/themes/
git clone https://github.com/Vincent-Design-Inc/VDI-Starter-v5.git
```
If you cloned it elsewhere, you can symlink it into the themes directory:
```bash
# macOS/Linux
ln -s /path/to/VDI-Starter-v5 /path/to/wp-content/themes/vdi-starter-v5
# Windows (run in an elevated Command Prompt)
mklink /D "C:\path\to\wp-content\themes\vdi-starter-v5" "C:\path\to\VDI-Starter-v5"
```
Using a symlink means your local edits are immediately reflected in WordPress without copying files.
### Step 2: Install PHP Dependencies
```bash
composer install
```
This installs PHP_CodeSniffer and the WordPress Coding Standards (WPCS) ruleset. These are dev dependencies used for linting, not runtime dependencies, but they are required for `composer lint` and `composer fix` to work.
### Step 3: Install JavaScript Dependencies
```bash
npm install
```
This installs the frontend build toolchain: Tailwind CSS v4 and its CLI, BrowserSync, Playwright, dotenv, and other utilities. Tailwind v4 uses the `@tailwindcss/cli` package directly (no `tailwind.config.js` file is needed -- configuration lives in `styles/theme.css`).
### Step 4: Configure Environment Variables
Copy the example environment file and edit it:
```bash
cp .env.example .env
```
Open `.env` and set the two variables:
| Variable | Description | Example Value |
|-------------------|-----------------------------------------------------------------------------------------------|------------------------------|
| `LOCALHOST_URL` | The full URL of your local WordPress site, including the scheme (`http` or `https`) | `https://vdi-starter.local` |
| `BROWSERSYNC_PORT`| The port BrowserSync should listen on. Defaults to `5000` if not set. | `5000` |
The `LOCALHOST_URL` must match exactly what your local WordPress environment responds to. If you are using Local by Flywheel with SSL enabled, include `https://`. If you are using Docker on port 8080, use `http://localhost:8080`.
BrowserSync proxies this URL and injects a live-reload script, so any change you make to PHP templates, CSS, or JS files will automatically refresh the browser.
### Step 5: Build Assets for the First Time
Before activating the theme, compile the Tailwind CSS so the theme has its stylesheet:
```bash
npm run build
```
This runs:
```
npx @tailwindcss/cli -i ./styles/theme.css -o ./static/dist/theme.css --optimize
```
It reads `styles/theme.css` (the entry point that imports all sub-stylesheets and the Tailwind framework), compiles all utility classes, and writes the output to `static/dist/theme.css`. The `--optimize` flag minifies the output for production.
The `static/dist/` directory is where WordPress loads the compiled stylesheet from. The theme's `Enqueue` class (`lib/class-enqueue.php`) checks for `static/dist/theme.css` and enqueues it with a file-mtime version string for cache busting.
> **Why build before activating?** If the compiled CSS file does not exist, the theme will still activate, but the frontend will be completely unstyled. The `Enqueue` class only enqueues `theme.css` if the file exists on disk -- it does not fail gracefully with a fallback, it simply does not load any stylesheet.
---
## Activating the Theme
Log into your local WordPress admin dashboard and navigate to **Appearance > Themes**. You should see **VDI Starter v5** listed. Click **Activate**.
> **CRITICAL WARNING: What happens on activation**
>
> When this theme is activated on a fresh WordPress install, `lib/activation.php` automatically performs the following actions. Read this list carefully before activating on an existing site:
>
> - **Creates 4 default pages:** Home, News, Page Not Found (Error 404), and Contact Us.
> - **Sets WordPress to use a static front page:** Home becomes the front page, News becomes the posts page. This overrides any existing "Reading Settings".
> - **Deletes the default "Hello World" post** (ID 1) and the **sample page** (ID 2). These are trashed permanently (`wp_delete_post` with `$force_delete = true`).
> - **Installs 7 plugins** from external URLs and selectively activates them:
> 1. **ACF Pro** -- installed and activated (from `https://docs.vincentdevelopment.ca/files/advanced-custom-fields-pro.zip`)
> 2. **Gravity Forms** -- installed and activated (from `https://docs.vincentdevelopment.ca/files/gravity-forms.zip`)
> 3. **UpdraftPlus** -- installed, NOT activated (from WordPress.org)
> 4. **Simple History** -- installed and activated (from WordPress.org)
> 5. **The SEO Framework** -- installed and activated (from WordPress.org)
> 6. **Better Search Replace** -- installed and activated (from WordPress.org)
> 7. **Google Site Kit** -- installed, NOT activated (from WordPress.org)
> - **Creates an "Owner" role** (administrator capabilities minus plugin/theme management).
> - **Writes an installation log** to `wp-content/mu-plugin-install.log`.
>
> **Do NOT activate this theme on an existing production site without reviewing `lib/activation.php` first.** The activation routine is designed for fresh installs and will modify pages, settings, and plugin state without confirmation.
### Optional: Import Sample Content
If you want test content (posts, pages, etc.) to work with, the repository includes a WordPress XML export file:
```bash
# In WordPress admin: Tools > Import > WordPress > Run Importer
# Upload: content/basic-wp-test-content.xml
```
This gives you sample pages and posts to verify that templates and blocks render correctly.
---
## Development Workflow
### Starting the Dev Server
```bash
npm run start
# or equivalently:
npm run watch
```
This runs `bin/.watch.js`, which starts BrowserSync and watches for file changes. When you edit a `.php` or `.css` file, BrowserSync:
1. Detects the change.
2. Recompiles Tailwind CSS (using the same `@tailwindcss/cli` command, but without `--optimize` so it is faster).
3. Reloads the browser.
When you edit a `.js` file in `static/js/`, BrowserSync injects the updated script without a full page reload (hot injection).
The dev server is accessible at the `LOCALHOST_URL` you configured, proxied through the `BROWSERSYNC_PORT`. For example, if your `.env` has `LOCALHOST_URL=https://vdi-starter.local` and `BROWSERSYNC_PORT=5000`, your dev URL is `https://vdi-starter.local` with BrowserSync overlay on port 5000.
### Building for Production
Before deploying or pushing changes that affect styles, always run:
```bash
npm run build
```
This compiles Tailwind CSS with `--optimize` enabled, which minifies the output and removes unused styles. The result is written to `static/dist/theme.css`.
> **Why not use `npm run watch` output for production?** The watch mode compiles Tailwind without optimization for speed. Production builds are significantly smaller because `--optimize` removes unused utility classes and minifies the CSS.
---
## Project Architecture
Understanding the directory layout helps you know where to find things and where to put new files.
```
VDI-Starter-v5/
├── acf/ # ACF Pro field group JSON (auto-synced)
│ └── group_*.json # One file per field group
├── bin/
│ ├── .watch.js # BrowserSync dev server script
│ └── .utils.js # Shared build utilities (Tailwind compilation)
├── content/
│ └── basic-wp-test-content.xml # Sample content for testing
├── docs/ # Documentation (this guide lives here)
├── lib/ # PHP utility classes (auto-loaded)
│ ├── activation.php # Theme activation routine (pages, plugins, settings)
│ ├── class-acf.php # ACF JSON load/save path configuration
│ ├── class-breadcrumbs.php # Breadcrumb navigation helper
│ ├── class-enqueue.php # Frontend/backend/editor asset enqueueing
│ ├── class-menuitems.php # Custom menu item handling
│ ├── class-resources.php # Resource management
│ ├── extras.php # Miscellaneous helper functions
│ ├── helpers.php # Template helper functions
│ ├── hooks.php # Theme hooks (menus, sidebars, cleanup, SVG uploads)
│ ├── search-features.php # Enhanced search functionality
│ └── show-template.php # Template debugging (shows which template is loaded)
├── static/
│ ├── dist/
│ │ └── theme.css # Compiled Tailwind output (generated, do not edit)
│ ├── img/ # Theme images
│ └── js/
│ ├── admin.js # Backend/editor JavaScript
│ ├── theme.js # Frontend JavaScript (loaded as a script module)
│ ├── components/ # JS components loaded as script modules
│ │ ├── backToTop.js
│ │ ├── button.js
│ │ ├── GetHeaderHeight.js
│ │ ├── Navigation.js
│ │ └── TagExternalLinks.js
│ └── modules/ # JS modules
├── styles/
│ ├── theme.css # Tailwind entry point (imports all sub-stylesheets)
│ ├── base/ # Base/reset styles and break-out utilities
│ ├── backend/ # Admin and editor styles (admin.css, editor.css)
│ ├── blocks/ # Per-block styles
│ ├── components/ # Reusable component styles
│ ├── fonts/ # Icon font (Lineicons)
│ └── navigation/ # Navigation styles
├── views/
│ └── blocks/ # ACF block definitions (block.json + template)
│ ├── accordion/
│ ├── boilerplate/ # Starter template for new blocks (excluded from registration)
│ ├── button/
│ ├── buttons/
│ ├── contact-info/
│ ├── grid/
│ ├── grid-cell/
│ ├── homepage-hero/
│ ├── media-text/
│ ├── media-text-innerblocks/
│ ├── page-children/
│ └── section/
├── tests/
│ └── site-a11y.spec.js # Playwright accessibility tests
├── .env.example # Environment variable template
├── composer.json # PHP dependencies (PHPCS + WPCS)
├── functions.php # Theme bootstrap (loads all lib/*.php files, registers ACF blocks)
├── package.json # Node dependencies and build scripts
├── playwright.config.js # Playwright test configuration
├── style.css # WordPress theme metadata header
├── theme.json # WordPress theme.json (colors, typography, layout settings)
└── whitelist.php # Playwright whitelist for testing
```
### How Auto-Loading Works
`functions.php` loads every PHP file in `lib/` using a glob pattern:
```php
foreach ( glob( __DIR__ . '/lib/*.php' ) as $filename ) {
include_once $filename;
}
```
This means adding a new file to `lib/` automatically includes it. No manual `require` statements are needed. However, be aware that files are loaded in alphabetical order. If one file depends on something defined in another, you may need to rename files with numeric prefixes to control load order.
### How ACF Blocks Are Registered
The `regACFBlocks()` function in `functions.php` scans the `views/blocks/` directory at runtime:
```php
function regACFBlocks() {
define( 'BLOCKS_DIR', get_stylesheet_directory() . '/views/blocks' );
if ( is_dir( BLOCKS_DIR ) ) {
foreach ( scandir( BLOCKS_DIR ) as $folder ) {
if ( ( '.' !== $folder && '..' !== $folder && 'boilerplate' !== $folder ) && is_dir( BLOCKS_DIR . '/' . $folder ) ) {
register_block_type( BLOCKS_DIR . '/' . $folder );
}
}
}
}
add_action( 'init', __NAMESPACE__ . '\\regACFBlocks', 5 );
```
Each subdirectory that contains a `block.json` file is registered as a Gutenberg block. The `boilerplate` directory is explicitly excluded -- it is a starter template for creating new blocks, not a block itself.
### How Stylesheets Are Organized
The Tailwind entry point is `styles/theme.css`. It imports sub-stylesheets using CSS `@import` directives:
```css
@import "tailwindcss"; /* Tailwind v4 framework */
@import "./base/index.css"; /* Base styles */
@import "./navigation/index.css";/* Navigation styles */
@import "./fonts/lineicons.css"; /* Icon font */
@import "./base/break-out.css"; /* Break-out utility */
@import "./components/index.css";/* Component styles */
@import "./blocks/index.css"; /* Block-specific styles */
@plugin "@tailwindcss/typography"; /* Typography plugin */
```
When you create a new block or component, add its styles to the appropriate subdirectory and make sure it is imported through the corresponding `index.css` file.
---
## Creating Custom ACF Blocks
To create a new ACF block, use the `boilerplate` directory as a starting point:
1. Copy `views/blocks/boilerplate/` to a new directory with your block name (use lowercase, hyphen-separated):
```bash
cp -r views/blocks/boilerplate views/blocks/my-block
```
2. Edit `views/blocks/my-block/block.json`:
- Change `"name"` to `"acf/my-block"`
- Change `"title"` to a human-readable name like `"My Block (VDI)"`
- Update `"description"`, `"icon"`, and `"keywords"` as appropriate
- If this block should only be nested inside another block, add a `"parent"` array (see `button/block.json` for an example)
3. Edit the PHP template file (`my-block.php`) to render your block's HTML. ACF fields are available via `get_fields()`.
4. If the block needs ACF field groups, create them in the WordPress admin under **Custom Fields > Field Groups** and associate them with the block. ACF will save the field group JSON to the `acf/` directory, which you should commit to version control.
5. Add block-specific styles in `styles/blocks/` and import them through `styles/blocks/index.css`.
The block will be automatically discovered and registered on the next page load because `regACFBlocks()` scans the directory on every `init` hook.
---
## Testing
### Playwright Accessibility Tests
The theme includes a Playwright configuration for end-to-end testing, with accessibility checks powered by `@axe-core/playwright`.
To set up Playwright for the first time:
```bash
npx playwright install
```
This downloads the browser binaries. Then run the tests:
```bash
npx playwright test
```
The test suite lives in `tests/site-a11y.spec.js`. By default, Playwright is configured to test against Chromium only (see `playwright.config.js`). You can uncomment other browser projects (Firefox, WebKit, mobile viewports) as needed.
If you want to initialize Playwright from scratch with all browsers:
```bash
npm init playwright@latest --yes "--" . '--quiet' '--browser=chromium' '--browser=firefox' '--browser=webkit' '--lang=js'
```
> **Note:** Playwright tests need a running WordPress instance to test against. Make sure your local environment is up and the theme is activated before running tests. You may also need to set a `baseURL` in `playwright.config.js` to point to your local site.
---
## Code Quality
### PHP Linting
Run PHP_CodeSniffer against the WordPress coding standards:
```bash
composer lint
```
This runs `phpcs` with the ruleset defined in `.phpcs.xml` and writes results to `phpcs-results.txt`. Fix violations manually, or use the auto-fixer:
```bash
composer fix
```
This runs `phpcbf` (PHP Code Beautifier and Fixer) to automatically correct fixable violations. Always run `composer lint` after `composer fix` to verify that remaining issues are intentional.
---
## Troubleshooting
### CSS Is Not Compiling or Styles Are Missing
**Symptom:** The frontend loads but looks completely unstyled, or changes you made to Tailwind classes are not appearing.
**Solution:** Run `npm run build`. The theme loads CSS from `static/dist/theme.css`, which is a compiled file. If this file does not exist (e.g., after a fresh clone), nothing will be styled. If you added new utility classes and they are not appearing, the file may be stale -- rebuild it.
The compilation pipeline is: `styles/theme.css` (entry point with `@import` directives) --> Tailwind CLI --> `static/dist/theme.css` (output).
### ACF Blocks Are Not Appearing in the Editor
**Symptom:** The block inserter in the Gutenberg editor does not show custom blocks like "Homepage Hero" or "Section".
**Solution:** ACF Pro must be installed and activated. Blocks are registered by scanning `views/blocks/*/block.json` on the `init` hook. Without ACF Pro, `register_block_type()` still runs, but ACF blocks require the ACF plugin to provide field data and rendering.
Also check that:
- The block directory contains a valid `block.json` file.
- The block directory is not named `boilerplate` (this is excluded by design).
- ACF Pro is activated (not just installed).
### Menus Are Not Rendering
**Symptom:** Navigation menus appear empty or show a fallback message.
**Solution:** The theme registers three menu locations in `lib/hooks.php`:
- **Main Navigation** (`main_navigation`)
- **Auxiliary Navigation** (`aux_navigation`)
- **Footer Navigation** (`footer_navigation`)
You must assign menus to these locations manually. Go to **Appearance > Menus** in WordPress admin, create a menu, and check the appropriate "Display Location" checkbox.
### JavaScript Is Not Loading
**Symptom:** Interactive features like the mobile navigation toggle or back-to-top button do not work.
**Solution:** The theme uses `wp_enqueue_script_module()`, which was introduced in WordPress 6.5. If you are running an older version of WordPress, script modules will not be loaded. Verify your WordPress version is 6.5 or higher.
You can check by looking at the page source for `<script type="module">` tags. If they are absent, your WordPress version likely does not support script modules.
### BrowserSync Is Not Connecting
**Symptom:** Running `npm run watch` starts BrowserSync but the browser does not auto-refresh on file changes.
**Solution:** Check these common issues:
1. **Wrong `LOCALHOST_URL`:** The URL in `.env` must exactly match your local WordPress site URL, including the scheme (`http` vs `https`) and any port numbers. Open the URL directly in a browser first to confirm it loads.
2. **Port conflict:** If another service is using port 5000, BrowserSync will fail to start or behave unpredictably. Change `BROWSERSYNC_PORT` in `.env` to an available port (e.g., `3000` or `8080`).
3. **SSL certificates:** If your local site uses HTTPS with a self-signed certificate (common with Local by Flywheel), BrowserSync may reject the connection. The `bin/.watch.js` configuration does not currently set `https: true` or `cert`/`key` paths, so BrowserSync proxies over HTTP by default. If your WordPress site forces HTTPS, you may need to adjust the BrowserSync configuration in `bin/.watch.js`.
4. **Firewall:** Ensure your firewall allows connections on the BrowserSync port.
### Plugin Installation Failures on Theme Activation
**Symptom:** Some or all plugins fail to install when the theme is activated.
**Solution:** The activation routine in `lib/activation.php` downloads plugin ZIP files from external URLs. Failures can occur if:
- Your local environment does not have internet access.
- The download URLs have changed (check the URLs in the source code).
- The `WP_CONTENT_DIR` directory is not writable.
- WordPress filesystem credentials are required but not available (the routine forces `direct` filesystem access, which may not work on all server configurations).
Check `wp-content/mu-plugin-install.log` for detailed error messages. Each plugin installation step logs success or failure with a timestamp.
### Tailwind Utility Classes Not Appearing in Output
**Symptom:** You added a Tailwind class to a template (e.g., `bg-blue-500`) but it does not appear in the compiled CSS.
**Solution:** Tailwind CSS v4 uses a content detection approach by default, scanning your template files for class names. Make sure the file containing the class is within the theme directory and uses a recognized extension (`.php`, `.html`, `.js`, etc.). If you are using dynamic class names (concatenating strings or storing classes in variables), Tailwind may not be able to detect them. In that case, use a Tailwind `@source` directive in your CSS or add the class to a safelist.
---
## Quick Reference
| Command | Purpose |
|---------------------|--------------------------------------------------------------------|
| `npm run start` | Start BrowserSync dev server with live reload (alias for `watch`) |
| `npm run watch` | Start BrowserSync dev server with live reload |
| `npm run build` | Compile Tailwind CSS for production (minified, optimized) |
| `composer lint` | Run PHP_CodeSniffer against WordPress coding standards |
| `composer fix` | Auto-fix PHP_CodeSniffer violations |
| `npx playwright test` | Run Playwright end-to-end tests |
| File | Purpose |
|-----------------------------------|------------------------------------------------------|
| `.env` | Local environment config (`LOCALHOST_URL`, `BROWSERSYNC_PORT`) |
| `styles/theme.css` | Tailwind CSS entry point (edit this to add imports) |
| `static/dist/theme.css` | Compiled CSS output (generated, do not edit manually)|
| `views/blocks/*/block.json` | ACF block registration files |
| `lib/activation.php` | Theme activation routine (creates pages, installs plugins) |
| `lib/class-enqueue.php` | Frontend/backend/editor asset loading |
| `lib/hooks.php` | Menu registration, sidebars, theme support, cleanup |
| `functions.php` | Theme bootstrap (auto-loads all `lib/*.php` files) |
| `theme.json` | WordPress theme configuration (colors, typography, layout) |
| `acf/group_*.json` | ACF field group definitions (version-controlled) |
docs/reference.md
+557
View File
@@ -0,0 +1,557 @@
# VDI-Starter-v5 Theme Reference
> Quick-lookup reference for the VDI-Starter-v5 WordPress theme. Covers hooks, filters, design tokens, CSS architecture, JS modules, helper functions, class APIs, CLI commands, deployment, and testing.
---
## Table of Contents
- [Hooks and Filters](#hooks-and-filters)
- [hooks.php (BasicWP Namespace)](#hooksphp-basicwp-namespace)
- [extras.php](#extrasphp)
- [helpers.php](#helpersphp)
- [class-enqueue.php](#class-enqueuephp)
- [class-breadcrumbs.php](#class-breadcrumbsphp)
- [class-resources.php](#class-resourcesphp)
- [theme.json Design Tokens](#themejson-design-tokens)
- [Colors](#colors)
- [Font Sizes](#font-sizes)
- [Font Family](#font-family)
- [Layout](#layout)
- [Spacing Units](#spacing-units)
- [CSS Architecture](#css-architecture)
- [Import Order](#import-order)
- [Adding a New Stylesheet](#adding-a-new-stylesheet)
- [JS Module Dependency Graph](#js-module-dependency-graph)
- [Script Module IDs](#script-module-ids)
- [Navigation Class API](#navigation-class-api)
- [Helper Functions](#helper-functions)
- [Class Reference](#class-reference)
- [CLI Commands](#cli-commands)
- [Deployment (GitHub Actions)](#deployment-github-actions)
- [Testing](#testing)
---
## Hooks and Filters
### hooks.php (BasicWP Namespace)
All hooks in this file live under the `BasicWP` namespace.
| Hook | Type | Priority | Args | Description |
|------|------|----------|------|-------------|
| `wp_head` | Action | 0 | — | Adds Google Fonts `<link rel="preconnect">` tags |
| `register_nav_menus()` | Direct call | — | — | Registers three menus: `main_navigation`, `aux_navigation`, `footer_navigation` |
| `widgets_init` | Action | — | — | Registers four sidebars: `sidebar-primary`, `sidebar-page`, `footer-1`, `footer-2`, `footer-3` |
| `wp_title` | Filter | — | — | Formats page titles as `Site Name: Page Title` |
| `excerpt_more` | Filter | — | — | Replaces default excerpt ellipsis with `&hellip;` |
| `include_page_title_in_hero` | Filter | — | — | Removes page title from hero section on single posts |
| `init` | Action | 1 | — | Aggressive WP cleanup and theme support registration (see below) |
| `wp_check_filetype_and_ext` | Filter | 10 | 4 | Allows SVG uploads (fix for WP 4.7.1 filetype check) |
| `upload_mimes` | Filter | — | — | Adds `svg` mime type (`image/svg+xml`) |
| `admin_head` | Action | — | — | Injects CSS to fix SVG display in the admin area |
| `wp_mail_from` | Filter | — | — | Sets the `From` email address to the admin email |
| `wp_mail_from_name` | Filter | — | — | Sets the `From` name to the blog name |
**The `init` (priority 1) hook performs aggressive cleanup:**
Removes:
- Emoji detection and styles (`remove_action` on `wp_head`)
- Block library styles (`wp-block-library`)
- Global styles (`global-styles`)
- REST API link tag from `wp_head`
- REST API link tag from `template_redirect`
- XML-RPC link (`rsd_link`)
- WP generator tag (`wp_generator`)
- WLW manifest link (`wlwmanifest_link`)
Adds theme supports:
- `post-thumbnails`
- `title-tag`
- `html5` (search-form, comment-form, comment-list, gallery, caption, style, script)
- `align-wide`
- `editor-styles`
- `responsive-embeds`
- `customize-selective-refresh-widgets`
---
### extras.php
| Hook / Filter | Type | Description |
|---------------|------|-------------|
| `hasSidebar` | Filter | Controls sidebar display based on an ACF true/false field on the current page |
| `body_class` | Filter | Appends `has-sidebar` class to `<body>` when a sidebar is present |
| `the_content` | Filter | `divWrapper()` wraps `<iframe>` and embed elements in `<div class="embed">` |
| `acf/include_fields` | Action | Registers "Page Sidebar" ACF field group (a true/false toggle for pages) |
| `init` | Action | `createOwnerRole()` creates the Owner role on every init |
**Owner role details:** The Owner role is equivalent to Administrator minus plugin management, theme management, and core update capabilities.
---
### helpers.php
| Hook / Filter | Type | Priority | Args | Description |
|---------------|------|----------|------|-------------|
| `custom_menu_order` | Filter | 10 | 1 | Enables custom admin menu ordering |
| `menu_order` | Filter | 10 | 1 | Defines the custom admin menu order |
| `block_categories_all` | Filter | 10 | — | Adds the `vdi-blocks` category to the block editor |
| `init` | Action | — | — | Registers the ACF "Global Fields" options page |
---
### class-enqueue.php
| Hook | Type | Method | Description |
|------|------|--------|-------------|
| `wp_enqueue_scripts` | Action | `enqFEAssets()` | Loads frontend CSS and JS |
| `admin_enqueue_scripts` | Action | `enqBEAssets()` | Loads admin CSS and JS |
| `enqueue_block_editor_assets` | Action | `enqEditorAssets()` | Loads block editor CSS |
---
### class-breadcrumbs.php
The `Breadcrumbs` class generates Schema.org-compatible breadcrumb markup. Context-specific methods:
| Method | Context |
|--------|---------|
| `getHomeBreadcrumb()` | Site front page |
| `getBlogPostsIndexBreadcrumb()` | Blog posts index |
| `getSinglePostBreadcrumbs()` | Single post |
| `getCustomPostTypeBreadcrumbs()` | Custom post type single |
| `getStaticPageBreadcrumbs()` | Static page |
| `getTaxonomyArchiveBreadcrumb()` | Taxonomy archive |
| `getPostTypeArchiveBreadcrumb()` | Post type archive |
| `getDateArchiveBreadcrumbs()` | Date archive (day/month/year) |
| `getSearchBreadcrumb()` | Search results |
| `get404Breadcrumb()` | 404 page |
---
### class-resources.php
| Hook | Type | Description |
|------|------|-------------|
| `init` | Action | Registers the `resources` custom post type |
| `post_type_link` | Filter | Customizes resource permalinks to `/resources/{term-slug}/{post-name}` |
The `resources` CPT uses a URL rewrite pattern that incorporates the first taxonomy term slug into the permalink path.
---
## theme.json Design Tokens
### Colors
All theme colors map to CSS custom properties. Use the CSS variable in your stylesheets or reference the slug in the block editor.
| Slug | CSS Variable | Name | Value |
|------|-------------|------|-------|
| `black` | — | Black | `#000` |
| `white` | — | White | `#fff` |
| `theme-bg` | `var(--color-background)` | Theme Background | Dynamic |
| `theme-text` | `var(--color-text)` | Theme Text | Dynamic |
| `theme-primary` | `var(--color-primary)` | Theme Primary | Dynamic |
| `theme-secondary` | `var(--color-secondary)` | Theme Secondary | Dynamic |
| `theme-bodylinks` | `var(--color-bodylinks)` | Theme Body Links | Dynamic |
| `theme-footerlinks` | `var(--color-footlinks)` | Theme Footer Links | Dynamic |
| `theme-success` | `var(--color-success)` | Theme Success | Dynamic |
| `theme-warning` | `var(--color-warning)` | Theme Warning | Dynamic |
| `theme-danger` | `var(--color-danger)` | Theme Danger | Dynamic |
| `theme-info` | `var(--color-info)` | Theme Info | Dynamic |
The dynamic colors (`theme-*`) resolve to CSS custom properties that can be overridden per-site in the customizer or ACF options pages. The static colors (`black`, `white`) are literal hex values.
**Usage example in CSS:**
```css
.my-element {
color: var(--color-primary);
background-color: var(--color-background);
}
```
**Usage in a block template:**
```html
<div class="has-theme-primary-color has-theme-bg-background-color">
...
</div>
```
---
### Font Sizes
| Slug | CSS Variable | Name |
|------|-------------|------|
| `base` | `var(--text-base)` | Base |
| `text-14px` | `var(--text-14px)` | Text 14px |
| `text-16px` | `var(--text-16px)` | Text 16px |
| `text-18px` | `var(--text-18px)` | Text 18px |
| `text-20px` | `var(--text-20px)` | Text 20px |
| `text-22px` | `var(--text-22px)` | Text 22px |
| `text-25px` | `var(--text-25px)` | Text 25px |
| `text-30px` | `var(--text-30px)` | Text 30px |
| `text-35px` | `var(--text-35px)` | Text 35px |
| `text-38px` | `var(--text-38px)` | Text 38px |
| `text-40px` | `var(--text-40px)` | Text 40px |
| `text-45px` | `var(--text-45px)` | Text 45px |
| `text-50px` | `var(--text-50px)` | Text 50px |
| `text-70px` | `var(--text-70px)` | Text 70px |
| `text-75px` | `var(--text-75px)` | Text 75px |
**Usage example in CSS:**
```css
.hero-title {
font-size: var(--text-50px);
}
```
**Usage in a block template:**
```html
<p class="has-text-50px-font-size">Big headline text</p>
```
---
### Font Family
| Slug | CSS Variable | Name |
|------|-------------|------|
| `theme-sans` | `var(--font-sans)` | Theme Sans |
```css
body {
font-family: var(--font-sans);
}
```
---
### Layout
| Setting | Value |
|---------|-------|
| `contentSize` | `100%` |
| `wideSize` | `1536px` |
These control the WordPress block editor content width and wide-alignment width.
---
### Spacing Units
Available spacing units for the block editor spacing scale:
`px`, `em`, `rem`, `vh`, `vw`, `%`
---
## CSS Architecture
The entry point is `styles/theme.css`. All imports use the CSS `@import` syntax processed by Tailwind CSS v4.
### Import Order
```
styles/theme.css
|
+-- @import "tailwindcss" # Tailwind CSS v4 base
|
+-- @import "./base/index.css" # Base styles
| +-- break-out.css
| +-- colors.css
| +-- forms.css
| +-- global.css
| +-- misc.css
| +-- prose.css
| +-- skip-link.css
| +-- typography.css
|
+-- @import "./navigation/index.css" # Navigation styles
| +-- nav-aux.css
| +-- nav-footer.css
| +-- nav-functional.css
| +-- nav-main-default.css
| +-- nav-main-mega.css
| +-- nav-mobile-accordion.css
| +-- nav-mobile-sliding.css
|
+-- @import "./fonts/lineicons.css" # Icon font
|
+-- @import "./base/break-out.css" # Break-out utilities (repeated for cascade)
|
+-- @import "./components/index.css" # Component styles
| +-- breadcrumbs.css
| +-- pagination.css
| +-- post-list.css
| +-- sidebar.css
| +-- site-footer.css
| +-- site-header.css
|
+-- @import "./blocks/index.css" # Block styles
| +-- buttons.css
| +-- core.css
|
+-- @plugin "@tailwindcss/typography" # Tailwind prose plugin
```
### Adding a New Stylesheet
1. Create the `.css` file in the appropriate directory (`base/`, `navigation/`, `components/`, or `blocks/`).
2. Add an `@import` line to that directory's `index.css`.
Example -- adding a new `cards.css` component:
```css
/* styles/components/index.css */
@import "cards.css";
```
```css
/* styles/components/cards.css */
.card {
/* styles here */
}
```
---
## JS Module Dependency Graph
```
theme.js (entry point)
├── Navigation.js # Mobile menu, sliding viewport, keyboard nav
├── backToTop.js # BackToTopButton custom element
├── button.js # ButtonComponent custom element, registerButtonComponent
├── GetHeaderHeight.js # Sets --header-height CSS variable
└── TagExternalLinks.js # Adds target="_blank" rel="noopener" to external links
admin.js
└── button.js # ButtonComponent for editor context
```
### Script Module IDs
WordPress registers these script modules via `wp_register_script_module()`:
| Module ID | Source | Dependencies |
|-----------|--------|--------------|
| `basicwp-theme` | `theme.js` | None |
| `basicwp-button` | `button.js` | `basicwp-theme` |
| `basicwp-admin` | `admin.js` | `basicwp-button` |
**Loading in a template:**
```php
wp_enqueue_script_module('basicwp-theme');
wp_enqueue_script_module('basicwp-button');
```
---
## Navigation Class API
The `Navigation` class is located at `static/js/modules/Navigation.js`.
### Constructor
```js
const nav = new Navigation(toggleId, menuSelector);
// toggleId: ID of the hamburger toggle button (e.g., 'menu-toggle')
// menuSelector: CSS selector for the nav menu container (e.g., '.nav-main')
```
### Methods
| Method | Description |
|--------|-------------|
| `desktopMenuDropdowns()` | Enables dropdown menus for desktop navigation |
| `mobileMenuToggle()` | Toggles the mobile hamburger menu open/closed |
| `initializeSlidingViewport()` | Sets up the sliding mobile menu structure |
| `navigateToLevel(level)` | Navigates the sliding menu to a specific depth level |
| `navigateBack()` | Goes back one level in the sliding menu |
| `animateToLevel(level)` | Animates the sliding transition to a target depth level |
| `resetSlidingNavigation()` | Resets sliding nav to the root level |
| `cleanupSlidingStructure()` | Removes sliding nav DOM elements (cleanup/teardown) |
| `createBackButton(label)` | Creates a back button element for the sliding menu |
| `setupSlidingClickHandlers()` | Attaches click handlers for sliding menu items |
| `shouldEnableSlidingViewport()` | Returns `true` if the current viewport width warrants the sliding menu |
**Usage example:**
```js
import Navigation from './modules/Navigation.js';
const nav = new Navigation('menu-toggle', '.nav-main');
nav.desktopMenuDropdowns();
nav.mobileMenuToggle();
nav.initializeSlidingViewport();
```
---
## Helper Functions
| Function | File | Signature | Description |
|----------|------|-----------|-------------|
| `getFieldValue` | helpers.php | `getFieldValue($field_path)` | Retrieves nested ACF values using dot notation. E.g., `getFieldValue('contact_info.phone')` resolves `get_field('contact_info', 'option')['phone']`. Uses `'option'` for Global Fields. |
| `blockWrapperAttributes` | helpers.php | `blockWrapperAttributes($classes, $is_preview)` | Returns block wrapper attributes. In preview mode returns `class="..."`; on frontend returns `get_block_wrapper_attributes()`. |
| `customMenuOrder` | helpers.php | `customMenuOrder($menu_ord)` | Customizes WordPress admin menu order. |
| `blockCategories` | helpers.php | `blockCategories($categories)` | Adds the `vdi-blocks` category to the block editor. |
| `consoleLog` | helpers.php | `consoleLog($data)` | Outputs data to the browser console via `<script>console.log()</script>`. |
| `customExcerpt` | helpers.php | `customExcerpt($text, $number_of_words, $more)` | Generates custom excerpts that end at sentence boundaries instead of mid-sentence. |
| `escEmbeds` | helpers.php | `escEmbeds()` | Returns an allowed HTML array for iframe/embed content (used with `wp_kses`). |
| `strposArray` | helpers.php | `strposArray($haystack, $needles, $offset)` | Finds the position of the first occurrence of any needle from an array. |
| `getChildrenPages` | extras.php | `getChildrenPages()` | Gets child pages of the current page, sorted by `menu_order`. |
| `hasSidebar` | extras.php | `hasSidebar()` | Checks if the current page should render a sidebar (controlled by ACF field). |
| `hasPageHeader` | extras.php | `hasPageHeader()` | Checks if the page should render a page header (based on `hero_style` ACF field). |
| `createOwnerRole` | extras.php | `createOwnerRole()` | Creates the Owner role (admin minus plugin/theme/core management). Runs on every `init`. |
| `getTheTitle` | extras.php | `getTheTitle()` | Gets the appropriate title for the current context (home, single, archive, search, 404). |
| `divWrapper` | extras.php | `divWrapper($content)` | Wraps iframes and embeds in `<div class="embed">`. |
**Usage examples:**
```php
// Get a nested ACF option field
$phone = getFieldValue('contact_info.phone');
// Block wrapper attributes (works in both editor and frontend)
$attrs = blockWrapperAttributes('my-block-class', $is_preview);
echo '<div ' . $attrs . '>';
// Custom excerpt ending at sentence boundaries
$excerpt = customExcerpt(get_the_content(), 30, '...');
```
---
## Class Reference
| Class | File | Key Methods | Description |
|-------|------|-------------|-------------|
| `Enqueue` | `class-enqueue.php` | `enqFEAssets()`, `enqBEAssets()`, `enqEditorAssets()` | Manages all asset loading: frontend, admin, and editor |
| `ACF` | `class-acf.php` | `saveJson($path)`, `loadJson($paths)` | Sets ACF JSON save/load paths for field group synchronization |
| `Breadcrumbs` | `class-breadcrumbs.php` | `generate()`, `render()`, plus per-context methods (see below) | Generates Schema.org-compatible breadcrumb markup |
| `MenuItems` | `class-menuitems.php` | `render()` | Renders nav menu items using `$views . '/components/menu-items/index.php'` |
| `Resources` | `class-resources.php` | CPT registration, `postTypeLink` filter | Registers the `resources` CPT with custom permalink structure |
| `ShowTemplate` | `class-show-template.php` | HTML comment in footer | Adds an HTML comment to the footer showing the active template path (debugging) |
### Breadcrumbs Method Details
| Method | Returns | Description |
|--------|---------|-------------|
| `generate()` | `array` | Builds breadcrumb data array for the current context |
| `render()` | `string` | Outputs breadcrumb HTML with Schema.org markup |
| `getHomeBreadcrumb()` | `array` | Breadcrumb for the front page |
| `getBlogPostsIndexBreadcrumb()` | `array` | Breadcrumb for the blog posts index |
| `getSinglePostBreadcrumbs()` | `array` | Breadcrumbs for a single post (includes category) |
| `getCustomPostTypeBreadcrumbs()` | `array` | Breadcrumbs for a custom post type single |
| `getStaticPageBreadcrumbs()` | `array` | Breadcrumbs for a static page (includes parent pages) |
| `getTaxonomyArchiveBreadcrumb()` | `array` | Breadcrumb for a taxonomy archive |
| `getPostTypeArchiveBreadcrumb()` | `array` | Breadcrumb for a post type archive |
| `getDateArchiveBreadcrumbs()` | `array` | Breadcrumbs for date archives (day/month/year) |
| `getSearchBreadcrumb()` | `array` | Breadcrumb for search results |
| `get404Breadcrumb()` | `array` | Breadcrumb for 404 pages |
**Usage example:**
```php
$breadcrumbs = new Breadcrumbs();
echo $breadcrumbs->render();
```
---
## CLI Commands
| Command | Description |
|---------|-------------|
| `npm run build` | Compiles Tailwind CSS v4 from `styles/theme.css` to `static/dist/theme.css` with `--optimize` |
| `npm run start` | Starts BrowserSync dev server with live reloading (alias for `npm run watch`) |
| `npm run watch` | Runs `.watch.js` -- BrowserSync with CSS injection on changes |
| `composer lint` | Runs PHP_CodeSniffer against WordPress coding standards; outputs to `phpcs-results.txt` |
| `composer fix` | Auto-fixes PHPCS violations |
| `npx playwright test` | Runs Playwright accessibility tests |
| `npx playwright test --ui` | Opens Playwright interactive UI |
---
## Deployment (GitHub Actions)
The deployment workflow is defined in `.github/workflows/wpengine.yml`.
| Setting | Value |
|---------|-------|
| Trigger | `workflow_dispatch` (manual). Push to `main` trigger is commented out. |
| Skip condition | Commits containing `#skipGA` in the message are skipped |
| Target path | `wp-content/themes/vdi-v5` |
| WP Engine environment | `vdiv5` |
| SSH key secret | `WPE_SSHG_KEY_PRIVATE` |
### Deployment Steps
1. **Checkout** the repository
2. **Composer install** -- `composer install`
3. **npm install** -- `npm install`
4. **Build** -- `npm run build`
5. **Remove node_modules** -- deleted before deploy
6. **rsync** to WP Engine
### rsync Flags
```
-azvr --inplace --delete --exclude=".*"
```
| Flag | Meaning |
|------|---------|
| `-a` | Archive mode (preserve permissions, timestamps, etc.) |
| `-z` | Compress during transfer |
| `-v` | Verbose output |
| `-r` | Recursive |
| `--inplace` | Update files in-place on the target |
| `--delete` | Remove files on target that no longer exist in source |
| `--exclude=".*"` | Exclude dotfiles (e.g., `.git`, `.env`) |
---
## Testing
### Accessibility Tests
```bash
npx playwright test
```
Runs `tests/site-a11y.spec.js` using `@axe-core/playwright`. Tests scan pages for WCAG violations.
```bash
npx playwright test --ui
```
Opens the Playwright interactive UI for step-by-step test debugging.
### PHP Linting
```bash
composer lint
```
Runs PHP_CodeSniffer against WordPress coding standards. Results are written to `phpcs-results.txt`.
```bash
composer fix
```
Auto-fixes PHPCS violations where possible.
### Playwright Configuration
The Playwright config (`playwright.config.js`) is currently set to run on **Chromium only**. Firefox and WebKit browsers are commented out but available for enabling.