- Run
npm installafter cloning to pull dev dependencies (includinglefthook). Git hooks rely on the binary that ships withnode_modules, so installing once per checkout is required. - Pre-commit and pre-push checks reuse scripts from the private
siteorigin-pre-commitrepository. SetSITEORIGIN_PRE_COMMIT_PATHto the absolute path of your clone so the hooks can find the shared scripts regardless of local layout.
-
Form elements and interactive components
- Input padding, button dimensions, form field spacing
- Reason: Should scale with user's font size for accessibility
-
Typography-related spacing that should scale
- Line spacing within text blocks
- Letter spacing (when relative scaling is desired)
- Reason: Maintains typographic rhythm across different font sizes
-
Component spacing that needs to scale with content
- Internal spacing within complex UI components
- Spacing between closely related text elements
- Reason: Maintains proportional relationships
-
User-facing spacing settings in FSE
- Spacing presets (margins, padding options)
- Block margins and padding
- Reason: Users understand "24px" better than "1.5rem"
-
Layout and grid spacing
- Container widths, content areas
- Grid gaps, column spacing
- Reason: Predictable, consistent layout structure
-
Font sizes
- All font size presets
- Reason: Theme already uses pixel-based font system
-
Borders and decorative elements
- Border widths, border radius
- Shadows, outlines
- Reason: Visual consistency regardless of font size
-
Fixed design elements
- Icon sizes, avatar dimensions
- Fixed-height components
- Reason: Maintain visual hierarchy and design intent
- Is this user-facing in the FSE? → Pixels (better UX)
- Should this scale with font size for accessibility? → REMs
- Is this a layout/structural element? → Pixels (predictable)
- Is this typography-related spacing? → Consider REMs
- Does the user need to understand the exact size? → Pixels
- Document the reasoning when choosing REMs in comments
- Always consider accessibility implications
- Test with different browser font sizes when using REMs
- Ensure consistency within similar component types
- Always use theme.json for styling instead of CSS when possible
- Maintain semantic color names (Primary, Secondary, Accent) rather than descriptive names
- Use consistent spacing scales - Our theme uses 8px increments (8px to 80px)
- Test with style variations - Ensure compatibility with dark.json and light.json
- Follow version 3 schema - Always use the latest theme.json version
- Use patterns over direct HTML in templates when possible
- Template parts should be modular and reusable across different templates
- Follow WordPress template hierarchy - Use proper naming conventions
- Include proper pattern headers - Hidden patterns need correct metadata
- Test template inheritance - Ensure fallback templates work correctly
- Extend blocks through variations rather than creating new blocks
- Use render_block filters for PHP-based modifications
- Follow WordPress coding standards for all PHP modifications
- Test block functionality in both editor and frontend contexts
- Document custom block styles in theme.json
- Create reusable patterns for common content structures
- Use semantic HTML in all pattern content
- Include accessibility attributes (aria-labels, proper heading hierarchy)
- Test patterns in different contexts - Various post types and templates
- Keep patterns focused - One clear purpose per pattern
- Minimize custom CSS - Leverage theme.json styling system
- Use local font files - Store in assets/fonts/ directory
- Optimize asset loading - Use wp_get_theme()->get('Version') for cache busting
- Test with caching plugins - Ensure compatibility
- Validate HTML output - Use semantic, valid markup
Before committing changes, ensure:
- Style variations work - Test with dark.json and light.json
- Responsive design functions across all viewport sizes
- Block editor compatibility - All blocks work in editor and frontend
- Accessibility compliance - Screen reader and keyboard navigation
- Cross-browser testing - Modern browser compatibility
- PHP compatibility - Test with minimum PHP 7.4
- PHP modifications go in
/inc/blocks/directory - JavaScript enhancements go in
/js/directory - Template parts go in
/parts/directory - Block patterns go in
/patterns/directory - Style variations go in
/styles/directory - Custom templates go in
/templates/directory
- Add proper file headers to all PHP and JS files
- Use @since 1.0 for version documentation
- Include @package siteorigin-snapshot in headers
- Comment complex logic - Explain the "why" not just the "what"
- Update contributing.md when adding new conventions