University of Wisconsin–Madison

Plugin Review Process

Why is there a Plugin Review Process?

WiscWeb is designed as a fully supported environment, which means that we guarantee, to the best of our ability, that everything installed in this environment will be up to date and will run as expected. This applies to WordPress, the UW Theme and all Plugins. If any of these items fails to work, it is the WiscWeb Team’s responsibility to provide the appropriate support to do the analysis, troubleshooting and updates as required.

Sounds simple enough, right? But there is a lot that goes into this. Every time we evaluate a plugin, there is a process that we run through. And every time there is an update to any Plugin, or WordPress or the UW Theme, we must run through the testing process for each and every Plugin that is installed. This consumes a lot of our support and training resources, which is why there is a limited standard set of Plugins that are installed in WiscWeb.

Plugin Evaluation and Testing Processes

Initial Plugin Review Process


  1. Evaluate if the requested functionality meets the objectives and criteria for Plugins in WiscWeb.
  2. In a testing environment, the WiscWeb team will conduct evaluations using plugin review criteria
  3. Gather feedback from WiscWeb Team on this initial testing
  4. Install and verify on WiscWeb Development environment
    1. Works with the existing infrastructure and software versions
    2. Works as expected in a multi-site
    3. Works with the UW Theme
    4. Works without affecting Plugins that are already installed
  5. Install and verify on WiscWeb QA environment
    1. Works with the existing infrastructure and software versions
    2. Works as expected in a multi-site
    3. Works with the UW Theme
    4. Works without affecting Plugins that are already installed
  6. Gather feedback from WiscWeb Team and selected users, using the plugin on WiscWeb QA environment
  7. Prepare and present to Governance Group a recommendation on feasibility, value and costs of adding plugin to WiscWeb’s supported environment
  8. Governance makes a decision on adding plugin to WiscWeb’s supported environment
  9. WiscWeb team creates all required training and KB documents
  10. WiscWeb team creates testing plan for plugin
  11. WiscWeb team conducts support awareness & preparation activities for production environment
  12. Schedule move to production
  13. Announce to WiscWeb Users on pending availability on WiscWeb Production environment
  14. Install and verify on WiscWeb Production environment
    1. Works with the existing infrastructure and software versions
    2. Works as expected in a multi-site
    3. Works with the UW Theme
    4. Works without affecting Plugins that are already installed

Installed Plugin Testing Process


  1. In a testing environment, the WiscWeb team will run through the established testing process
  2. Gather feedback from WiscWeb Team on this initial testing
  3. Install and verify on WiscWeb Development environment
    1. Works with the existing infrastructure and software versions
    2. Works as expected in a multi-site
    3. Works with the UW Theme
    4. Works without affecting Plugins that are already installed
  4. Install and verify on WiscWeb QA environment
    1. Works with the existing infrastructure and software versions
    2. Works as expected in a multi-site
    3. Works with the UW Theme
    4. Works without affecting Plugins that are already installed
  5. Gather feedback from WiscWeb Team and selected users, using the plugin on WiscWeb QA environment
  6. Request customer testing of their sites in WiscWeb QA environment
  7. WiscWeb team updates all required training and KB documents
  8. Schedule move to production
  9. Announce to WiscWeb Users on pending availability on WiscWeb Production environment
  10. Install and verify on WiscWeb Production environment
    1. Works with the existing infrastructure and software versions
    2. Works as expected in a multi-site
    3. Works with the UW Theme
    4. Works without affecting Plugins that are already installed
  11. Install updates in Production.

Objective

The objective of the plugin review process is to help ensure the quality of the WiscWeb WordPress service in the following areas:

  • Integrity: By preventing outages or compromises due to vulnerabilities introduced by
  • Availability: By selecting efficient plugins that render functionality quickly, handle unexpected conditions gracefully, and degrade upon failure of external dependencies gracefully without impacting service
  • Maintainability: By allowing efficient and timely upgrades to WordPress minor and major version upgrades by minimizing plugins that do not maintain compatibility with new versions of WordPress (WordPress.org releases a new version of WordPress every 3 to 4 months).
  • Usability: For content editors and web developers (both technical and nontechnical) by maintaining a streamlined and understandable WordPress user interface and minimizing unnecessary duplication of
  • Learnability: By emphasizing ease of use and quality of documentation in selected plugins, and by ensuring training and support stay current with available plugins as required to ensure service levels (especially for non­technical content editors).
  • Adaptability: By providing a mechanism for WiscWeb WordPress content editors, administrators and core team members to continually enhance WiscWeb in response to evolving requirements and trends, and by providing a mechanism to retire plugins which have become obsolete or have been superseded by better plugins or enhancements to WordPress core

Plugin Review Criteria

No. Criteria Measure
1 The plugin is compatible with the UW WordPress Theme. It does not conflict with the functionality built into the UW WordPress Theme.
2 The plugin provides valuable functionality in a new or unique way and has broad use cases. It does not duplicate functionality of an existing installed plugin available through the UW Theme or other plugins offered by the WiscWeb Service. It will benefit a substantial number of WiscWeb sites over a long period of time.
3 The plugin is compatible with the current version of WordPress and is actively maintained. It is compatible with the latest WordPress version, and has a history of maintaining version compatibility with new versions of WordPress prior to or shortly after release of new WordPress version release.
4 The plugin is compatible with WordPress Multisite. It supports use in WordPress Multisite (a single code base and database of WordPress, segmented into individual and independent sites) by allowing distributed content editors to use the plugin in their individual websites without data, control (the ability to make changes) configuration settings or errors bleeding through the segmentation provided by the sites.
5 The plugin is compatible with web accessibility practices. It is capable of producing web content and interactivity that is accessible by individuals of all abilities and disabilities.
6 The plugin has a substantial active user base and plugin usability and documentation are adequate for the target audience. It has substantial number of reviews, references and how­ to articles on third party websites, lots of downloads, consistently over time.If the plugin is meant to be used by non­technical content editors, the functionality is intuitive and easy to learn and/or documentation and training materials are adequate.
7 The plugin does not introduce security risks, does not introduce significant performance overhead and does not introduce external dependencies which could negatively affect performance and availability. It does not contain functionality or code vulnerabilities that could allow an attacker to steal data, delete data, change data, introduce “backdoors” or use wisc.edu as an attack vector to effect UW IT services or other organizations’ IT services.It does not make inefficient SQL queries or vast numbers of SQL queries per page request and does not overwhelm WiscWeb or other servers with HTTP requests.If it requires external dependencies (such as data retrieved via HTTP requests) it fails gracefully and does not slow down or completely take down WiscWeb WordPress services.
8 The plugin can be removed, replaced or retired if required. If it becomes unsupported or must be disabled on short notice due to a security vulnerability or severe performance degradation, the university can accept the effort required to remove, replace and/or retire the plugin.

Request Process

If you believe that the plugin you would like, meets the criteria above, you may request its addition to WiscWeb by completing the Plugin Request Form.

Once a request is received, the plugin will be added to the evaluation list and will be put in queue for the review/evaluation process. Reviews are done on a quarterly basis. Please refer to our Plugin Request Spreadsheet for a catalog of all requested plugins that are being reviewed.

Plugins are required to be reviewed against the criteria outlined within this document and are required to go through WiscWeb’s Version Control process.

Plugin Catalog

Once a plugin is added to WiscWeb, it will be added to the WiscWeb Plugins page.