Keeping your website up to date is crucial for security, performance, and functionality. For content management systems (CMS) like Drupal this means regularly updating core software, contributed modules, and themes. To simplify this process, many hosting providers and third-party services offer online automatic subscription services that promise to handle these updates for you.
While the convenience might sound tempting, there are compelling reasons to think twice before opting for this approach. Here’s why manual updates—or at least a more hands-on strategy—are often the smarter choice.
Automatic updates sound great until they happen at the wrong time. When you rely on an online subscription to push updates, you often lose control over when those updates occur. An update might roll out right before a major site event, during peak traffic, or without prior testing. Even minor updates to core or contrib modules can introduce compatibility issues, break custom code, or disrupt functionality. Without a staging environment to test changes first, you’re essentially gambling with your live site’s stability. Manual updates, on the other hand, let you schedule maintenance windows and verify everything works as expected before going live.
Most websites aren’t just a collection of off-the-shelf components—they include custom code, configurations, or integrations tailored to specific needs. Automatic update services don’t know your site’s unique setup. A new version of a module or theme might conflict with your customizations, leading to broken features or a completely inaccessible site. For instance, an update to a core CMS component might deprecate a function your custom module relies on, and an automated system won’t pause to warn you. By managing updates yourself, you can review changelogs, test compatibility, and make adjustments proactively.
The pitch for automatic subscriptions often leans heavily on security: “Stay protected with the latest patches!” While timely updates are indeed critical for patching vulnerabilities, blindly trusting an automated service isn’t a foolproof security strategy. What if the service itself is compromised or fails to verify the integrity of update packages? Worse, some updates might unintentionally expose new vulnerabilities that hackers can exploit before you even notice. Manual updates give you the chance to vet each release, cross-check with community feedback, and ensure you’re not trading one risk for another.
When an automatic update goes wrong—and it can go wrong—you’re often left scrambling. Many subscription services don’t offer seamless rollback options, meaning you’re stuck troubleshooting a broken site in real time. If you handle updates yourself, you can (and should) back up your site beforehand, test the update in a development environment, and have a clear path to revert changes if something fails. Automation might save time upfront, but it can cost you dearly when recovery becomes a manual nightmare.
Automatic update subscriptions aren’t free—whether it’s a monthly fee or bundled into a hosting package, you’re paying for convenience. Over time, those costs add up, especially if the service doesn’t deliver as promised. More importantly, you become dependent on a third party to maintain a critical part of your site. If the provider changes their terms, raises prices, or shuts down, you’re left in the lurch. Managing updates in-house keeps you in control and avoids tying your site’s fate to someone else’s business decisions.
Updates aren’t just about security—they often bring performance improvements, new features, or bug fixes that could enhance your site. An automatic system applies these changes without context, but a manual approach lets you dig into what’s new. Maybe a contrib module now offers a setting that could streamline your workflow, or a theme update improves mobile responsiveness. By taking charge, you can align updates with your site’s goals instead of letting them happen passively.
Instead of handing over control to an automatic subscription, consider a hybrid approach. Use tools like Composer to streamline updates while retaining oversight. Set up a staging environment to test changes, automate backups, and establish a regular maintenance schedule that fits your needs. If you’re short on time or expertise, hire a developer or agency for periodic reviews rather than outsourcing to a faceless service. The goal is to stay proactive, not reactive.
Automatic online subscriptions for updating core, contrib modules, and themes might promise a hands-off solution, but they come with trade-offs that can jeopardize your site’s stability, security, and flexibility.
Websites are living systems—each with unique quirks and requirements—and they deserve more than a one-size-fits-all fix. By opting for a manual or semi-manual update process, you’ll keep your site running smoothly, minimize risks, and maintain the freedom to adapt on your terms. Convenience is nice, but control is invaluable.
Drupal Updates Drupal PlanetDear Readers,
Over the past year, Drupal’s Certified Partner Program has made significant strides, adding 26 new companies and bringing the total to 101 Certified Partners. These partners played a crucial role in Drupal’s sustainability, sponsoring 87% of all contributions in 2024—a massive 158,387 issue credits out of 203,738 total contributions. But here’s the challenge: only 7% of the 1,440 active organizations on Drupal.org are Certified Partners, and just 15% of companies are responsible for 96% of all contributions. This imbalance threatens the long-term sustainability of Drupal, and we need to do more.
As Tim Doyle outlines, Drupal's future depends on expanding its network of Makers—agencies and organizations that give back to the project rather than just benefit from it. The Drupal Association has set a bold new goal: tripling the number of Certified Partners and pushing for greater participation from larger companies that profit from Drupal but haven’t yet committed to contributions. At the same time, plans are in motion to reward high-level contributors and drive more business to those actively supporting Drupal’s future.
This is a pivotal moment. With Drupal CMS creating new opportunities and the open-source landscape rapidly evolving, agencies must decide: Are we investing in the future of Drupal, or just relying on it? If your company builds with Drupal, now is the time to step up, contribute, and help shape the next chapter of the project.
We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now.
To get timely updates, follow us on LinkedIn, Twitter and Facebook. You can also join us on Drupal Slack at #thedroptimes.
Thank you,
Sincerely
Alka Elizabeth
Sub-editor, The DropTimes.
Today we are talking about Drupal Contribution, how you can approach it within your company, and why a Contrib First approach is important with guest Steve Wirt. We’ll also cover Config Importer & Tools as our module of the week.
For show notes visit: https://www.talkingDrupal.com/490
TopicsSteve Wirt - civicactions.com swirt
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Avi Schwab - froboy.org froboy
MOTW CorrespondentAvi Schwab - froboy.org froboy
DevCollaborative is a certified Drupal Partner, demonstrating our expertise in the space and giving back to the open source community that our business benefits from.
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.
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.
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 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.
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.
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.
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.
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?
Drupal WordPress Drupal PlanetOne 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:
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!
Last week, initial support for Blocks landed, so this week two continuations of that initial support landed:
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.Week 27 was November 11–November 17, 2024.
That means it can now render the “main content”, “page title” and “messages” blocks!