Are there any WordPress plugins banned on your network?
ANSWER: Yes, there is an ever-evolving list of WordPress plugins that we “blacklist” from our servers for reasons of security and performance; in most cases these plugins can actually be installed for a short amount of time, however, our network cron jobs will automatically delete such plugins several times each day. This approach allows our clients to test a certain plugin if they like, while enforcing a cleanup policy that protects our clients from risky software.
Categories of banned plugins
Because WordPress adaption continues to grow rapidly, and because there are thousands of new plugins being developed each year, it is become increasingly difficult to specify a list of banned plugins for our clients. This is because nearly every day, we find another plugin that we need to ban for various reasons. Instead, we provide the below list of categories to give our clients a better idea of what types of plugins we disallow and for what reasons.
- Excessive logging: WordPress is already a very dynamic application, so reducing the amount of unnecessary database writing is essential to maintaining good performance. This includes things like traffic analytics, post views, share counts, history logs, actions logs, etc. If it’s writing to the database on every single action or page load, it’s probably banned. Most of these types of features attract “amateur” webmasters, and are not truly necessary at the PHP-level. Things like traffic stats and otherwise should always be managed off-server using dedicated applications.
- Excessive third party API usage: This is not so common, but some plugins send dozens or hundreds of calls to third party API servers. Often this is due either to poor coding or poor concept, but either way it is a huge performance hit that we want to protect our clients from.
- Fatal errors: If or when we discover them, we ban any plugin that causes or potentially causes fatal errors (e.g. 500 errors), which are typically generated at the PHP-level.
- PHP hacks: Any plugin that attempts to manipulate the server’s php.ini configuration is banned, along with any plugin that tries to “inject” PHP code into WordPress posts and pages, etc. The proper way to add custom code snippets is with shortcodes in WordPress, or using one of the “blocks” in the new Gutenberg block editor.
- Fake CDNs: Any plugin that “hosts” your images, scripts, or other resources but is not a full scale CDN service is banned, because the performance is typically poor and configuration options are usually slim to none. Again, these things are aimed at “wowing” amateurs, and are not used by professional syadmins.
Some background:
Initially when we launched LittleBizzy, we sought to avoid banning any WordPress plugins. The reason for this is that we didn’t want to manipulate open-source software like WordPress into our own proprietary hosting environment in such a way that discriminated against certain plugins, or in a way that “betrayed” the spirit of open-source collaboration between various individuals, teams, and businesses. However, over time we’ve concluded that quite often it’s not web hosts doing the betraying, but rather some of the very poor plugins out there; that is, when certain WordPress plugins negatively affect the security and performance of your website in a measurable way, or when the goal of a plugin is to “mislead” or even scam WordPress webmasters, then frankly it is such players that are to blame for any bad blood — not us!
Ultimately, while our underlying network security can’t be beat — every single website in our network is placed on it’s own VPS server, without fail — we eventually felt compelled to extend our stated mission of being the “best managed WordPress hosting in the world” into the arena of so-called plugin regulation, because of the drastic side effects involved when installing these little firecrackers. After all, just because Client A is isolated from Client B, it doesn’t mean that we’ve provided the most optimized hosting environment possible. On the contrary, our main goals — speed, stability, and security — surely don’t start and stop with just the server stack, so arguably neither should our management.
The above list will continue to evolve constantly. In particular, we seek to rid our clients of any plugins that are using deprecated code, hurt website accessibility, can be linked to DDOS or other similar attacks, generate email spam, or otherwise degrade the overall speed, stability, and security of your WordPress website.
If you find another WordPress plugin that you think we should consider “banning” for whatever reason, or if you’d like us to reconsider a plugin that is currently banned, please let us know anytime.
Related questions:
Leave a Reply