Blacklisted WordPress Plugins

The Plugin Blacklist plugin is included by default in SlickStack, but is not a required “core” MU plugin.

However, there are certain categories of WP plugins that will still be force-deleted by the ss-clean Bash script in SlickStack for reasons of security and stability. We try to keep this list relatively slim, to avoid overly controlling the stack customization of each team or agency. However, the philosophy of SlickStack in some cases is clear, and we want to establish best practices for the DevOps community at large when it comes to LEMP cloud servers and WordPress. These are the auto removed plugin categories below:

• Backup plugins. Plugins that retain local backup storage/archives or support automated backups are a bad idea for security and stability reasons. They not only use tons of CPU and RAM on your server, but also generate tons of archive files that hackers can easily find and download, thus accessing all of your user data (and cloning your website).
• Caching plugins. SlickStack has server-level caching built-in already, called Nginx FastCGI Cache, which is much faster than PHP-level cache plugins in WordPress. There is no need for cache plugins therefore which can actually slow down your site on SlickStack and conflict with the existing server-level caches.
• Performance/speed plugins. By default SlickStack already bundles several MU plugins that disable common bloatware in WordPress Core. This, along with the fact that server-level caching is built-in already, means that performance related plugins will only generate more codebloat and slow down your site, or cause instability. Since our goal is not just speed, but also best practices (to achieve stable WordPress websites) we frown on things like “concatenating” JS or CSS scripts, or removing assets on a per-page basis. In many cases such features can break your WordPress website immediately, or later on during software updates or web design changes. It’s just not a good idea, which is why “serious” companies never use them.
• Bloated security plugins.
• Excessive logging plugins.
• Excessive API call plugins.
• Deprecated and abandoned plugins.
• Vendor specific plugins (e.g. Migrate To XYZ Hosting).
• Custom post type plugins that only support certain vendor themes.
• Shortcodes (snippets) plugins that only support certain vendor themes.
• Hacking third-party design products. This category is becoming exponentially more common now that certain page builder plugins have become more popular. (On a side not, the concept of page builder plugins is something of a nightmare to begin with.) The problem is that when a design agency discovers that page builders are missing a feature they need, they create a quick “hacky” plugin to customize the page builder, then they often share that plugin on WordPress.org and other people begin installing it. Then, later the page builder company adds a similar or conflicting function, and your website breaks. It’s just never a good idea to install third-party functions that “hack” other design products. If you want a new feature, you should contact the owner of the WordPress theme or page builder plugin directly and ask them to add that feature. If this sounds annoying, it is! Which is why you should be using either custom WP themes or simple and reliable lightweight themes instead of relying on very bloated and problematic page builders.
• Fonts instability. Using custom fonts, i.e. web fonts, is a great option for modern web design. Typically using a web font source like Google Fonts or Font Squirrel is the best way to load fonts as they have very powerful (and free) CDNs for delivering the font files, and also many users already have those fonts cached in their browser. Plus, their software will automatically calculate which sub-variety of each font variation to deliver based on the device and browser version of the client. However, for privacy or security reasons (etc) but mostly just for “fun” many web designers have begun using plugins like Use Any Font (etc) which gives real-time previews in the page builder or post editor. This is cute and fun, however the preview is nearly always inaccurate when compared to the live site design. Plus it causes constant conflicts with other design plugins like page builders and cache files etc. If you want to use a custom font in your web design, and not use a public CDN for it, than it is best to manually upload the web fonts to your server and then “call” them in your CSS files… that’s it. There is no need to install more software to WordPress in order to merely upload font files or to preview them in your post editing window, which causes security problems, instability, bugs, and is nearly always inaccurate anyways.

The goal of SlickStack is to reinforce the benefits of open source software, such as portability and integration, and help small businesses avoid plugins that are misleading, insecure, or otherwise cause instability in various forms.

Keep in mind that this blacklist approach is nowhere near fool-proof. Determined developers can find a way to rename and activate plugin folders, classes, and functions, so that our blacklist cannot detect them properly. But well-meaning users who trust our judgement will see a very clear warning in regard to above categories.