You can add custom themes and plugins provided:

  1. Your CampusPress plan includes the option to add custom themes and/or plugins (email to confirm if included).  
  2. The theme or plugin meets our custom code guidelines.

Submitting Themes

We use Git for managing code. To add themes to your network, please head over to BitBucket and register. Then email with your email address and CampusPress network URL.

All theme additions and edits should submitted via BitBucket as pull requests with “campuspress”( user selected as reviewer.

Once submitted, our team will review the theme (and all subsequent edits) for security and reliability before pushing live and/or placing on a staging environment.

Depending on the queue and complexity of the theme or plugin (or edit) this can take up to 24 hours (or more for complex use cases). Please keep in mind this important review timeline when launching new sites or changes.

Also, include in the commit message your name and email address so we know who to notify once the commit is pushed live or who to contact with questions.

Note: Divi is common plugin in our networks but we have it under “divi” folder name instead of default “Divi”. Please keep it in mind when adding Divi child themes.

Requesting Plugins

All plugin requests must be submitted by a super admin via email to and include the following information:

  1. A link to the site where the plugin can be downloaded from.
  2. Reason why you would like the plugin added.

All plugins must pass our code review guidelines to be installed on CampusPress.  Please email before purchasing any plugins.

Code Guidelines

During the review process, we’ll check to ensure that all themes and plugins adhere to the WordPress Theme Guidelines and WordPress Coding Standards.

In addition, the theme or plugin must not rely on 3rd party services, phone home, and must:

  • not automatically upgrade or modify theme files;
  • not change timeout of wp_remote_* calls;
  • not ever change wp_feed_cache_transient_lifetime (hook to the filter);
  • not use SHOW TABLES, instead use SHOW TABLES LIKE ‘wp_xyz’;
  • not use DESC to describe table, instead use DESCRIBE;
  • not change WP_DEBUG, error_reporting or display_errors;
  • not remove default roles (remove_role);
  • not flush rewrite rules ($wp_rewrite->flush_rules is not allowed);
  • not flush cache (wp_cache_flush is not allowed);
  • not contain SQL queries. Themes should use WordPress built in functions for fetching post, pages, attachments, users and respective meta tags;
  • not create new tables or modify table schema;
  • not use filesystem functions listed here;
  • not store files in the server file system. Themes must always make use of WordPress attachments if it accepts file uploads;
  • not use error_log function;
  • not try to get all sites in networks at once with something like “get_sites( array( ‘number’ => 0 ) )” (it can lead to time out on large networks);

We reserve the right to modify the list of checks above. If we discover performance or security issues after approval and the theme or plugin complies to all of the checks, we will collaborate with you on the next steps and best options.

We try to make checks as thorough as possible. However if we discover a theme or plugin does not follow our guidelines after approval we reserve the right to temporarily remove it until it complies to all the checks.

Theme/Plugin Updates

We require you to increase the version parameter for files like CSS, JS, and images when updating your theme/plugin. For CSS it’s best to use wp_enqueue_style function and for JS wp_enqueue_script. Both of them have $ver parameter useful for increasing version. For paths to files like images and fonts, it’s best to change the path from, for example, “images/image.jpg” to “images/image.jpg?ver=2”. It’s worth noting that this also applies to paths in CSS files.

To bump version in many places at once, its best to create a function like “get_{theme/plugin_slug}_ver() { return 2; }” or define constant like “{THEME/PLUGIN}_VER”  and use it when needed. Relying on “wp_get_theme()->get(‘Version’)” or “get_file_data” is not the best as this info is cached and takes more time to refresh.

For themes that have been added and used on the network, it is not a good idea to change the main folder’s names. That’s because WordPress stores this info in DB and after a change like this its impossible for the system to find the correct theme. It applies to regular themes, child themes and parent themes.

Theme Update Workflow

If you are making changes to an existing custom theme, or upgrading a theme, it is better to do all the theme testing on a development network rather than on your production network.

Your work flow would look like the following:

  1. Submit pull requests in Bitbucket to the Development network.
  2. Test the updates on your Development network.
  3. Submit pull requests to the Production network.
  4. Check update on your Production network.

Email if you need a Development network for testing theme and plugin updates.