Integrate WordPress plugin blacklist.txt with ss-clean-files deletion? about slickstack

[jessuppi]

@Bronislawsky Thanks for the suggestion. In all likelihood, there will always remain a certain list of plugins that are "hardcode" disallowed to avoid conflicts with SlickStack. The question is more really defining the categories of plugins that this applies to, which is a work in progress:

https://slickstack.io/faq/blacklisted-plugins

It is a balance trying to keep things as open as possible by default, while still settling on a philosophy and best practices that SlickStack wants to evangelize.

SMTP plugins might be one category that we end up allowing again since it speaks toward avoiding censorship and email API monopolies. Others, like cache plugins, will always be deleted.

[jessuppi]

An update on this:

Several days ago, we finalized our "policy" on this, at least for a while... but first, some background.

After more users complained about certain WordPress plugins being force-deleted in SlickStack despite them having disabled the blacklist.txt (or using a custom blacklist.txt), we introduced a temp fix last year with an option in ss-config that was called SS_CLEAN_FILES_WORDPRESS_PLUGINS so that this function could be disabled.

However, after more discussions and consideration, we have removed this option, and decided the following:

• force-deleting certain WordPress plugins can no longer be disabled in SlickStack
• there will be no integration with the blacklist.txt feature, since this is both technically very difficult to achieve, but also because these two features now serve more distinct purposes
• going forward, SlickStack will only force delete plugins that fall into these categories:
  • Malware
  • Exploitable (this generally refers to deprecated plugins with known security problems that are no longer being patched or updated by the author)
  • Database Thrashing (plugins that are known to cause servers to crash, also usually deprecated)
  • Unresolvable Conflicts which refers to plugins that inherently conflict with SlickStack

This greatly narrowed and better defined scope should help avoid confusion in the future.

Keep in mind, for future readers of this thread, there are certain plugins we consider to "conflict" with SlickStack even if there are no fatal errors, such as cache plugins or "hide wp-login" plugins.

Remember that our project doesn't aim to be everything to everyone, we want to create a lightweight WordPress stack with server-level caching and security features that is as open as possible, while still reducing common bloat. If a server-level feature can be done more reliably using commonly agreed methods, we will usually prefer that over a plugin.

Community feedback on our blacklist.txt and the plugins we force delete is always welcome.

Further comments are welcome here anytime, thanks!

[jessuppi]

By the way, there are too many commits to reference in this Issue, but future readers can check here:

Ref: https://github.com/littlebizzy/slickstack/blob/master/bash/ss-clean-files.txt