I like the idea of sandboxing plugins, but I don't like the move away from GPL, and I would rather not junk PHP just to get isolates. PHP is one of WordPress's

I like the idea of sandboxing plugins, but I don't like the move away from GPL, and I would rather not junk PHP just to get isolates. PHP is one of WordPress's advantages: it runs on basically any web host, you have no edit-compile-debug loop to worry about, and all state is temporary by default. Switching to JavaScript means we have a persistent process that has to be rebooted, and we're now married to single-threaded event loops and async/await syntax, which leaks[0] into everything. Additionally, as others have already mentioned, the best security would be no dynamic code at all, just static pages generated by Jekyll. This should have been a Jekyll frontend, IMO. >And because WordPress plugins run in the same execution context as WordPress itself and are so deeply intertwined with WordPress code, some argue they must carry forward WordPress’ GPL license. That is a feature, not a bug. I already have to debug broken or poorly-documented WordPress plugins as-is, my job would be 100x harder if those plugins were proprietary and forbade inspection of the code. Furthermore, while the GPL forbids locking down plugins to charge a licensing premium, it does not forbid charging money in general. While in theory you can legally pirate paid WordPress plugins (it's called "nulling"), in practice few do this because it's an obvious and blatant security risk[1]. Paid plugin authors are selling support and software assurance that has real value. Also, I must take umbrage with the legal hedging. "Some argue"? Like, the GPL is strategically ambiguous with regards to the definition of a "Program"[2], but it'd be very hard to write a useful WordPress plugin that does not become part of the same Program. [0] This is predominantly a fault of JavaScript, which has no threading story and is designed to fit in a foreign event loop. In Rust, async code can spawn and await real threads to hold blocking code, and sequential code can host its own event loop to run async in. [1] Especially if you were to, say, name your nulled version "Secure Custom Fields". Nobody would EVER do that, right? [2] No, proprietary Linux modules don't count. Linux has a userspace syscall exception that defangs the GPL, so it's perfectly possible to write kernel-mode code that only touches syscall equivalents.