PHP Development
PHP Compatibility Features
Pitfall: Adding PHP features to the wrong directory. Rule: PHP features inlib/compat/ MUST target a specific wordpress-X.Y/ subdirectory.
- Determine the target WordPress version
- Create or use the appropriate
wordpress-X.Y/directory - Place your feature file there
Package Architecture
Private APIs in Bundled Packages
Pitfall: Using private APIs in packages that are distributed via npm. Rule: Avoid using private APIs in bundled packages (packages withoutwpScript or wpModuleExports).
Why: Bundled packages may be imported via npm into plugin scripts. Private APIs are intended for Core usage only and can cause incompatibilities.
package.json - if it lacks wpScript or wpModuleExports fields, it’s a bundled package.
block-editor Package Dependencies
Pitfall: Adding WordPress-specific dependencies to@wordpress/block-editor.
Rule: @wordpress/block-editor is a WordPress-agnostic package. NEVER add core-data dependencies or direct REST API calls to it.
block-editor package is designed to be reusable in non-WordPress contexts. Adding WordPress dependencies breaks this design.
Solution:
- Pass WordPress-specific data as props from higher layers (
editor,edit-post,edit-site) - Use the data registry pattern for extensibility
Build Tool Changes
Pitfall: Adding Gutenberg-specific features to@wordpress/scripts.
Rule: @wordpress/scripts is a generic build tool used both in Gutenberg and by plugins targeting WordPress Core directly. Avoid Gutenberg-specific changes in it.
@wordpress/scripts serves multiple communities:
- Gutenberg plugin developers
- WordPress Core contributors
- Third-party plugin and theme developers
Testing
Test Coverage Expectations
Pitfall: Assuming tests are optional. Rule: All code changes should include tests. Pull requests without tests may be delayed or rejected. Expected test types:- JavaScript changes: Unit tests or integration tests
- PHP changes: PHPUnit tests
- UI changes: E2E tests (when appropriate)
- New blocks: At least one fixture file per save function and deprecation
Prefixed Functions in Tests
Pitfall: Testing source functions instead of built functions in PHP. Rule: Test the built (prefixed) versions of functions, not the source versions. Why: Gutenberg’s build system prefixes PHP functions withgutenberg_ to avoid conflicts.
Code Quality
Linting and Formatting
Pitfall: Ignoring linting errors or inconsistent formatting. Rule: All formatting and linting issues are enforced through CI. Fix them before submitting.- Inconsistent indentation
- Missing semicolons
- Incorrect spacing
- Unused imports
Build Failures
Pitfall: Submitting PRs without ensuring the build passes. Rule: Ensure the build passes locally before pushing.- TypeScript errors
- Import/export mismatches
- Missing dependencies
- Circular dependencies
Accessibility
Accessibility Testing
Pitfall: Forgetting to test accessibility when making UI changes. Rule: Accessibility should be thoroughly tested for all UI changes. Test with:- Keyboard navigation (Tab, Enter, Escape, Arrow keys)
- Screen readers (NVDA, JAWS, VoiceOver)
- High contrast mode
- Reduced motion preferences
- Zoom at 200%
- Missing ARIA labels
- Keyboard traps
- Insufficient color contrast
- Missing focus indicators
- Non-semantic HTML
React Native Compatibility
Native File Synchronization
Pitfall: Forgetting to update.native.js files when renaming functions/classes.
Rule: Verify that changes affecting function/class/variable names are mirrored in corresponding .native.js versions.
Backward Compatibility
Breaking Changes
Pitfall: Introducing breaking changes without deprecation warnings. Rule: Follow the WordPress Backward Compatibility policy. For public APIs:- Add deprecation warning using
@wordpress/deprecated - Provide migration path
- Document in dev notes
- Maintain old API alongside new one
Block Deprecations
Pitfall: Changing block markup without providing a deprecation. Rule: If block markup changes, add a deprecated version.Pull Request Workflow
Commit Organization
Pitfall: Making a PR with poorly organized commits. Best practices:- Keep commits focused and atomic
- Write clear commit messages
- Squash WIP commits before requesting review
- Don’t mix unrelated changes
Keeping PRs Focused
Pitfall: Submitting large PRs with multiple unrelated changes. Rule: One feature or fix per PR. Benefits:- Easier to review
- Faster to merge
- Easier to revert if needed
- Clearer git history
Development Environment
wp-env Status
Pitfall: Running E2E/PHP tests without wp-env running. Rule: Always check wp-env status before running tests.Quick Reference Checklist
Before submitting a PR, verify:- PHP features target specific
wordpress-X.Y/directory - No private APIs in bundled packages
- No
core-datadependencies inblock-editor - No Gutenberg-specific changes in
@wordpress/scripts - Tests included and passing
- Testing built/prefixed PHP functions
- Build passes locally
- Linting and formatting pass
- Accessibility tested (for UI changes)
-
.native.jsfiles updated (if renaming) - Deprecation warnings added (for breaking changes)
- Block deprecations provided (if markup changed)
- wp-env running (for E2E/PHP tests)
Next Steps
- Review Architectural Decisions to understand design principles
- Check Coding Guidelines for style conventions
- See Testing Guide for testing requirements