Six Bug Reporting Best Practices for Manual Quality Assurance Engineers

Kathleen Smith

Manual quality assurance (QA) in web development is the process of manually checking a website or application to identify bugs, usability issues, and design inconsistencies. Typically performed by QA specialists or developers, it ensures a seamless user experience by catching issues that automated tests might miss. In other words, it’s essential to delivering a fully functioning website that works as intended.

However, identifying bugs is only part of the QA job — reporting them effectively is just as critical.

A well-written bug report helps developers understand the issue quickly, saves time, and improves the chances of a fast and accurate fix. In this post, we’ll look at six key characteristics of an actionable bug report.

1. Clear, Descriptive Titles (Think “Obvious” but Helpful)

First impressions matter, and your bug title is the first thing your team will see — so make it count! A good title conveys exactly what the issue is by identifying the specific component, page, or feature affected, along with a concise summary of the problem.

Consistency is key — avoid interchanging terminology (e.g., “Taxonomy” vs. “Taxonomy Term,” which may refer to entirely different things) and stick to the naming conventions established in your CMS or project.

Example Title:
“‘Cute Puppy Photo Request’ form can be submitted even when required fields are blank.”

2. Explain How to Reproduce the Issue

Reproducibility is the cornerstone of bug resolution. If developers can’t replicate the issue, they’ll (rightfully) struggle to understand what QA is reporting.

Provide clear, step-by-step instructions in the exact order you performed them. Don’t skip seemingly trivial details, as these can often be critical in reproducing the problem accurately.

Example Steps to Reproduce:

As an anonymous user, navigate to [relevant URL here]
Verify that the “Cute Puppy Photo Request” form is visible
Leave all required fields blank
Click the “Submit” button at the bottom of the form
Note that the form is successfully submitted without validation errors

3. Include Relevant Screenshots or Screen Recordings

Visual aids like screenshots or videos provide context and make it much easier for developers to understand visually complex issues, such as alignment problems or animation glitches. Tools like Scrnli, native OS features, or browser extensions can help capture these details.

For extra impact, consider providing a voiceover for your recordings. There’s nothing like softly narrating QA best practices to soothe developers while they debug.

Pro tip: Include screenshots for any ticket a QA professional touches. Not only does this serve as a handy reference for future troubleshooting, but it can also pinpoint exactly which merge introduced a new bug.

4. Describe the Expected vs. Actual Results

Clearly outlining both the expected and actual outcomes helps distinguish a genuine bug from a feature or misunderstanding. Whether it’s a quick one-liner (“error should not appear”) or a more detailed explanation involving user experience considerations, this context is invaluable.

Example:

Expected Result: After clicking “Submit,” the user should see an error message if the required fields are not filled out.

Actual Result: After clicking “Submit,” the user can submit the form without completing the required fields, and no error message is displayed.

5. Specify the Environment and Configuration

Some bugs occur only in specific environments (we’re looking at you, Safari). Always include details about the browser, OS, device, and CMS or app version where the issue was encountered. This helps prioritize fixes and ensures issues can be replicated under the same conditions.

Example:

Browser: Chrome v95.0
OS: Windows 10 Pro
Device: Desktop
Screen Resolution: 1920×1080
CMS Version: WordPress 6.5

6. Reference Related Bugs or Previous Fixes

Many bugs are related to previous issues or fixes. If something feels familiar, take the time to dig into the backlog or related tickets—it might save hours of investigation. Mentioning related bugs, project-specific issues, or core bugs provides helpful context for developers and ensures nothing falls through the cracks.

Example:
“This issue appears to have resurfaced after the ‘Cute Puppy Forms’ module update in ticket #12345.”

Final Thoughts

Effective bug reporting is one of the most valuable skills a QA engineer can bring to a project. Clear, detailed, and organized reports enable developers to address issues quickly, ensuring a better end product. And let’s be honest — developers will secretly thank you for it (even if they never say it out loud).

Choosing a Content Management System: Proprietary vs. Open Source

Grant Proulx Web Copywriter

Let’s say your organization needs a new website. You meet with your team to discuss the best way forward. Some are touting the benefits of an open-source content management system (CMS) like Drupal or WordPress. Meanwhile, others argue that a proprietary system is the right way to go. But you’re the one who has to make the final call. So, which one will it be? In this post, we’ll look at open source vs. proprietary CMS and what each one has to offer.

If you know anything about us, you already know that we strongly prefer open source for a long list of reasons. We’ll get into those reasons below, but we’ll also give proprietary systems a fair shake — promise. Hopefully, the more you know about each option, it will be clear why we’ve built our organization around open source right from day one.

What is a proprietary CMS?

A proprietary CMS is a software platform owned and controlled by a company. Its users need to purchase licenses or subscriptions for access and updates. It typically offers limited customization compared to open-source CMS, with restricted access to the source code.

Organizations that choose the proprietary route usually cite a few main reasons:

Dedicated Support: Proprietary CMS platforms typically have dedicated customer support, offering immediate help with technical issues, bugs, and updates.
(Perceived) Security: With a closed-source environment, clients sometimes have the perception that proprietary CMS platforms have fewer vulnerabilities, since the code is not accessible to the public. The vendor manages security updates and patches. (Below, I’ll get into why this is more about perception than reality.)
Tailored Solutions: Proprietary CMS vendors may offer customized solutions, features, or integrations to meet specific business needs within a particular industry.
Legacy: In many cases, the client is already deeply invested in other proprietary platforms/software from a provider (their suite of office applications for example), so they’ll also use their CMS for the sake of convenience and continuity. There’s a pretty large company whose name starts with ‘M’ that relies heavily on this in their sales pitch.

These benefits, however, often come with trade-offs, such as higher costs and limited flexibility compared to open-source CMS options.

So, what about open source?

Open-source CMS platforms like WordPress, Joomla, and Drupal account for a majority of websites on the internet. WordPress alone powers approximately 62.7% of all sites. They’re also usually more cost-effective to maintain in the long run compared to proprietary CMS platforms for a number of reasons:

For Starters, They’re Free: Open-source platforms like WordPress and Drupal are free to use, eliminating the need for expensive licensing fees associated with proprietary software.
No Vendor Lock-In: With a proprietary CMS, the vendor retains ownership of the code, limiting your control and flexibility. With an open-source CMS, clients own and control the code, meaning full customization and portability is yours. Using open-source software also means you’re not dependent on a single company for updates, support, or hosting.
Flexibility and Customization: Drupal and WordPress offer extensive customization options with thousands of themes, plugins, and modules; users can tailor their websites to meet their needs without being locked into vendor restrictions.
Community Support: Open-source platforms have large, active communities of developers and users who contribute to forums, create plugins/modules, and more. This collective knowledge base can provide faster solutions and innovations.
Continuous Improvement: Open-source platforms are regularly updated with security patches, new features, and enhancements contributed by the community, making them more dynamic than proprietary software, which might have slower release cycles.
Ownership and Control Is All Yours: With open-source software, you have full ownership and control over your website, including the ability to host it anywhere and modify the underlying code. Proprietary systems may impose hosting restrictions and limit access to the source code.
Security and Transparency: Open-source platforms are generally considered to be more secure because the code is publicly available for scrutiny, allowing security experts to identify and patch vulnerabilities quickly. Proprietary systems may be more opaque, making it harder to spot and fix security issues. So while it’s true that many more people have access to open-source code, this results in greater platform security — despite what many proprietary system providers (and their sales teams) would like you to believe.
Scalability: Open-source platforms like Drupal are highly scalable, making them suitable for both small websites and large enterprise-level applications, whereas proprietary solutions may have limitations or require expensive upgrades to scale effectively.
Integration Capabilities: Drupal and WordPress are known for their ability to integrate with a wide range of third-party tools, APIs, and systems, providing more flexibility in building feature-rich websites — while proprietary platforms may restrict integrations or charge extra for them.
Innovation: Open-source platforms often lead in innovation, as developers from all over the world can contribute new ideas and functionalities, fostering a continuous flow of creativity and technical advancement.

It’s your call.

So, returning to our opening paragraph scenario, it’s your call; you have proponents in your organization on each side of the coin. Which do you choose? Do you listen to those team members clamoring for a proprietary CMS and its benefits? Or do you choose the flexibility and efficiency of an open-source platform?

Not that we would openly encourage you to choose one over the other. Good heavens, no! However, if you should decide to go with an open-source CMS — specifically Drupal or WordPress — we have a little motto here at Kanopi:

Never build alone.

Since 2010, we’ve been building websites that meet our clients’ unique needs, whether designing and developing from the ground up or enhancing existing sites with upgrades and CMS migrations. Our approach combines UX research, discovery, and visual design to create a user-friendly digital experience, followed by expert development to bring your vision to life. Even after launch, we provide ongoing support to ensure your site continues to perform at its best. With us as your partner, even the staunchest proprietary fans will be tipping their hats to you.

Have a look at some of our favorite Drupal and WordPress projects.

Drupal 7 End of Life: A Guide to Next Steps

Allison Manley Director of Marketing & Communications

This post was last updated in September 2024 to incorporate information about the recent release of Drupal 11.

Kanopi is a Drupal Certified Partner and can help with your migration needs.

Launched a decade ago, Drupal 7 (D7) has allowed many organizations, from airports to government agencies, hospitals, and more, to create engaging websites powered by over 40,000 modules and 2,500 themes.

But as they say, all good things must come to an end. According to a Drupal PSA, Drupal 7 will reach its end of life in January 2025, and its farewell leaves many organizations considering their next steps.

D7’s end-of-life (EOL) was originally planned for November 2022, but with the impact of COVID-19 on so many website owners and their budgets, the Drupal maintainers decided to extend the timeline to 2023. Now, a final extension has been made, pushing the timeline again by two years.

Even with this extension, the impending EOL date has a lot of organizations that are dependent on Drupal 7 weighing their options. These organizations can either:

Stay on D7 using a long-term support provider
Migrate to Drupal 11 (the most recent version)
Switch to a new CMS

Every website and organization is different. There’s no catch-all answer when it comes to deciding when and how to upgrade your Drupal system. However, it’s highly recommended that organizations still using Drupal 7 consider moving to Drupal 11. This gives you the greatest access to new features and functionality to ensure your website is at the top of its game.

In this blog post, we’ll outline the pros and cons of each option and describe the process of switching to Drupal 11.

Drupal 7 End of Life: Frequently Asked Questions

Drupal timeline featuring Drupal 11’s 2024 release, Drupal 7’s 2025 EOL, and Drupal 10’s 2026 EOL

What does Drupal end of life mean?

When software reaches its end-of-life date, it will no longer receive bug fixes or security updates from the Drupal community and security team. This also includes the modules that are used!

How long will Drupal 7 be supported?

Previously, Drupal 7’s end-of-life was scheduled for November 2023. In June of 2023, Drupal extended the deadline to January 5, 2025. After this time, the Drupal Security team will no longer provide support or Security Advisories for Drupal 7.

Is Drupal 7 still supported?

Yes. Drupal 7 will still be supported until January 5, 2025. Even though this version is a decade old, its end-of-life does not mean the end of your site.

Once the community stops supporting Drupal 7 after EOL, a group of approved and vetted vendors can continue to provide security updates for Drupal 7 core and certain contrib modules under the Drupal 7 Vendor Extended Support program.

What is the difference between all Drupal versions?

Currently, Drupal 7, 10, and 11 are supported. Drupal 8 and 9 both reached their end of life and are no longer supported. Drupal 11 is the most recent version.

When did Drupal 11 launch?

Drupal 11 launched in August 2024. This version offers helpful new features, better workflows, and greater flexibility for website builders.

What do you need to do to prepare to get out of Drupal 7?

If you’re ready to transition away from Drupal 7, you’ll need to ensure your team is aligned and ready to take on the next steps. To prepare for an upgrade, you should:

Conduct technical mapping. When picking new modules or new features, keep in mind that you’re planning for the future. Do you have a clear update path for when you upgrade to D11 (and beyond)? Check out Kanopi’s Drupal 7 to 10 migration guide for a full sequence of steps to follow (you’ll need to upgrade to Drupal 10.3 before launching a D11 migration).
Conduct a content audit. A content audit helps determine what should stay and what should go on your site. This is especially helpful when it comes time to migrate to a new site.
Identify stakeholders. You’ll likely have several members of your team involved in the steps needed to update your site. Make note of who will be responsible for what and how you’ll start the process.
Determine your budget. Whether you migrate to D11 or move to an entirely new CMS, you’ll need to set a realistic budget to ensure you can complete the project.

Drupal 7 End of Life Options

To upgrade or not to upgrade. That is the question…

The path after Drupal 7 is not a one-size-fits-all process. You have several other paths to choose from regarding the next steps to take. Here are the options to consider:

1. Continue using Drupal 7

Your website won’t cease to exist after Drupal 7’s EOL date, so you can continue using the system for an extended period. This choice is recommended for organizations that need a bit more time to gather the resources and budget needed to switch to D11 or a new CMS.

Pros

Your modules will still continue functioning.
Ongoing support and technical expertise from a partner like Kanopi can help support your site until you’re ready to migrate.

Cons

There won’t be any security fixes.
You may be on your own to fix any modules or integrations that stop working.
You may miss out on innovative new features.

2. Upgrade from Drupal 7 to 11

For organizations that are ready to upgrade their site and take advantage of new functionality and security features, migrating to Drupal 11 is the way to go.

Pros

The powerful migration module has many tools to help developers migrate even the most complex Drupal 7 website to Drupal 11.
If you’re already considering a website redesign, you can start fresh on Drupal 11 and have time to plan.

Cons

It could be costly, depending on the complexity of your site. An upgrade to Drupal 11 from Drupal 7 will require a developer to create a migration, meaning a brand new website needs to be built in Drupal 11. All content from your current Drupal 7 will be migrated to the new site or rebuilt.

3. Move to an entirely new CMS

This option only makes sense if you have the funds to carry out an extreme rebuild. But if your site is very simple (for example, a blog) and doesn’t require many features or functionality, moving your legacy Drupal 7 to a CMS like WordPress can be a very cost-effective solution.

Pros

Moving to a new CMS can be a cost- and time-effective solution if your site is simple.
You can use the transition as an opportunity to launch a full brand refresh.

Cons

If your site is more advanced, it can be costly and time-consuming to rebuild it on an entirely new platform.

To help decide which path to take, consider your organization’s:

Budget: If your D7 site is complex, do you have the funds needed to upgrade to D11 or move to a new CMS?
Time constraints: Does your team have enough time to devote to a website rebuild? Will you have more or less free time in the coming months?
Goals: Do you want to expand your website in the future to drive more conversions? Are you interested in modernizing your website or updating your brand?

If you’re not ready to make a decision at this exact moment, some agencies and providers can keep your D7 website updated and move you to Drupal 7 long-term support.

You’ll have to rebuild eventually. But, by choosing a support package, you can take the time you need to make a strategic decision, as well as buy some time to allow funds to free up.

Kanopi’s Drupal 7 End of Life and Support Package

At Kanopi, we’re here to help Drupal 7 users until you’re ready to make the jump. We offer solutions for organizations who decide to stay on Drupal 7 past its EOL and those ready to transition to Drupal 11.

For those who decide to remain on Drupal 7 for the time being, there is some good news. When D7 reaches its end of life, Drupal users will not see any immediate difference from the front-end perspective, and neither will your site visitors! In the back-end of your Drupal site, the platform and modules will begin to display as “Unsupported,” but everything else will essentially continue to work as it had previously.

By choosing Kanopi as your long-term support provider, we patch and maximize the value of your Drupal 7 investment for as long as possible—with the lowest level of financial investment until you are ready to move to D11.

Our Drupal 7 support services include:

A continuous improvement approach: Instead of large structural changes, we work on small incremental changes that support your budget. Our services include module and plugin upgrades, bug fixes and security patches, updating content types/views, and more.
A website growth plan: In addition to keeping your D7 site supported beyond EOL, we also work closely with you to future proof your site. We create a roadmap for exactly how you can increase conversions for your organization using your website
Support and security: Kanopi currently supports 150+ Drupal 7 domains. We work to keep their sites healthy until they’re ready for an upgrade.

If you’re interested in learning more about our D7 support plans, contact the Kanopi team here. We can help you determine the best path forward based on your goals.

Transition to Drupal 11 with Kanopi

For most organizations, transitioning to Drupal 11 is the recommended path to getting the most value out of your website. Making the switch allows you to stay ahead of the curve and ensure your website takes advantage of the security tools and advanced features of D11.

Upgrading your Drupal site from D7 to D11 is a more involved process than traditional upgrades because you’ll have to transfer all of your data to a new Drupal 11 site. Plus, before you can launch your Drupal 11 site, you must update to Drupal 10.3. As Drupal explains, “Sites running 10.2.x or earlier versions must first update to 10.3.0 or later prior to updating to Drupal 11, because all core updates added prior to 10.3.0 have been removed. If any modules or themes have been removed you may use the respective contributed project instead.”

With that in mind, Kanopi’s Drupal 7 to 10 migration guide describes the steps you need to follow to upgrade your site, including:

Audit your Drupal 7 site. Review all types of site functionality in this audit, including your modules, content types, paragraphs, etc. This can help you determine where you stand currently and if you should conduct any maintenance before upgrading your site.
Identify necessary redirects to keep your SEO rankings. Identify top-performing content and determine whether you’ll need to implement a redirect to maintain SEO performance.
Create a backup site copy. This will serve as a migration source to ensure everything is in the right place.
Review hosting for technical requirements. Ensure your website host can support the minimum technical requirement of PHP 8.1. Also, review your host for performance elements such as speed, security, and reliability.
Migrate your site’s content. Determine which content types you’d like to maintain or alter, then let your developer initiate the migration.
Upgrade your themes and modules. Choose the right theme for your organization, add your custom features, and organize your content.
Finalize migration, deploy, and run tests. Identify any issues or areas for improvement and test your site until you get it right.

Once you’re on Drupal 10, you’ll have to take a few additional steps to prepare for Drupal 11. Resolve themes and modules that were deprecated in Drupal 10 and removed from Drupal 11 and update contributed modules and projects to ensure compatibility in Drupal 11.

Review the rest of the complete guide for in-depth tips on the common considerations and challenges organizations face when upgrading their Drupal 7 sites to Drupal 10 and eventually 11.

Making the Most of Your Site Upgrade

If you decide to make the leap to Drupal 11, congratulations! This is an exciting moment in your web design journey.

However, you may feel apprehensive ahead of the migration process. Of course, you want your new site to be successful in driving conversions and engaging audience members, and you don’t want to lose any vital data along the way.

Make the most of your site upgrade by:

Using this opportunity to launch a full brand refresh, if desired. You’re already creating a new website for your organization. Why not use this opportunity to refresh your brand? Consider the elements of your brand that could use updating, such as your logo, color palette, fonts, or imagery. Incorporate these fresh elements as you update your site to Drupal 11.
Upgrading your site in multiple ways, including accessibility and user experience. Does your website incorporate the latest accessibility guidance? How about user experience best practices? As you craft your Drupal 11 site, keep in mind how you can optimize your site for accessibility and usability. For example, can you simplify your navigation menu? Can you increase text contrast to assist people with visual impairments?
Taking advantage of Drupal 11’s innovative tools. D11’s innovative content staging workflows, simplified front-end development, and configuration flexibility make the platform much more user-friendly and moldable for developers. Use these tools to give your website the design elements and innovative features that you always wanted to offer.
Testing your new site every step of the way to check for issues or roadblocks. Conduct frequent tests to determine if everything is working as it should. This way, you can identify roadblocks and address them before they become detrimental to your ability to connect with audience members.
Reaching out to web development professionals for help. If you feel overwhelmed by the task ahead of you when it comes to updating your Drupal site, don’t panic. Website development professionals like our team at Kanopi can help ensure your upgrade runs smoothly and you’re making the most of Drupal 11’s advanced features.

These tips will help you make the most of your upgrade and move into the future with a more well-rounded, advanced website.

How Kanopi Has Helped D7 Clients

Kanopi offers a variety of website growth plans, allowing you to choose the path that best suits your needs and goals. These plans range from a Drupal 7 transition plan to technical SEO strategies and fully customized plans.

If you’re ready to start the migration process, we’re happy to help. Our web design professionals at Kanopi are experts in Drupal planning and development. Each team member has an average of 11 years of experience in Drupal Development, and several of them are Acquia and Pantheon certified professionals. We are also a supporting partner of the Drupal Association, regularly contribute to the Drupal Project, and are one of the main organizers of BADCamp.

A Handy Visual Guide to Drupal Versions, from 7 to Modern Drupal

Jim Birch Director of Build Engineering

If yours is one of the 42% of Drupal sites that are still using Drupal 7, we’re writing this post specifically with you in mind.

After all, you’ve probably heard the news by now; as of January 5th, 2025, everyone’s beloved, trusted Drupal version 7 will reach its end-of-life. If you haven’t done so already, this means it’s time to start thinking about the ‘m’ word — yup, migration — to a newer version.

Modern Drupal’s versions 8, 9, 10, and the newly released 11 are similar in many ways, yet very different in others. The Drupal 7 migration process is kind of similar to finally trading in your trusty old well-worn VW camper van for a brand new Porsche. As you can imagine, a transition of such magnitude could be a tad jarring for some — not to mention a wee bit confusing.

That’s why we’ve created this handy infographic, to give you an overview of the key differences between each modern Drupal version, their respective functionalities, and how they solve specific business needs.

What about Drupal 8 & 9?

Since these versions have both reached their end-of-life, there’s no long term support for them. We’ve still included them in our comparison, since their features are integral to understanding the path of version 10 and beyond; however, we don’t recommend them for new builds or upgrades.

An overview of Drupal 7 to Drupal 12

This chart is best viewed when downloaded.

The one thing to keep in mind is that anything higher than Drupal 8 is part of Drupal’s composable future — i.e., not only can Drupal integrate with virtually any business or marcom software or service, but it in itself is composable. Taking the best open source tools — CKEditor, Symfony, and Twig, for example — allows modern Drupal to keep innovating and improving while keeping your website’s appearance and functionality intact.

Drupal remains an excellent platform, and its newest releases demonstrate its commitment to staying current and providing the best possible experience to its users. It’s also incredibly complex, which is why any successful migration from Drupal 7 will involve a great deal of planning and resources — not to mention expertise. That’s why it’s highly recommended to work with a web developer, whether as part of your organization or a third-party web development firm.

Where does Drupal CMS fit in?

Drupal CMS aims to make Drupal more accessible to a broader, less technical audience while keeping the platform feature-rich. Rather than downloading and installing the latest version of Drupal, a user who wants to spin up a Drupal site quickly can instead download Drupal CMS for an easy-to-use, out-of-the-box experience. This makes it easier than ever for users to go from installation to a fully functional website, even if they have little to no prior Drupal experience. Drupal CMS comes pre-packaged with carefully curated “recipes” that cater to everyday use cases. We’ve written about Drupal CMS here.

Screengrab of the on-demand webinar from Jim Birch about Drupal Recipes and Starshot

Kanopi worked on its Recipes initiative. Check out this webinar by Kanopi’s Jim Birch called “Recipes. Starshot, and the Future of Drupal.” (47 minutes)

Need more help?

When searching for the right Drupal partner, it’s helpful to find an organization with experienced developers who contribute to the project on an ongoing basis. At Kanopi Studios, we provide Drupal development services for all types of organizations, including nonprofits, corporations, healthcare organizations, and higher education institutions.

We’ve also written several blog posts about the various Drupal versions and their upgrade paths:

Ready to launch the migration process? Contact our team today!

References:

Digital Asset Management Tools for Drupal and WordPress

Katherine White Chief Technology Officer

In the fast-paced digital content creation and management world, having a robust system to organize and distribute your assets is crucial. This is where Digital Asset Management (DAM) tools come into play. DAM tools provide a centralized platform to store, manage, and share various digital assets such as images, videos, documents, and more. Fortunately, many of these tools seamlessly integrate with popular content management systems (CMS) such as Drupal and WordPress.

What is a Digital Asset Management Tool?

A Digital Asset Management tool is essentially a digital library for all your digital assets. It allows you to:

Store: Keep all your assets in a secure and organized repository.
Manage: Categorize, tag, and search for assets with ease.
Share: Distribute assets internally or externally with controlled access.
Track: Monitor asset usage and performance.

One of the biggest benefits of using open-source software such as Drupal or WordPress is the modular nature of the platforms. Plugins and modules are already available for many common third-party systems, including DAMs. If a more custom solution is needed, a qualified partner can build an integration for any tool that provides an API and works seamlessly with your CMS. If a DAM is right for your organization, several integrate well with either Drupal or WordPress for businesses with a wide range of resources and needs.

1. Acquia DAM (formerly known as Widen)

Acquia DAM is a comprehensive DAM solution offering various features for managing and distributing digital assets. It is a powerful and versatile solution suitable for organizations that require a robust and scalable platform to manage their digital assets effectively.

Pros:

Seamless Integration: Acquia DAM integrates smoothly with both Drupal and WordPress, making it easy to access and manage assets directly within your CMS.
Robust Features: It offers a wide array of features, including fine-grained roles and permissions, advanced search, metadata management, and version control.
Scalability: Acquia DAM can handle large volumes of assets and users, making it suitable for organizations of all sizes.
Brand Consistency: Provides centralized control over brand assets, ensuring consistency across all channels.

Cons:

Cost: Acquia DAM can be relatively expensive compared to some other DAM solutions.
Complexity: The extensive feature set can make the learning curve a bit steep.

Common Use Cases:

Enterprise-Level Asset Management: Acquia DAM excels in managing large and complex asset libraries, making it suitable for large organizations with diverse asset management needs.
Marketing and Creative Teams: The platform’s robust features and integrations support marketing and creative workflows, streamlining asset creation, management, and distribution.
Brand Management: Acquia DAM helps maintain brand consistency by providing centralized control over brand assets and ensuring proper usage across all channels.

2. Bynder

Bynder is a user-friendly and collaborative DAM solution that excels in helping organizations maintain brand consistency and streamline creative workflows. Its intuitive interface and focus on teamwork make it a valuable tool for marketing and creative teams that must collaborate effectively and ensure that their brand is presented consistently across all channels.

Pros:

Intuitive Interface: Bynder’s interface is easy to navigate and understand, even for users with varying levels of technical expertise, minimizing the learning curve.
Collaboration: The platform offers tools for real-time collaboration, allowing teams to work together on asset creation, review, and approval processes, fostering efficiency and productivity.
Brand Consistency: Bynder helps maintain brand consistency by providing centralized control over brand assets, ensuring that everyone uses the most up-to-date and approved versions.
Creative Workflow Management: Bynder streamlines creative workflows with features like task management, project tracking, and feedback tools, facilitating efficient collaboration between creative teams and stakeholders.

Cons:

Limited Integrations: While Bynder integrates with Drupal and WordPress, the integrations might not be as seamless as some other DAM solutions.
Pricing: Bynder can also be on the pricier side.

Common Use Cases:

Marketing and Creative Teams: Bynder’s collaborative features and focus on brand consistency make it ideal for marketing and creative teams to work together efficiently and maintain brand standards.
Brand Management: The platform’s centralized control over brand assets and usage guidelines helps organizations ensure their brand is consistently presented across all channels.
Global Teams: Bynder’s cloud-based architecture and multi-language support make it a good fit for organizations with globally distributed teams. It facilitates collaboration and asset sharing across different locations.

3. MediaValet

MediaValet is a cloud-based digital asset management (DAM) solution that prioritizes scalability, performance, and security, making it well-suited for organizations that handle large volumes of digital assets and require fast, reliable access.

Pros:

Cloud-Based Architecture: MediaValet’s cloud-based nature eliminates the need for on-premise infrastructure, enabling easy access to assets from anywhere with an internet connection.
High Performance: The platform is built for speed and efficiency, ensuring quick uploads, downloads, and asset previews, even for large files.
Scalability: MediaValet can handle massive asset libraries and user bases, making it suitable for organizations with growing needs.
Security: The platform employs robust security measures, including encryption, access controls, and audit trails, to safeguard valuable digital assets.
Integrations: MediaValet offers integrations with various third-party applications, including popular CMS platforms and marketing tools, streamlining workflows.

Cons:

User Interface: Some users might find MediaValet’s interface less intuitive than other DAM solutions.
Feature Set: While MediaValet offers a good range of features, it might not be as comprehensive as some other solutions.

Common Use Cases:

Large Asset Libraries: MediaValet excels in managing and delivering large volumes of digital assets, making it ideal for organizations with extensive media libraries.
High-Traffic Environments: The platform’s focus on performance ensures fast and reliable asset access, even in high-traffic scenarios.
Security-Conscious Organizations: MediaValet’s robust security features make it a good fit for organizations that handle sensitive or confidential information.
Distributed Teams: Cloud-based access enables teams across different locations to collaborate and share assets seamlessly.
Video and Rich Media Management: MediaValet’s support for video and rich media formats and its high-performance capabilities make it well-suited for organizations that work extensively with these assets.

4. PhotoShelter

PhotoShelter has an intuitive UI to drive brand engagement, get better content ROI, and improve efficiency. PhotoShelter is used by 75% of the top 50 higher education institutions, including global enterprise clients like Delta Airlines, FreshDirect, IMG Golf, and Wendy’s. The HIPAA compliance make it a good choice for healthcare.

Pros:

HIPAA compliance & proprietary data infrastructure: PhotoShelter manages its own HIPAA-compliant private cloud infrastructure, so data isn’t sent to a 3rd party for hosting. And the company claims it has never been hacked or lost an asset in the 20 years since it was founded.
Real-time workflow: With smart features, PhotoShelter can get content from live shots to launch on social media in under a minute, so users are never slowed down.
Easy search with AI: PhotoShelter’s unique AI Visual Search and proprietary AI tagging capabilities can save tons of time on searching and adding manual metadata.
Social media content amplification: PhotoShelter offers tools to automatically distribute content and track its engagement across other social media accounts. An organization can tap into followers from partners, influencers, employees, or other key groups.

Cons:

Not for very small organizations: PhotoShelter is not appropriate for very small organizations; it works best for organizations that are mid-market or larger and need a collaborative platform.
Not for federal government organizations: PhotoShelter is not FEDRAMP or ITAR/EAR certified, so it is not appropriate for organizations requiring those certifications.

Common Use Cases:

Enterprise Organizations: Enterprise organizations trust PhotoShelter to ensure their content workflows are seamless across all of their teams.
Marketing & Creative Teams: PhotoShelter’s real-time workflow, collaboration tools and integrations mean it can help marketing & creative teams get content created, organized, and distributed faster than ever.
Live Content: With PhotoShelter’s real-time distribution capabilities, it is great for getting content out from live events, ensuring maximum engagement.
Complex Social Media Ecosystems: Because of PhotoShelter’s social media distribution & tracking capabilities, PhotoShelter’s social media distribution & tracking capabilities make it ideal for organizations who want to drive engagement across an ecosystem of accounts – such as partners, employees, influencers, or talent.

Which Digital Asset Management tool is right for your needs?

Choosing the right DAM tool depends on your specific needs and requirements. Acquia DAM, Bynder, and MediaValet all offer powerful features and integrate well with Drupal and WordPress. When deciding, consider factors such as budget, ease of use, scalability, and feature set. Remember, a well-implemented DAM solution can streamline your asset management workflow, improve collaboration, enhance brand consistency, and ultimately empower your organization to tell its story effectively through digital content.

Default Content in Drupal

Jim Birch Director of Build Engineering

In Drupal 10.3, the DefaultContent API was added to Drupal core as part of the experimental Recipes APIs. These APIs allow Drupal to create content from files that are part of a recipe.

This content that we programmatically create isn’t intended for deploying or migrating content, we have the Workspaces and other modules for that.

Instead, it can be a great tool in our toolkit for creating demos and test content, while freeing developers and testers from the drudgery of repetitive content creation.

How did we get here?

Starting back in 2011, a group of open-source Drupal developers started working on a new install profile for Drupal called Snowman. Instead of having a generic and unopinionated starting point, the idea behind Snowman was that it wanted to provide a ready-to-use Drupal site tailored for a specific use case.

One such use case was for an install profile for a band site, during which it looked like Lee Rowlands (larowlan) came up with the idea which eventually became the Default Content module.

The Default Content contrib module

While we added a way in core to consume content config files from recipes, we are still at the start of what core can do, and mid-journey of what the contrib module aims to do.

Until the recent interest from the Recipes Initiative team, the Default Content module has always been used for creating default content configuration files for custom modules and install profiles. You could create content on a local site, export it to your module or a module in an install profile, and when that module was enabled (or a site was started from the install profile), and you installed the default content module as a dependency, you would get your content imported. This all still works exactly as it always has, and now it can also be used with recipes.

Drupal Recipes are a framework and set of tools for automating the configuration of a site. They allow developers to rapidly configure entities, fields, and other settings. A recipe can be applied to any number of different sites. This means creating multiple sites can be achieved faster and with a greater degree of consistency in how they are configured. A great deal of human error and forgetfulness can be avoided by using Recipes, particularly for repetitive config. (Check out my comprehensive guide to Drupal recipes.)

Using the Default Content module

The export process is the same for modules and recipes. Let’s review that now.

Getting set up

Install the module as you normally would. Since I am using the module for creating content for recipes, I install it in the dev section of my composer requirements as I do not need it in production.

composer require --dev drupal/default_content

And enable the module:

drush en -y default_content

The module doesn’t have a user interface. Instead, it provides drush commands that can be run to export content.

What can we export?

Out of the box, we can export the following entity types:

Content type nodes: node <node id>
Taxonomy Terms: taxonomy_term <taxonomy term id>
Files: file <file id>
Media: media <media id>
Menu Links: menu_link_content <menu link id>
Content blocks: block_content <block id>
Shortcuts: shortcut <shortcut id>

At this time, there isn’t a way to export by bundle type, think all nodes of type Article, or all menu links from the main menu, but there is a patch for it.

Let’s take a look at the three commands that the module provides to export content.

Default content drush commands

default-content-export-references

Exports an entity and all its referenced entities. This is my go to command as it helps you export referenced media, files, taxonomy terms, and users from the parent node.

Alias:

dcer

Arguments:

entity_type – The entity type to export.
entity_id – The ID of the entity to export

One of these arguments is required.

Options:

folder – The module or recipe’s content folder to export to. Entities are automatically grouped by entity type into directories.

Examples:

# Exports node 123 and all its dependencies.
# To a module:
drush dcer node 123 module_name 

# To a recipe:
drush dcer node 123 --folder=recipes/recipe_name/content

# Export all nodes and all their dependencies.
drush dcer node --folder=modules/custom/my_custom_module/content

default-content-export

Exports a single entity. If you want to manage your own dependencies.

Alias:

Arguments:

entity_type – The entity type to export.
entity_id – The ID of the entity to export

Both of these arguments are required.

Options:

file – Write out the exported content to a file instead of stdout

Examples:

# Exports node 123 only. You are responsible to export dependencies.
drush dce node 123 module_name

default-content-export-module

Exports all the content defined in a module info file. This is most helpful for distribution and install profile maintainers where they would want to maintain and update default content from a canonical source.

Alias:

dcem

Arguments:

module – The machine name of the module

The argument is required.

Options:

None

Examples:

# Exports all the content defined in a module info file.
drush dcem module_name

# The module's info file would need to have a section like this:
default_content:
  node:
	- c9a89616-7057-4971-8337-555e425ed782
	- b6d6d9fd-4f28-4918-b100-ffcfb15c9374
  file:
	- 59674274-f1f5-4d6a-be00-fecedfde6534
	- 0fab901d-36ba-4bfd-9b00-d6617ffc2f1f
  media:
	- ee63912a-6276-4081-93af-63ca66285594
	- bcb3c719-e266-45c1-8b90-8f630f86dcc7
  menu_link_content:
	- 9fbb684c-156d-49d6-b24b-755501b434e6
	- 19f38567-4051-4682-bf00-a4f19de48a01
  block_content:
	- af171e09-fcb2-4d93-a94d-77dc61aab213
	- a608987c-1b74-442b-b900-a54f40cda661

Creating a Drupal recipe with Default content

So let’s create a recipe that can store default content we can send to a test server so our QA engineer can test. We’ve created a node that has our new feature on our local environment. Rather than having to rebuild that page manually, we will export the content, and apply the recipe after it has been deployed.

Create the recipe structure

We keep our recipes in the recommended folder above the webroot.

You can manually create a recipe folder, the content folder, and a recipe.yml file or use the command line:

mkdir recipes/recipe-name
mkdir recipes/recipe-name/content
touch recipes/recipe-name/recipe.yml

In our recipe.yml file, we only need a name, description, and type.

name: 'Recipe name'
description: 'Demo content for ticket xyz'
type: 'Content'

Export your content

Using the drush commands above, usually the dcer command to export the content you need. Verify in your /content folder that you now have the entities you expect. It should look something like this:

We can now uninstall the Default Content module from our local environment.

Normally we just use recipes in our local development environments and deploy the resulting config, but when leveraging the Default Content module in your recipes, you will deploy them to your server.

Once deployed and applied on your site, you’ll probably want to remove your recipe in a subsequent pull request as you don’t need it in production.

Commit and deploy your new recipe along with your code changes as you normally would.

Applying the recipe

Once your deployment has finished, you can use Drupal core’s recipe script to apply the recipe. If you have cli access to your server, from the webroot you can run:

php core/scripts/drupal recipe ../recipes/recipe-name -v

This uses the recipe PHP script from Drupal to apply the recipe from its current location. The -v flag prints verbose information during the application process.

If you are using Drush 13 or above, they added a recipe command which is a wrapper around the core script.

drush recipe ../recipes/recipe-name -v

If you are on Pantheon, you can user Terminus to run either command:

# PHP script
terminus drush site.env -- ev "passthru('php core/scripts/drupal recipe ../recipes/recipe-name -v');"

# Drush 13+
terminus drush site.env -- recipe ../recipes/recipe-name -v

Verify the content has been created as expected and have your PMs and clients rejoice in the fact that you saved them some time having to recreate it!

What Default content isn’t made for

Default content is not meant to be a replacement for content deployment solutions. It can be a good starting point on new sites. It’s great for demo sites, and quality assurance and user acceptance testing, but there are better solutions like the Workspaces module in Drupal core that allow for you to stage content and deploy it later.

One of the biggest reasons is that we don’t know what the IDs will be on the destination site. You may have started out with the same database, but there is a good chance that the IDs have been increased on the production site by content editors adding new articles or pages.

You can also apply a recipe multiple times, or install and uninstall a module and add that default content again. There are issues in the module’s queue to address some of these situations, but work still needs to be done to improve the processes.

What’s next?

There are plenty of issues in the module’s issue queue to improve the quality and functionality of Default content, and the eleven year old Support default content entities core issue that has recently won some success thanks to the Recipes initiative.

I’d love to hear your thoughts and feedback on how you are using Default Content, or how you plan on using it! Please reach out to me in the Drupal Slack or on LinkedIn.

What You Need to Know about the Drupal 9 to 10 Upgrade

Jim Birch Director of Build Engineering

If you’re up to date on your Drupal news, you’re probably aware that Drupal 10 was released in December 2022, and Drupal 11 was launched in August 2024.

As a current Drupal 9 user, you may be strategizing your website’s transition. Drupal 9 users must first upgrade to Drupal 10.3 before they can move to Drupal 11. As Drupal explains, “All core updates added prior to 10.3.0 have been removed.”

Luckily, the Drupal 9 to 10 upgrade was heralded as the easiest upgrade in Drupal’s history. That’s because Drupal 10 is backward-compatible with Drupal 9 and does not require a major overhaul of the core system. However, the planning and development process will still require time and attention to ensure the upgrade goes smoothly.

Let’s examine the Drupal upgrade process and how your organization’s marketing team can provide support.

Fast Facts about the Drupal 9 to 10 Upgrade

Brush up on your Drupal release history with these fast facts:

Drupal 9 was released in June 2020. At the time of its release, it offered an easier upgrade than ever before, as it built on features released for Drupal 8.
Support for Drupal 9 ended in November 2023. That means there aren’t any new features or security updates being released for this version anymore.
Drupal 11 was released in August 2024. However, before they can upgrade to D11, Drupal 9 users must upgrade to Drupal 10.3.

What’s New in Drupal 11?

As mentioned, Drupal 11 is built on innovations released as part of Drupal 9. When switching to Drupal 10 and 11, you won’t be confronted with an entirely new structure and system to get used to.

That being said, Drupal 11 offers plenty of new features to look forward to, including:

The experimental Recipes API that enables simple sharing of module configurations and additions.
The Drupal core Workspace module that facilitates content staging using multiple workspaces on a single site.
Single-Directory Components for simplified front-end development.
A new Navigation module that restructures the admin toolbar using modern tools.
An Access policy API that provides more flexibility for access controls.

Steps to Upgrade From Drupal 9 to 10

If you upgraded your site from Drupal 7 to 9 in the past, you know that migration required transferring all of your data to a brand new Drupal 9 website. The Drupal 9 to 10 migration (and 10 to 11!) won’t be such a significant undertaking.

However, you can still take a few measures to set your website up for success. Follow these steps to prepare your Drupal 9 site for the migration:

Upgrade to at least Drupal 9.4.4 or later. Core updates made before 9.4 have been eliminated, so you must be on at least Drupal 9.4.4 to use the data upgrade path from CKEditor 4 to CKEditor 5.
Run Drupal Rector on custom modules and themes. Drupal Rector scans code for deprecated functions and helps developers upgrade them.
Upgrade to CKEditor 5. CKEditor 4 reached its end-of-life at the end of 2023. To stay up to date, check out Drupal’s step-by-step instructions for upgrading to CKEditor 5.
Check your PHP version. Drupal 10 requires PHP 8.1 or higher. Log into your website’s hosting account and check the settings in your control panel to verify which version of PHP you’re using.
Check your modules and themes. Not all modules and themes from Drupal 9 will be compatible with Drupal 10. If your site uses a module or theme that was removed from Drupal core, download the contributed project version before migrating to Drupal 10.
Update to Drupal 10 and test your site. Run automated code tests using tools like Drupal Rector or PHPStan. Also, conduct manual testing to ensure that everything is working as expected. Check your forms, links, page navigation, and other site elements to note any user experience issues.

If you have a web developer on your team, you can either take these steps yourself or work with an external Drupal developer.

Working with a Drupal Development Expert

Although the Drupal 9 to 10 transition is a more straightforward upgrade, it’s still typically recommended that you work with a Drupal web developer to oversee the process. This can ensure a smooth transition and help maintain data integrity and security.

Look for a Drupal web development firm that offers services such as:

Overseeing the process from start to finish
Custom module development depending on your organization’s needs
An accessibility-focused approach to ensure your website is usable for all audiences
Third-party and custom API integrations to integrate tools like your payment gateway or security portal seamlessly with your Drupal website
Mobile responsive design to create a positive mobile user experience
Search engine optimization (SEO) recommendations to maintain or enhance your website’s search results rankings
Ongoing support to implement module upgrades and security patches as needed and to help with other aspects like content strategy and performance enhancements

If you’re looking for an experienced Drupal partner, Kanopi Studios is a great choice. Our Drupal team members have an average of 11 years of Drupal experience each. We are also a supporting partner to the Drupal Association, a founding sponsor of Discover Drupal, and regular contributors to the Drupal Project.

Upgrading your website from Drupal 9 to 10 and eventually 11 shouldn’t be a hassle. With these tips, you can make the already simple process even easier.

Looking for more Drupal tips and resources? Start here:

The Ultimate Guide to Drupal Planning and Development. Kanopi’s Drupal planning and development guide offers tips for keeping your website up-to-date and effective, no matter which version you’re currently using.
The Top WordPress & Drupal Trends. Want to know the latest trends for top content management systems WordPress and Drupal? Check out this guide.
7 Statistics to Guide Your Next Website Refresh or Upgrade. Looking to refresh your website as you upgrade to a new Drupal version? Use these statistics to guide the process.

The Pros and Cons of a Headless Website

Shane Robinson Director of Solution Engineering

What is a “headless” website?

In the ever-changing world of web development, staying ahead of the curve is crucial. Traditional monolithic websites have served us well, but as the demand for more dynamic, interactive, and flexible digital experiences grows, so does the need for more advanced solutions.

A headless website separates the backend (your content management system or CMS, such as Drupal or WordPress) from the front end (the user interface), allowing developers to deliver content via APIs to any device or platform. This architectural approach provides numerous advantages but isn’t appropriate for every project. So when does a headless website make sense for your business, and why might it benefit your next web development project?

When is a headless website the right choice?

Omnichannel Delivery

A headless CMS delivers content across multiple platforms — web, mobile, IoT (Internet of Things) devices, smartwatches, and more. The headless architecture empowers you to integrate and deploy content and experiences via APIs, ensuring consistency and flexibility across various channels. With a headless site, you can create content once and distribute it everywhere, enhancing your reach and user engagement. You can also create a single, unified experience that ties your disparate platforms together — so your CMS, e-commerce platform, membership program, and any other tool you can think of can be integrated into a seamless experience for your users.

Technical Flexibility

Headless websites offer unparalleled flexibility for projects requiring high customization and a unique user interface. Since the site decouples the front and back end, developers can build the user interface using any technology or framework (React, Vue.js, Angular, etc.). This freedom enables bespoke, highly interactive, and performance-optimized websites tailored to your business needs.

Improved Performance and Scalability

Headless websites can significantly improve performance and scalability. Decoupling the front and back ends allows you to optimize each layer independently. This separation allows for faster load times and a more responsive user experience. Additionally, it’s easier to scale different parts of the architecture according to demand, ensuring your website can handle traffic spikes without compromising performance.

Enhanced Security

Security is a paramount concern for any website. Headless architectures can enhance security by reducing the attack surface. Since the front and back end are separated, attackers find it harder to exploit vulnerabilities. Furthermore, APIs can be secured independently, and sensitive data can be better protected, giving you peace of mind.

Content Personalization and A/B Testing

Personalizing content for different user segments and conducting A/B testing are essential strategies for improving user engagement and conversion rates. A headless CMS makes these tasks straightforward and more efficient. By leveraging APIs, you can dynamically deliver personalized content and easily integrate A/B testing tools to optimize user experience in real-time.

Future-Proofing Your Digital Strategy

As technology continues to evolve, having a future-proof digital strategy is crucial. A headless architecture ensures your website can adapt to emerging technologies and platforms without requiring a complete overhaul. This adaptability allows your business to stay competitive and quickly respond to market changes and technological advancements.

Streamlined Workflow for Development Teams

Headless websites foster a more streamlined workflow for development teams. Frontend and backend developers can work simultaneously without dependencies, accelerating the development process. This parallel workflow reduces bottlenecks and enhances collaboration, leading to faster project completion and more efficiency.

When might a headless website not be the right choice?

While headless websites offer numerous benefits, they might only suit some projects. Here are a few scenarios where a traditional monolithic approach might be more appropriate:

Ease of Familiarity

WordPress or Drupal are well known to users and are known for their ease of use and user-friendliness. This familiarity makes it simple for non-technical users to update the site’s configuration.

Although a headless site can have content driven by WordPress or Drupal, technical knowledge is paramount when adding and updating configuration. A developer will usually be required.

Plugin/Module Ecosystem

WordPress and Drupal boast an almost endless ecosystem of plugins/modules that can extend the functionality and features of your website, from SEO to commerce, forums, and beyond.

A headless site can have its own suite of plugins, and if driven by WordPress and Drupal, some plugins/modules will play nicely with the headless front end. However, your pool of choice is drastically reduced.

Content delivery

Even if you do need to share content from your CMS with your mobile applications and other systems, you can still do so using Drupal or WordPress in a traditional CMS build. These platforms provide robust and customizable APIs that other applications can leverage, whether the main content site is headless or not.

This allows you to allow your CMS to do what it does best, manage content while serving the content you choose to the applications that need it.

Theming and Design

WordPress and Drupal both offer many free themes for almost every industry. Vendors in this space can build you a custom theme that is nearly endlessly flexible — and flexible to the content editor. This allows editors to create unique landing pages on the fly and move components around as they see fit without the need to bring in a developer.

Although a headless CMS has complete freedom when it comes to design, the design still needs to be implemented on the front end. This takes a lot of time and budget. Once built, that end product can actually be a bit rigid, requiring you to get a developer every time you want to create a different type of landing page or move a component above or below the fold.

Cost and Technical Debt

WordPress and Drupal will have a lower initial cost to build and maintain, even with maintenance, to ensure that all security updates are released in a timely manner. The pool of skilled developers and agencies is vast, and hosting partners offer automated updates, allowing you to find a maintenance package that fits your budget.

A headless CMS will require a significant investment to build initially and may cost more to maintain than a traditional CMS build. You are now maintaining two systems: your back end and your front end. Developers familiar with this architecture are highly specialized, and development may take longer or require more expensive and less widely available development resources. Depending on your hosting partner and final architecture, managing two hosting environments may also be a challenge: one for your front end and one for your back end.

Real-time Preview

WordPress and Drupal provide real-time feedback while managing content. They allow you to preview content before publishing it to the public. The instant visual feedback in the editor allows you to better illustrate your message by knowing how it will display on the front end.

While real-time preview in headless environments is becoming better and more prevalent, it can require a separate build process, which may slow down content creation.

Edit in Place

In a CMS such as WordPress and Drupal, editing in place (inline editing) has become common practice. It is supported by core WordPress or Drupal or by plugins and modules that add or expand it. Editing in place gives the content creator the ability to modify content directly on a webpage without having to navigate to a separate editing interface, much like you would in Google Docs or MS Word.

Editing in place on a headless website is possible, but may be more complex. Using plugins to bring inline editing into your site requires up-front investment and development efforts. One of the main differences here is that plugins on a headless site are not plug-and-play and often require development efforts to ensure that they work correctly without issues across the entire breadth of your site’s content.

Page Caching

WordPress, Drupal, and the respective hosting partners that specialize in managed hosting handle page caching extremely well. Whether you publish a new page or update an existing one, the CMS knows the ID of the page being created/updated and clears only that page’s cache on the front end immediately. When this does not happen, it is usually due to aggressive caching practices that a vendor can help you tailor to your needs.

Rebuilding a page’s cache in a headless CMS can be cumbersome and require revalidating large sections of your site at once — sometimes even the entire site. It can result in a large performance hit just to publish a simple content update. Maximizing performance with aggressive caching on the front end can prevent content from going live until the next time the site cache is cleared or the API data refreshes.

SEO

WordPress and Drupal have a vast number of SEO features built-in and provided by contributed plugins/modules. Allowing content editors and administrators to tailor their SEO on the fly without the need for developer intervention.

A headless CMS requires heavy manual effort up front to configure and set up the site’s SEO. Any changes to the SEO strategy will require a developer to work with the site’s code.

Support & Community

Both WordPress and Drupal have the support of a well-established, massive, and ever-growing community of developers and advocates. This makes it easy to find resources, well-trained and knowledgeable developers, and efficient issue troubleshooting.

Headless websites require specialized skills and expertise. While the headless community is growing, there are a vast number of implementation methods out there, making the community specialized and fragmented. This makes it harder to troubleshoot issues, find skilled developers, and maintain the site long-term. Implementing and maintaining a headless architecture might be challenging for your team if they need to gain experience with modern front-end frameworks or API management.

Simple Websites with Limited Interactivity

A headless architecture might be overkill if your website is straightforward with minimal interactivity. Traditional CMS platforms like WordPress can efficiently handle such requirements.

What if I have an existing CMS?

If you have an existing WordPress or Drupal CMS, then there is good news. Both of these popular platforms have evolved to support a headless CMS architecture. The content management capabilities that you are used to are separated from the presentation layer or front end and used solely for storing and managing content.

The front end can be built with the technology we previously mentioned, including React. This approach provides a backend that is familiar to your organization while allowing for the flexibility of a headless front end.

Although a headless approach makes tasks like personalization and A/B Testing more flexible and achievable, they are possible within your existing CMS. Third-party tools and plugins like Lytics and Optimizely can be used to provide these services.

The choice is yours.

Headless websites offer flexibility, performance, and scalability that traditional monolithic architectures cannot match. Some projects demand omnichannel delivery, customized user interfaces, improved performance, enhanced security, content personalization, future-proofing, and streamlined development workflows. In that case, a headless website might be the right choice for you.

Evaluating your specific project requirements, budget, and available resources is essential before deciding on your site architecture. By carefully considering these factors, you can determine whether a headless website is the right fit and ensure the success of your digital strategy.

Whether you choose a headless or traditional approach, the key is to deliver exceptional user experiences that meet your business goals and keep your audience engaged.

Do you have Drupal Burn?

Shane Robinson Director of Solution Engineering

Is this you?

You’re always on edge. You can’t relax. You can’t sleep. You’re thinking about it constantly. At the neighbor’s BBQ. At your daughter’s recital. Even yoga class provides no respite. It’s not giving you a moment’s peace.

Of course, I’m talking about your website.

Hey, we’ve seen it a thousand times before here at Kanopi. You have a website that was built in the Drupal content management system (CMS), and now it’s making your life a living hell. Content updates — even ones that should be simple and routine — are an excruciating, soul-crushing ordeal.

There’s a name for this condition: Drupal Burn. And if it’s happening to you, it may comfort you to know you’re not alone.

We’ve seen it happen, with Drupal 7 clients and onward. Even clients on modern Drupal, like Drupal 10 or 11, aren’t always immune. In fact, we’ve seen cases so severe in some clients that they’re practically begging us to scrap it all and rebuild in a different CMS — even if they just built a modern Drupal site in recent years.

Degrees of Drupal Burn

At Kanopi, we diagnose Drupal Burn according to 1st, 2nd and 3rd degrees:

1st Degree Drupal Burn

Updating your site is a constant struggle.
Edits take way longer than they should.
Each update to a section of the site requires multiple humans to sort out.
Your site search constantly brings back incorrect, irrelevant information.
Your current or previous vendor is holding you hostage; i.e. not providing you with administrative access to the site, the code, and the database.

2nd Degree Drupal Burn

All 1st degree symptoms, plus:

You don’t like the design.
The site isn’t converting.
You need to find workarounds everytime you edit the site.
You don’t have access to the site, or are unsure where it is hosted, or registered, or if it’s even being maintained.

3rd Degree Drupal Burn

All 1st and 2nd degree symptoms, plus:

Your site is constantly down due to performance and security issues.
Your performance scores are so low they are in the sub-basement.
You can’t edit the site without it crashing.
You’re in constant triage and reactive mode.
You’ve been abandoned by your previous vendor.

At this point you hate Drupal with the passion of a thousand suns, and are ready to give up on it altogether. Alas, do not despair, Drupal Burn victims. Despite how things may seem, it is a highly curable condition.

How to cure Drupal Burn

Quite often, the cure for Drupal Burn is much simpler than a complete rebuild. Believe it or not, all it takes is some training, along with reworking parts of your site to address pain points.

In fact, we’ve developed a specific treatment for each stage of Drupal Burn.

Treating 1st Degree Drupal Burn

Training

Like many things in life, editing-related headaches large and small are often a matter of proper training. We’ll work with you to identify editing issues and provide thorough, efficient, relevant training.

Each training session is recorded and provided to you for future reference. We can also provide written training documentation upon request.

Full site access

It’s a frustrating feeling when you lack proper access to your site and its various assets, especially since it all belongs to you. We’ll ensure that you can always access your site’s properties, including:

You administrative account
Hosting
Domain registration
Analytics
Code
Database
Plus all third-party integrations.

Treating 2nd Degree Drupal Burn

These types of Drupal Burn can typically be treated by implementing strategic enhancements with ongoing support hours. This allows us to work with you to target priority issues causing Drupal Burn. Prioritizing these items is a collaborative effort that involves ranking issues according to importance, impact, and effort level. In doing so, we can customize an editing experience that works best for you and your team.

Treating 3rd Degree Drupal Burn

These, of course, are the most severe types of Drupal Burn; however, even these are treatable.

In addition to technical work, we find that our Drupal Burn patients also require emotional support — helping you navigate, sort, and file the negative experience of a content management system that didn’t allow you to manage content.

Along with combining 1st and 2nd degree treatments, treating 3rd degree Drupal Burn also requires:

Pinpointing troublesome code, and replacing it with modules or efficient, secure code.
Installing and testing upgrades and updates.
Locating and resolving content editing issues
Create an editing flow that works for you and your team.
Analyzing your hosting environment,
Making recommendations to improve performance and security.

Just don’t burn your Drupal site

We know Drupal Burn hurts. It’s frustrating. It wastes your time, and it can make you feel like you’ve wasted a lot of money. Hang in there and don’t give up. Reach out for help. We’ve provided numerous clients with a permanent cure for their Drupal burn, including:

1st degree case: Eye Recommend
2nd degree case: TWIT
3rd degree case: UCSF School of Nursing (they had 4 rebuilds in 3 years!)

We’re here for you, too.

After all, your website has klout. It has SEO juice. It was a big investment, and is of course an ongoing investment. And remediating a modern Drupal site (Drupal 8+) is a far lower level of effort and investment than rebuilding your site from scratch.

When properly configured and supported, your modern Drupal site can run cost-effectively and produce results for 10 years or more. We’re here to help you make it happen. Think of Kanop i as the prescription for your Drupal Burn.