Congratulations! You’re getting your code ready for WordPress.com VIP.
This document covers three types of reviews: Theme Reviews, Plugin Reviews, and Deploy Reviews.
Before You Submit Your Theme for Review #
Once you have your theme fully built and tested in your local environment, the theme is ready for us to review. We generally need 10-15 business days to do a full theme review (we also have priority reviews available for a rush fee—get in touch if that’s of interest). Send it to us in an email as a zipped attachment.
If the theme is more than just a basic theme, it will speed up the review process for us to fully understand the purpose of any custom code and what it’s trying to accomplish. Therefore, the more technical and in-depth documentation you have, the better. If the theme is based on another theme, please let us know. Here are some more suggestions to fast-track your theme review.
We also like to review all plugins you’re planning to use. We have reviewed a small, but growing list of plugins, and modified some of them to make them more stable, secure, and performant. If your site hasn’t launched yet on WordPress.com, then please only consider the few plugins crucial for your user experience. It will make the launch process go much smoother.
We’ll provide feedback relating to any errors, irregular code, or calls in the theme that must be fixed and/or explained before the theme can be approved. Our code review process is collaborative—we encourage you to introduce yourself to how it works.
After your theme has been approved, we’ll provide access to your own subversion repository.
Here are several notes that will help speed up the review process and reduce the number of iterations needed to reach a successful launch:
- WordPress code is licensed under the GNU Public License v2 (GPL2). All theme and plugin code needs to be GPL compatible or custom code you’ve written in-house—split or proprietary licenses are not allowed. The reasoning for this is that you, and we, need to have the legal rights to modify the code if something is broken, insecure, needs optimization, etc.
- If you are using a premium theme or plugin, please get in touch with us before purchasing as we may already have it available on WordPress.com or have previously reviewed it.
- If you are just starting up with your theme development, please check out the already approved WordPress.com public themes (SVN) and evaluate if you could base your development on one of these. This could reduce the review time dramatically. The Twenty Ten and Twenty Eleven themes, for example, make great base themes.
- Please make sure that the code you submit for review is well-tested and includes all the information needed to function on a clean, current WordPress installation. If any content needs to be setup in order to test your theme, please provide a WordPress export with sample data.
- Please note that plugins and other functions that alter the database structure or perform write operations on the filesystem interfere with our architecture, and we likely will not be able to approve these kinds of scripts. More details are shared in Best Practices.
- Make sure that all of your plugins are included and running from within your theme folder. The plugins will be loaded by the themes’ functions.php file or similar methods. Some plugins need alteration of paths and/or urls in order to keep functioning in such an environment.
Common Issues with Theme Reviews #
We review a lot of themes. Many of the issues we find repeat themselves over and over again. To save yourself (and us) time, here are some things you should keep a keen eye out for:
- Initialize the VIP environment with our helper function.
- Make sure you call
vip_powered_wpcom()in your theme’s footer.php.
- Properly validate, sanitize, and escape your data. The first two apply to whenever you’re handing user-submitted data (e.g. post meta boxes, frontend forms, etc.) and the latter applies to whenever you’re printing data from the database.
- Enqueue scripts and styles, and make sure you’re doing so on the proper hook.
- Prefix any custom functions you write.
- Don’t use query_posts().
- If your theme is based off another theme (like TwentyEleven), make sure you’ve extended it as a child theme and didn’t simply copy and paste the files over without modifications.
- Use tabs, not spaces, and follow all of the WordPress Coding Standards.
As always, if you have any questions about the best approach for a particular problem, please get in touch.
Before You Submit A Plugin for Review #
If you are interested in using a plugin that isn’t available as a pre-approved VIP shared plugin, we will have to review it for stability, performance, and security before it can be used on WordPress.com.
Before deciding on a particular plugin solution, please share with us the problem you are trying to solve, or the experience you are trying to create. We likely can add our own insights to the scenario, and suggest advantages and weaknesses of different approaches.
When submitting a plugin, we appreciate as much detail as possible about how the plugin will be used and what it’s trying to accomplish (examples are particularly helpful). Our code review process is collaborative — we encourage you to introduce yourself to how it works.
Plugin Guidelines #
- WordPress code is licensed under the GNU Public License v2 (GPL2). All plugin code needs to be GPL compatible or custom code you’ve written in-house. Split or proprietary licenses are not allowed. The reasoning for this is that you, and we, need to be have the legal right to modify the code if something is broken, etc.
- The plugin needs to run on the latest version of WordPress with MultiSite (previously WordPress MU) enabled.
- The plugin should not directly write to the filesystem as this will not work with our distributed environment. You can use the WordPress API though, such as
- The plugin should use the existing database tables and structure (no alterations). Custom post types, custom taxonomies, post meta, etc. are incredibly flexible.
- The plugin should not rely on the plugin activation and deactivation hooks as VIP plugins are a part of your theme and are loaded using
require_once()rather than the plugins menu.
- If you’re currently using Jetpack on your self-hosted WordPress site, you don’t need to include it on your WordPress.com VIP site—every feature that exists in Jetpack is already included in WordPress.com.
Please pre-review your plugin before submitting it to us to make sure it meets the WordPress.com guidelines for code. Depending on the complexity of the plugin under examination, the initial plugin review could take up to 2 weeks.
Once Your Plugin is Approved #
Plugins on WordPress.com VIP are organized differently than a standard self-hosted WordPress.org site, since on VIP you only have access to your site’s theme folder. To use plugins on a WordPress.com VIP site, you add them to a “plugins” directory within your theme directory, and require_once/include_once them in
require_once( __DIR__ . '/plugins/custom-plugin/custom-plugin.php' );
Deploy Reviews #
Once your plugin and themes have passed review they are moved to the VIP production repo and you are granted the necessary access to submit code changes.
We still review everything before deploying, so you can expect tickets, commits, or reverts from us if we find any issues. If issues are found in submitted code and it’s a simple fix, we fix the issue and notify the developer before pushing the code live. If it’s a more complex problem, we do not deploy the code. Instead, we revert the code and notify the developer with guidelines on how to fix the problem.
We deploy code changes to VIP sites throughout the business day and strive to have all changes live within two hours. Note that changes to CSS files and images are deployed automatically.
Some guidelines to help speed up the deploy process:
- Only commit tested code. Never use WordPress.com for testing or debugging. If there is something you cannot reproduce or work out in your local environment, please open a ticket and ask for assistance.
- Including a detailed commit message speeds up the time it takes us to review and deploy the code, and is also essential for future debugging or in case of emergencies.
- If you have significantly large or complex changes to push, please send the changes in as a patch ahead of time.