[schroeding]

Honest question, how would that work?

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?

[pwdisswordfish9]

Maybe run it on Peachpie (which should already give perf gains) and go with the new plugin model.

[paulryanrogers]

WP doesn't control where folks host it. Limiting its support to one .Net implementation would severely limit its market.

[TimTheTinker]

> PHP code is not sandboxable

People said the same about JavaScript, and yet smart people figured out ways to do it. For example: https://github.com/googlearchive/caja

PHP may be particularly challenging to sandbox, but it's not too much for talented engineers to figure out.

As a near-last resort, a secure PHP subset language could be developed.

[withinboredom]

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.