Template repo for WordPress plugin development that uses Composer to manage dependencies (along with package scoping to prevent collisions), a gulp workflow for development, external hosting via AWS, and automated releases through GitHub Actions. Also utilizes the WordPress Plugin Library to help structure plugin classes.
- Replace all the following values with your own namespace (recommended format:
Vendor\Namespace
)namespace WP_Plugin_Template
@package WP_Plugin_Template
use WP_Plugin_Template\...
NOTE: Basically find all instances of "WP_Plugin_Template" and replace with your custom "Vendor\Namespace" value.
- Update
composer.json
with your settings, paying special attention to the following keys:name
- Adjust to match your namespace, but lower-casedautoload.psr-4
- Adjust to match your namespaceextra.imposter.namespace
- Adjust to match your namespace (keep the "\Dependencies" tail)
- Update
package.json
and reset the version to1.0.0
(or whatever you want the initial version to be) - Update
.ci/data/changelog.yml
and remove allreleases
but one, and change thetag_name
andname
to reflect the version inpackage.json
- Update
.ci/data/plugin-info.yml
with your own information. - Update your project/repo's Secrets for use with GitHub Actions:
AWS_S3_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION
- Update the "Release" workflow (
./github/workflows/release.yml
) environment variables (lines 13-15):PLUGIN_SLUG
- Should matchslug
inplugin-info.yml
DOWNLOAD_URI
- Should matchdownload_uri
inplugin-info.yml
DEST_DIR
- Should be the relative path ofDOWNLOAD_URI
, e.g. -https://cdn.ccstatic.com/wordpress-plugins/wp-plugin-template/
would bewordpress-plugins/wp-plugin-template
(no leading or trailing slash!)
- Update
phpcs.xml
, specifically:minimum_supported_wp_version
testVersion
text_domain
(inWordPress.WP.I18n
)minimum_supported_version
(inWordPress.WP.DeprecatedFunctions
)prefixes
(inWordPress.NamingConventions.PrefixAllGlobals
)
- Add or remove any plugin ZIP files dependencies for local development to
.ci/plugins
- These should be "private" plugins that otherwise cannot be found through WP Admin, or the minimum supported version of required plugins
- Make sure to update the
"mappings"
or"plugins"
config in.wp-env.json
to point to the plugins (which will be unzipped into.plugins/
)
- Update this README.md file with your own info!
- Delete both
composer.lock
andpackage-lock.json
and then run the following:$ composer install $ npm install
NOTE: Make sure to commit the new
composer.lock
andpackage-lock.json
files that are generated! - Follow the Development and Release instructions below!
To install this plugin:
- Download the latest release from GitHub (the saved file should be named wp-plugin-template-{version}.zip).
- Go to the Plugins → Add New screen in the WordPress Admin.
- Click the Upload button at the top next to the "Add Plugins" title.
- Upload the zip file downloaded in the first step.
- Click the Activate Plugin link after installation completes.
This plugin uses @wordpress/env package for local development.
- Ensure Docker is installed and running.
- Clone this project to your local machine.
$ git clone git@github.com:screid123/wp-plugin-template.git
- Install NPM and Composer dependencies.
$ npm ci $ composer install
- Start the local development server.
$ npm start
- Navigate to http://localhost:8888 in your web browser to see WordPress running with the local WordPress plugin or theme running and activated.
- The plugin is not active by default! This is on purpose in order to help test any activation hooks. Log into the
WordPress Admin (http://localhost:8888/wp-admin/), navigate to the plugins menu and activate the plugin (install and
activate any other plugins desired as well).
NOTE: The default credentials are username:
admin
password:password
. - Start the webpack dev server to watch PHP, CSS and JS files for changes, and automatically recompile:
Press
$ npm run dev
Ctrl + C
to stop watching. - Stop the local development server when finished.
$ npm stop
- Update the
package.json
version number to the appropriate version (this project adheres to Semantic Versioning). - Update the
.ci/data/changelog.yml
file with the corresponding version and changes. Changelog updates are required for publishing a release.NOTE: If the
version
inpackage.json
does not match atag_name
inchangelog.yml
, the build will fail. - Run the release command to compile all files and generate corresponding markdown files (e.g. -
CHANGELOG.md
).$ npm run release
- Commit all changed files to your branch.
- Open a Pull Request for your branch to be merged into the
main
branch. - Upon approval, merge the Pull Request using the "Squash & Merge" option.
- To release the new version, add a lightweight tag with a semantic version prefixed with
v
(if a pre-release, add a-rc.X
suffix, whereX
is the release candidate increment):This will kick off the automated release workflow in GitHub Actions which builds the plugin ZIP, publishes a new release with the changelog update, attaches the ZIP as a release artifact, and pushes the ZIP and a$ git checkout main $ git pull $ git tag v1.0.0 # or "v.1.0.0-rc.1" for a pre-release $ git push --tags
manifest.json
to the S3 bucket for distribution.NOTE: Pre-release assets will not be uploaded to S3 and thus will not prompt for an update in the WordPress Admin.