wppunk/WPPlugin
Stars: 140
Forks: 24
Pull Requests: 18
Issues: 11
Watchers: 12
Last Updated: 2023-07-07 23:10:59
Boilerplate for WordPress plugin using autoload, coding standard, webpack, PHP/JS tests, etc.
License: MIT License
Languages: PHP, JavaScript, SCSS, Shell
WP Plugin
Get Started
One-line install:
composer create-project wppunk/wpplugin your-plugin-directory
Or you can copy the archive or clone via Git and then run:
composer init-project
Requirements
Make sure all dependencies have been installed before moving on:
- WordPress
- PHP >= 7.2.5 (You can easily downgrade it)
- DOM extension
- CURL extension
- Composer
- Node.js >= 14.8
- npm
- ChromeDriver (for acceptance tests)
Structure
plugins/your-awesome-plugin/ # → Root of your plugin.
├── .codeception/ # → Codeception additional directories.
│ ├── _config/ # → Configs for DB connection.
│ ├── _data/ # → Folder for SQL dump.
│ └── _support/ # → Additional classes for the Codeception tests.
├── .github/ # → GitHub additional directories.
│ └── workflows/ # → Workflows.
│ ├── plugin-name.conf # → Config for the server.
│ └── plugin-name.yml # → Actions for GitHub.
├── .tests/ # → Tests.
│ └── php # → PHP tests.
│ ├── acceptance # → PHP Acceptance tests.
│ ├── unit # → PHP Unit tests.
│ │ └── _bootstrap.php # → Bootstrap file for PHP unit tests.
│ ├── acceptance.suite.yml # → Config file for the acceptance tests.
│ └── unit.suite.yml # → Config file for the unit tests.
├── assets/ # → Assets directory.
│ ├── build/ # → Assets build directory.
│ └── src/ # → Assets source directory.
├── node_modules/ # → JS packages (never edit).
├── src/ # → PHP directory.
├── templates/ # → Templates for plugin views.
├── vendor/ # → Composer packages (never edit).
├── vendor_prefixes/ # → Prefixed composer packages for non-conflict mode (never edit).
├── .codeception.yml # → Main codeception config.
├── .env.example # → Example for the .env.development and .env.production files
├── .eslintignore # → JS Coding Standards ignore file.
├── .eslintrc.js # → JS Coding Standards config.
├── .gitconfig # → Config for git.
├── .gitignore # → Git ignore file.
├── .phpcs.xml # → Custom PHP Coding Standards.
├── .scoper.inc.php # → Config for the PHP Scoper.
├── .stylelintrc # → Config for the style linter.
├── .webpack.mix.js # → Laravel Mix configuration file.
├── CHANGELOG.md # → Changelog file for GH.
├── composer.json # → Composer dependencies and scripts.
├── composer.lock # → Composer lock file (never edit).
├── LICENSE # → License file.
├── package.json # → JS dependencies and scripts.
├── package-lock.json # → Package lock file (never edit).
├── plugin-name.php # → Bootstrap plugin file.
├── README.md # → Readme MD for GitHub repository.
├── readme.txt # → Readme TXT for the wp.org repository.
└── uninstall.php # → Uninstall file.
Autoload
We use PSR-4 and composer autoload for PSR-4. You can find it in composer.json in directive autoload.
Coding Standards
To check all coding standards:
npm run cs
PHP Coding Standard (PHPCS)
We use a custom coding standard based on WordPress Coding Standard. We disabled rules for the naming of WordPress files for using PSR-4 autoload. Also, we have a feature, which can allow testing your code using different PHP environments.
Custom PHPCS your can find in the .phpcs.xml.
Your can check PHPCS using a CLI:
composer cs
or
npm run cs:php
Pay attention, tests have a bit another coding standards because testing libraries all using camelCase format for methods, function, variables, and properties.
PHPCS checked before each commit, before the push, and in GH Actions.
JS Coding Standard (JSCS)
We use a default WordPress JSCS, but you can modify it in the .eslintrc file.
You can check JSCS using a CLI:
npm run cs:js
SCSS Coding Standard (SCSSCS)
We use a default standards for SCSS, but you can modify it in the .stylelintrc file.
You can check SCSSCS using a CLI:
npm run cs:scss
Environments
For any constants you can create the .env.development and .env.production files. For example, we use these constants from the .env.example file for the browserSync inside the Laravel Mix config and for acceptance tests.
Frontend
All assets are located in assets/src/*.
All builds are located in assets/build/*.
CSS preprocessor is SCSS.
We use Laravel Mix for the assets build. You can modify it in .webpack.mix.js file.
For run Laravel mix you can use the next commands depend on situation:
npm run build
npm run build:production
npm run start
GitHub
GH Actions
All steps for GH Actions you can find in .github/workflows/plugin-name.yml file. Also, for wake up a webserver, we need to add .github/workflows/plugin-name.conf
GH Hooks
Just make you GH repository clear. We use the Husky library to add actions before commit, push, etc. This helps developers make their GH more clear.
GH Templates
Basic GH templates for better security issues, support requests, bug reports, enhancements, feature requests, pull requests, and contributing templates.
Dependency injection container
The lightweight Dependency Injection component implements a PSR-11 compatible service container that allows you to standardize and centralize the way objects are constructed in your application.
Automatic load your dependencies using the type hinting.
You can disable plugin hooks very easily using a DIC. Just get the plugin object from the dependency injection container $container_builder->get( PluginName\Front\Front::class ). Example just disabling frontend assets:
function remove_plugin_name_frontend_assets( $injector ) {
$front = $injector->make( PluginName\Front\Front::class );
if ( ! $front ) {
return;
}
remove_action( 'wp_enqueue_scripts', [ $front, 'enqueue_styles' ] );
remove_action( 'wp_enqueue_scripts', [ $front, 'enqueue_scripts' ] );
}
add_action( 'plugin_name_init', 'remove_plugin_name_frontend_assets' );
PHP Scoper
You need to add prefixes for each outside dependency because other plugins or themes can use the same dependencies, and it can conflict between packages.
composer scoper
Automated testing
We are using for automated testing a Codeception library runs all types of PHP tests.
PHP unit tests
For running use a CLI command:
composer unit
- Main configuration file
.tests/php/unit.suite.yml - Unit tests inside
.tests/php/unit/*folder. - Bootstrap file
.tests/php/unit/_bootstrap.php - Each filename for test class must have a suffix on
*Test.php. - Each test class must extend a
PluginNameUnitTests\TestCaseclass. - You can also add some code to
PluginNameUnitTests\TestCase.php - Each test method must have prefix
test_ - Additional files for autoloading in tests running you can add to
.codeception/_support/*folder.
Also, unit tests will be checked on a push to repository action and inside the GH Actions pipeline.
PHP acceptance tests
Warning! The acceptance tests make REAL actions on your site. Before running need to create another database and create a dump.sql file with fresh WP install.
Before running, you need to (It needs to make just one time. I hope you can do it):
- Install a ChromeDriver
- Create a new database. For example, I named a database
codeception_db - Install a clear WordPress
- Export database to
dump.sql - Move a
dump.sqlfile to the.codeception/_data/folder. - Copy a file
.codeception/_config/params.example.phpto.codeception/_config/params.local.php. - Update your connection information to the testing site connection in
.codeception/_config/params.local.phpfile. - Update your
wp-config.phpfile:
if (
isset( $_SERVER['HTTP_X_TESTING'] )
|| ( isset( $_SERVER['HTTP_USER_AGENT'] ) && $_SERVER['HTTP_USER_AGENT'] === 'wp-browser' )
|| getenv( 'WPBROWSER_HOST_REQUEST' )
) {
// Use the test database if the request comes from a test.
define( 'DB_NAME', 'codeception_db' );
} else {
// Else use the default one (insert your local DB name here).
define( 'DB_NAME', 'local' );
}For running use a CLI command:
composer acceptance
- Main configuration file
.tests/php/acceptance.suite.yml - Unit tests inside
.tests/php/acceptace/*folder. - Each filename for test class must have a suffix on
*Cest.php. - Each test method must have prefix
test_ - Each test method must include
AcceptanceTesteras argument. - You can add some methods to AcceptanceTester in
.codeception/_support/AcceptanceTests.php. - Additional files for autoload in tests running you can add to
.codeception/_support/*folder.
JS unit tests
For running use a CLI command:
npm run unit
- Main configuration inside
.tests/js/package.jsonin directoryjest - Unit tests inside
.tests/js/unit/*folder. - Bootstrap file
.tests/js/setupTests.js - Each filename for test class must have a suffix on
*.test.js. - Just import your class for testing and write tests.
Also, unit tests will be checked on a push to repository action and inside the GH Actions pipeline.