WordPress isn’t Suited for Major Publishers?

austin@alleyinteractive.comIn this post, WordPress.com VIP Featured Service Partner Alley Interactive‘s managing partner Austin Smith shares his thoughts regarding a recent article which dismisses the potential and power of WordPress as an enterprise solution. We naturally disagree with the article and turn this post over to Austin. 

Felix Salmon sounded off earlier this week, at some length, about one of my favorite topics—choice of CMS for news organizations. One of his central points is that Vox Media has a distinct advantage because of its über-CMS. I admit, what I’ve read about Chorus makes it sound pretty awesome. But there’s a broader question here about CMS models in general—do you want your CMS to run everything, or do you want it to be a component in a broader digital ecosystem?

First, I can answer this question for myself and most of our clients—I think the CMS should be a component in a broader digital ecosystem. From the look of the screenshots on TechCrunch, Chorus includes an ad management platform and a full-scale user management system. I’m not jealous of these features, nor are we often asked for them. The heft of maintaining such a platform would be unbearable for most publications, and to this extent I take Salmon’s point that an organization that can own the full scope of its digital experience may ultimately come out ahead. But we generally handle these features via third-party integration and our publisher sites still succeed.

Second, we build publisher sites on both Drupal (The New Republic, National Review Online) and WordPress (The New York Post, Digiday, Flavorwire, The New York Observer), so I’m in a unique position to take offense at Salmon’s casual offing of both:

Off-the-rack CMSs like WordPress and Drupal are OK for small-to-medium sites, but aren’t particularly well suited to be the framework for a major publishing operation.

Ouch! On whose authority? You could build a platform like Chorus on either WordPress or Drupal, and probably come out ahead. Drupal has long called itself a “Content Management Framework,” and would be naturally suited to this challenge. Similarly, anything you can do in PHP, you can package as a WordPress plugin. Plus with WordPress, you get the added benefit of editorial commonality—chances are pretty good that your reporters will have seen a WordPress admin screen before.

Also, people who live in glass houses shouldn’t throw stones. These über-CMS projects have a tendency to fail pretty spectacularly, and humble as they apparently are, WordPress and Drupal are antidotes to this syndrome. The TechCrunch article about Chorus mentions WordPress.com VIP specifically as an alternative to this model. By virtue of its bulletproof reliability, careful curation, constant monitoring, and strong system of developer support, WordPress.com VIP takes a ton of this risk off the table. And in collecting a large number of high-traffic media sites, they’ve built a common set of shared plugins which handle many common publisher-site tasks. When WordPress gets better for one, it gets better for the others, too. Similarly, our biggest Drupal projects have launched successfully on Pantheon, and many other Drupal publishers run on Acquia.

Perhaps the “rising tide lifts all boats” mentality does not translate to digital media, as an open-source developer like me would prefer. But even if you buy into an eat-or-be-eaten mentality, it’s hard to believe that your CMS will win or lose the war.

Invective aside, one point I can take is that owning the full stack is a luxury that requires an immense scale. But is it a necessary condition for success? I don’t know, and I’m not sure Salmon does either:

I’m fascinated by the Medium experiment: I think it has a lot of potential, especially if it starts to support custom domains, like Tumblr did early on.

Great, but which is it? Medium or Chorus? I think we can agree that it’s too early to say, and that there could be plenty of room for both. But WordPress and Drupal do great things for big publishers too, and they aren’t going away.

Thanks to Austin for his commentary.

Interested in more information about WordPress solutions for publishing and media? Get in touch. 

10 thoughts on “WordPress isn’t Suited for Major Publishers?

  1. When I saw 17,000 simultaneous users reading the Apple event live-blog we had running last month at the New York Times, I was reasonably convinced that WordPress can scale.

  2. Obviously, there are plenty of examples to show that open-source CMS are more than adequate to serve the newsrooms of major publishers. But both sides of this debate are looking at it from the journalists’ perspective.

    What about the ad traffickers? The ad server is their CMS and – at least in my experience – none of their options are adequate. They’re all a pain to use and spit out near-meaningless numbers, and I can absolutely see why a publisher would want to build their own. And if you’re going that route, why not roll an editorial CMS into it?

    1. I think you’re right about ad servers, especially given that most platforms were built for trafficking standard display ads, which, while still in heavy use, are no longer the whole picture. Specifically, most ad servers we work with are pretty bad at native ads, which to me are a good reason to have the ad system and CMS on the same platform. But why would the ad platform come first? Why not build an ad management platform on WordPress?

      1. Good question. I can see where it’d be really hard to shoehorn the structure you’d need for a full-service ad platform into the WP database structure without a ton of meta queries that would slow things down compared to a NoSQL solution. That’s my initial guess at least.

        That, or advertisers are more impressed by “We built a custom ad platform from the ground up” than by “We built a custom ad platform as a WordPress plugin”, even if the difference is merely perception.

    2. On ad servers, I think they’ll start to converge, or maybe just integrate more tightly, as publishers move further from display advertising (which, I would argue, is still a completely separate use case from a CMS) to “native” units.

      (Edit: Austin beat me to it :))

      One practical concern I’ve seen first-hand with a custom or non-standard ad server (and which may have since been mitigated…it’s been a few years), is the discrepancy in reporting between the publisher and advertiser. DFA is the dominant platform for advertisers, and it wasn’t rare for us to over-deliver campaigns by 15-20% just to make sure everything looked “right” in DFA — we moved to DFP specifically so we can be on the same system and avoid that.

      1. I think you’re right about ad servers and CMS converging, but it does raise the question: is the CMS an extension of the ad server, or vice versa? A publisher with a traditional editorial staff of full-time professional journalists might answer that differently from one that relies on far-flung “grassroots” contributors like Vox.

      2. My favorite solution these days is a combination of these two ideas—native ads served through the CMS but tracked through a JS platform backed by a fast stats system running Node/Mongo or similar. Display ads are a different use case, yeah, and the market is mature enough at this point that the wisdom of replicating DFP entirely is questionable, I think.

  3. “Off-the-rack CMSs like WordPress and Drupal are OK for small-to-medium sites, but aren’t particularly well suited to be the framework for a major publishing operation.”

    It’s ironic that Felix published that on a WordPress site, operated by a major publishing operation (Reuters) that claims over 1500 journalists are using their fairly sizable WP installation.

  4. Building a complex custom content management tool for a large organization while tied to the upgrade cycle, legacy overhead, and the community politics of an open source project is no picnic. The main fallacy of the article lies in the assumption that large news organizations only need massively complicated tools for success. Famously Apple used Cray supercomputers to help design Macs and Cray used Macs to help design their supercomputers. Sometimes a blazingly fast custom system can be an advantage, and sometimes an off-the shelf one can be an even bigger advantage.

    That said, building Chorus-like system in Drupal would be a worse idea than starting from scratch.

  5. I so appreciate this article and the discussion. I’m deep enough into WP to know Salmon was wrong but needed some backup!

    The fact that everybody on here is saying something of valuable also speaks to why I’m digging the WP community.

    I’ve watched newspapers struggle to go online with proprietary systems that got in their way and sometimes still do. It was so obvious that their expensive CMS’s were part of why they couldn’t respond to the changes on the web and got eaten alive in so many cases.

    Newspapers could have been leading developments on the web but they dropped the ball over and over again at every level. What I still wonder about is whether or not they embraced systems that reflected their backwards looking stance or if the systems kept them from seeing other possibilities.

Comments are closed.

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.