Thank you for your interest in contributing. This document covers setting up a local environment, running the checks, and proposing a change.
This project follows the Automattic Code of Conduct.
- Node.js LTS or later
- Docker Desktop
- Composer
- Clone the repository.
- Install dependencies:
composer install npm -g install @wordpress/env
- Start the WordPress environment:
wp-env start
- Visit http://localhost:8888 and log in with
admin/password.
composer lint # PHP syntax
composer cs # Coding standards
composer test:unit # Unit tests (no WordPress needed)
composer test:integration # Integration tests (single site, needs wp-env)
composer test:integration-ms # Integration tests (multisite, needs wp-env)- Create a branch from
develop:git checkout develop git pull origin develop git checkout -b fix/short-description
- Make your change, with tests.
- Run the checks locally.
- Push your branch and open a pull request against
develop.
We follow the WordPress VIP Coding Standards, configured in .phpcs.xml.dist. Run composer cs-fix to fix what PHPCS can fix automatically.
Unit tests live in tests/Unit/ and run without WordPress. Integration tests live in tests/Integration/ and run inside wp-env.
- New behaviour should come with tests.
- A bug fix should come with a test that fails without the fix.
- Keep each pull request to one change, and explain what it does and why.
- Reference related issues, for example
Fixes #123. - Make sure CI passes before requesting a review.
- Sign your commits.
developandmainonly accept commits with a verified signature, so a pull request with an unsigned commit cannot be merged until it is re-signed and force-pushed. See GitHub's guide to signing commits.
Maintainers cut releases from a release/x.y.z branch into main. Pushing the version tag publishes a GitHub release with an installable ZIP attached, and stable releases (tags without a hyphen) are deployed to WordPress.org.