The quality of a contributor's work can be reliably tied to the quality of their tools. Your editor (IDE), local development environment, code linters, unit testers, compilers, shell scripts, and other tools can all have a profound impact on your efficiency and quality. So it's important to always be thinking about how your tools and workflow can be improved.
What are your pain points?
What is tedious?
What are things that you often miss or forget to do?
As much as possible, when you identify improvements, try and look for ways to automate their solutions with scripts. If a script isn't possible, write a checklist which you can follow to reduce your cognitive load and the dreaded context switching we all love so much.
The following are tools we use at XWP. This list will grow and change over time and is not meant to be comprehensive. Generally, we encourage, and in some cases require, these tools to be used in favor of other ones. Rules governing tools to be used and packaged with a client site will be much stricter than those used on internal projects.
Also see the PhpStorm docs for integrating our code checkers:
The following should all be integrated into
wp-dev-lib and pre-configured there for use in your plugin or site project; they should integrated into your IDE, be run automatically before committing via the
pre-commit hook, and also run after pushing to a pull request via Travis CI:
Any additional references to code checker tools elsewhere in these best practices should be amended to this list.
When starting out, many developers edit PHP files on their local machine and then upload the changes via FTP to their production site to test. This is bad! A slightly better workflow is to have a separate staging server to upload changes to and test there. This is less bad, but still not good. Both of these are examples of cowboy coding.
Proper development workflow is always centered around version control. Code being deployed to a shared environment must always be first committed to version control or else risk being lost or overwritten. In order to test code without first having to commit it, it is essential for all developers to have a local development environment — a web server and database running locally.
There are a variety of solutions out there to get a local development environment up and running (e.g. MAMP and XAMPP), but we've found that Docker is a far superior solution. We typically use Docker paired with Lando or Vagrant and VirtualBox to build and interact with virtual environments that match production as closely as possible. There are many setups and configurations available, but here are a few that we suggest based on the project requirements:
Docker + Vagrant
The Docker with Vagrant and VirtualBox local development environment
wpsh-local can be embedded within a plugin using Composer. Making it perfect for both open source or client plugins that have no other dependencies besides WordPress. You can see how
wpsh-local is implemented in our
block-extend scaffolding plugin.
WordPress Core Recently WordPress Core built a local development environment directly into the repository that uses Docker and NPM. To have WordPress Core running at http://localhost:8889 you can do the following commands:
git clone https://github.com/WordPress/wordpress-develop.gitcd wordpress-develop/npm installnpm run build:devnpm run env:startnpm run env:install
🏭 Uses Composer for adding project dependencies, including plugins and themes.
🌎 Uses Composer autoloader for using any of the popular PHP packages anywhere in the codebase.
👩💻 Provides a local development environment based on Docker that can be run inside Vagrant without having to install Docker on the host machine.
🚀 Includes automated build and deploy pipelines to WordPress VIP Go.
WordPress VIP Classic
For classic VIP sites we have a private repository called
wordpress-vip that provided a good starting place for those project. It's based on VVV 2.0+ but is not used much anymore now that new sites are setup on VIP Go. Any clients still on the legacy system will already have a development environment available to you when you onboard to the project.
VVV Varying Vagrant Vagrants (VVV) use to be our standard Vagrant setup for client sites and local development. However, over the past few years has become used much less due to its slow provisioning.
This is a development library that is great for adding coding standards, linting and automated testing even to legacy projects since checks are applied only to new code by default.
block-extend plugin has been developed as a starter for creating Gutenberg centric plugins and is also used during candidate coding challenges.
Our template plugin for scaffolding WordPress plugins called
wp-foo-bar has historically been used to scaffold Customizer centric plugins for both our clients and Core. However, it has not been kept up-to-date this past year with all the new shinny development and editorial tools coming into play. It either needs to be updated or deprecated. It's likely that the
block-extend plugin will somehow be merged back into this scaffolding.
Grunt - Grunt is a task runner built on Node that lets you automate tasks like Sass preprocessing and JS minification. Grunt is our default task runner and has a great community of plugins and solutions we use for on company and client projects.
Gulp - Gulp is also a task runner build on Node that offers a similar suite of plugins and solutions to Grunt. The biggest difference is Gulp allows you direct access to the stream of information from your source files and allows you to modify this data directly.
Composer - We use Composer for managing PHP dependencies. Usually everything we need is bundled with WordPress, but sometimes we need external PHP libraries like “Patchwork”. Composer is a great way to manage those external libraries.
When a WordPress install is managed and maintained by an engineering team, and when the infrastructure supports it, plugins in a WordPress project can be easily managed using Composer. WordPress Packagist provides a Composer repository that mirrors all public WordPress plugins and themes.
NPM - We use
Git - We use Git for version control. We encourage people to use the command line for interacting with Git. GUIs are permitted but will not be supported internally.
SVN - We use SVN, but only in the context of WordPress.com VIP. Again, we encourage people to use the command line as we do not support GUIs internally.
The mouse is the enemy. The book Pragmatic Programmer highlights the inefficiencies of interacting with a computer via a mouse. A workflow can be drastically sped up via keyboard commands. But think beyond “keyboard shortcuts” and the convoluted finger gymnastics they often involve (Ctrl-Alt-Command-Shift-A…). Think instead about the code you might write from your keyboard every day in PHP:
wp_insert_post( array( 'post_title' => 'Hello World' ) );
These commands are articulated in computer language, here interpreted by PHP. However, this isn't really optimized for repetitive commands you write over and over and over again. A better language for repetitive tasks is Bash. When you open your computer's Terminal (e.g. iTerm2) you are being dropped onto a Bash prompt: an interpreter for code written in the Bash programming language.
git commit -m "First commit"
When all of your instructions are composed of commands that are read by an interpreter like PHP or Bash, then you can turn your commands into scripts to automate your repetitive tasks, such as setting up a brand new WordPress install, or syncing a database down from production and translating its hostnames.
For WordPress, there is a de facto tool for interfacing with WordPress from the command line: WP-CLI. Becoming familiar with the commands available, and even writing your own commands, can greatly speed up your development workflow and allow you to script tasks for others to run without having to share a long complicated set of manual instructions. This is an extremely powerful tool that allows us to do imports, exports, run custom scripts, and more via the command line. Often this is the only way we can affect a large database (WordPress.com VIP or WPEngine). This tool should be installed by default in a development environment, if it's not create an issue on GitHub.
We use a variety of tools to test our sites for accessibility issues. WebAim has some great resources on how to evaluate sites with a screen reader.
We’re also a fan of a few browser tools that lend us a hand when it comes to testing areas like color contrast, heading hierarchy, and ARIA application.
The Visual ARIA Bookmarklet - A bookmarklet that can be run on a webpage and color codes ARIA roles.
WAVE - A toolkit from WebAIM, that also has an extension for Chrome/Firefox. It evaluates a webpage and returns accessibility errors.
Accessibility Developer Tools - A Chrome extension that adds an “Audit” tab in Chrome’s developer tools that can scan a webpage for accessibility issues.
Tota11y - A visualization toolkit that can be used as a bookmarklet, and reveals accessibility errors on a webpage.
Tanagaru Contrast Finder - Another color contrast tool that tests colors against the levels of conformance, but also provides you with alternatives should your provided colors fail.
We use visual regression testing to ensure code changes don’t have unforeseen repercussions. This provides a helpful visual aid to check against CSS changes, plugin updates, and third-party script updates.
BackstopJS - A tool used to run visual regression tests that compares known reference states against updates.