Developing for WordPress applications

When writing custom code or adding third-party plugins and themes, WPVIP’s unique infrastructure might necessitate different considerations and approaches.

For example, in a typical WordPress installation plugins and themes are managed with File Transfer Protocol (FTP) or within the WordPress Admin dashboard (WP Admin). On WPVIP there is no FTP access, and the WordPress Admin dashboard cannot be used to add, update, or remove plugins and themes. Instead, all plugins, themes, and custom code must be managed in an application’s version-controlled code repository.

WordPress Core files are provisioned by the platform for your application. You do not have direct access to WordPress Core files, but you can manage the version of WordPress that is running on your environment(s).

Other files that you might be accustomed to accessing directly, such as media files, also have very limited access. All media files that are uploaded or imported to a WordPress environment (i.e. all files within the /wp-content/uploads/ directory path) are not stored locally. Instead, they are stored in the external, read-only VIP File System object store.

All of these infrastructural differences are designed to improve the security and performance of your application.

WordPress skeleton

A new GitHub repository for WordPress applications is provisioned with a “skeleton” structure of files and directories. The files and directories located within the WordPress skeleton each serve a unique purpose and instructions for their use should be reviewed carefully.

For example, the /plugins and /themes directories located in the GitHub repository map to the /wp-content/plugins/ and /wp-content/themes/ file paths when code is deployed. To add a new plugin to a WordPress site, the plugin’s file(s) must be add to /plugins in a code commit to the branch that deploys to the WordPress site’s environment.

Plugins and themes

To customize the features and functionality of your WordPress site(s), you and your team must add all plugins, themes, and custom code to the application’s GitHub repository.

The plugin or theme files should be decompressed when they are added (i.e. not archived, like a *.zip format). Once the files are committed to a repository and deployed to an environment, a plugin or theme can be enabled of disabled through the site’s WordPress Admin dashboard.

Adding plugins and themes with subtrees and Composer

GitHub subtrees can be used to pull in third-party plugin code. By using the Git subtree workflow, a copy of the referenced code is pulled into the site’s repository.

The use of submodules is not recommended, especially for branches deploying to a production environment.

Plugins can be treated as PHP dependencies, and Composer can be used on VIP to pull in runtime dependency packages—such as plugins—during a local or continuous integration (CI) builds

Some plugin repositories, such as AMP for WordPress, contain unbuilt versions of code. In these cases, running the command, composer install is required for the plugin to work properly. Repositories like this cannot be referenced as submodules as these build commands are not run on the server.

Plugin security

Plugins that are located in the /plugins directory of a WordPress environment’s wpcomvip GitHub repository branch are automatically scanned by Codebase Manager. Known security vulnerabilities and available version updates identified by Codebase Manager are reported in the VIP Dashboard’s Plugins panel. Pull requests to upgrade plugins with available updates can be initiated within the VIP Dashboard’s Plugins panel.

Plugin incompatibilities

Some WordPress plugins are incompatible with WPVIP’s read-only web containers, read-only VIP File System, and the built-in caching layers. As a best practice, developers are advised to rigorously test all plugin candidates—and all custom code—on non-production environments before adding them to a production environment.

Automated code analysis on pull requests

Any code pushed to the WordPress application’s repository in a GitHub pull request is analyzed by the VIP Code Analysis Bot (the Bot) for code quality and security. The Bot is set up to run specific scanners: Vulnerability and Update Scan, PHPCS analysis, PHP linting, and SVG analysis.

The VIP Code Analysis Bot runs automatically on open pull requests (targeting any branch) when the pull request is opened or following any new commit. Depending on the size of the change, it may take a few minutes for feedback from the Bot to appear. If no issues are detected in the automated scan, no feedback or messages will be added by the Bot.

If the Bot leaves feedback in the comments of your pull request, you should ensure the security and stability of your WordPress application by addressing all feedback from the Bot by amending the relevant code according to its suggestions before merging the pull request.

VIP MU plugins

In addition to WordPress Core files and the code in your application’s GitHub repository, VIP Must-Use (MU) plugins are also deployed to each of your environments.

VIP MU plugins are a collection of performance enhancements that provide WordPress applications with integration to the WPVIP Platform infrastructure (e.g. cache management), helper functions useful to developers, commonly used performance enhancements (e.g. file concatenation and minification), and common WordPress plugins like Jetpack and Akismet.

WPVIP recommends that you review the plugins and features that are added by VIP MU plugins. This can help you avoid unnecessarily adding the same or similar items to your application codebase.