Clutch spoke with John Locke, the Founder of Freelock, about the comparison between Drupal and WordPress – two of the most well-known website builders. Learn more about Freelock on their Clutch profile or at www.freelock.com.
Introduce your business and what you do there.
Freelock LLC is a web development and maintenance company. Compared to many other agencies, we tend to work with clients for years at a time, providing ongoing support, keeping sites up-to-date, watching analytics and providing feedback on how a site is doing. We keep clients PCI-DSS-compliant and current with everything, and doing what they should be, to get the most out of their websites long after they’ve launched.
What are some of the main challenges and goals which clients come to you with, when looking to build a new website?
Quite often, we are called up when an original design agency has handed off a website, and left the client hanging in terms of what to do next. When running a business, the website is never done—there are constant improvements to make to it as the business and technical landscapes change. We get brought in for small enhancements, or after a website has been hacked—we’ve done multiple cleanups of hacked sites, where an attacker got in and planted malicious ads or search-engine-gaming code.
Is there something people should keep in mind when choosing a different platform?
Far too often, we see people looking at how much it will take to get a site launched, and not how much it will take to maintain it over the long haul—what the costs will be for years and years.
Could you give a quick introduction to Drupal and WordPress, focusing on what differentiates them from each other?
Drupal has been our focus for a long time, since our first Drupal 5 sites over 10 years ago. It’s a great platform for building sites which will store information, and it’s really a database under the hood. We’ve brought many people over from technologies like Access or FileMaker Pro for managing client or donor databases of various sorts, where there were certain business processes built in. With Drupal, they were able to put those processes on the web, where they can interact with their clients, vendors or donors. It’s great for e-commerce and membership sites, as well as for any sites which do more than display content.
WordPress is on the other end of the scale, in the sense that while it does have a database on the backend, it primarily provides the ability to update content, and not necessarily more sophisticated tasks. It’s extremely popular. We built a few WordPress sites early on and then moved away from it because it’s pretty hard to manage regular changes compared to Drupal. We’ve recently been brought back to it due to client demand. A client with multiple sites liked what we were doing with Drupal, so much that they asked us to manage their WordPress sites as well. We looked at the tools we’d built, and realized that we had all the hard work done to automatically test, back up, and deploy changes to WordPress sites as well as Drupal, with a few small additions to the pipelines.
Designers love WordPress because it’s more about the presentation than it is about underlying data. If someone is trying to start a marketing campaign or build a glitzy product which needs to look polished and nicely-designed, WordPress is a fast solution to go with, since so many designers are familiar with it, and can get something running quickly. It’s great for blogging and news platforms or static websites, but less so when we need to add a bunch of other data to it. WordPress can definitely do a lot more than that, but it very quickly becomes a lot harder to manage and has nowhere near the level of support for complex sites that Drupal provides.
Are there people to whom you wouldn’t recommend either platform to?
It all boils down to what the goals for the website are; this is one of the first questions we ask. If it is an informational site which won’t be changed a lot, then WordPress is fine. If the owner wants the site to do more – for example, to manage training courses, job applicants, memberships, events, or communications with their customers – or if they have a lot of people contributing content to different sections of a site, they will very quickly reach the point that it costs more than it would in Drupal.
The lower-end of the market has largely been taken over by the Software-as-a-Service (Saas) players like Squarespace and Wix. Those are extremely cost-effective for someone with a small budget. The SaaS companies provide the infrastructure, and spread the security and maintenance costs across thousands of customers, whereas, when running a WordPress or Drupal site, it’s up to the user to keep it secure and up-to-date. It’s renting versus owning your site – when you own your own property, it’s up to you to maintain. This is the kind of service we provide, but there’s more cost involved than simply renting a spot on a SaaS platform.
WordPress users can make updates themselves, but they’re updating directly on the production site, which means that if something goes wrong, the site can go offline. If their backups properly working, it may be fine, but each time they do this they risk breaking something. Most companies that value their website and don’t want it to go down under any circumstances are much better served by testing all updates before they get pushed out to production. It’s far easier to stage and test code updates to Drupal than to WordPress. It is possible to do with the latter, and we have built tools for the process, but there are several extra steps involved.
Why is it important to maintain a website, and what resources are necessary when doing it in-house?
There are various aspects to maintenance, one of which is just keeping the content fresh. This is something which most of our clients do in-house or with a marketing person. The whole point of using a CMS like WordPress or Drupal is to make it easy for site owners to keep their content up-to-date.
We do have clients that have us make content changes, but our primary role is more security-oriented. First off, we make sure there is a solid backup of the site in place, so that, if something does go wrong, we can recover it promptly and undo the damage, with minimal downtime.
The next part is making sure all the code is updated. These platforms are used by millions of websites and like any other computer software, they have bugs which can be attacked. Our typical Drupal install has a million lines of code, and even with a low error rate this means thousands of bugs. All active platforms have security updates which should generally be applied as quickly as possible – if they aren’t, the site becomes vulnerable to attack. Many people don’t think that they’re a target, but in this age of major Equifax and Yahoo attacks, I hope we’re moving past this point. I hope people are coming to realize that leaving sites unpatched is like leaving your front door wide open – someone will come in and take over, use the website to attack other websites, consumers, DNS servers, or simply use the site’s resources to mine Bitcoins, and so on. Instead of having a website that supports the business, the website becomes a part of a much bigger problem—it may be controlled by malicious actors who are attacking other people, whether or not it interferes with the business directly.
If a website has e-commerce capabilities or sensitive data, it becomes far more critical for it to be kept up-to-date, as a responsibility for the customers. If there is a breach, and the owner wasn’t adhering to PCI DSS compliance, they will be held accountable, which can put them out of business.
Are there any features you’re particularly impressed with on either platform?
There are quite a lot. Drupal is the platform we’re most familiar with, and it changes with each major version. Drupal 8 is the latest one, and it uses the same concepts as all previous versions—it’s not that different for people using it, but it is entirely different under the hood, meaning in many cases it has an entirely different set of plug-ins. Some have been updated from previous versions, but many of the plug-ins from earlier versions are longer needed, since the same functionalities are now a part of core Drupal.
There is a lot of change happening in media management; the tools are impressive, but they’re also changing quickly, and have been breaking more frequently than usual. I expect this to stabilize in 6 months or so.
WordPress has decent media-management under the hood. One of the differences I’ve seen with it is that it tends to embed short code and HTML snippets; the media management tools are helpers to get things in place, and users end up needing to get to the code a bit more. WordPress has a reputation of being user-friendly, compared to Drupal, but we’ve found the opposite to be true—WordPress core is decent, but there are so many competing plug-ins, a tremendous amount of overlap, and very few “standard” ways of solving a problem. Much of this goes back to the way in which the community works together (or not)—with WordPress, it’s huge, and there are many different factions and sets of plug-ins. When picking a CAPTCHA, for example, we need to pick particular plugins designed to work with the other plugins on the site—some work with MailChimp, some work with Core or a particular other plug-in, but there’s not a universal solution. You end up with a big mish-mash of stuff, and a very confusing administrative interface.
In Drupal, there is a strong community pressure to develop plug-ins which are best-of-breed and work across the board. When adding a CAPTCHA module of some kind, it will work with every form which can be put in Drupal, since they’ve spent a lot of time making sure all forms work the same way, using the same APIs. With Drupal, we generally only have 2-3 choices for each type of problem we want to solve with a plugin. As a result, when selecting a plug-in for something, the differences are pretty clear, usually with entirely different approaches for solving the problem. There’s always more than one way to do it, but it’s a matter of matching it to how we organize data, and what the best fit is for us. And the administrative interface keeps everything very cleanly organized, consistent, and easy to use once a user has learned the basic patterns.
With WordPress, we find a dozen plug-ins, all doing the same thing, and have to weed through them to determine any sense of quality. Some of those are paid, and some are free. Inevitably, none of them do exactly what we need to do, and requires customization. It’s a hodge-podge solution that leads to slapped-together sites – while these can sometimes be built quickly, they often lead to unmaintainable sites. WordPress Plug-ins regularly get abandoned, nobody pays attention to the vast majority of them from a security point of view, and this leads to a security nightmare down the road.
With Drupal, many of the contributed plug-ins see security reviews from the core Drupal Security team. Security updates appear right on each module’s page, and in a central feed. If a module is included in the core security review, we can be sure that someone is paying attention, and see how well they are maintained.
Are there any specific limitations or drawbacks you’ve found on either platform?
Both are written in PHP, which has come a long way over the years. It’s not known for being strong with long-running processes like chat systems or other functionalities which require live-updating the browser. This is an area where we’ve seen Node.js taking over. It can certainly be done on Ruby on Rails and Python, as well as PHP, but nobody really does. We go to Node.js for anything which needs live updates.
Another area where I would say they’re not extremely strong is big data. We like building reports and portals in Drupal; it’s a great platform for reporting the results of big data calculations, but other tools can perform the actual calculations far better.
Before PHP 7, there were some issues around internationalization—many of the PHP functions did not handle long character sets correctly. Drupal has shimmed this quite a bit, so that it would work well with older PHP, and it’s a great platform for multilingual sites. Because so many multi-lingual sites are built in Drupal, it has gotten substantially better with each major release, and Drupal 8 is one of the best platforms out there for multi-lingual sites today.
With WordPress, we’re entirely at the mercy of plug-ins – there is no support for multi-lingual sites in core.
Could you talk a bit more about the Drupal community?
It’s definitely an unusual one. Drupal is one of the poster children of successful open-source projects, along with Linux, MySQL and PostgreSQL. WordPress is also open-source, but its community is fractured, and they don’t really behave like an open-source community. There are many people working on the core, but the plug-ins are commercial. The license both projects use (GPL v2) requires that derivative works cannot change the license. The Drupal community has interpreted this to mean that you cannot create an entirely proprietary Drupal module – modules are derivative works of Drupal, and thus cannot carry a different license. This means that any Drupal modules out there are automatically open-source, and people can use them freely. While WordPress carries the same license, the community has not determined that this applies to all plugins – which has created drama but little clarity. And in practice, we see a lot of paid, commercial WordPress plugins and even some active hostility towards open source.
At times, the Drupal community does seem insulated. With Drupal 8, the big catchphrase was “getting off the island”. They saw their community as an island of people who had started using Drupal, and didn’t know anything else. This has been changing quite a bit, but it’s still a tight-knit community anchored by DrupalCon in North America, which draws 3,000 attendees every year.
We came to Drupal after the community was firmly established, and have seen it as one among many other open source communities we participate in. We’ve been building websites since before Drupal existed, and thus never felt like Drupal was our only community.
It can be tumultuous at times, but, at the same time, at a technical level, Drupal 8 is better than any previous version by a long shot—it uses far more industry-standard practices, it’s object-oriented, and has done many things to make it easier for outside developers to learn. The very thrust of the “get off the island” mantra was to have easier on-ramps for interacting with the rest of the technical community. There is a new influx happening right now, with many developers starting to see how great Drupal 8 is.
Is there anything else you’d like to add about the website building or maintenance process?
It’s important to have a good testing framework. When we’re talking about changes within huge amounts of code, things break. We’ve built a pipeline which allows us to put everything on a development server, and run behavior tests. A robot will click on links and fill in forms, making sure that the expected outcomes are happening. We also run the site through a set of screenshot tests, where we take snapshots of a set of pages before and after upgrades, and see down to the pixel level if anything has changed, before rolling the new code out to production. This is the sort of thing which large websites do all the time—set up a deployment process which catches things before they break and take down a live site.
Whatever platform is being used, if site uptime is important for leads retention and running a shopping cart, then it’s critical that tests be done to a copy of the site, offline. This should be a strong consideration when picking a platform – with Drupal 8’s configuration management and portability, it’s easier to have test copies with Drupal. For smaller companies that can’t do this in house, partnering with a company to provide this service makes a lot of sense.
We have 5 additional questions. For each of these, we ask that you rate each platform on a scale of 1 to 5, with 5 being the best score.
How would you rate them for functionality and available features?
WordPress – 4.5
With all the plug-ins, it’s easy to build a site that can do a lot, but much harder to make it maintainable over the long haul.
Drupal – 4.5
It has great functionality out of the gate. There are still corners that need a developer to round out the site – but the result is usually very easy to maintain.
How would you rate each for ease of use and ease of implementation?
WordPress – 3
It’s easy for simple sites, but it becomes tremendously hard for complicated ones.
Drupal – 4
It’s easier to implement complicated features on, and easier to manage when the site gets beyond a certain scale.
How would you rate them for support, as in the response of their team, and the helpfulness of available resources online?
WordPress – 2
Most of what we find are code snippets, often written by people who don’t know how to code. This can lead to large security holes, and WordPress is probably the most hacked platform out there.
Drupal – 2
Drupal is hit-or-miss, depending on the day and the source of information. The major version differences are a big challenge—how something is done in Drupal 7 may not apply at all to Drupal 8, and people who know one version may not know the other.
How likely are you to recommend each platform to a friend or colleague?
WordPress – 3
We recommend it for simple sites, but it limits growth. It becomes very expensive and complicated to do a quality job.
Drupal – 5
Drupal 8, in particular, is the best platform out there.
How would you rate them for overall satisfaction?
WordPress – 2
I have not seen much to like about it under the hood. We can generally fix things quickly, but we have to do it every time. For someone who likes things organized and easy to maintain, WordPress is not the solution.
Drupal – 4
There’s always room for improvement, on the media management side, for example. Drupal 8 has been out for 2 years, and there are still a few missing pieces in the ecosystem. It’s the beginning of the cycle, and it will be a solid solution for the next decade at least.