Third-party plugins are subject to WordPress's security model and implementation.
Automattic could create a PluginV2 system with tightened security and new requirements for plugin developers, then put a plan in place to deprecate and remove support for v1.
Yes, after 18 years of WordPress development, the architects' excuse of blaming bad actors in plugin ecosystem has begun to wear thin, especially when contemporaries or predecessors like Firefox or Debian never had remotely the same level of problems with their users being hacked constantly by plugins/packages.
They were able to fix this by moving to the WebExtension model instead of letting extensions directly interface with XUL/XPCOM[0]. Of course, then everyone got angry that they couldn't do ridiculously invasive changes to the browser with an extension anymore.
...and face a fully justified user/dev revolt that makes Mozilla's worst day look like a single angry tweet. Remember that there's a massive paid ecosystem around WP plugins & themes, not to mention the stuff Automattic sells (hosting, their own plugins, etc.)
They can't afford it, and most people don't want it. I think history shows that taking flexibility away from something popular because of its flexibility is not good business. At least you can install a plugin now and completely sidestep this awful 'site builder'. If that goes away, hoo boy.
PHP code is not sandboxable (ignoring the ability to disable functions), AFAIK. Is it? So plugins do have complete (read) access over the entire code, the secrets in the config files, the database etc.?
Not allowing plugins to directly execute PHP code would either fundamentally break the wordpress plugin model or require an interpreter for a turing-complete "wordpress plugin programming language", right? That would kill any performance, especially on uncached wordpress instanced, even on PHP 8, wouldn't it?
You can sandbox php by changing the context the thread is running in before entering the plugin code. The issue is that there’s (currently) no delineation between internal code and plugin code (actions / filters) and changing back out of that context without a plugin doing the same to escape the sandbox.
I think it's probably too late to save wordpress. Squarespace and such are just better products for the average company. It would require a fundamental redesign of wordpress to solve its issues and at that point it just becomes a clone of the existing products.
> WordPress is used by 65.3% of all the websites whose content management system we know. This is 43.3% of all websites. [1]
And these numbers have been growing for years. In other words, WordPress is and will be widely used for a long time. So I’m not sure WordPress really needs saving. :p The number of OSS contributors has also been growing. So the project itself hasn’t been stagnating either.
Disclaimer: I’ve been a WordPress contributor and work for Automattic.
Sorry, I didn’t mean in a popularity way. But security wise, I don’t know how it would be possible to make Wordpress secure when the average user installs a bunch of plugins / themes and then leaves never to update it again. I just can’t see how this can work without becoming a fully managed platform.
It's fair to the extent that you're required to rely on 3rd-party products to get something done. If WordPress-the-Technology uses WordPress-the-Ecosystem as a main selling point, then its their choice to bundle their reputations together.
Interesting concept: reputation bundling. In this instance of the technology and its ecosystem, but potentially useful in describing other situations as well.
Is this something you came up with on the spot? I haven't come across this idea in communications literature and a cursory search only brings up other types of bundling in economics/business/strategy.
Not directly, but their API and security design absolutely does influence how normal plugins behave (i.e. common bugs), and how well they can limit the damage of abnormal ones.
