To paraphrase Churchill, Wordpress is the worst CMS -- except for all the others.
I'd love to find an open-source CMS (preferably in Python or Ruby) with clean, secure, elegant code and a well-organized framework that comes with a friendly admin and active, responsive development community like Wordpress, but so far I've got nothing.
(If anyone has any suggestions, please do feel free to share them!)
It's Python (a Django app). BSD license. It has many advantages over Wordpress that I won't get into here, but all this is offset by one massive disadvantage: It rests on the Django framework.
Django is a nice framework for web development but it takes at least a few months to learn for someone starting from scratch. The installation process for Mezzanine requires some Django knowledge.
Installing Wordpress on the other hand requires zero PHP knowledge. A reasonably intelligent person can teach themselves Wordpress basics in days (the basics of self-hosted Wordpress, selecting a theme, selecting key plug-ins, etc.). No PHP required.
With Wordpress, it's not too difficult to select a provider (i.e. Bluehost) and have Wordpress automatically installed within minutes using Simple Script. If Mezzanine could be automatically installed like this, I think it would quickly become a popular and much more maintainable alternative.
> Installing Wordpress on the other hand requires zero PHP knowledge.
I don't disagree with your intent - it's critical to have a quickstart option for people who aren't primary developers - but there's a downside to this: a comically high percentage of exploited sites are Wordpress because it's not trivial to secure or stay updated.
That's a much harder problem to solve since you really need an automatic updater but the odds of something requiring human attention during an upgrade are high.
Your statement is patently false in two spots: One, WordPress is not a "comically high percentage" of exploited sites (presumably vs other CMS'?) - I challenge you to prove that (besides the problem of defining 'comically' for these purposes).
Two, WordPress is trivial to update, both for the core software, as well as for plugins. It's literally a two-click process to update with a constant reminder in the UI that updates are available.
I've built and manage dozens of WordPress sites at all levels, and in the few encounters I've had with compromised sites, 100% of the time it is because the end user has been willfully lazy about clicking the update button in the software.
Mezzanine contains a fabric installation that can take a vanilla ubuntu install, and have a production server up and running with Postgres, memcached, et al, in a single command:
Very cool - I didn't know about this. However, this still presupposes you have a local Python/Django/Mezzanine installation. Simple for a Django web developer, probably not too bad for a non-Django web developer - but it's a bit much to expect a non Developer to set up Python, Django, and Mezzanine on their local system.
On the other hand, I see a way to make this simple for a non developer. Set up a virtual machine with everything all set up. Then all the end user would have to do is download VMware or virtualbox. Then download the VM image with Ubuntu/Django/Mezzanine/Fabric. And then you'd be approaching the same level of simplicity of getting started with self-hosted Wordpress.
Can you name 1 or more cloud providers that have auto installers for Mezzanine? I'm not aware of any. Here's a post from 4 months ago comparing installing Mezzanine on a number of PaaS providers. None seemed anywhere close to as simple as installing Wordpress on Bluehost:
Read the comments and you'll find out that Mezzanine isn't yet compatible with Django 1.5, causing headaches for those trying to install it for the first time.
> Read the comments and you'll find out that Mezzanine isn't yet compatible with Django 1.5, causing headaches for those trying to install it for the first time.
Django 1.5 came out less than a month ago. Given the size of Mezzanine, it's not surprising that it hasn't been upgraded immediately.
I'm not sure why this would effect the install process, either: any host that can handle Django apps is likely to have both 1.4 and 1.5 available at the very least.
We'd been tracking Django 1.5 changes during the release candidates and were mostly compatibile with it up until its release. When it was released, a few issues cropped up - those were resolved within a day or two, so there was a brief period where it was incompatible with 1.5, but that's no longer true.
So it was incompatible with 1.5 for less than 48 hours. Latest version works fine against 1.5, enjoy :-)
Thanks for piping in - unfortunately I'm too late to edit my 1.5 comment.
Can you describe the easiest way for non-developers to get started with Mezzanine? Is there a way to do it that doesn't involve installing Python, Django, virtualenv, Mezzanine, other apps, etc.?
I agree, Ross's tutorial is brilliant. Unfortunately it stops right before deployment. For a new developer, or someone who is tech savvy, but not a programmer - deployment can be a maze. I installed Mezzanine on a VPS, something I'm sure is fairly common - so the localhost wasn't available - so that complicated things a bit. Got mod_wsgi working with apache, but not with Mezzanine. Anyway, not to turn this into a support query or anything - but I think deployment is tricky. Ross ended up shooting over some code snippets and I was very grateful for them, but would love to see deployment covered in the same way he did the other parts of the tutorial if there are any takers.
I discovered Concrete5 ( http://concrete5.org ) a few years ago after building many Wordpress sites (large and small), and totally fell in love with it. It's not perfect, but it's much better than any other CMS out there for end-users, designers, and developers:
* Editing UI is on the front-end -- users just go to the page they want to edit and click on things to edit them, which is much more intuitive than a back-end dashboard
* Content on pages is a collection of "blocks", so each portion of content on the page can be edited separately (as opposed to one WYSIWYG editor for the whole page). I've even built a free addon that lets designers compose their own custom block interfaces ( http://concrete5.org/marketplace/addons/designer-content ), so if you have a "employee bio block" (for example), you can have an image chooser, a textbox for a headline, a wysiwyg editor for the description, and a page chooser for a link instead of requiring the user to fidget with alignments, floats, and custom styles in TinyMCE/FCKEditor.
* Create themes from your existing design / markup -- the CMS flows around your design as opposed to you having to construct your design around the requirements of the CMS (this is much more of a problem with Drupal than Wordpress, but still gets annoying in WP for non-blog-like designs).
* Underlying architecture is fairly sane -- definitely has some idiosyncracies, but nothing like Wordpress (or Drupal or Joomla). There's a simple MVC pattern going on so you separate your model / controller / view code, and the underlying system has a decent "API" for working with pages, content, users, files, etc. Also, if you have very customized functionality, you can just create a separate page in your site and tell the system to not do anything... that you will handle everything yourself on that particular page or area of your site.
The only downside is that it's not as popular as wordpress so the documentation is lacking and there are not as many free plugins and tutorials available (but hopefully this will continue to change as time goes on).
But it has made building CMS-based websites so much more fun for me. Hit me up ( concrete@jordanlev.com ) if you want to discuss further or have any questions.
I liked Concrete5 when I was playing around with it. I was very excited by its potential; especially looking at projects where maybe WP was overkill.
Where the bottom fell out was in two areas:
1. Paid plugins
I cannot rationally tell my clients 'this software might have a few cases where it is easier than WP to use and manage; but you'll be spending several hundred dollars replicating free functionality available on WP'.
Its a non-starter.
2. The software still looks kind of 'hokey' compared to WordPress
WordPress has lots of issues and there are a ton of other great alternatives. But, its like Facebook vs. all other social networks -- you go where the people are because it makes everything better.
1. Yes, there is a lot more of everything available for wordpress (free and paid plugins/themes). I think this is what a lot of the comments here are saying about why Wordpress is so prevalent... not because it's good necessarily, but because it just has so much stuff available for it.
FWIW, I build custom-designed sites for my clients, and I deliver complete sites that don't require any additional functionality. I don't even bother telling clients how to install new plugins, so for my situation this is a moot point.
When I do pay for plugins, it's because the functionality it provides would take me much more time to build myself (so if my rate is $100-150/hr., paying $30 or $50 or even $200 for something that would take me 4-8 hours of work is a complete no-brainer).
2. Not sure what you mean by "hokey"... the front-end is entirely designed by the person building the site, and the back-end uses Twitter Bootstrap (as of version 5.5 which was released last year). But to each their own :)
I too have moved from Wordpress to Concrete5 and was a huge fan. I appreciated the flexibility of the system, combined with the free availability. However, a few things have started to bother me about it:
* The CMS interface is very powerful, which can be a good thing in some cases, but for most sites I make it is more of a liability than an advantage. Users can easily format the headline red because they think it deserves more importance, they can add new layouts everywhere adding columns to pages etc. For pages that are carefully designed, this provides a lot of room for screwing up the site, both accidentally and on purpose.
* Due to the power of interface, it becomes a lot more complex than it should be. While this may not be a problem for advanced users, for small sites (small business, club, individual person etc) the person editing the site is often not too skilled and every new menu is a new opportunity to get lost and to click the wrong option. If I click a block, there are about seven options and only half of them should ever be used by the editor. Custom options for a site are hidden in a page properties menu somewhere and there are so many options that should never be touched on the way to get there.
* I have been disappointed by the lack of commitment to excellence and best practices by the Concrete5 team. There are so many parts of the system that are made to “just work” instead of being based on modern best practices. Half of the blocks produce HTML that you don’t want to have in a modern HTML5 based site. I know that you (jordanlev) have been working on some improved blocks, so kudos for that! Also, this is more of a general impression and I haven’t been using C5 for about a year, so things might have changed.
* Creating custom blocks comes with quite some complexity, so you either have to invest the time to create them or try to work with an existing block and work around their limitations. Try having a table on a page that can be edited by the user with the possibility to add a class to some rows so they can be highlighted with CSS.
* I’ve had a lot of performance issues, where a site would take ~10s to load the first page.
I would still use Concrete5 for projects where I know that a lot of flexibility without my intervention is needed and there are skilled people who will be able to edit the site without screwing everything up or when minimal costs are needed.
For all other (small) projects, I have started using Perch, which isn’t open source, but an absolute joy to use. It’s reasonably priced, gives you real control over the code and makes it possible to have a nice, well-documented interface for the editor where they can easily edit everything within the boundaries that are defined by the design. Where a custom block in Concrete5 needs several PHP files, an XML database schema etc you just create a HTML template file with some template tags in Perch and you have full control over the order, labels and help texts in the CMS back-end.
It took me a while to get my head around the concepts and see which problem should be solved which way in Perch, but now I finally have a CMS where I have full control over the code and can make the edit interface as easy to use as possible, with minimal effort on my part.
I realize that this sounds a bit like a sales pitch, but I have no affiliation with the developers. Of course, there’s a risk associated with using a closed-source product by a small company, but Perch has been around for a while and the development continues to be very active with a very responsive team.
And don't forget the amazing amount of functionality that's available for free using the plugin system.
It's a classic software development problem - Wordpress's complexity is both it's strength and weakness, and will probably be it's downfall one day (but not just yet)
On the other hand, most of the free plugins are awful. Many of the paid ones are as well, in fact. Many plugins can bring your site to its knees as soon as five people look at it sideways.
And the templates, some are simply STUNNING it makes you wonder why pro designers charge you so much for stuff that barely holds a candle to stuff you see on WP.
Then you install the template and everything goes to shit, you have to read some of the stuff support writes to users, it boils down to "we sold you a broken product and now we will give you just a hint about how to get it to almost work".
Still lightyears ahead of templates on other CMSs...
> Still lightyears ahead of templates on other CMSs...
Yup, but I think that's primarily because WordPress has a stranglehold on the market. Nobody will use another CMS because WordPress has all the stuff, and nobody will develop mass-market stuff for another content management system because WordPress has all the users. The network effect is strong, and displacing WordPress wouldn't be profitable enough to be worth the effort to counteract that effect.
(Obviously this is a slight exaggeration — somebody uses another CMS — but I think it's pretty accurate from a bird's eye view.)
I think the best way would be to come up with a way to port those templates to other CMS that doesn't involves rewriting the whole thing, or perhaps a wrapper?
Then you install the template, and realize the only reason it looks so good is because they have pretty top notch photos and pages filled with content.
I've found plugins to be extremely hit-and-miss, though.
I was helping a photographer friend who bought a commercial theme, which broke admin-side Javascript when he did the 3.4 -> 3.5.1 update. We still haven't figured out exactly what happened, but it just reinforced for me again that a) Wordpress hasn't adequately documented which APIs are stable and not, b) Authors, even of paid add-ons, don't keep their stuff up to date.
The theme replaced jQuery bundled with WordPress with some external version (eg. Google hosted or otherwise) and did it so on both the admin and front end. That's usually the cause of those sort of issues. 3.4 -> 3.5 brought up a lot of JS compatibility.
Look in the theme's directory for `wp_deregister_script` and see if anything was deregistered and re-registered (`wp_register_script`).
> Wordpress hasn't adequately documented which APIs are stable and not
If it's it in a major release, it's stable. When you buy any piece of software you're relying on its author knowing "the right thing to do (tm)". The author of the commercial theme thought it was okay to replace some bit of core javascript and din't bother to check on it. Or they didn't bother to be specific about it -- only do custom JS stuff on their theme's options page or on the front end. It's easy to do that, but you have to know how to do it (it's not documented in the Codex).
You could take a look at FeinCMS for Django. But seriously with Rails or Django - especially Django due to the admin site - a bespoke CMS is a fairly trivial endeavour. My initial CMS took a couple of days and it's been easy to extend it for every site that's come along since.
It's a hell of a lot easier for end users than Wordpress and as it's bespoke for every client, they never get clobbered with chunks of the admin that bear only a loose relationship to their own content.
I'm just catching up with this thread but the reasons that jshakes states in his blog post is some of the reason why we started hacking away on http://getbarley.com/ We'd love to open source it (API is built on CodeIgniter) when its ready.
My .2 about the current state of CMSes is that it is time for a bit of a disruption. WordPress codebase is directly tied to a lot of very big publications being able to do business daily and I don't see it being rewritten from scratch any time soon. Unless, of course, a sub-project is created. That being said, there is a lot of room for new ideas, new approaches, and new CMSes to capture at least _some_ of what WordPress currently powers. Another reason why we started hacking away at Barley... we think it is time for something brand new that is MVC from a codebase and specifically built for HTML5 / Mobile from the front-end. We hope we're right.
ProcessWire isn't just the best PHP CMS out there right now; I'd argue it's the best thing to happen to the CMS landscape in the last few years.
There are more powerful CMSes out there, to be sure, but the crazy thing is just how completely unprecedented PW's power is for its ease of use. It's easy like WordPress, yet it's scalable to enterprise sites with deep content taxonomies.
And it's elegant. Ironic for something built in PHP, I know, but working with its simple building blocks of templates and fields and its jQuery-like content selectors comes with a feeling of "why didn't someone do this a long time ago?"
I maintain a number of sites that use PmWiki [1] as a CMS. The community's small (though active), it's in PHP, and the editing isn't WYSIWYG, but the reason I ended up with it in the first place is how well the framework is organised and how easily add-ons can be packaged and included to add to or even replace core functionality. Templates are also completely separate from the PHP.
One feature of PmWiki that I've yet to come across in any other CMS are PageLists, which allow you fetch semi-structured data and other content from the rest of the site and displaying it using a custom template.
Our CMS, Forge (http://factore.ca/forge-cms) is a semi-open source (in that you're free to use it for whatever you want but we don't have a community built up for it yet) Ruby on Rails CMS that focuses on rapid application development. It's VERY opinionated (moreso than Rails) but it lets you get things done really quickly and mostly stays out of your way on the front-end. Shoot me a message if you're interested in checking it out.
Why do you insist on using GoDaddy? This is a particularly terrible ISP which severely and artificially limits your deployment options... why should your choice of blogging software depend on it?
I don't insist on using GoDaddy. My point was, and I probably didn't state it clearly, that the reason Wordpress is so popular, is because it's easily installed. Also, the reason why it's piecemealed together.
I've been learning the webapp2 framework on Google App Engine. I took the Udacity CS course and the web development course. I have a site on GAE, I built using Python. It took me six months from start to finish and lots of trail and error. It was fun for me, but definitely not everyones cup of tea. Most people aren't going to take the time.
"I would love to be able to solder things together as easily as I can hold them together with duct tape. To me, that is what makes duct tape the best."
The "automagical installation" is something that can be done, but it's up to the provider to do it. A Python website (as well as for Ruby) ain't a bunch of files served by Apache, but something more... smart.
Call me crazy, but being able to drop files into a docroot of an apache install and have them Just Work seems like a much smarter market strategy for uptake of your product than what can currently be done with either Python or Ruby.
Then again maybe you had a different idea of "smart".
As someone who hasn't spent a ton of time extending any CMS but uses a lot of frameworks, I enjoyed EE too during the short amount of time I used it. Out of wordpress, drupal, and EE, EE is the one where writing plugins felt like normal programming since they hooked right into code igniter. (Not sure how things have changed in the last couple of years though.)
Main downside of EE that I remember is that when you add new functionality, the way it accomplishes this is by dynamically altering a table schema to add new columns. You can easily get up to hundreds of columns. That just seemed like it had to be a wrong approach to me, but I didn't investigate further.
Is ExpressionEngine better for medium to large sites? I've worked with it a bit and did not like it at all, just wondering what it's better for. Did not seem as intuitive for content creators or mom and pop site users.
I don't think EE is intuitive for Mom and Pop people. If that's your market then WP or something else will probably suit you better.
But if you're an actual business who can spend an hour training your Content Manager(s), then it's worth it, IMHO. It's a dedicated CMS and IMHO better to work on than WP.
I might be in the minority on HN, but I think that WordPress is doing fine just as it is. Whereas my gag reflex kicks in at the mention of a Drupal contract, WordPress is still pleasant-ish to work with. It's simple enough that I can get my own custom work done without having to spend a ton of time fighting the core system. Though, YMMV depending on the nature of the custom application, I'm sure.
I love that everything custom must go into wp-content. I love that any custom theme functions are supposed to go in functions.php. This keeps things easy to isolate and debug. Its an extreme whose opposite is Drupal, where some obscure functionality can be popping off in one of hundreds of .module or .tpl files.
Its pretty much summed up by "my gag reflex kicks in at the mention of a Drupal contract, WordPress is still pleasant-ish to work with".
I mostly agree, except it's not "simple to customize" in even a majority of cases.
The 'upload and online', however, is and will continue to be the killer feature that will keep rails/python/java/etc-based CMS at a major disadvantage.
Starting projects today, I prefer Grails. Starting a project which I had an intention of distributing to a wide number of users (potentially for eventual world domination), I'd use PHP. Nothing else comes close to the ease of getting the widest number of people able to upload/install.
As far as I can tell WordPress is stuck. Its success is largely down to the number of theme's and plugins it currently has. You can build pretty much any basic functionality by just installing the plugin's for it.
A rewrite would probably benefit the performance and abilities of Wordpress but it would be at the cost of ALL the themes and plugins. The platform would start again from scratch. I don't follow Wordpress too closely but I haven't heard of any one talking about - or having the energy for - such a rewrite.
Would Automattic even allow such a rewrite to go through? It would be a horrible transition for Wordpress.com.
As for alternatives... There are a number of good CMS with a well designed, easy to use admin panel. They aren't popular though, plugins are scarce and support is uncertain. This often makes Wordpress the best choice by default. Which is kinda sad.
It's massively entrenched because of the network effect of the themes and plugins, no doubt. What will overtake wordpress as a blog/cms platform is something that can allow for a large number of the popular themes and plugins to be dropped in (or converted silently). It probably won't happen, but think of Lotus/Excel, for example (or WordPerfect/Word) - both Lotus and WordPerfect were dominant for a long time. People converted when their data/functionality was easily imported in to MSOffice. It's not a perfect comparison, but I suspect this will be what is needed to get people to migrate from Wordpress.
Even that will be an uphill battle, given how many wordpress installs are one-click installs from control panels, somewhat customized to the specifics of that control panel's paths/security/etc.
But the thing is, many of the major flaws of WordPress are baked into its theme and plugin formats. Much like with Excel, you'll need to match it quirk-for-quirk to interoperate with it. And what's the point of simply reimplementing WordPress?
I think you could probably get away with shooting for something like 70-80% functionality via a wrapper layer around your new APIs. Even Excel and Word aren't 100% compatible between their own versions, and WP is going through a transition period where many older plugins don't work either.
The goal would not be to reimplement all of wordpress, but implement a compatibility layer suitable to emulating enough of the basics to allow some migrations and encourage people to try out something new.
There's dozens of CMS and blogging engines out there, but no one has attempted a WP-emulation layer (as far as I can tell). Although, given it's PHP nature, and direct grabbing of $_GET and $_POST and such, it may simply not be possible at all.
Wordpress is making big steps in the right direction.
* Their wild pile of oddly-named functions are being deprecated and moved into well-designed classes.
* Better templating options are being promoted.
* Yes, the global $wp_query leaves some to be desired, but at its core, wpdb's WP_Query is a decently powerful database abstraction, and if used right can perform well at scale.
No, the hooks aren't going away, nor is the URL-to-template mapping. But those are the parts that make it so flexible and easy to work with. MVC is a controller dictatorship, WP's code is a democracy.
I think curation and code review should really be an important part of the theme and plugin repositories.
Perhaps they need 'approved' and 'Open' directories for the repositories?
There used to be this issue with people having issues distributing plugins; now with github, that is much much easier.
There is just so much bad code floating around, people not following best practices and loading JS libraries that core includes, conflicts with other plugins, etc. Its a mess.
Code review is a part of the theme repository, if you're talking about themes hosted on WordPress.org. Themes hosted elsewhere (ThemeForest, GitHub, etc) have no such oversight.
Themes hosted on WordPress.org (the official repository) have to pass through the Theme Review Team, which does enforce certain guidelines and standards: http://make.wordpress.org/themes/guidelines/
There's also a large group of people moving to add similar oversight for the official plugin repository; but when you have a repository with 24,000+ separate projects, managing a code review for each one - and for changes to each one - is a huge undertaking.
I had heard there was a Code review for the theme repository, my feeling (pure speculation) is that the review process is there to weed out truly bad coding or malware but there was no strict edicts on style or 'the right way to do things'.
I understand enforcing methods and whatnot is probably not in the best interest of Automattic, WordPress.org nor the community; if it is feasible at all. I'd just like to see some kind of curation based on 'the right way to do things', if anything just so I know when I'm doing things the right way.
The Codex and general documentation has become a bit muddled with new APIs and conflicting philosophies between developers. What used to be WordPress' greatest asset (its documentation) is starting to falter behind a bit. It's been hard for me since ~3.2 to figure out where I should be changing my boilerplates as WP updates.
I follow TRAC, I keep as updated as I can on future changes and point releases but without solid documentation sometimes I feel like I don't know if I'm doing things the way they were intended.
The settings API [0] is really bad. That said, you can still use parts of it without the `add_settings_field` and `add_settings_section` bits.
Or you can build reasonably powerful abstractions over top of it that let you get a lot of stuff done quickly.
The power of the settings API is users can go in and remove fields. This plugin I installed has a field I don't want to show to my client? Let's just remove it. And we can do that without editing the plugins files directly and keep it safe for upgrading.
I'm yet to inherit a PHP project that does not contain a file called "functions.php" and it always makes my heart sink when I see it.
What I don't get is the demand for all kinds of stuff to be built on top of wordpress that doesn't really have much to do with content management or blogging. For example online games, CRM systems, auction sites etc.
Seems a bit like asking for a CMS system that has been implemented as a minecraft mod.
People treat WordPress like a Swiss Army Knife because they can. Why build an online directory or CRM or auction site from scratch when you can just use WordPress? It can be a bit sloppy, code-wise, but it works and you can get the job done a lot faster than it would take to do it from scratch.
Consider an online business directory. You could just build one from scratch or use some script designed for that purpose but WP simply offers more flexibility. If you decide you want a Google Map displayed in each listing, just download the relevant plugin. If you want to add oEmbed functionality (for, let's say, embedded videos), it's already built-in. If you want to do advance taxonomy queries use the Taxonomy Drill-Down plugin, etc.
Yes, it's all held together with chewing gum, but it works.
I suggested our company site be re-done using Joomla. The original site was on an ancient platform that we don't work with anymore and we kept an entire server around for it.
We spun up a cloud server with Joomla on it for production use, and a local VM for testing. We had a template created for a couple hundred bucks from some ideas our designers came up with (they can't code, so...) from an Eastern-European on a freelancing site.
Then we just let our marketing guy (also can't code) and some interns loose putting up content. It took a few weeks of their spare time and we had a great looking, functional website.
Since then, the marketing guy has installed a hundred different 'Joomla plugins of the week' and brought the site down a bunch of times, trying to make it into a blog, newsletter, signup sheet, web store...
Ugh I have been there with Joomla... my marketing guy thought he was creating Yahoo! for the 21st century but in reality he was breaking the site every 3 hours and then calling me for help.
Granted I'm not a WP expert but something like CRM seems like something that would be a different category of problem to what WP is intended to solve. It would seem like fitting a square peg into a round hole, where most of the existing functionality wouldn't even be very relevant?
My understanding is that for the more complex examples (CRM, auction site) it doesn't work particularly well. Sure you can do it but if you're having to work with Wordpress internals rather than rely on plugins that someone else has written that's when the pain hits.
I did take a look at that, and developers were still complaining about it. I also wasn't too impressed with the way that Woo went about acquiring the project to be honest.
It makes me wonder if the companies behind that online game and auction site were "sold" Wordpress by a developer/designer as a way they could easily update their website. Perhaps whoever pitched Wordpress as a solution in those cases didn't have the knowledge to build a fully functional website from the ground up without Wordpress.
As a fellow PHP developer, I can say I share the heart sinking feeling when I see "functions.php".
A lot of it is due to the fact that it's much easier to sell an end-user on a plugin to their existing site that requires little to no server configuration than a completely separate system.
Whether or not it makes sense as a WordPress add-on is not really taken into account by users, who just see it as easy to set up and manageable from the same dashboard as the rest of their site.
Perhaps they were comfortable with WP, perhaps they didn't want to spend time reinventing the wheel, perhaps they didn't want to have to support a massive body of code.
If you go to the sign saying 'Put stuff in this box so you don't lose it' and then go down the map in a straight line, until you get to desert. There's a little skinny bit of desert the goes between two blobs of ocean? Just above and to the left of that there appears to be a surface spawner,
There also seems to be quite a few chunk-error style generation artifacts.
Minecraft servers with world maps that allow users to select different view styles need to be gently careful. One longform troll is to mine an enormous swastika at a specific depth. It takes so long to do this that map-resets are unpopular.
The main benefit to Wordpress is its built-in content editing system that's mostly accessible to end users. So you can build a site for someone and then show them how to use the nice admin interface and page editor, and let them manage the content themselves after you're gone, rather than having to be involved for every little page change afterward.
And of course as others have mentioned, the plugins are pretty great too. A client can ask you if you can do X (e.g., tie into their Twitter) and BAM, install a plugin, done, you look like a hero. Compare that to having to write/install/test something similar.
The main problem perpetuating Wordpress' design woes is its plugin ecosystem and how it depends on Wordpress' internals. A massive hook system, scopeless globals passed around like nobody's business and overall reliance on how "things work" right now - if you change any of that, you break most of the plugins (the code for which looks even worse than Wordpress itself).
An idea I always have in the back of my queue is to write an adapter over the hook system and various state variables plugins expect to have, and bridge it (the plug-in system) to something like the Zend Framework or Symphony. The amount of work involved prevents it from becoming more than a pipe dream.
Not what I was talking about - this allows you to run wordpress on a symfony site and share user state (pretty trivial).
I'm talking about an adapter that allows you to run Wordpress plug-ins - without Wordpress. Basically allowing you to write a normal blog system while leveraging the huge community and functionality of WP plugins.
This article is good but misses a minor point: Wordpress was never intended to be MVC, the developers had probably never even heard of MVC when it was first developed. Wordpress is a bastard.
I've thought about how terrible actually hacking on Wordpress actually is, and truth be told, the horribleness is so entrenched that any kind of form or community effort to improve it would introduce incompatibilities with the ecology that are insurmountable. Wordpress is stuck.
> Wordpress was never intended to be MVC, the developers had probably never even heard of MVC
Not only the developers, maybe even most developers outside of certain communities. I'd been exposed to the concepts, but I'd never worked on an "MVC" site until about 3-4 months after the first release of WordPress, and I'd been doing for over five years at that point.
> I've thought about how terrible actually hacking on Wordpress actually is
Hacking core is pretty bad. Heck, even reading core to try and understand what's going on under the hood can be a challenge.
But writing themes and plugins is not that bad -- indeed, if it was, I suspect you would find a far smaller mass of them. It's not MVC, and particularly if you're used to that organization of a web app, it's disorienting, but the APIs are reasonably organized, well-specified, and let even n00bs get things done.
Software rewrites are extremely challenging, and more often than not, fail (good example: http://www.joelonsoftware.com/articles/fog0000000069.html). Perhaps a more measured factoring approach over time would be more appropriate?
I don't understand the point of what he's proposing. Rewriting WordPress as completely as he wants and breaking all existing plugins and themes would surely just result in someone forking the existing code and maintaining a backwards-compatible version.
The ecosystem is the valuable thing, and they'd be insane to throw that away. All the problems he notes are basically just a result of WordPress growing and changing over the decade it's been around, and/or direct results of having originally been written in PHP 4.
Gradual refactoring, as you say, makes more sense. Otherwise you might as well just build an entirely new system from scratch.
WordPress is already going through a measured factoring approach.
Themes were ported over from a mishmash of procedural calls into the WP_Theme object in version 3.4. Posts (and pages, custom post types, etc) were ported over from an associative array and various procedural calls into the WP_Post object in 3.5.
But WordPress does - and likely always will - work to retain backwards compatibility so that existing themes and plugins won't choke after a core update. So even when newer APIs and refactored objects exist, its up to individual developers to 1) learn about them and 2) start using them.
Since then, there have been common infrastructure components like Create.js, PHPCR, and Symfony2 that have been widely accepted by many of the projects. Through that, the state of Content Management is now steadily improving.
Sadly, WordPress has so far stayed outside of this development.
I think the first step would be that the Wordpress core developers start to mingle with the PHP community. I simply have not met a single Wordpress core developer at any PHP conference and I tend to go to 6-10 a year in various countries around the world.
I have also not seen any Wordpress core dev participate on an php-src internals discussion let alone something like the Framework Interoperability Group that outs out the PSRs.
Note I guess it might actually be that I did come across a Wordpress core dev, but maybe they just didnt identify them as such.
But without communication the chances of collaboration are low and without collaboration imho its going to be hard for Wordpress to identify and assess the potential for new directions.
That being said, Wordpress is king of the hill and it at least right now there is no indication of this changing. So changing might just have a ton of risks with maybe little chance of success. Then again I guess AOL once thought quite similar about their position.
PROTIP: If you want to get rid of wordpress, make something that will run on cheap hosting with one click installs, and be easy enough that a non-technical user can setup their own site with it.
Until the ecosystem shows any signs of slowing down, posts harping about the codebase of WordPress will lack conviction. There is an army of developers who don't particularly like the inner workings of WordPress. But WordPress is thriving and has a booming commercial & free theme and plugin market. A glorious rewrite in whatever ideological direction you want to take it is more likely to damage its success. If a better codebase is so important, another CMS should eventually gain more ground. In which case, it's more productive to talk about why another CMS is so good, rather than lament about WP.
Having said that, the codebase is likely to become more javascript centric, which might make things even more complex. It will be interesting to see it evolve. I just don't think calling WordPress 'dire' accurate. Nor is it in need of rewrite just for the sake of writing more beautiful code. Does it have to adapt and evolve? Of course.
Words are wind and WordPress is not gonna be "fixed" any more than PHP itself will.
If you want something different/better, start it yourself and evangelize it. If it really is better and you do a good job hopefully it will eventually win out.
That's probably fair but PHP is never gonna be totally sane. There will always be weird quirks that are just ingrained in the language. Every language, every application has weird shit because it's all made by people who are just bundles of weird shit.
The problem is when someone else's weird shit is incompatible with your weird shit.
The beauty of WordPress is its ubiquity. I jump on my hosting account, click on the 1-click install and bingo. Click upgrade WP and boom - upgraded. Choose one of thousands of free themes and yipee-ki-yay!
The multitude of themes and plugins and the fact that I really have no need to get my hands sticky in PHP unless I really have some desperate need to fiddle with a pot of goo, is really what makes WordPress number one.
It might not be great under the covers, but the lipstick on this pig just seems to be enough to keep me happy!
Fixing WordPress's code problems don't really need to break plugin compatibility. They can rewrite the core, have new features requiring doing things the new way, and have small adapters to maintain the backward compatibility.
But yes, this refactoring is going to cost and there is unfortunately not many people for whom it is a worthwhile expense. If Automattic is able to think about 10 years in the future, it might make sense for them to start investing in such a clean up.
It's a very tough act to balance, because too many changes will prompt criticism that all kinds of things are breaking on a new update. You can't please both ways, so things move pretty gradually.
Having said that each new version has improvements. The direction I think is more dictated towards where the web is going. Each new release increases the amount of javascript, even backbone has made its way into core. There will also soon be better support for other DBs.
I agree with the conclusion that WordPress developers could use more "rules" when developing.
But there's really nothing keeping you from defining your own rules and working within the WordPress system. It's not MVC, but you can get something as good by keeping frontend-related code/templates in a theme and backend-related code/modules inside of plugins.
The problem is that 3rd party plugins you use might not use your rules. So the code you are getting for free (or cheaply) isn't coded how you would have liked. Code it from scratch or re-factor it to suit your needs. If you were using another framework, you probably would have had to code that functionality yourself anyway.
While I'm at it some more pet peeve's RE some common complaints:
* Everything is in functions.php. Cool, so setup YOUR functions.php like this:
require_once("includes/config.php");
require_once("includes/settings.php");
require_once("includes/helpers.php");
require_once("classes/class.myclass.php");
Problem solved.
* The posts table doesn't support my data structure. Awesome, just add your own table and add a class wrapper to push/pull data. Add methods to search or whatever you need. Sure this may be slightly easier with other frameworks because they do a bit of that for you. But if you've done this once before, you just copy and paste the code and change the object names, etc.
Maybe I'm wasn't disciplined enough when I used PHP frameworks in the past, but with all of the structure and rules, I found myself wasting as much time working around those constraints in special situations as I was saving using their module scaffolding/etc.
(Again) I agree with this article 100%. Wordpress is so messed up right now. It's codebase is clunky and it has a lot of redundant code (variables especially) out there.
I want you to:
Install Wordpress version 'X', develop themes and plugins for it and do an update after say, 6 months or after a year or so and tell me it doesn't break anything or show weird behavior. (Some versions show CPU spikes even for simple post aggregations)
Some examples of redundant code:
Try creating pagination for a page and you'll notice they use two variables $page and $paged for the same functionality and this has zero documentation, you need to spend hours and hours trying to find out if it was you or if the core of wordpress is so bad. Wordpress has become bloated because they want to maintain backwards compatibility with previous versions, which I think is a bad idea for NOW. They could easily launch a new version removing the support for old versions, just like JQuery did.
Don't get me wrong - Wordpress is the best blogging solution right now you'll ever find, that's so polished and so forth. But it's the worst CMS you can build on top off for your projects (been there!).
Right now, the best solution for me would be:
rails generate scaffold Post name:string title:string content:text
The author states the problem himself: Wordpress is a blogging platform that people are trying to turn into a full blown CMS.
Stop trying to do that. If you want a "real" CMS with serious content types and a more thought-out plugin system, go use Drupal (if you have to use PHP and not much time to code). If you have more bones for coding, start with Symfony like your colleagues, or Django, or RoR.
If you have even the faintest inkling that a site will mutate from a blog to something more serious, don't start with Wordpress. If your fundamental data types from day one until infinity are not pages or posts, do not start with Wordpress. You cannot make it into something it's not, even though it's getting so popular that enough people will be tempted to do so.
The reason Wordpress is still so popular is that blogging and basic website creation are still getting more popular, and Wordpress is still a great way to accomplish either of those things since it will be used exactly as intended. I don't anticipate these common needs will shift too much in the near future, and the LAMP stack is just too stable and well-supported to go anywhere, so Wordpress is gonna be around for a long time.
> It is like trying to teach a language that doesn’t have an alphabet
Chinese doesn't have an alphabet. It's used by many people and it's possible to teach to those who use alphabetic languages.
That doesn't mean everybody should learn it, or that it's a model for how a de novo language should be designed today. Use it for what it's good for: talking with Chinese people.
In general, I'd just be more careful with cultural analogies like that.
> The author states the problem himself: Wordpress is a blogging platform that people are trying to turn into a full blown CMS.
Trying and succeeding.
Pressbooks, book publishing engine on top of WordPress (selfhosted & Saasversion)
Woocommerce ecommerce with 600k+ downloads (selfhosted & Saas version)
WP e-Commerce, 2 million+ downloads
BuddyPress, equips WP with social network features 1.4+million downloads
P2 Theme, quick community messaging almost 350k downloads
Collabpress, project and task management solution 36k downloads
bbPress, complete forum package, half a million downloads.
S2Member, Wishlist, DAP, MagicMembers, WP Member are among many other membership site solutions, >1 million downloads
Pods, Toolset and other solutions that extend its CMS capabilities, easily 200k+ downloads.
EditFlow, adds professional editorial workflow experience, 50k+ downloads
Fundify, Ignition Deck, crowdfunding solutions on WordPress.
And look in the wild, sites running WordPress: Real estate sites, agencies, hotel sites (there's a WP saas for that now too), restaurant sites (Happy tables), auction sites, market place sites, portfolio sites, photo gallery sites, governmental sites, membership sites, marketing sites equipped with landing pages etc, news sites, online magazines, Event sites and more.
Just a blogging tool, I see. Do continue to look away as it is only going to get worse (in your eyes).
Most people using WordPress are not developers. So naming conventions that might make sense to you don't apply to the average user.
It's called "wp-content" because that's where all personal, custom stuff goes--all your photos, plugins, etc. (Not including your MySQL data.) When you upgrade WordPress (which wasn't always automatic) your "content" is left untouched--because you want your own stuff apart from the rest of the application. The other directories, more or less, are owned by the core developers and Automattic.
Since 2004 when I started blogging, I've watched WordPress add so many bells and whistles. It's the opposite of what made it appealing in the first place, an elegant "poem" of an application. Now with so many developers working on it, it tries to be all things to all people.
What's interesting to me, to see websites outgrow WordPress. Sometimes your content expands such that WordPress can't deal with it. WordPress is a one-size-fits-all solution and that's ultimately limiting. At that point you can contact someone like me to create a custom application from scratch that just does what you want--not 1000 extra things you don't want, yet preserving your URLs for SEO, etc.
If we can't get WordPress to change, why not fork it and build a "developer" friendly version while maintaining compatibility with subsequent iterations of WordPress?
Frankly, I find the people who run the WP development community to be insufferable (Matt included). If you've ever read their discussions for code changes, it just makes you want to pull your hair out. Their pedantic in fighting rivals Wikipedia.
Maintaining complete compatibility with WordPress, including any future changes, while trying to clean up design problems (how is this actually possible without breaking anything?) would be a full-time unpaid job from hell and who would actually thank you for it?
Exactly. Everyone that says "fork it" also say "maintain plugin/theme compatibility". That compatibility is part of the problem. The best solution is something that is easy to install and administer for non-dev users. To get something with the extensibility of wordpress will probably take a very long time. For now we just have to deal with what wordpress is.
As others have mentioned, forking WordPress won't help. Writing abstraction layers might help a little (I've done that myself a few times) but instead, if you use WordPress, I'd encourage you to get involved with improving it directly. It's a slow process (especially as WordPress still supports PHP 5.2) but there is progress.
If you know PHP then there's loads of issues you could get involved with to help move it forward. Here's just 4 that could do with some attention:
I've used Symphony CMS (getsymphony.com) to build several websites, one of them quite large. I love it. It's the first CMS I've used that isn't a total mess architecturally. At it's core it provides a highly customizable interface for maintaining a database of content, XML data sources that pull from that database (or external XML sources), and XSL templates that are combined with the XML to produce the HTML pages of the site.
It's totally open source, and development is carried out on github (which includes all its extensions (http://symphonyextensions.com/)). The developer forums on the main website are active and many of the core developers answer questions rapidly. I can't recommend it enough.
Its downsides are 1) XSLT (some people can't stand it) 2) No polished off-the-shelf templates, you'll have to roll your own (but it's easy enough to get something up with Bootstrap and tweak it for your purposes).
I could not agree with this more. As I've developed larger and larger sites the more I've become frustrated with how hacky and garbage even "solid" WP code is. For crap's sake, if you use child themes you have to make functions with no return values. You have no choice.
Is a rewrite the answer? I dunno, but I sure as heck moved the WP sites to WP Engine rather than risk our servers' health on trying to deal with security and performance.
I still think it's hard to beat when dealing with a lot of content. There's at least a hundred ways to enumerate all the ways the admin sucks, but it is pretty functional compared to say, Joomla, which we migrated from. Joomla is a black box with no particular logic where I have to reach for horrific third party bullcrap to accomplish even the most basic tasks. If you have experience with Joomla, imagine managing 5000 pages with it.
Somebody writes this article every few years, and whenever it's published, a greater percentage of the Internet runs on WordPress than at the time the last article of its type was published.
WordPress is pragmatic, and that has paid off for the project. I think more projects should follow their example.
Interesting article. I actually do like developing for WordPress, but agree with you on many points. I'm just in the middle of having to write extra code to create a table in the database to hold some additional meta data for a custom taxonomy (sigh). Like many developers (I suppose), I've just built a small set of tools that allow me to get round some of the major issues, and starting with a decent theme (I'm quite a fan of Roots) can allow some pretty solid web development. It's never going to be quite as good as a ground-up build, but finding the hours to push into user interface development is hard - the settings and admin screen APIs in WordPress aren't bad.
Some really excellent comments in this discussion. While there is some predictable reactions (my way is right! your way is wrong!) I'm impressed by the number of people who've taken a more nuanced view of how and why platforms get adopted by developers and regular folks.
One thing I'd encourage people to think about in terms of how we take WordPress to the next level isn't just that we have a ton of plugins and themes that people love, but how we got them in the first place. That network effect wasn't always there, it developed over time, and was caused by something.
I do a lot of work in both Magento and WordPress and Magento has often been cited as a way of "doing it right" being built on Zend and all. If that's doing it right, I'm happy with doing it wrong.
WordPress is a great way of getting going fast. Probably a lot of guys come upon the thing just about the time a product is ready to be sunset or needs to be introduced to a team. Anything at that point is due a rewrite. I would imagine this experience alone is the cause of much consternation and whatever the product/website would have been built on would be the whipping boy.
For all the people mentioning Joomla, are you talking about 1.0, 1.5, 1.6-1.7, 2.5, 3.0? The framework, the CMS, or both? These are all radically different products, which is symptomatic of the challenges that project has had. I'm curious to know who thinks it's gotten better, or worse, and why -- or if everyone's just recalling the 1.0-1.5 era when Joomla had more adoption than anything else like it.
There is always Habari, the newer, modular “microkernel”, modern PHP based, Apache-licensed CMS/blogging platform. Since it’s PHP, it features the same easy deployability. But it has stagnated in the last years and only recently has development taken up speed again. If you’re interested in hacking on something like that, drop by irc.freenode.net #habari or mail to habari-dev@googlegroups.com.
To ease out some of the pains James writes about, I created a bare Wordpress repo that is designed to separate content, media and wordpress' own files so it works better with git, git submodules and deployment with ie. capistrano.
To rewrite WordPress successfully (so it doesn't break everything all at once) would take a hybrid approach, making hundreds of rewrites of smaller chunks over time, maintaining compatibility while improving the code, allowing theme and plugin authors to support new implementations as they are offered, deprecating old ones over time.
Rather than tackling a rewrite of Wordpress itself, what about a set of conventions and practices for add-ons and themes, a clearly defined set of API functions, and an automated validator to enforce at least some of it.
Even if the validator was just a grep for function calls outside of a whitelist, that would be an excellent starting point.
More a framework than an CMS really, the best thing about it is you can build how you want to i.e everything is incredibly flexible. For clients you can easily create a super simple interface for editing.
I was wondering if I would see Umbraco (www.umbraco.com) here - I just used it for a project and walked away very impressed. And the client loved it. Version 6 is moving to MVC.
it seems to me WP has tried to be everything to everybody and the cracks are finally starting to show.
I've never been a huge fan of WP for several reasons. One is the horror of trying to crowbar one of their themes into what I want it to look like. The second is the ungodly amount of bloat the have on their themes and templates.
Just give me something stripped down and lightweight that I can build on. Too many of these frameworks are just constantly in your way when you need to do something.
There is nothing stopping you from forking your own version of WordPress. It is GPL and as long as your derivative work is also GPL you should be fine.
i've had to hack additional functionality into some third-party wordpress plugins for clients. it is a nightmare compared to my own PSR-0/Composer projects. it's just an incredibly twisted kludge of code stuffed with globals and craziness. most unpleasant experience ever.
sadly, wordpress's massive plugin ecosystem of poorly written spaghetti is the very thing that will prevent it from being rewritten.
I think you mean it's successful because of its lack of rules, and I disagree. WordPress's low barrier to entry stems from a combination of PHP's ubiquity and a positive feedback loop of popularity. More rules wouldn't hurt either of these factors.
More like PHP's ubiquity which leads to easy installs for non-developers. The reason wordpress is so successful doesn't revolve around the devs. It's because your everyday blogger can setup a blog in 20 minutes. The dev focus comes from having so many users.
Umm, whatever, no rules implies _no safe assumptions can be made_. Getting WP plugins to play nicely with each other can be like sorting out INIT conflicts in the Mac OS 6 days.
See some of the real world issues, not programmer-level gripes you bring up. Which BTW show your lack of creativity in solving problems through thinking outside of the box.
I'll give you an example:
If you don't like get_permalink(), make yourself a get_the_permalink() { return get_permalink(); }
as a wordpress developer using it as a framework I love this like "WordPress isn’t a platform suited to anyone except those unlucky enough to have somehow become WordPress developers."
I'd love to see his vision of a code-cleanup happen to WordPress.
Considering Node can talk to MySQL - yes. Well, yes BUT.
The "but" comes in when you talk about existing themes and plugins - some are much larger applications, and all are built in PHP. So to migrate, you'd need to reimplement both WordPress itself and various themes and plugins in Node.
Not to mention that you'd need to build traction with developers to keep supporting it. Not every PHP master is also a JS master, so finding buy-in from the existing community will be hard.
Also, remember that PHP comes standard on most shared hosting environments - which is where WordPress is most often installed. Node, however, does not. So once you have developers on board, you have to get hosts on board to help set up the application.
I would argue, as others have done, that the author is correct in his points, but a rewrite would throw away the main advantages of using Wordpress over alternatives.
There are tons of successful initiatives to create a 'better' CMS. But they suffer from a lack of ready-made modules and a lack of developers 'fluent' in these systems.
In the end, it's about the right tool for the job, and unfortunately Wordpress is often the right tool despite all its issues. If we are caught in the Wordpress ecosystem, then perhaps the best thing to do is to 1) contribute to making it (slightly) less bad, and 2) create best practices for theme and module development, improve documentation, etc.
Why anyone would want to do that is beyond me though, but I deeply respect those who do so, instead of writing their own shiny and clean solution.
As for me, I started with Wordpress, no clue what I was doing, and very basic knowledge of programming. Wordpress worked, and I made a living.
Then I 'upgraded' to Drupal, and loved its flexibility and powerful modules, worked out my own 'admin interface' and happily used this base system for many complex sites. I made a slightly better living.
Then I got into Rails development. I learned about 'environments', TDD, MVC, and so on, and soon realized that Drupal has many, many drawbacks.
(And, as an aside, to configure and maintain these Drupal sites and the interaction of its powerful modules requires a skill and mindset that is about equal to writing (basic) Rails sites or using other frameworks. Except that in Drupal, instead of version-controlled code, you have one giant database and you click click click forever instead of writing a few lines of code.)
Now, I'm doing (in the eyes of many front-enders) weird shit like learning Clojure and Node.js to see what I can do with it, playing with a bunch of different frameworks and CMS offerings, and trying out these new-fangled front-end-heavy buzzwords like Angular, Backbone and Ember.
And yet, if a client has little money, or if I need something quick, I often still opt for Wordpress. It hits the sweet spot. If a client has more money later, well, then I could look into using a framework and rolling out something myself. Drupal, despite it's deceptive initial attractiveness, is almost never a good solution.
I use Wordpress mostly for the client. In the same way that I've inherited Wordpress sites after a developer disappeared, or if a designer couldn't figure it out, I assume others might inherit my projects. If the client has little budget, I really don't want them to be forced to hire expensive Drupal developers, or 'proper' developers who can figure out 'obscure CMS <x>'.
But generally I try to stay away from those clients, if I can help it.
"I’m not going to list all the things that make WP at odds with best practises, but here are the brass tacks"
There is a strange paradox that an infatuation with best practices seldom yields a successful product...because it seldom yields a product at all. And those products that do scratch itches and grow and evolve tend to have widely criticized code bases.
Wikipedia, Wordpress, Firefox, mySQL, Linux...there isn't a successful major open source product that doesn't have legions of code purists telling everyone why they're in dire condition and if only....
Not trying to be cynical, but it is odd how often these sorts of posts appear, always under the pretense that something must be done now or everything is going to fail.
And those products that do scratch itches and grow and evolve tend to have widely criticized code bases.
Maybe. But wordpress is just plain illogical. I heard people trying to use wordpress as an ecommerce platform. WTF? Wordpress is a blogging platform first and foremost.
WIkipedia keeps being an encyclopedia, linux keeps being an OS, mysql keeps being a database, firefox keeps being a browser, and so on.
Wordpress? It's a blogging platform that sometime have an ecommerce plugin tacked into it.
If you still think of it as being a mere blogging platform, you haven't been paying attention. Woocommerce, which is just one of dozens of ecommerce solutions running WordPress has over half a million downloads. Clearly people & businesses don't adhere to your logic.
Fx has had many man-hours put into it, attempting to reduce their technical debt and improve the efficiency of maintenance work. They know what's still wrong in the browser, and they're working on it, but progress is slow. There's a reason that Mozilla's working on Rust, and it's not just for S&G.
MySQL is so bad that when MariaDB happened, several long-standing architectural issues were cleaned up. Maria's got a lot of improvements that were made in response to MySQL's community not making those improvements.
Linux... I don't understand why you put Linux on this list. The only people complaining about Linux architecture are:
* Tanenbaum followers who believe that microkernels will save us all
* Binary driver authors who want Linux to be more amenable to their evil schemes
* C++ weenies who are offended by Linux's refusal to adopt C++ as other kernels have done
* C hackers who don't like the brace style of Linux
All of these groups have axes to grind; they're not approaching things from some position of "this code is not performant enough" or "if only more things were supported."
WP and Wordpress picked the wrong implementation language. It happens. Migrating them off of PHP is non-trivial. We already know all of this. It's not that we think everything is going to fail; it's more that we have seen Wordpress get hacked so many times over the years and we're sick and tired of it.
WP and Wordpress picked the wrong implementation language.
Both of those projects may have gone nowhere had they picked any of numerous other implementation languages.
I am no PHP booster (I find it to be an abomination), but it is the foundation of a remarkable number of successful products, despite being the target of endless criticism. It could very well be that the laissez faire approach that PHP encourages breeds actual results, while many other purist platforms has advocates still arguing about the best way to pass a closure.
I'd love to find an open-source CMS (preferably in Python or Ruby) with clean, secure, elegant code and a well-organized framework that comes with a friendly admin and active, responsive development community like Wordpress, but so far I've got nothing.
(If anyone has any suggestions, please do feel free to share them!)