Hacker News Reader

Comment by scotch_drinker | Hacker News Reader

Wait so he's complaining that a free piece of software that is designed to "create a beautiful website or blog" (from Wordpress.org) doesn't cut it as a high powered CMS?

I think if we're honest, wordpress is a blogging platform and if you try to deform it into your own little niche needs, you need to accept the inherent risks.

View on HN

The post mentions that the issues extend into WordPress' regular redesigns of the admin interface, and their consistent lack of solid testing:

"This would actually be a much smaller issue if it wasn’t for the WordPress’ update schedule. I am 100% for constant updating of software, but the current desire to redesign the AdminUI 2-3 times a year creates a huge amount of friction from both clients and developers."

"Kev, they released a BETA version that they didn’t even load on Windows. The MENU didn’t work. Not some advanced feature throwing a bug, the fucking MENU didn’t work. I can’t test our themes and software against that. Lets be honest mate, how did it get past their tester and release procedure? Oh, thats right, they dont have a Tester. They just load it on their MacBooks and presume it works for the other 95% of the world. It’s a fucking shambles, and clearly they’ve learnt nothing since the 3.0 fuck-up."

I work with WordPress a lot, and have regularly had similar issues. Even as a blogging platform, WordPress is increasingly difficult to manage.

That portion of the post is the opposite of what I'd pick out to illustrate that it has a point. It's just dripping with misplaced rage and entitlement and doesn't even point out a bug in any shipping version of WordPress. It strongly emphasizes the word "BETA" and then goes on to literally curse them out for the fact that it had major bugs. Like, yeah, that's what that means. Do you go grabbing a cook's half-done risotto and tell them to quit because the consistency is terrible?

I agree that WordPress's issues multiply in proportion to how much you want it to do, but the fact that prerelease software has bugs is not one of them.

"... the fact that it had major bugs. Like, yeah, that's what that means."

No, that's not what beta means. I expect core functionality to work properly in a beta. I expect there to be intermittent issues, and I expect advanced/fringe features to maybe sometimes not work. I expect there to be workarounds for most (but not all) issues that crop up. But the freakin' main menu didn't work. How is that beta-quality? I'd hesitate to call it alpha-quality.

And yes, I know, it's open source, it's free, you shouldn't feel entitled. I know. I wrote and maintained open source software for 5 years. But c'mon, from the perspective of the developer, have enough pride in your work to at least do a little testing before throwing a release over the fence.

1. I know definitions are a little hazy, but your definition of a "beta" is not really the traditional meaning. In a beta, core functionality should mostly be there, but it's expected to be buggy. Beta is the point at which most bugs are expected to be worked out, because that's the point when the software is mostly feature-complete. That's why people who use the beta are called "beta testers." I mean, you're welcome to your definitions, but it seems unfair to curse out free software developers for not adopting your personal jargon. (Here's a handy reference for the anonymous downvoter: http://en.wikipedia.org/wiki/Software_release_life_cycle#Bet... ) At any rate, it is certainly not meant to be an end-user release, so if that's the worst accusation you can find to throw at them before you start swearnig, you're really being unfair.

2. The article is a bit vague (which doesn't help its case), but if the bug is the one I'm thinking of, saying that "the main menu didn't work" is a bit of an exaggeration. I believe the actual issue was that the main menu didn't work in Explorer. Broken Explorer support is very common among beta software unless they're specifically targeting Explorer specially.

> your definition of a "beta" is not really the traditional meaning. In a beta, core functionality should mostly be there, but it's expected to be buggy.

I expect bugs, yes, but the "traditional" meaning of beta is that core functionality is done and it's passed through QA and some form of alpha stage with internal and some trusted external testers to catch, at a minimum, glaringly obvious stupidity.

I'll excuse a beta release with some significant but not absolutely critical feature clearly walled off and labelled "this bit doesn't work yet". I'll not excuse one where critical functionality becomes clearly unusable just by virtue of running on a supported platform. That's so beyond the pale for what is -- even if in a twisted/attenuated sense -- a commercial product as to reflect nothing less than utter incompetence.

What disturbed me about this article is the lack of testing. For a major piece of software like Wordpress, ANY release (alpha, beta, whatever) should include a test phase that stalls the release if it doesn't pass.

If Wordpress was mission critical for my business, after reading this article I'd be investigating their build process very carefully. If it turns out that they don't have an effective test phase, I'd be migrating my customers to an alternative as fast as I could.

I think the author's problem, and the problem of nearly every frustrated WordPress user, is that the alternatives aren't nearly as enjoyable to work with as WordPress. It has a nice, understandable, and flexible API, and even though its greatest strengths are really only in blogging, the friendliness of the environment naturally invites stretching its use.

For these people, I would strongly recommend a look at ProcessWire. It's kind of like a radically simplified Drupal that is at least as easy to use as WordPress, if not more so, and has a similar attention to design and detail. I've been using it for a few months now across two very different projects, and I'm wishing I'd found it earlier.

An alternative that is not as well known is ExpressionEngine. FWIW, we've done a slew of EE installs and a few WordPress intalls and clients that have made the switch from EE to WP have loved it. The admin UI is attractive for end users, and when it comes to theming, designers love the flexibility of the layout variations and front-end developers can actually implement said designs without hacking the EE theming system. This is definitely not the case with WordPress.

Here is a great blog post about the transition from WP to EE written by one of our designers - http://www.viget.com/inspire/wordpress-to-expressionengine/

and here is another unique EE site that shows the flexibility of its native theming system -

www.teamviget.com

> ...that have made the switch from EE to WP have loved it.

Might want to revise that to "from WP to EE."

Yeah, that confused my balls.

As someone who's done his fair share of ExpressionEngine development, the template system is a source of endless frustration as soon as you need to do anything remotely complex on the page or deal with user input. It is a great choice for blogging sites where a group of editors publish content to a site in predefined channels, but really falls down if you push it too hard.

Template processing is slow, processing order is wonky, and it's very easy to create N+1 query loops that can only be avoided by writing custom SQL queries/php. They also made some poor database structure choices in certain areas.

Mostly though it just boggles the mind why they put so much effort into creating a regex-based templating system when the app is already just PHP.

Still, probably the best CMS I've used and it certainly has its uses. I just wouldn't use it to develop anything complicated ever again.

Sorry for the confusion - I meant to say "from WordPress to ExpressionEngine" on the first line... I don't know how to edit a post, so I'm just replying here.

This is the first I've heard of it, but a quick glance at its website suggests that ProcessWire may be very promising. Do you have any additional thoughts on it, having worked with it before?

What took a little while to click with me, and really hit it home for me once it did, is how simple ProcessWire's approach to content and data actually is. Its primary admin UI looks like it's for editing a straightforward site hierarchy, and it certainly can be, but the key is that its "pages" don't have to be web pages. A combination of some simple PHP and some quick setup in the admin lets you build all sorts of things.

At its core, ProcessWire just gives you an extensible, hierarchical (and relational when you need it) model to build upon, and then gives you a really slick jQuery-style syntax by which to access it. You build templates in PHP, but the selector syntax is so easy to work with, it brings to mind WordPress theming.

One of its founding principles is that it is markup-agnostic. I'm using it right now for an XML source that feeds a site (and possibly later a mobile site, an app, or anything), with the XML being a ProcessWire template.

Just my 2 cents about XML. Don't use it as a feed for data. It's better to use JSON. Specially for mobile applications.

At least with ProcessWire, it would be pretty straightforward to re-template it to output JSON instead of XML (or keep both).

If you play it that way: At least WordPress is user friendly ;)

I recently went through the process of selecting a CMS for a client. ProcessWire, was the ONLY one I looked at and thought, "ok, now this makes sense." In the end, I couldn't use it because it doesn't yet support repeatable content sections in the admin. Sadly, had to go with Wordpress.

The roadmap for 2012 is actually pretty exciting: http://processwire.com/about/roadmap/

In addition to repeatable fields, they're planning a versioning system, staging states, and even a forms builder. Not exactly earth-shaking for a normal CMS, but these will open up all sorts of possibilities for ProcessWire.

Exactly. I don't keep up with Wordpress too much, but my perception is that you should go with something like Drupal (or other proprietary options) if you want a platform fully capable of being a CMS.

That said, any CMS will struggle with the challenges that he lists. It's not some sort of magical entity where you turn it on and it's perfect.

I feel bad for his clients...

Except that Drupal is, interface-wise, even worse than Wordpress; and management of the damn thing is difficult even for the developers among us. It's hard to recommend it when you know clients/users will struggle with it.

Handing a Drupal website over to a client was always hard. No wysiwyg, no automatic updating, built-in dependency hell (that the client can see in /modules), _constant_ warnings about module updates and security updates and core updates and updates of every other kind, make Drupal an extremely tough sell.

Just a few nitpicks;

Drupal does have wysiwyg implemented as a module http://drupal.org/project/wysiwyg (actually several competing editors are possible),

Drupal also can do automated updates, though I wouldn't advise it. Drush works for it, http://drupal.org/project/drush and a lot of people use it with great success. You would want a carefully vetted rollback plan though. The better road is to forgo updates other than security until scheduled maintenance or a MUST have feature is present. The GUI /update process is actually quite nice if you've set everything up properly.

The thing about Drupal is doing everything doesn't have to be painful, but if you've approached it in a "non-Drupal" way it can get bad quickly. Drupal is complex and the hand off to a customer is never easy with complex software. Have you tried the same with Plone?

>and management of the damn thing is difficult even for the developers among us.

Understatement of the year so far.

I love Drupal, but since there's no bright line separating configuration and content, rolling features up from a dev environment to staging to live can sometimes be a nightmare, particularly if the Features and Strongarm modules don't have you covered.

Agreed. Drupal has an incredibly steep learning curve. I was told to learn PHP BEFORE using Drupal and it's been a huge advantage. I can't imagine a non-developer trying to change some content or add a feature themselves.

Drupal is extremely powerful, but would be a nightmare for users used to the WP platform.

I have been presented with relatively straightforward CMS site concepts and come to the conclusion that they would be better done in Rails or Django than Drupal because a) it would be easier to present a usable interface, and b) those would actually be less likely turn out looking like a tower of paperclips and bubblegum.

This may just be my lack of experience in Drupal talking (I've got plenty of experience in PHP, just not Drupal), but I put a pretty decent amount of thought into the matter and even mocked up simple prototypes just to see if there was something I was missing.

The big difference is that in Drupal it's possible to get pretty far without ever writing a single line of code, even templates. For some use cases that's very powerful, especially an environment where you have trainable, reasonably technical people who aren't programmers.

But for the talented developers and/or programmers on the team, it's a complete productivity and sanity drain. Moreso if you're, say, part of HN's target audience, because you'll know all the modern web development techniques, and you'll be able to use none of them.

I have had an absolutely terrible experience with it, which sadly isn't unique amongst these big PHP projects.

It's not bad once you get your head around it. Sure, it's not buzzword compliant (MVC, TDD, ORM OH MY!) but for what it is, it can be pretty compelling.

My primary job for the last 2 years has been developing a Drupal site for a group of daily newspapers with monthly page views in the low 8 figures.

We were in a situation where we had to get a site up quickly (Our small group was bought off from a much larger conglomerate, so the huge $$$$ Java system we had been using went away). Drupal allows us to get a tolerable site up in about 3 months, and a much better site up about 6 months later. Have there been pain points? Sure. But if we'd used anything else there's no way we would have been on our feet nearly as quickly.

Are we investigating other options? Of course, if I wasn't I wouldn't be doing my job. There's a part of me that would love to rewrite the whole thing in Rails or Django. That would be a huge undertaking though.

I really don't doubt that for many people it has its place, as evidenced by your experience, but the moment you want any semblance of interactivity (at which point you can argue that a CMS is the wrong tool for the job) or efficiency/optimisation, you're screwed.

We've had different experiences, but I wouldn't touch it with a 10' bargepole, not any more. And I'm glad I've been managing to encourage my boss to start moving away from it. The only positive thing I've been able to take from it is a list of things never to do in my own code.

Like I say, it's not just Drupal. It's a side-effect of over-complication in the name of simplicity, and trying to run in parallel a system that makes it easy for non-devs to use. It's a recipe for disaster if you want lean, maintainable code.

Depends. We serve ~40 PHP requests a second (and that's NOT counting stuff that hits the cache) on reasonable hardware - an 8G webserver VM, and a 4G DB VM, both with 4 cores allocated, and hot copies of each for failover. Our site is pretty interactive, and even the stuff that's cached is short (5 minutes or less) timeouts.

The drawback to that is that all configuration goes into the database making deployment very, very difficult.

Oh, and it causes performance problems too.

Yep when we had to do work on drupal sites all the junior staff where frightened to even change add a small piece of content as the interface was so bad an the sites where prone to breaking if you made innocuous changes.

When was the last time you tried Drupal?

For me personally, I'm moving away from Wordpress as well in favor of either hand-written static pages or just rolling quick Sinatra/Rails apps.

Now of course I don't expect that either of these is as user-friendly to many (and they don't solve many of the ailments that he cites without effort), but what I'm trying to escape from are the things that are just 'broken' about Wordpress. I hate the 'loop' that they use. I don't like PHP one bit compared to Ruby. No automated tests. I really dislike the way theming works generally. The layout of the entire application is just wrong to me. I like the ease of deployment, but I've got enough experience that deploying a Sinatra app takes me only seconds.

For me, what Wordpress once did for me quickly is no longer an asset generally. With my personal skills and experience I can much more quickly get a Rails/Sinatra blog off the ground than I can reskin a Wordpress one and beat it into submission.

In order to be deformable and retain its function, you have to build the program in ways that allow it to deform. You have to decouple the various functions. That's why I love Plone so much. Sure, it's alien technology for most, but it's so great I can't stand most CMSs I see being used and marketed as "professional tools".

Wordpress isn't a CMS, SilverStripe is, and it has a full MVC framework that it's built on too - makes coding extensions MUCH nicer than both WP and Drupal (ughhh).

For me it's rails for the complex stuff, SilverStripe for the simple sites. Keeps me and clients happy.

I agree SilverStripe is really clean to theme and extend... however some of its base functionality can be a little dodgy at times :)

Still the best open source CMS I have used.

I suspect a lot of people become expert in a "CMS" like WordPress or Drupal, because it seems easier than learning to work with a proper framework like Rails, and then find themselves stuck inside the platform.

Like project management systems, CMS is destined to be reinvented by everyone, every day of the week.

It's very hard to convince people of going with a proprietary, custom solution. Many people have been burnt here, and it's a tough sell to upper management.

All CMS is necessarily a "proprietary, custom solution". All CMS (like all software) exists somewhere on the spectrum of "easy to use" vs "extensible and customizable".

If management chooses to rely on a vendor to set the roadmap, then they are fools, and there's not much you can do to help foolish management.

Here's another vote for SilverStripe. I've run it in production for a year and a half and been very happy with it's performance and caching options. (You can do partial caching all the way up to a full but automated static export.) The MVC framework borrows a bit from rails and makes it one of the nicest PHP CMSes to develop for. It's much more fun than managing WP custom post types and the interfaces I can create for end users are better. Downsides? Documentation could be better and not as many off-the-shelf modules available. Both LibreOffice.org and OpenStack.org are powered by SilverStripe.

Some of the stuff he was listing also sounds like his clients want a CRM, something like Salesforce, Dynamics or Basecamp.

really, like what?

Doc management, Workflow management, Digital asset management, User management, Access Management

My first inclination is to agree with you. The OP should never have used WordPress as a multi-tenant CMS in the first place. OTOH, he does raise some issues that affect WP use even in its original blogging context. I use WP, I like it, I don't have immediate plans to change, but if I ever personally hit a "this was obviously never tested" case like he did I'd probably change my mind pretty quickly.

Reply on news.ycombinator.com