Re:WordPress 3.6 arrives with better post locking, built-in ...
by stephenr on Saturday August 03, 2013 @02:13AM
(#6151324)
Plugins can only access "everything" because of the complete lack of architecture or design. Wordpress is a series of ill thought out hacks, extended by other hacks, extended by yet more hacks.
Every time one of our WP developers asks me to help with something (usually they assume its a server config issue) I'm astounded at the shit I find when I discover the source of the problem.
Re:WordPress 3.6 arrives with better post locking, built-in ...
by jacques_chester on Saturday August 03, 2013 @06:46AM
(#6151744)
Like I said, I don't like Wordpress either. But within the constraints of shared hosting LAMP, guaranteed isolated processes are not possible. PHP adds a lot of introspection, so anything declared anywhere can be read or changed.
Wordpress is not alone in this. It's the platform.
Re:WordPress 3.6 arrives with better post locking, built-in ...
by stephenr on Saturday August 03, 2013 @08:15AM
(#6151892)
You don't need isolated processes to have better architecture and a sane plugin model.
Re:WordPress 3.6 arrives with better post locking, built-in ...
by jacques_chester on Saturday August 03, 2013 @09:52AM
(#6152059)
We're still talking about different things. Yes, WP could be better. This is demonstrable from other, better-designed engines within the LAMP/shared constraints.
But no such system can prevent any plugins from doing whatever they want to do.
Re:WordPress 3.6 arrives with better post locking, built-in ...
by stephenr on Saturday August 03, 2013 @11:37PM
(#6154544)
Introspection & Reflection in PHP don't expose everything, and frankly even if they did, it would be quite easy to analyse plugins and have an approved list of "safe" plugins that is used either as an advisory or as a basis for the available plugins shown to a user.
Re:WordPress 3.6 arrives with better post locking, built-in ...
by nkuttler on Saturday August 03, 2013 @04:02AM
(#6151469)
Themes being PHP code or plugins being hosted on wordpress.org without any code review isn't beyond anybody's control. Of course the former will never be fixed, there is no deprecation policy.
But yeah, if you have to host such software virtualization and isolation is a good idea.
Plugins run in the same process, with the same privileges, because there is basically no other way to do it.
OK, sure, you can do a kind of kabuki theatre where you present an API and insist plugin authors use it. But then they can access everything anyway and can find the MySQL login details by introspection. So it's pointless.
Another reason why I think apps should target virtual machines and be designed from the OS up. In such a design you can isolate plugins as standalone users and standalone processes.