drupal

When it comes to building a website, two content management systems (CMS) often dominate the conversation: WordPress and Drupal. Both are powerful, open-source platforms with passionate communities, but they cater to different needs and skill levels. As someone who’s worked with both, I’ll break down their key differences—honestly—focusing on ease of use, flexibility, security, and cost, so you can decide which fits your next project best.

Ease of Use: WordPress Wins for Beginners

WordPress is the king of simplicity. With over 43% of the web running on it, its user-friendly dashboard, plug-and-play themes, and massive plugin library make it a go-to for bloggers, small businesses, and anyone who wants a site up fast. You don’t need to know code to get started—install a theme, add a few plugins like Yoast for SEO or WooCommerce for e-commerce, and you’re live in hours.

Drupal, on the other hand, has a steeper learning curve. It’s not that it’s impossible to use—it’s just built for developers or those comfortable digging into the backend. Setting up a basic site takes more time, and customizing it often requires familiarity with PHP, Twig, or its module ecosystem. If you’re not technical, Drupal can feel overwhelming, whereas WordPress feels like it’s holding your hand.

Flexibility: Drupal’s Power Shines

Where WordPress excels in accessibility, Drupal takes the crown for flexibility. It’s a CMS for complex, custom projects. Need a site with intricate user permissions, multilingual capabilities out of the box, or integration with enterprise-level systems? Drupal’s modular architecture lets you build exactly what you want, no compromises. Government sites, universities, and large organizations—like the White House or Harvard—rely on it for a reason: it bends to fit your vision.

WordPress is flexible too, but it leans on plugins to extend functionality. This can lead to bloat—too many plugins slow your site down or create compatibility issues. While WordPress can handle complex sites (think CNN or TechCrunch), it often feels like you’re jury-rigging it to match Drupal’s native capabilities. If your project is straightforward, WordPress is fine, for anything bespoke, Drupal’s the better bet.

Security: Drupal Edges Out Slightly

Security is where the debate gets spicy. WordPress’s popularity makes it a bigger target for hackers. It’s not inherently insecure—core WordPress is solid—but its vast plugin and theme ecosystem is a mixed bag. A poorly coded plugin or an outdated installation can leave you vulnerable. You’ll need to stay vigilant with updates and invest in security plugins like Wordfence.

Drupal has a reputation for being more secure out of the box. Its smaller market share (around 2% of websites) means fewer attacks, and its community is obsessive about patching vulnerabilities fast. Plus, Drupal’s built-in security features—like strict access controls and a focus on enterprise-grade standards—give it an edge for sensitive data. That said, no CMS is bulletproof, misconfigure either one, and you’re asking for trouble. Drupal just requires less babysitting.

Cost: WordPress is Cheaper Upfront, Drupal Pays Off Long-Term

WordPress is the budget-friendly option to start. Free themes and plugins abound, and hosting is dirt cheap—think $5/month on Bluehost. But costs creep up as you scale: premium plugins, developer fees for custom tweaks, and higher hosting for traffic spikes add up.

Drupal’s upfront cost is higher. You’ll likely need a developer to set it up, and hosting requirements are beefier (think VPS or dedicated servers over shared hosting). However, for large-scale sites, Drupal’s efficiency and lack of reliance on third-party add-ons can save money over time. It’s an investment: pay more now, maintain less later.

Performance: Drupal Scales, WordPress Needs Help

Out of the box, Drupal performs better under heavy loads. Its caching system (hello, Views!) and leaner core make it ideal for high-traffic sites with complex queries. WordPress can struggle here—without optimization (think caching plugins like W3 Total Cache or a CDN), it bogs down as traffic grows. For small sites, WordPress is snappy enough, scale up, and Drupal’s architecture shines.

Community and Support: WordPress Has the Edge

WordPress’s community is massive—forums, tutorials, and meetups are everywhere. Need help? Someone’s already solved your problem on Stack Overflow or a YouTube video. Drupal’s community is smaller but fiercely dedicated, with a focus on enterprise users. Documentation is top-notch, but it’s less beginner-friendly. If you’re DIY-ing it, WordPress support feels more accessible, Drupal assumes you know what you’re doing.

The Verdict: It Depends on You

Here’s the honest truth: neither is “better” in a vacuum. WordPress is perfect if you want a quick, affordable site with minimal fuss—think blogs, portfolios, or small e-commerce shops. Drupal is your pick for complex, custom, or high-stakes projects where control and scalability outweigh ease of use.  

If you’re a solo entrepreneur with no coding skills, start with WordPress. If you’re a developer building for a client with big ambitions (and a bigger budget), Drupal’s your tool. Both can get you there—it’s about matching the CMS to your goals, not forcing your goals into the CMS.  

What’s your take? Have a project in mind?

Share this

Add new comment

One of the most frequently performed actions in Experience Builder (XB) is inserting a component. That UI was moved to the sidebar last week to make it immediately available. After dragging a component onto the canvas, the most common next action is modifying the default component inputs.
So that’s precisely what Jesse Baker, Harumi “hooroomoo” Jang, Luhur Abdi “el7cosmos” Rizal and Lauri “lauriii” Timmanee iterated on this week:

Robust component previews

While modifying a component’s inputs (in the “Settings” tab in the right sidebar you can see above), the preview updates live. This is a crucial part of the XB user experience.
However … Single Directory Components (SDC) can completely fail to render if/when the values assigned to an SDC’s props (i.e. what you typed into that “Settings” tab) are not yet valid. For example: if you managed to type “http” but not the rest of a URL, then that is not a valid URL.
It’s up to XB to not attempt to not update the preview as long as the Content Creator-entered values for a component (currently only SDCs, more later) are not yet valid.

This is the problem Ben “bnjmnm” Mullins, Ted “tedbow” Bowman, Jesse and I fixed after Travis Carden first noticed this. Ben led the development of the solution: performing client-side validation, using both HTML5 client-side validation (used by some Drupal field widgets) and JSON schema validation (which is possible for all SDC props). Once that infrastructure is present, it’s quite simple: don’t update the preview until the input is valid.
Fun fact: XB was using the uri field widget, which uses <input type="url">. That comes with automatic strict absolute URL client-side validation. We had to switch to the link field widget instead.

An obvious consequence: sometimes the preview doesn’t update as fast anymore. So far we’ve found this to not be really noticeable, for two reasons. First, the used field widgets are shaped to disallow invalid values as much as possible (for a type: string, enum: […], you’ll see radio buttons, for example, eliminating the possibility of invalid values altogether). Second, the inputs whose values are “most difficult” to be valid tends to be URLs, and either those URLs aren’t directly visible (in links), or they’re highly visible (images, videos) and it intuitively makes sense those can’t appear until the full, valid value is present anyway.

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Blocks, continued

Last week, initial support for Blocks landed, so this week two continuations of that initial support landed:

• Felix “f.mazeikis” Mazeikis, Dave “longwave” Long and I enabled the thorough validation that landed 4 weeks earlier for Block-sourced components, and given it was now thoroughly validated, it became possible to reliably enable support for rendering entire pages using XB’s page variant!1
  Interesting tidbit: to avoid changes elsewhere in the XB codebase, we had to use PHP Fibers — available since PHP 8.1 — to achieve this. 🤓
• Dave and I added support for derived block plugins, which means that for example one “menu block” per menu is also available in XB, as you’d expect

Grab bag

• Dave, Jesse and Ted fixed a pretty silly bug: it became impossible to drag a component in between two other components! 😅
• Jesse tightened TypeScript definitions (discovered last week while working on section saving). This helps keep out development pace high.
• Also to keep the pace high: our end-to-end test suite always started with the same single article node with a prepopulated XB component tree. This made sense originally, because it literally was first possible to have a server-side-stored component tree and render it, and only then was the UI built to allow a Content Creator to build such a component tree.
  We’ve long since reached that point, so it was about time we added an end-to-end test that starts with an empty canvas. Thanks, Ted & Ben!
• Issue #3484671 by longwave, wim leers: Add support for block derivatives — https://git.drupalcode.org/project/experience_builder/-/commit/fdbbd78d9b6e4f8de0b650fc46643fc5bbc57d6b

Week 27 was November 11–November 17, 2024.

• 1

  That means it can now render the “main content”, “page title” and “messages” blocks!

A new website as easy to navigate as the airport itself

Tampa International Airport consistently ranks #1 in customer satisfaction thanks in part to how easy it is to navigate. Our goal of the redesign of tampaairport.com was to make sure their Drupal 10 website was just as easy to maneuver. Their team wanted to level up their website’s airport map from simple and static to interactive and dynamic.

React application with Drupal content management

The application's goal was to fetch data from the newly implemented site, providing users with a tool to easily navigate the airport, search for specific locations, and even order food in advance at airport restaurants and cafes. The decision to build a React application stemmed from its performance and ability to integrate with the Drupal site, enabling site editors to consolidate, manage, and edit all content through the Drupal UI. This approach ensured that content updates could occur dynamically without the need for additional development efforts, setting up their team to sustain the custom map.

Recognizing that the primary users of this application would be on mobile devices, we worked hard to ensure that all JavaScript libraries and node packages were lightweight and optimized for mobile performance. 
We significantly reduced the overall footprint of the React application before integrating it into the Drupal site by leveraging techniques like code splitting, which separates components that can be loaded independently, and tree shaking, which removes unused code when bundling multiple JavaScript files. This reduced package size ensures a more efficient experience for users accessing the app on their mobile devices.

React Leaflet library

From a technology standpoint, the application is built using React Leaflet, a library that establishes connections between React and the open-source Leaflet JavaScript library.  The incorporation of Leaflet enables us to display custom images, replacing traditional geographical maps within the interface. To dynamically display our SVG maps, we utilize the ImageOverlay component using map information provided by our custom API endpoint provided by Drupal. We use memoization at the location level so that when users switch between maps, the application swiftly recalls previously viewed layers, ensuring a seamless and responsive experience.

Leaflet provides us with the flexibility to set our own boundaries for the map layer. In this application, we opted for a 1000 by 1000 base grid. Within the Drupal UI, editors have the ability to effortlessly add new map locations by specifying X and Y coordinates, effectively placing locations on the map within the established grid.

Furthermore, editors can easily customize the displayed map icons and manage the inclusion of locations within specific icon groupings, all through the user-friendly provided UI. This streamlined process empowers editors to make dynamic adjustments to the map without the need for additional development support.

Interactive user experience

The application also includes a list view of the map in which users can select specific locations, triggering a seamless navigation experience on the visual map. Each location in the list displays details such as their name, description, business hours, current status, and proximity to airport gates. Upon choosing a location, the application responds by centering the corresponding point on the visual map.

This interactive feature enhances user experience, allowing them to effortlessly explore and locate points of interest without manually searching the entire map. The linkage between the list view and the visual map ensures that users can easily transition from browsing a curated list of locations to visually identifying and locating those places on the map interface. It serves as an intuitive method to guide users from the textual representation of locations to their spatial representation on the visual map.

Notably, the list view was designed with accessibility in mind, ensuring better usability for keyboard and screen reader users. This thoughtful implementation caters to a diverse range of users, making it an inclusive and user-friendly experience for all. Check it out for yourself.

The collaboration between the Drupal and React technologies allowed us to build a solution that seamlessly meets the needs of both users navigating the maps and the editors on the Tampa International Airport team. Even though creating this map from scratch was a blast, the custom application I built could easily be applied to another client’s map or way-finding tool.

A strong start of the week by Harumi “hooroomoo” Jang and Jesse Baker, to remove the “insert” panel appearing over the left sidebar, in favor of the components being listed inside the left sidebar:

The XB UI is once again leaping ahead of the back end: the UI for saving compositions of components as “sections” landed, well ahead of the necessary config entity, let alone the needed HTTP API for actually saving those! 👏

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Blocks

After a lot of iteration, Dave “longwave” Long, Felix “f.mazeikis” Mazeikis, Ted “tedbow” Bowman, Lee “larowlan” Rowlands and I landed the initial MR to add Blocks support to XB!

Until now, XB was tightly coupled to Single Directory Components (SDC). That’s no longer the case, thanks to the introduction of:

• ComponentSource plugins: the existing SDC support was refactored into an sdc component source, the new Block support lives in a block component source
• XB’s Component config entities now have a source property, referring to one of those source plugins

There’s still lots of loose ends — from the pragmatic low-level choice of using hook_block_alter() to automatically create Component config entities, to the rather limiting facts that block plugins’ settings forms do not yet work (the default settings are always used). But the basic infrastructure is there!

This was a huge refactor: 35 files, +1861, −878 is no small diffstat 😅

Grab bag

• Atul “soaratul” Dubey fixed the deletion of components with non-empty slots leaving cruft behind.
• The “tabs” in the both sidebars were updated to match the designs by Shyam “shyam_bhatt” Bhatt, Jesse and Harumi.

Week 26 was November 4–November 10, 2024.

Drupal is a complex framework, but it delivers exceptional results, making your investment worthwhile. To fully leverage its potential, it's crucial to follow correct architecture and coding standards, ensuring the project’s long-term success. Working with a knowledgeable partner can get you a long way compared to the situation you’d be in if you started with someone without Drupal experience. In this article, we’ll guide you through the process of finding a solid Drupal development company.

At the beginning of 2025, a new CMS hit the market that could revolutionize how you can manage content online. We mean Drupal CMS, a platform designed primarily for marketers that offers intuitive tools for creating websites without coding. What sets this project apart? What capabilities does it offer, and how does it differ from the Drupal Core? We encourage you to read the article or watch an episode of the “Nowoczesny Drupal” series.

Pantheon strips the values of all query string parameters starting with "utm_" and replaces these with "PANTHEON_STRIPPED". Although they have good reasons to do this (performance), this practice does prevent you from using the values in php. If you want…

Take control of your Drupal 7 to 10 node migration with our latest technical guide. Learn to extend core plugins, manage entity relationships, and implement custom filtering solutions. We’ve included practical code examples and step-by-step instructions for handling basic pages and articles so you can migrate your next project with confidence.

I've started working on maintaining Views Data Export again.

I've decided to document my work in 2 week 'sprints'. And so this article is about what I did in Sprint 3.

The sprint ended up being a lot longer than i'd planned for various reasons, mostly illness. I'm starting another sprint today, and so wanted to post an update and draw a line under 'Sprint 3'.

Sprint progress

At the start of the sprint in the Drupal.org issue queue there were:

• 48 open bugs
• 4 fixed issues.
• 63 other open issues

That's a total of 115 open issues.

By the end it looked like this:

• 45 open bugs
• 1 fixed issue.
• 63 other open issues

So that's a total of 109 open issues, only a 5% reduction from before.

Key goals

In this sprint I wanted to:

• Go through the remaining bug reports

Bug reports

• I've still not managed to get through the remaining bug reports, though some have been closed/fixed in the sprint.

Future roadmap/goals

I'm not committing myself to doing these exactly, or any particular order, but this is my high-level list of hopes/dreams/desires, I'll copy and paste this to the next sprint summary article as I go and adjust as required.

• Update the documentation on Drupal.org
• Not have any duplicate issues on Drupal.org