-
Notifications
You must be signed in to change notification settings - Fork 98
Contributing
We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.
To start, clone this repository into any WordPress install being used for development:
git clone [email protected]:GoogleChromeLabs/pwa-wp.git wp-content/plugins/pwa
cd wp-content/plugins/pwa
npm install
composer install
npm run build
For a development environment using wp-env, see https://github.com/GoogleChromeLabs/pwa-wp/pull/778
You may then just activate the plugin in the admin or via WP-CLI: wp plugin activate pwa
.
Your WordPress install must be configured to serve responses over HTTPS. Without this, your browser will refuse to install the service worker. The exception here is if your WordPress install is located at localhost
, in which case HTTPS is not required. But in general, WordPress development environments are often located at domains example.test
or example.local
, and for them:
- On Lando, see SSL/TLS.
- On VVV, see Setting Up HTTPS.
- On Local by Flywheel, installation of SSL certificates is supported in the UI.
- On Chassis, see Add and configure OpenSSL.
Pull requests will be checked against WordPress-Coding-Standards with PHPCS, and for JavaScript linting is done with ESLint. The pre-commit
hook will runs these tests will automatically prior to pushing.
To create a build of the plugin for installing in WordPress as a ZIP package, do:
npm run build
This will create an pwa.zip
in the plugin directory which you can install. The contents of this ZIP are also located in the build
directory which you can rsync
somewhere as well.
Please run these tests in an environment with WordPress unit tests installed, like VVV.
Run tests:
$ phpunit
Run tests with an HTML coverage report:
$ phpunit --coverage-html /tmp/report
When you push a commit to your PR, Travis CI will run the PHPUnit tests and sniffs against the WordPress Coding Standards.
Contributors who want to make a new release, follow these steps:
- Bump plugin versions in
pwa.php
(×2: the metadata block in the header and also thePWA_VERSION
constant), and theStable tag
inreadme.txt
. Verify vianpx grunt shell:verify_matching_versions
. - Run
npm install; docker run -it --rm --name composer-install -v "$PWD":/app -w /app php:8.0-cli-alpine sh -c "wget -O /tmp/composer.phar https://getcomposer.org/download/latest-2.x/composer.phar && php /tmp/composer.phar install"
- Do
npm run build
. - Install the
pwa.zip
onto a normal WordPress install running a stable release build; do smoke test to ensure it works. - (Optional) Draft blog post about the new release, presumably on Make/Core.
-
Draft new release on GitHub targeting the release branch, with the new plugin version as the tag and release title. Attaching the
pwa.zip
build to the release. Include link to changelog in release description. - Run
npm run deploy
to to commit the plugin to WordPress.org. - Open pending release verification email. Review changes in SVN.
- Publish GitHub release.
- Confirm the release on WordPress.org.
- Verify the release is available on WordPress.org; try installing it on a WordPress install and confirm it works.
- (Optional) Publish release blog post, including link to GitHub release.
- Close the GitHub milestone.
- For major releases, create a release branch (
x.y
). - Bump versions in
pwa.php
ondevelop
branch to next…-alpha
; do the same in the release branch. - Make announcements.
Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
The list of contributors who are featured on the WordPress.org plugin directory are subject to change over time. The organizations and individuals who contribute significantly and consistently (e.g. 3-month period) to the project are eligible to be listed. Those listed should generally be considered as those who take responsibility for the project (i.e. owners). Note that contributions include more than just code, though contributors who commit are most visible. The sort order of the contributors list should generally follow the sort order of the GitHub contributors page, though again, this order does not consider work in issues and the support forum, so it cannot be relied on solely.
This project follows Google's Open Source Community Guidelines.