Re:The complicated futility of WordPress
by pwdisswordfish9 on Wednesday February 02, 2022 @04:44AM
(#30175551)
Maybe run it on Peachpie (which should already give perf gains) and go with the new plugin model.
Re:The complicated futility of WordPress
by paulryanrogers on Wednesday February 02, 2022 @09:01AM
(#30177596)
WP doesn't control where folks host it. Limiting its support to one .Net implementation would severely limit its market.
Re:The complicated futility of WordPress
by TimTheTinker on Wednesday February 02, 2022 @01:08PM
(#30181409)
> 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.
Re:The complicated futility of WordPress
by withinboredom on Wednesday February 02, 2022 @12:51PM
(#30181135)
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.
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?