WiscWeb has a plugin review process for each requested plugin within the service. The following links provide more info about this process and how to request a plugin:
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.
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.
- 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.
- 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 nontechnical 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 is compatible with the current version of WordPress. | 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. |
| 3 | 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. |
| 4 | The plugin is compatible with the other WiscWeb approved plugins | The plugin should not interfere with the function or performance of other WiscWeb plugins. If the plugin cannot be activated while another approved plugin is active, it will not be approved for use. |
| 5 | 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. |
| 6 | The plugin is actively being maintained and updated. Plugin changelogs are thorough, comprehensive, and easy-to-follow. The plugin is listed in the wordpress.org repository or was built by a well-known company (not a single developer). | We want to see that this is a plugin that is fully supported by the vendor. We must be able to reach out to the vendor, when needed, and feel confident that they will be able to help. Having more than one developer means that if one person leaves, there is still someone else who can assist. As we base much of our plugin update testing process on changelogs provided by the vendor, we require these to be easy to understand and comprehensive. |
| 7 | The reviews of the plugin are largely favorable. | If the plugin has a lot of complaints and low reviews from customers, that could mean that it could be problematic for WiscWeb and that it is not being actively maintained. |
| 8 | High number of active installs. | We want to see that the plugin is being widely used. There should be several thousand installs. |
| 9 | 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. |
| 10 | 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 nontechnical content editors, the functionality is intuitive and easy to learn and/or documentation and training materials are adequate. |
| 11 | The plugin does not introduce security risks | 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. |
| 12 | The plugin does not introduce significant performance overhead and does not introduce external dependencies which could negatively affect performance and availability. | 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. As part of this exploration, we aim to answer the following questions: Does it load a lot of scripts, styles or other assets? How many files run on page load? Does it perform complex operations? Does it perform remote requests (i.e. external APIs)? |
| 13 | The plugin does not allow for the archiving or display of sensitive or restricted data. | WiscWeb is not set up to host/support sensitive or restricted data. Therefore, any plugin that captures this information will not be allowed. |
| 14 | 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. |
| 15 | The plugin does not exist in the WordPress list of incompatible plugins. | WordPress List of Incompatible Plugins |
Request process
If you believe that the plugin you would like meets the criteria above, please add it to our Feature Request Board. If it proves to fit broad needs for campus, we will test it for compatibility in WiscWeb. Please note: We cannot promise that because a plugin is requested that it will be added to the service offering.
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.