3 ms·

> when NoSQL databases have been available for years is outrageous! I work for a shared hoster, we host a ton of WordPress sites. The problem here is that in

> when NoSQL databases have been available for years is outrageous! I work for a shared hoster, we host a ton of WordPress sites. The problem here is that in shared hosting world MySQL is ubiquitous, along with PHP. It's all you need to get your WordPress blog up and running. Adding a dependency on a NoSQL datastore breaks that simplicity. Also which NoSQL database do you target because not all of them are suitable for running in these types of environments. Also wp_options is, as the table name suggests, mostly just option settings which are looked up by a known key "option_name" then the json-like blob is read from the "option_value" field and parsed. There's very little or no searching done for values inside that blob so you're adding NoSQL complexity just to store key/value pairs. MySQL is a well known, well understood thing and "just works" for apps like WordPress.

nikolay 11y ago
This problem could easily be solved by adapters. You can have a default adapter storing this into MySQL tables, but open it up for databases that are designed to do just that effectively. Oh, well, WordPress doesn't even support PostgreSQL, which alone can do both pretty effectively. There's os much spaghetti code in WordPress that I always have a bad feeling pushing that code to Production (with capital "P"). A lot of people praise WordPress for the great number of plugins and themes, but the reality is that only 1% of those are quality code, forward-compatible, following best practices, secure, and suitable for use and not just getting something out of the door quickly. That's why WordPress needs rethinking and most importantly - some sandboxing of themes at least because you can't even allow a shared hosting to upload custom themes as most of them can hack your entire infrastructure being plain PHP code. I can't believe WordPress being such an archaic product, why they don't support Smarty-based themes, which could be execution-safe.

nikolay 11y ago

This problem could easily be solved by adapters. You can have a default adapter storing this into MySQL tables, but open it up for databases that are designed to do just that effectively. Oh, well, WordPress doesn't even support PostgreSQL, which alone can do both pretty effectively. There's os much spaghetti code in WordPress that I always have a bad feeling pushing that code to Production (with capital "P"). A lot of people praise WordPress for the great number of plugins and themes, but the reality is that only 1% of those are quality code, forward-compatible, following best practices, secure, and suitable for use and not just getting something out of the door quickly. That's why WordPress needs rethinking and most importantly - some sandboxing of themes at least because you can't even allow a shared hosting to upload custom themes as most of them can hack your entire infrastructure being plain PHP code. I can't believe WordPress being such an archaic product, why they don't support Smarty-based themes, which could be execution-safe.