fidzu : web

We take over projects from other agencies and see them through to completion - even if they are stuck, have errors, or require urgent intervention.

21 Jul 2026 7:25am GMT

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, while others will move to Acquia Source. Drupal CMS played an important role in these decisions by making Drupal more approachable for marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation makes both harder by creating recurring duplication. Integrations, security practices, governance policies, design systems, and technical expertise must all be developed and maintained across multiple platforms.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save tens of millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

20 Jul 2026 10:10pm GMT

Visual page builders often arrive with a familiar promise: fewer developer handoffs and more control for editors. Drupal CMS 2.0 makes that promise concrete by using Drupal Canvas as its default editing experience, with drag-and-drop composition, live previews, and editing directly on the page. The change does not remove front-end development. It moves the unit of work from the individual page towards reusable components and the rules surrounding them.

Single-Directory Components make those rules visible in code. Part of Drupal core's render system since Drupal 10.3, a component can keep its Twig template, metadata, CSS, JavaScript, and related assets together. Props define structured inputs, slots create controlled areas for nested content, and schemas can restrict the values a component accepts. Drupal's SDC quickstart describes these inputs as an application programming interface, or contract, for the component.

Consider a featured article card. Developers can encode its semantic markup, heading structure, image treatment, responsive behaviour, accessibility requirements, spacing, and permitted visual variants. Editors can choose the article, label, image, and approved presentation without adding arbitrary classes or rebuilding the markup. The editor gains useful control because the developer has already decided where flexibility is safe.

Recent Drupal publications make this division of labour clearer. In the 4 December 2025 blog post "Drupal Canvas 1.0 Released," Drupal founder Dries Buytaert described reusable components that match a team's design system. His 23 October 2025 State of Drupal recap presented visual page building for end users alongside component work for front-end developers, while Drupal.org's 24 March 2026 post "Drupal at 25: Built to Last. Ready for What's Next." said Canvas can speed page creation without sacrificing structured content. The pattern is clear: visual tools redistribute development work rather than make technical expertise unnecessary.

Canvas also extends component development beyond traditional Twig-based theming. Its code components contain JavaScript and CSS, can receive page data and custom inputs, and can be created in the browser or maintained in a local codebase. They render through Preact with a React compatibility layer. For teams that need source control, shared files, static assets, or package dependencies, the local workflow supports development outside the Canvas interface and synchronisation with the Drupal site.

Greater component power creates a governance question. A schema can restrict the values a component accepts, but the development team must still decide which choices are meaningful, who owns the component, and how changes will affect pages already using it. Too many exposed options can weaken the design system, while too few can recreate the bottlenecks that visual building is meant to reduce. Reusable components should therefore be reviewed as public interfaces, with clear defaults, accessibility checks, documented variations, and predictable behaviour.

Existing custom themes do not need to adopt this model in one large rewrite. Teams can begin with repeated elements such as cards, teasers, calls to action, and heroes, then move their inputs into documented props and their flexible regions into deliberate slots. Components can be tested within the theme before mature and stable choices are exposed through Drupal Canvas. The future Drupal developer may assemble fewer pages directly, but will carry more responsibility for building the platform on which those pages can be assembled safely.

Readers can follow The DropTimes on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication's Drupal Slack channel at #thedroptimes.

(Kazima Abbas, sub-editor at The DropTimes, writes and curates this week's Editor's Pick.)

20 Jul 2026 4:57pm GMT

At the European Identity and Cloud Conference (EIC 2026) in Berlin, we explored how Threat Modeling with LEGO® SERIOUS PLAY® can help uncover security, privacy, and human-rights threats in age-based content restriction systems. Starting from an Issuer-Holder-Verifier model, participants built harms such as exclusion, surveillance, profiling, and correlation, then mapped them back to flows, actors, and assumptions. The exercise showed how compliance choices can become Web architecture.

20 Jul 2026 9:23am GMT

On 2 July 2026 , the W3C Advisory Board organised a meetup around the web and web standards. It featured three talks and had time to mingle.

15 Jul 2026 3:29pm GMT

This blog post is about incremental improvements by W3C's IT/Systems Operations Team to how W3C member representatives use the W3C website to nominate, change, and remove the people who participate in W3C groups on behalf of their organization.

06 Jul 2026 1:05pm GMT

On January 14, 2006, John Resig introduced a JavaScript library called jQuery at BarCamp in New York City. Now, 20 years later, the jQuery team is happy to announce the final release of jQuery 4.0.0. After a long development cycle and several pre-releases, jQuery 4.0.0 brings many improvements and modernizations. It is the first major … Continue reading →

18 Jan 2026 12:29am GMT

It's here! Almost. jQuery 4.0.0-rc.1 is now available. It's our way of saying, "we think this is ready; now poke it with many sticks". If nothing is found that requires a second release candidate, jQuery 4.0.0 final will follow. Please try out this release and let us know if you encounter any issues. A 4.0 … Continue reading →

11 Aug 2025 5:35pm GMT

Last February, we released the first beta of jQuery 4.0.0. We're now ready to release a second, and we expect a release candidate to come soon™. This release comes with a major rewrite to jQuery's testing infrastructure, which removed all deprecated or under-supported dependencies. But the main change that warranted a second beta was a … Continue reading →

17 Jul 2024 2:03pm GMT

When it comes to crafting an article, the headline is crucial for grabbing the reader's attention and enticing them to read further. In this post, I'll explore the 7 types of article headlines and provide examples for each using the subjects of product management, user experience design, and search engine optimization. 1. The Know-it-All The […]

The post 7 Types of Article Headlines: Craft the Perfect Title Every Time first appeared on Smiley Cat.

29 May 2023 10:20pm GMT

Product management is one of the most exciting and rewarding careers in the tech world. But it's also one of the most misunderstood and misrepresented. There are many myths and misconceptions that cloud the reality of what product managers do, how they do it, and what skills they need to succeed. In this blog post, […]

The post 5 Product Management Myths You Need to Stop Believing first appeared on Smiley Cat.

09 Apr 2023 5:28pm GMT

The role of a product manager is crucial to the success of any product. They are responsible for managing the entire product life cycle, from conceptualization to launch and beyond. A product manager must possess a unique blend of skills and qualities to be effective in their role. Strong strategic thinking A product manager must […]

The post The Key Strengths of the Best Product Managers first appeared on Smiley Cat.

11 Dec 2022 4:43pm GMT

Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT