Why we don’t build websites with WordPress
qdigitalstudio.com
qdigitalstudio.com
For what it's worth, concrete5[1] solves many of the issues discussed, and has been our go-to CMS for some time now. It satisfies both developer and client needs quite nicely.
This applies to software development and engineering too. Pick the right tool (stack) to solve the problem at-hand with an eye towards lifecycle maintenance. As a professional developer for 10+ years, that's one of the most important things I've learned.
#1 Whatever you use to build a selfhosted website, you have to maintain it and deal with security issues. A bespoke system that you build has unknown security flaws, is hard to replace, is hard to find specialised developers for and is hard to update.
#2 Software Upgrades are constant
Of course. You can mitigate issues with upgrades. But the fact that you're using a piece of software that is actively worked on is generally a good thing. Compared to other platforms, WP gives a damn about backward compatibility though, which reduces the amount of time you spend on upgrade activities.
#3 Themes are only not awesome if you don't know what the hell you are doing and you don't know how to pick a good one. I trust an agency knows what it is doing, but in this case I guess not.
#4 Sure you can not rely on plugins, but then you have to build your own code and maintain it, test it, reinvent the wheel, all on your customer's pocket. That's not very efficient and doesn't guarantee your code will be better than the work of a community.
#5 The argument is getting even sillier now... To use software you need to have some knowledge, yes. But anyone can learn, which is the point. The alternative is you pay an agency to build something bespoke, but where does that leave you if you want to customise or change it?
And actually, serious work requires paying developers a lot of the time, no matter what route you go. WordPress developers are bountiful and compared to other specialists, charge lower rates. So the author makes another self-defeating argument.
#6 WordPress has lots of features that you may not need. But you can lock it down and add new features with greater ease than you can if you build something lean yourself. If there's a better tool, of course you use the better tool. But there's a reason most people go with WordPress, because invariably, people's needs eclipse the ability to cost-effectively expand beyond some simple initial features.
#7 What happens when your developer needs help?
Truly, this boggles my mind that anybody with a clue would say this out loud. WordPress has tons of documentation, forums, paid and unpaid professionals available for help, more than any other platform...and because it is OSS you can pretty much fix or at least identify most problems you might encounter yourself. If you are picking a platform based on access to help, WordPress is one of the best choices you can make.
#8 "WordPress does not have the corner on the SEO market, or any other cool feature."
WordPress largely covers all SEO needs. The time of gimmicky SEO tactics is largely over anyway. Now sites just need to make sure they generate the proper markup and run fast.
Bottom line
If you're going to write an article explaining why you don't use WordPress, do it right. Contrast it against what you use and highlight the benefits of what you use, but also be honest about the downsides. Case in point, a bespoke system has a whole array of disadvantages that can hurt clients. Many of the painpoints the author mentions become even worse if you build a bespoke system. It's not a good way to start a relationship with a client, by distorting the landscape that way.
So here I am defending WordPress...
> Sucuri reports that 78% of the sites with security issues they work on are WordPress sites.
Or maybe it's because WordPress is by far the most popular CMS. It's a bit like the argument why there are 'no' viruses on macs. Sure, there might be some merit to the argument that it's intrinsic to the OS, but a big part of it is that the market share is much larger for Windows.
I'm still willing to bet that WordPress core is probably safer than any of the self-built CMS'es that offer feature parity.
> While WordPress’s core software is built and tested by a centralized development team, the same is not true for the thousands of themes and plugins
If the alternative is a platform with 'managed plugins' or 'no plugins other than self-written ones', then obviously that's probably safer than random code downloaded from the internet. But there's the option to just not use these plugins, leaving you with a core that is probably safer, or at least as safe, as whatever you're using instead. Not every 'feature' needs to be used.
> One of my professional colleagues told me this story and I know it’s not unusual. As he was setting up a new WordPress site for a non-profit, he recalled another site he built with a theme he really liked
Same as above: just don't use themes or only use a few carefully-vetted ones. I'm willing to bet any dev shop worth their salt has their own 'starter theme' built from scratch.
> But that doesn’t work for us. Our clients want to be able to change their look and feel based on their customer feedback, to integrate new features, or just because they want to. And we want to be able to tell them, “Yes, we can change what your site looks like—with no limits.” For us, a site that doesn’t adhere to standard coding practices is simply not good enough. The poor code quality and design constraints of pre-built themes do not work for a custom website.
So build a theme. It's really, really easy to do, and if a client pays me a few thousand for a site I sure as hell won't saddle them with a cheap theme that is difficult to customize.
> But for complex site, this constraint really gets in the way. For example, a site that requires a searchable product database, resources like white papers and case studies, and a directory of sales representatives can be built with WordPress, but it’s going to take a developer more time to set up the data structure and make all of these parts usable for a content editor.
While I agree that it's probably easier to do this 'from scratch' than mess with WordPress' innards, there's a perfectly fine solution to this that can handle quite a degree of complexity: the Advanced Custom Fields (ACF) plugin. More on that later.
> We prefer to build a site from the ground up. With a tool like WordPress, we have to strip out a bunch of the default features just to make it more secure and fit with a website’s specific goals.
I tried that a few times only to realize that it's a major amount of work to get the crucial parts working, and the end result is probably rougher than WordPress (which offers most of these core feature out of the box).
Sure, use Django, RoR, or something else if your needs are custom enough that you end up fighting WordPress. But judging from their 'our work' section, I can't really see what they need that can't be done with WordPress and ACF, and a handful - at most - of reputable plugins.
Finally, I just can't help but notice that their own site is not exactly the prettiest, to put it mildly. Now, if this were some developer site I wouldn't really hold it against them, but from looking at their portfolio (and the fact that they apparently prefer fucking ExpressionEngine to Wordpress) they strike me as a fairly typical CRUD website agency. Design is kind of core to that line of work.
So, anyways, what's so great about ACF that it alone was enough to pull me back to WordPress? Well, it piggy-backs on WordPress' slick UI (relative to most popular or self-built CMS' anyways) and allows you to enrich any content type or post or whatnot with extra fields. Pretty much anything you might need, at least for the kind of sites they seem to build. The UI for these fields is slick, and the plugin offers pretty decent functions for getting your data out of the system. I generally just directly query the metadata though.
As far as getting data into your database, this pretty much obviates the need for tons of plugins. You'll have to build your own gallery code, or whatnot, but honestly I believe any quality dev should should do that already, or settle for high-quality front-end plugins that do what they need. Of course, if you use a front-end plugin it's gonna need it's data in a particular format. That's trivial to achieve with ACF: get your data out, and shape it in your theming layer.
Anyways, maybe I'm being too hard on them, but this article just doesn't make much sense to me. Especially since their alternative is ExpressionEngine which, last I looked, was a very shitty hosted system that locks you and your clients into a commercial third party.
http://www.quickanddirtytips.com/education/grammar/what-is-a...