Data plays a pivotal role in shaping customer interactions, so implementing a CDP can empower businesses to unify and analyze customer data from various sources. This can lead to more personalized and effective marketing strategies, improved customer segmentation, and enhanced digital experiences.

However, diving into CDP implementation without proper assessment can lead to challenges such as underutilization of the platform, data management issues, and inadequate return on investment. To avoid these challenges, organizations must comprehensively evaluate their readiness across various dimensions before embarking on a CDP implementation journey.

Evaluating Readiness For CDP Implementation

Before implementing a Customer Data Platform (CDP), organizations must establish several prerequisites to ensure a successful integration and utilization of the platform.

• Ensure a clear data strategy, outlining objectives, sources, and governance frameworks aligned with broader business goals.
• Ensure good data quality through cleansing and validation for accurate insights and decision-making.
• Assess and enhance the technology infrastructure required to support a CDP integration.
• Foster cross-functional collaboration, secure stakeholder buy-in, allocate resources, and develop a comprehensive change management plan.

Once these prerequisites are in place, the next step is to conduct a thorough evaluation across different dimensions.

Do You Need A CDP

Assess your organization across the following dimensions to evaluate the need for a CDP.

1. Data Maturity & Infrastructure

Assess your organization's data management capabilities and infrastructure readiness for CDP integration.

• Current Data Sources

Identify existing data sources and evaluate their formats, accessibility, and captured data.

• Integration Capability

Assess the ability to integrate data sources with a CDP, considering API availability and compatibility.

• Data Quality & Consistency

Ensure data accuracy, reliability, and adherence to governance and compliance standards.

Organizations with scattered data across various platforms and systems who wish to enable better decision-making should consider implementing a CDP. On the other hand, organizations with limited data sources do not need a CDP and should consider a different solution depending on their goal.

2. Organizational Readiness

Evaluate your organization's readiness beyond technology.

• Stakeholder Alignment

Ensure key stakeholders understand and support the CDP initiative.

• Skillset Availability

Assess if your team has the necessary skills for CDP implementation or if training/new hires are needed.

• Technology Stack Compatibility

Evaluate compatibility with existing technology and potential upgrades.

Organizations where multiple stakeholders across departments need access to unified customer data for decision-making should consider opting for a CDP. On the other hand, organizations with a unified vision for utilizing existing data sources and access to the right technology infrastructure for supporting data integration can do without a CDP.

3. Future Scalability

Consider the scalability of your CDP implementation.

• Scalability Assessment

Evaluate scalability to accommodate future business growth.

• Flexible Architecture

Ensure the CDP architecture can adapt to evolving data sources and business needs.

Implementing a CDP is a great idea for organizations anticipating significant customer data volume and complexity growth. It is also ideal for organizations anticipating the adoption of new technology and data sources in the future.

Businesses anticipating minimal growth in customer data volume and with a stable industry can look into other avenues for building better customer experiences.

4. Change Management

Address organizational changes associated with CDP implementation.

• Culture Of Data-Driven Decision Making

Foster an environment where decisions are based on data insights.

• Process Integration

Ensure seamless integration with existing processes to make data insights actionable.

• Change Management Strategies

Implement strategies to manage organizational transitions smoothly.

Organizations transitioning to a data-driven culture with the necessary stakeholder approvals, training, and support are usually in a great position to implement a CDP. Organizations with this culture or those not looking to change their current processes and systems should refrain from implementing a CDP.

5. Resource Availability

Ensure the availability of resources for successful CDP implementation.

• Technical Expertise

Assess the need for skilled data management, integration, and analysis personnel.

• Infrastructure

Ensure adequate technological infrastructure to support CDP requirements.

Allocate the budget for initial implementation, maintenance, and updates.

Implementing and managing a CDP requires specialized skills and expertise. Organizations with this expertise or are willing to invest in it should consider implementing a CDP.

6. Data Democratization

Promote accessibility and understanding of data across the organization.

• User-Friendly Tools

Implement tools for easy data access and interpretation.

• Data Governance

Establish clear policies on data access, usage, and security.

• Training & Literacy

Provide training to improve data literacy across the organization.

Organizations looking to unify customer data for decision-making should consider implementing a CDP.

7. Technology Compatibility & Integration

Ensure seamless integration with existing technology platforms.

• Existing Tech Stack Assessment

Evaluate compatibility with current systems.

• API & Data Exchange Capabilities

Ensure seamless data exchange with other systems.

Organizations looking to change their existing technology platforms that operate in silos and hinder data exchange and integration should consider opting for a CDP. Businesses with existing technology platforms that operate cohesively allow seamless data exchange and integration without needing a specialized platform like a CDP.

8. Use Case Definition & Business Goals

Align CDP implementation with business objectives.

• Clear Use Cases

Identify specific use cases for the CDP.

• Alignment with Business Objectives

Ensure CDP directly contributes to achieving key business goals.

Implementing a CDP is a good idea when businesses require advanced data analysis capabilities, such as personalized marketing or real-time analytics, that cannot be achieved using existing tools. It can also help segment customers based on specific criteria and personalize marketing strategies.

9. Compliance & Data Governance

Ensure compliance with data privacy regulations and robust governance.

• Data Privacy & Security

Confirm compliance with data protection regulations.

• Audit & Reporting Requirements

Support necessary audit trails and reporting for compliance.

Organizations operating in highly regulated industries or globally must comply with necessary data governance and compliance regulations such as GDPR and CCPA.

10. Budget & ROI Consideration

Evaluate the financial aspects of CDP implementation.

• Cost-Benefit Analysis

Understand the total cost of ownership and expected ROI.

• Long-Term Financial Commitment

Consider long-term maintenance and scaling costs.

Implementing a CDP is beneficial when the potential benefits, such as improved customer engagement, increased sales, and enhanced marketing effectiveness, outweigh the initial investment and ongoing costs.

11. Vendor Evaluation

Select a suitable CDP vendor.

• Market Research

Conduct thorough research on potential CDP vendors.

• Proof Of Concept

Consider running a pilot program to test effectiveness.

Customer support and assistance are crucial for successful CDP implementation and ongoing maintenance. Ensure a thorough vendor evaluation when choosing a reputable and reliable CDP vendor.

12. Scalability & Future-Proofing

Ensure CDP scalability and adaptability.

• Scalability Assessment

Ensure CDP can scale with business growth.

• Adaptability To Future Trends

Ensure CDP can adapt to future data trends and technological advancements.

A scalable CDP solution is necessary when businesses anticipate significant data volume and complexity growth. A CDP can help adapt to future data trends and technological advancements.

Submit The Form To Get Personalized CDP Recommendations

Assessing readiness across these areas ensures successful CDP implementation and effective utilization in driving business growth and enhancing customer experiences. You can also submit this form to determine if you need a CDP or speak to our experts about your business requirements and goals.

We have made a recent update on drupal.org that you haven’t probably noticed. In fact, although it's a meaningful and important section, I bet you have not seen it in months or even years. It's something you would have only seen when you registered on Drupal.org for the first time. I’m talking about the welcome email for new registered users.

One of the goals we have had recently is improving the way our users register and interact with drupal.org for the first time. Improvements to onboarding should improve what I call the long tail of the (Open Source) contribution pipeline (a concept, the long tail of contribution, that I will explain further in the next few days).

For now, let’s have a look at one of the first things new users in our community saw first:

This is what I called the huge wall of text. Do you remember seeing it for the first time? Did you read any of it at all? Do you remember anything important in that email? Or did you just mark it read and move on?

Fortunately, we've taken a first, incremental step to make improvements. As I said before, this isn't something our existing userbase will see, but the new welcome email to Drupal.org has changed and been simplified quite a bit. Here is the new welcome email:

We have replaced a lot of the wall of text with a simpler set of sections and links, and landing pages on drupal.org. This simplifies the welcome email, but is also going to allow us to track which links are most useful to new users, how many pages they visit on drupal.org, where do they get stuck, what interests them most, etc - and use that to make further refinements over time.

The other section I wanted to include is something that is very important for the Drupal Association, but also for the whole community. I wanted to highlight the contribution area, something that was not even mentioned in the old email. Our hope is this is an opportunity to foster and promote contribution from new users.

A few weeks ago I also launched a poll around contribution. This poll combined with the updates on these few changes in the user registration are aimed towards the same goal: improving contribution onboarding. You can still participate if you’d like to, just visit https://www.surveymonkey.com/r/XRTNNM3

Now, if you are curious about what I am calling the long tail of the contribution pipeline, watch this space.

Routes in Drupal can be altered as they are created, or even changed on the fly as the page request is being processed.

In addition to a routing system, Drupal has a path alias system where internal routes like "/node/123" can be given SEO friendly paths like "/about-us". When the user visits the site at "/about-us" the path will be internally re-written to allow Drupal to serve the correct page. Modules like Pathauto will automatically generate the SEO friendly paths using information from the item of content; without the user having to remember to enter it themselves.

This mechanism is made possible thanks to an internal Drupal service called "path processing". When Drupal receives a request it will pass the path through one or more path processors to allow them to change it to another path (which might be an internal route). The process is reversed when generating a link to the page, which allows the path processors to reverse the process.

It is possible to alter a route in Drupal using a route subscriber, but using path processors allows us to change or mask the route or path of a page in a Drupal site without actually changing the internal route itself.

In this article we will look what types path processors are available, how to create your own, what sort of uses they have in a Drupal site, and anything else you should look out for when creating path processors.

Types Of Path Processor

Path processors are managed by the Drupal class \Drupal\Core\PathProcessor\PathProcessorManager. When you add your a path processor to a site this is the class that manages the processor order and calling the processors.

There are two types of path processor available in Drupal:

• Inbound - Processes an inbound path and allows it to be altered in some way before being processed by Drupal. This usually occurs when a user sends a request to the Drupal site to visit a page. Inbound path processors can also be triggered by certain internal processes, for example, when using a path validator. The path validator will pass the path to the inbound path processor in order to change it to ensure that it has been processed correctly.
• Outbound - An outbound path is any path that Drupal generates a URL. The outbound path processor will be called in order to change the path so that the URL can be generated correct.

Basically, the inbound processor is used when responding to a path, the outbound processor is called when rendering a path.

Let's go through a couple of examples of each to show how they work.

Creating An Inbound Processor

To register an inbound service with Drupal you need to create a service with a tag of path_processor_inbound, and can optionally include a priority. This let's Drupal know that this service must be used when processing inbound paths.

It is normal for path processor classes to be kept in the "PathProcessor" directory in your custom module's "src" directory.

services:
  mymodule.path_processor_inbound:
    class: Drupal\mymodule\PathProcessor\InboundPathProcessor
    tags:
      - { name: path_processor_inbound, priority: 20 }

The priority you assign to the path_processor_inbound tag will depend on your setup. The internal inbound processor that handles paths in Drupal has a priority of 100, so any setting less than 100 will cause the processing to be performed before Drupal's internal handler is called.

The InboundPathProcessor class we create must implement the \Drupal\Core\PathProcessor\InboundPathProcessorInterface interface, which requires a single method called processInbound() to be added to the class. Here are the arguments for that method.

• $path - This is a string for the path that is being processed, with a leading slash.
• $request - In addition to the path, the request object is also passed to the method. This allows us to perform any additional checks on query strings on the URL or other parameters that may have been added to the request.

The processInbound() method must return the processed path as a string (with the leading slash). If we don't want to alter the path then we need to return the path that was passed to the method.

To create a simple example let's make sure that when a user visits the path at "/some-random-path" that we translate this internally to be "/node/1", which is not the internal route for this page. In this example, if the path passed into the method isn't our required path then we just return it, effectively ignoring any path but the one we are looking for.

Now, when the user visits the path "/some-random-path" they will see the output of the page at "/node/1". It is still possible to view the page at "/node/1/" and see the output, so we have just created a duplicate path for the same page.

This is a simple example to show how the processInbound() method works, we'll look at a more concrete example later.

Creating An Outbound Processor

The outbound processor is defined in a similar way to the inbound processor, but in this case we tag the service with the tag path_processor_outbound.

services:
  mymodule.path_processor_outbound:
    class: Drupal\mymodule\PathProcessor\OutboundPathProcessor
    tags:
      - { name: path_processor_outbound, priority: 250 }

The priory of the path_processor_outbound is more or less the opposite of the inbound processor in that you'll generally want your outbound processing to happen later in the callstack. The internal Drupal mechanisms for outbound processor is set at 200, so setting our priory to 250 means that we process our outbound links after Drupal has created any aliases.

The OutboundPathProcessor class we create must implement the \Drupal\Core\PathProcessor\OutboundPathProcessorInterface interface, which requires a single method called processOutbound() to be added to the class. Here are the arguments for that method.

• $path - This is a string for the path that is being processed, with a leading slash.
• $options - An associative array of additional options, which includes things like "query", "fragment", "absolute", and "language". These are the same options that get sent to the URL class when generating URLs and allow us to update the outbound path based on the passed options.
• $request - The current request object is also sent to the method and can make decisions based on the parameters passed to the current path.
• $bubbleable_metadata - An optional object to collect path processors' bubbleable metadata so that we can potentially pass cache information upstream.

The processOutbound() method must return the new path, with a starting slash. If we don't want to change the path then we just return the path that was sent to us, otherwise we can make any change we require and return this string.

Taking a simple example in the inbound processor further, let's change the path "/node/1" to be "/some-random-path". In this example we are looking for the internal path of "/node/1", and if we see this path then we return our new path.

With this in place, when Drupal prints out a link to "/node/1" it will render the path as "/some-random-path".

On its own this example doesn't do much; we are just rewriting a path for a single page. The real power is when we combine inbound processing and outbound processing together. Let's do just that.

Creating A Single Class For Path Processing

It is possible to combine the inbound and outbound processors together into a single class by combining the tags in a single service. This can be done by combining the path processors together in the module's services file.

services:
  mymodule.path_processor:
    class: Drupal\mymodule\PathProcessor\MyModulePathProcessor
    tags:
      - { name: path_processor_inbound, priority: 20 }
      - { name: path_processor_outbound, priority: 250 }

The class we create from this definition implements both the InboundPathProcessorInterface and the OutboundPathProcessorInterface, and as such it includes both of the processInbound() and processOutbound() methods.

Now all you need to do is add in your path processing.

It's a good idea to create a construct like this so that you translate the path going into and coming out of Drupal. This creates a consistent path model and prevents duplicate content issues where different pages have the same path.

The Redirect Module

If you are planning to use the inbound path processor system then you should be aware that the Redirect module will attempt to redirect your inbound path processor changes to the rewritten paths. The Redirect module is a great module, and I install it on every Drupal site I run, but in order to prevent this redirect you'll need to do something extra, which we'll go through in this section.

To prevent the Redirect module from redirecting a path you need to add the attribute _disable_route_normalizer to the route before the kernel.request event triggers in the Redirect module's RouteNormalizerRequestSubscriber class. We do this by creating our own event subscriber and giving it a higher priority.

The first thing to do is add our event subscriber to our custom module services.yml file.

  mymodule.prevent_redirect_subscriber:
    class: Drupal\mymodule\EventSubscriber\PreventRedirectSubscriber
    tags:
      - { name: event_subscriber }

The event subscriber itself just needs to listen to the kernel.request event, which is stored in the KernelEvents::REQUEST constant. We need to trigger our custom module before the redirect module event, and so we set the priority of the event to be 40. This is higher than the Redirect module event, which is set at 30.

All the event subscriber needs to do is listen for our path and then set the _disable_route_normalizer attribute to the route if it is detected.

getRequest()->getPathInfo() === '/en/some-random-path') {
      $event->getRequest()->attributes->set('_disable_route_normalizer', true);
    }
  }

}

When the Redirect module event triggers it will see this attribute and ignore the redirect.

This will only happen if you are changing the path of an entity of some kind using only the inbound path processor. Creating only the inbound processor creates an imbalance between the outer path and the translated inner path, which we then need to let the Redirect module know about to prevent the redirect. If we also translated the outbound path in the same (and opposite) way then the redirect wouldn't occur.

Doing Something Useful

We've looked at swapping paths and preventing redirects, but let's do something useful with this system.

I was recently tasked with creating a module that would allow any page to be rendered as RSS. It wasn't that we needed a RSS feed, but that each individual page should have an RSS version available.

This was required as there was an integration with an external system that was used to pull information out of a Drupal site for newsletters. Having RSS versions of pages made it much easier for the system to parse the content of the page and so produce the newsletter. This also meant that if the theme changed the system wouldn't be effected as it wouldn't be using the theme of the site.

Essentially, the requirement meant that we needed to add "/rss" after any page on the site and it would render the page accordingly.

The resulting module was dubbed "Node RSS" and made extensive use of path processors to produce the result.

The first step was to create a controller that would react to path like "/node/123/rss" to render the page as an RSS feed. This required a simple route being set up to allow Drupal to listen to that path and also to inject the current node object into the controller. The route also contains a simple permission, which provided a convenient way of activating the system when it was ready.

node_rss.view:
  path: '/node/{node}/rss'
  defaults:
    _title: 'RSS'
    _controller: '\Drupal\node_rss\Controller\NodeRssController::rssView'
  requirements:
    _permission: 'node.view all rss feeds'
    node: \d+
  options:
    parameters:
      node:
        type: entity:node

The rssView action of the NodeRssController just needs to render the node and return it as part of an RSS document. Using this we can now go to a node page at "/node/123/rss" and see an RSS version of the page.

I won't go into detail about producing the RSS version of the page here as it contains a lot of boilerplate code that goes beyond the scope of this article.

So far we only have half the functionality required. Seeing an RSS version of the page via the node ID is fine, but what we really want is to visit the full path of the page with "/rss" appended to the end.

The next step is to setup our path processor so that we can change the paths on the fly. In addition to the tags we are also passing in two other services for us to use in the class. These services are the path_alias.manager service for translating paths and the language_manager to ensure that we get the path with the correct language.

services:
  node_rss.path_processor:
    class: Drupal\node_rss\PathProcessor\NodeRssPathProcessor
    arguments:
      - '@path_alias.manager'
      - '@language_manager'
    tags:
      - { name: path_processor_inbound, priority: 20 }
      - { name: path_processor_outbound, priority: 220 }

The processInbound() method looks for the "/rss" string at the end of the passed path. If this is found then we remove that from the path and try to find the internal path of the page in the site. If we do find the path then it will be returned as "/node/123" instead of the full path alias and this means we can just append "/rss" to the end of the path to point the path at our NodeRssController::rssView action.

  public function processInbound($path, Request $request): string {
    if (preg_match('/\/rss$/', $path) === 0) {
      // String is not an RSS feed string.
      return $path;
    }

    $nonRssPath = str_replace('/rss', '', $path);
    $internalPath = $this->pathAliasManager->getPathByAlias($nonRssPath, $this->languageManager->getCurrentLanguage()->getId());

    if ($internalPath === $nonRssPath && preg_match('/^node\//', $internalPath) === 0) {
      // No matching path was found, or, it wasn't a node path that we have.
      return $path;
    }

    return $internalPath . '/rss';
  }

The opposite process needs to happen for the processOutbound() method. In this case we look for a path that looks like "/node/123/rss" and convert this back into the full path alias of the page. If we find an alias for that path then we append "/rss" to the path and return it.

  public function processOutbound($path, &$options = [], Request $request = NULL, BubbleableMetadata $bubbleable_metadata = NULL): string {
    if (preg_match('/^\/node\/.*?\/rss?$/', $path) === 0) {
      // String is not an RSS feed string.
      return $path;
    }

    $nonRssPath = str_replace('/rss', '', $path);
    $alias = $this->pathAliasManager->getAliasByPath($nonRssPath, $this->languageManager->getCurrentLanguage()->getId());

    if ($nonRssPath === $alias) {
      // An internal alias was not found.
      return $path;
    }

    return $alias . '/rss';
  }

We now have an RSS feed for any content path on the website (as long as it is a node page of some kind).

If we attempted to visit the RSS output of any other kind of page (like a taxonomy term) then we would receive a 404 error. This is possible thanks to the route we have in place as the parameter will only accept node paths.

As we have translated the path completely we do not need the Redirect module overrides here since there is a coherent input/output mechanism for these paths. It's only when there is an imbalance in the paths that we need to override the Redirect module to prevent redirects.

Don't worry if you are looking for the full source code for the above module as I have recently released the Node RSS module on Drupal.org. It only has a dev release for the time being as I would like to add the ability to pick what content types are available for the feeds. I'm also testing it with different setups to make sure that the feed works in different situations. Let me know if it is useful for you and please create a ticket if you have any issues.

If you want to see another module that makes use of this technique then there is the Dynamic Path Rewrites module. This allows the rewriting of any content path on the fly without creating path aliases. This is an alternative to using modules like Path Auto without actually creating path aliases within your system and uses a nice caching system to speed up the responses.

Conclusion

The path processing system in Drupal is really quite powerful and can be used to build some interesting features that rewrite paths on the fly. We can take any incoming request and redirect it to any path we like on the fly.

Without this system in place we would need to generate additional aliases for every path we wanted and add them to the database before we would be able to use the system. That is fine on smaller sites, but I manage sites with millions of nodes and that amount of data would bloat the database and probably not be used all that much.

Path processing does have some interactions with other modules (like Redirect) but these problems are easily overcome. Perhaps the most complex part of this is ensuring that you have the right weights to some of the interactions here as getting things wrong will likely lead to unwanted interactions.

The Splash Awards are not only a recognition of hard work and outstanding dedication, but also a chance to network with industry peers, talk about the latest trends in web development and design, and celebrate the best solutions.

And the winner is…

The 2023 Splash Awards will be presented on November 10 in Mannheim, Germany. As every year, we look forward to presenting our work and hope to continue our success story this year. We congratulate all nominees and look forward to exchanging ideas with other experts in the Drupal community.

See all nominated projects

We contributed the module Search API Decoupled to allow the creation of engaging search experiences with client-side Javascript applications. 

In comparison to traditional server side search, client side solutions are much faster, because fetching and rendering search results is much more efficient then requesting full pages. 

We released the backend functionality of Search API Decouple in Drupal Dev Days 2023 in Vienna, the slides and video are available online.

However, Drupal needs a fully working search client so that developers and marketers can easily evaluate the functionality for their projects. 

Such a client should provide great search functionality out-of-the-box and should be easy to extend and style.

We applied for funding at the Drupal Innovation Contest Pitchburgh but we did not get it. 

But we decided to build and contribute the functionality anyway.

Jill Farley, Ken Rickard, and Byron Duvall discuss their experiences with the Cypress front-end testing framework.

We want to make your project a success.

Podcast Links

Transcript

George DeMet:
Hello and welcome to Plus Plus, the podcast from Palantir.net where we discuss what’s new and interesting in the world of open source technologies and agile methodologies. I’m your host, George DeMet.

Today, we’d like to bring you a conversation between Jill Farley, Ken Rickard, and Byron Duvall about the Cypress front end testing framework. Cypress is a tool that web developers use to catch potential bugs during the development process. It’s one of the ways we can ensure that we’re building quality products that meet our client’s needs and requirements. 

So, even if you aren’t immersed in the world of automated testing, this conversation is well worth a listen. Without further ado, take it away, Jill, Ken, and Byron.

Jill Farley:

Hi, I'm Jill Farley from Palantir.net. I'm a senior web strategist and UX architect. Today, I'll be discussing Cypress testing with two of my colleagues. I'll let them introduce themselves, and then we can have a relaxed conversation about it.

Ken Rickard:

I'm Ken Rickard. I'm senior director of consulting here at Palantir.net.

Byron Duvall:

And I am Byron Duval. I'm a technical architect and senior engineer at Palantir.net.

Jill Farley:

Well, thanks for sitting down and talking with me today, you guys. We are going to maybe just start this off for anybody who doesn't know what Cypress automated testing is with a quick, maybe less technical overview of it. So, Ken, what are Cypress tests in 60 seconds?

Ken Rickard:

In 60 seconds, Cypress is a testing framework that is used to monitor the behavior of a website or app in real time within the browser, so it will let you set up test scenarios and record them and replay them so that you can guarantee that your application is doing what. You expect it to do when a user clicks on the big red button.

Jill Farley:

I did not time you, but that was brief enough. To give a little context for why we're talking about this today, our technical team, led by Ken, just recently developed a virtual event platform for one of our clients. Actually, it was developed a couple of years ago.

We've been iterating on it for a few years and it's unique in that it debuts for a few intense weeks each year. It's only live for a couple of weeks and specifically hosts this virtual event for four days, and then goes offline for the rest of the year. So, we have to get it right and we specifically have to get it right for the tens of thousands of visitors over the course of that four-day event that are coming.

So, this year we really went all in on Cypress testing to really ensure the success of the event.

So, Ken, I've heard you say we have 90% test coverage on this particular platform right now after the work that we've done. What does that mean? What does 90% test coverage mean?

Ken Rickard:

"It means we can sleep at night," I think, is what I mean when I say that. It’s simply that roughly 90% of the things that an individual user might try to do on the website are covered by tests. So, I joke a little bit about what happens when you press the big red button.

I mean, we have big orange buttons on the website, and the question becomes, "What happens when you press that button? Does it do the thing you expect it to do?" Also, the content and behavior of that button might change depending on whether or not we're pre-conference, we're during the conference, or we're during a specific session in the conference, and that changes again post-conference.

So, we have all of these conditions that change the way we expect the application to behave for our audience. I'll give you a simple example. During a session, the link of the session title, when you find it in a list, doesn't take you to the session page. It takes you to the video channel that's showing that session at that time. That is true for most sessions for a 30-minute window during the entire conference.

Our testing coverage is able to simulate that so we know, "Yep, during that 30-minute window, this link is going to go to the right place." So when we talk about that sort of 90% coverage, it means, from an engineering standpoint, well, even from a product management standpoint, you can look at the feature list and say, "Well, we have 300 features on this website and we can point to explicit tests for 270 of them."

Those numbers I just made up, but that gets you the point.

Jill Farley:

That sounds like an incredible amount of work to try to understand what to test and what types of tests to write. I'm actually going to go over to Byron for a second. As a member of the development team, what was it like actually writing these tests, creating them, and using them?

Up front, prior to them actually doing their job and covering our bases, if it was hard, let's talk about that.

Byron Duvall:

It was interesting and it was different because we use a different language for the testing. There's a lot of special keywords and things that you have to use in the testing framework, so just learning that was a bit of a curve.

Then, the biggest issue, I think we ran into with all of the testing was the timing of the test. The Cypress browser runs tests as fast as it can, and it runs faster than a human can click on all of the things. So, you start to see issues when the app doesn't have time to finish loading before the test is clicking on things. You have to really work to make sure that you have all of the right conditions for that to happen, and everything loaded, and you have to specifically wait on things.

I think that was the most challenging part. We usually had an idea of what we were looking for when we were writing a piece of functionality, what we were looking for it to do. That was kind of an easier part because we could write the click commands and write the test for what we're actually looking for in the return on the page.

So, that was the easiest part of it. The trickiest part was just the whole timing issue.

Jill Farley:

So Ken, how do we decide what to test if we're doing hundreds of tests? Is there ever really an end to what we can test or how do you do that prioritization?

Ken Rickard:

There is a theoretical end because we could theoretically cover every single combination of possibilities. You go for what's most important, and for what the showstopper bugs are. So, for instance, three simple examples of the first test we wrote, actually test #1: Do the pages that we expect to load, actually load? And do they have the titles that we expect them to have when we visit them?

Test #2: Those pages all exist in the navigation menu. Does the navigation menu contain the things we expect it to? And when you click on them, do they go to the pages we want them to? Also fairly simple.

Then we start to layer in the complexity because some of those menu items and pages are only accessible to certain types of users, certain types of conference attendees on the website. So you have to have a special permission or a pass to be able to see it.

So test #3 would say, "Well, we know that this page is only visible to people who are attending a conference in person. What happens when I try to hit that page when I'm not an in-person attendee? And does it behave the way we expect it to?"

So we start from the sort of show stoppers, right? Because if someone has paid extra money for an in-person ticket, but I let everyone view that page or don't treat that in-person user as special in some way, we're going to have angry clients and angry attendees. So we sort of test that piece first.

Then it's a question of, I would argue, testing the most complicated behaviors first. Like, what is the hardest thing? What is the thing most likely to go wrong that will embarrass us? And in that case, it's we have a whole bunch of functionality around adding and removing things to a personal schedule.

And we counted it up and over because we have pre-conference, during conference, post-conference there turned out to be 15 different states for every single session and we have tests that cover all fifteen of those states. So that we know what happens when you do, like I say, click the big something at the specific time.

So that's really how we break it down.

Jill Farley:

Makes tons of sense. Sounds like those are both, well, it brings new meaning to coverage. We're not just covering the functionality; we're kind of covering our butts too, making sure that, you know, we're not missing any of the big things that could really affect the attendee experience and the business, I guess, the business focus of the conference.

Ken Rickard:

Right. And the other thing too, the, well, those two other things as well. It does let us focus on what the actual requirements are because there are times when you go to write a test, you're like, "Well, wait a minute. I'm not sure what this thing should do if I click on it. Let's go back to the project team and find out." And we did that a number of times.

And then when you have something that's complex and time-sensitive, the biggest risk you run from a development standpoint, I think, is "Oh, we fixed issue A but caused issue B." So, you get a bug report. You fix that bug and it breaks something else.

Complete test coverage helps you avoid that problem. Because we broke tests a lot and you'd see a failing test and be like, "Oh wait, that thing I just touched actually has effects on other parts of the system." And so having those pieces again gives us a better product overall.

Jill Farley:

So test failures could be a good thing in some cases.

Ken Rickard:

Very much so. I actually was reviewing someone's work this morning and they had to change the test cases. I don't think they should have, based on the work they were doing. So, I was reviewing the pull request and I said, "Hey, why did you change this? This doesn't seem right to me because it indicates a behavior change that I don't think should exist."

Jill Farley:

Byron, I want to ask you. I know that you were involved in some of the performance work on this particular platform. What do you think? Did our Cypress tests in any way prevent some performance disasters? Or do you think that it's mostly about functionality? Like, do the two relate in any way?

Byron Duvall:

I don't think we had any tests that uncovered performance issues. I can't think of any specific example. It was mostly about the functionality and it was about avoiding regressions, like Ken was talking about. You change one thing to fix something, and then you break something else over here. I don't think that we had any instances where a performance bug would have been caught.

Ken Rickard:

I would say every once in a while. One of the things that Cypress does is it monitors everything your app is doing, including API requests. I think it came in handy in a couple of cases where we were making duplicate requests. So, we had to refactor a little bit. These were pretty small performance enhancements, so yeah, nothing big around infrastructure scaling or things like that.

But Cypress could catch a few things, particularly, I mean, if you're talking about a test loading slowly. It's like, “Oh, we have to wait for this page to load.” That can be indicative of a performance issue.

Byron Duvall:

Yeah, that's a good point. And then, the Cypress browser itself will show you every request that it's making, so you can tell if it's making lots of requests that you don't believe it should be making, or if it's making them at the wrong times. That could indeed be a way to uncover something, but it's really completely separate from the tool that we use to test performance outside of those other clues that you might get from Cypress testing.

Jill Farley:

So we've talked about Cypress testing and functionality. Can it test how things look? How things display?

Ken Rickard:

It can. But it's not a visual testing tool. It's not going to compare screenshot A to screenshot B, but we could write specific tests for markup structure in the HTML. For example, does this class exist inside this other class? It does have some tools for testing CSS properties, which we use in a few cases. Jill, you'll remember this. Are we using the right color yellow in one instance? Thus, we have an explicit test for, “Hey, is this text that color?”

Jill Farley:

That's the that would have been the big disaster of the event is if it wasn't the right color yellow.

Ken Rickard:

So, we do have a few of those which are visual tests, but they are not visual difference tests. That's a whole different matter. However, you can write a test to validate that. Let's revert to my previous example: the big orange button is, in fact, orange.

Jill Farley:

Just a couple more questions. Let's start with: What are a few ways that going all in on Cypress testing this year got in our way? Perhaps there's something we might do a little differently next time to streamline this, or maybe it's always going to get in our way, but it's worth it.

Ken Rickard:

I think the answer is, it can be painful, but it's worth it. The fundamental issues we had when we push things up to GitHub and then into CircleCI for continuous integration testing is that we don't have as much control over the performance and timing of the CircleCI running of the app as we do when we're running it locally. So tests that pass routinely locally might fail on CircleCI. That took us a long time to figure out. There are ways to get around that problem, which we are using.

The other significant issue is that to do tests properly, you have to have what are called data fixtures. These simply mean snapshots of what the website content looks like at certain points in time. They're called fixtures because they are fixed at a point in time, so they should not change. But because we were transitioning from last year's version of this application to this year's, there was a point where we had to change the content in our fixtures. We're actually about to experience that next week when we transition from the test fixtures we were using to a new set of fixtures, which contain the actual data from the conference - all of the sessions, all of the speakers, all of it.

Updating that is a massive amount of work. So being able to rely on things like, "Hey, I want to test that Jill Farley's speaker name comes across as Jill Farley," means we have to make sure that the content we have maps to that.

Jill Farley:

Is it fair to say that incorporating this into our development process, again, it's worth it, but it slows it down?

Ken Rickard:

I don't think it overall slowed us down. I believe overall, it might have increased our efficiency.

Byron Duvall:

Indeed, I believe it did increase our efficiency. It allows us to avoid a lot of manual point-and-click testing on things when we're done. We can do some development, write a test or have someone else write the test, and use that tool to do our manual testing while we're coding instead of just sitting there pointing and clicking. Even creating test data, if we have the fixtures in there like Ken was talking about, is a big help as well.

One of the things that did slow us down, however, was being able to differentiate between a timing or an expected failure versus an actual problem or regression with the code. There were instances where we didn't recognize which type of failure it was. We changed the test, but then we inadvertently broke something else in the app, so we should have paid more attention to that specific test failure.

When you're trying to troubleshoot various types of failures, timing failures, and things that may differ on CircleCI or just fail intermittently, figuring out whether it's a real problem or not can slow you down. It can also kind of defeat the purpose of testing as well.

Ken Rickard:

Right. In normal operation, which I would say we're in about 90% of the time, it simply means that on a given piece of work we're doing, we're changing just one thing, and that's the only thing we need to focus on. We can trust the tests to cover everything else. So, we can be assured that nothing else broke. The question then becomes, do we have a good new test for this thing that just got added?

Sometimes, I conduct pull request reviews without actually checking out the code and running it locally. I can just look at it and think, "OK, I see what you did here. You're testing here. You didn't break anything. OK." That's acceptable and, actually, it's a great feeling.

Jill Farley:

This is probably the last question. We've talked a lot about the benefits to the development process and kind of gotten into the specifics of how to do it. I'm curious for anyone who's considering incorporating this into their process, are there key, you know, kind of maybe two to three benefits from a business perspective or a client perspective? Why take the time to do this? I can actually think of one from a business side. I was sort of the delivery manager on this project, and in layman's terms, the manual QA process on the client side, once we sort of demoed this work to them, was so much shorter. I mean, last year, when we weren't doing this, there was a lot more pressure on the human point and click testing, like Byron was saying, not just on our development team side but on the client side as well. So as they're reviewing the functionality and really testing our work to see if it's ready for prime time, the development of a safer testing process really decreased the amount that we found during the final QA phases. It was really nice to sit back at that point and say, "Yeah, we've covered all of our bases." So Ken, what would you say are the biggest business benefits to incorporating Cypress testing into a product?

Ken Rickard:

The biggest business benefits, I would say, are getting a better definition of what a feature actually does because the developers have to implement a test that covers that feature. This creates a good feedback loop with the product team regarding definition. Another significant factor that derails projects is either new feature requests that come in at inappropriate times or regressions caused by making one change that accidentally breaks multiple things we were unaware of. You witnessed such incidents in past projects when we didn't have test coverage, but now we don't have to deal with that anymore. Those are the big ones.

It also occurred to me, as you were talking about the client, that one of the nice things about Cypress is that it records all the tests it runs and generates video files. Although we didn't share those with the client, we could have sent them the videos and said, "Okay, we just finished this feature. Here's how it plays. Can you make sure this covers all your scenarios?" They could watch the video and provide feedback. This potential is significant from a business standpoint because it allows for various asynchronous testing. It's funny because when you play back the Cypress videos, you actually have to set them to play at around 1/4 speed, otherwise, it's hard to follow along.

Jill Farley:

So that question I had about does this slow us down? It sounds like we make up the time.

Ken Rickard:

Oh, we definitely make up the time. Yeah, most definitely, again, just in in catching regressions.

Jill Farley:

So, business benefits we've got: saving the client time and heartache on the final QA, we've got getting to a better definition of what a feature does, safeguard against regression. Byron, do you have any other thoughts on the sort of business benefits of Cypress?

Byron Duvall:

I think that pretty well sums it up. I don't think I would add anything to that list, that's pretty comprehensive.

Ken Rickard:

I mean, it's a little selfish to say, but I think it made us better developers, because you have to think through all of the implications of things.

Jill Farley:

Well, I think that's a great statement to end this conversation on. You both feel as though you're now better developers because of this experience. Thank you both!

Hopefully, this gave everyone an idea of how we went about it, some things to plan for, and a bit of guidance on how to approach introducing Cypress into your process. Thank you both so much for your time, and happy Cypress testing!

A stable version of Recipes is yet to be released in 2023, this initiative is a prominent part of Drupal 10.

Drupal 10 provides a powerful platform for building websites and applications. It offers various ways of site-building, including profiles, distributions, and now recipes. 

As part of the Drupal strategic initiative, site-builders & developers can greatly benefit from the improvements to be provided by the recipes initiative.

Drupal 10 recipes are expected to provide more flexibility and ease of use to site builders and developers, allowing them to create custom solutions that meet their specific needs. Although a stable version of recipes is yet to be released in 2023, this initiative is a prominent part of Drupal 10 features. 

This blog will help you understand how recipes are different from profiles and distributions and how they are a way forward in Drupal site-building. 

Understanding Profiles & Distributions

Profiles and distributions are often confused, but they are not the same thing. Drupal vanilla, or the basic Drupal installation, is relatively bare and lacks many of the essential features required to create a full-fledged website.

Profiles and distributions are pre-configured packages that contain a set of modules, themes, and configurations that can be used to create a specific type of website.

Profiles and distributions are pre-configured packages that contain a set of modules, themes, and configurations that can be used to create a specific type of website.

Distributions are built on top of Drupal and provide a use-case-specific package. They include a pre-selected set of modules, themes, and configurations that are designed to fulfill a particular use case.

For instance, a media and publishing distribution will include modules like feed, carousel banner, facet search, or similar features specific to media websites. 

Distributions are a great way to get started quickly and provide a solid foundation to build on top of.

Profiles, on the other hand, are subsets of distributions and are included in Drupal core. Drupal core comes with three installation profiles: Standard, Minimal, and Demo (Umami). 

Installation profiles determine the set of modules, themes, and configurations that are included in a distribution. 

For an e-commerce site, one could use the standard installation profile as a base and add additional modules and themes to customize the site.

Drupal vanilla is bare and lacks any pre-configured settings or features. Profile and Distribution are similar concepts in Drupal, but serve different purposes.

Enter recipes!

What are Drupal Recipes?

Recipes are a modular approach to site-building in Drupal. They are small use cases that can be easily combined or customized to create a unique solution. Recipes are like microservices that can be plugged in and played as needed.

Recipes are modular building blocks that allow developers to create custom site features quickly and efficiently.

A distribution is a use case that customizes Drupal to fulfill a specific need. Unlike distributions, recipes do not use installation profiles and can be tweaked at any point in the site-building process.

Installation profiles are part of Drupal core. These profiles determine which set of modules, themes, and configurations are installed during the initial setup of your Drupal site. 

The actual backend of any distribution is happening here, as installation profiles are responsible for setting up the initial site structure.

A Profile is a type of distribution that provides a more focused set of features for a specific use case. Profiles can be thought of as smaller, more specific distributions that cater to particular needs.

Unlike distributions, recipes do not use installation profiles and can be tweaked at any point in the site-building process.

To illustrate the differences between these site-building methods, let's consider an example. Suppose you want to build a news website that includes features such as a feed, carousel banner, and facet search. You could use a pre-built news distribution that includes these features out of the box. 

However, if you need to make further customizations, you would need to modify the installation profile or distribution, which could be time-consuming and complicated.

Alternatively, you could use an installation profile such as Standard and then install the necessary modules manually. This approach provides more flexibility, but it requires more effort and expertise to set up. 

Finally, you could use a recipe approach and install each required module and configure them individually. This approach provides the most flexibility but requires the most effort to set up.

Steps to install Drupal recipe

Why Recipes?

One of the primary objectives of Recipes initiatives is to overcome the challenges, site maintainers and developers face with distributions and to:

• Allow users to install multiple Drupal recipes on the same project, unlike the current scenario where selecting a distribution like OpenSocial prohibits the installation of another distribution like Commerce Kickstart or Thunder. This limitation will be eliminated, and multiple Drupal recipes can be installed on the same site.
   
• Install a recipe at any point in a project's life cycle, which is currently not feasible. For instance, if a user wants to incorporate community collaboration tools in their site after a few years of using standard Drupal, they can do so without any impediment.
   
• Simplify the process of maintaining the multisite architecture. This initiative aims to ensure that any changes made do not create additional challenges in this regard.
   
• Make updating easier, which is currently a challenging task as every existing site is in a different state, the Update Helper module developed by a few distributions will be integrated into the core.
   
• Make it easy for Drupal recipes to provide demo content, which is currently done in different ways such as importing from CSV or using custom modules, a functionality will be provided in the core to enable Drupal recipes to ship demo content.

What Drupal recipes are not

Drupal recipes have certain limitations, such as:

Wrapping Up

In conclusion, Drupal provides several site-building methods that allow users to create custom solutions to their specific needs. Profiles, distributions, and recipes are all powerful ways that can help you build your Drupal site efficiently and effectively. 

Drupal 10 recipes are an exciting addition to the Drupal ecosystem and will help make building websites and applications faster and more efficient than ever before. 

As a leading open-source community leader, OpenSense Labs has helped numerous enterprises transform their digital presence with our expert Drupal services and solutions. From custom Drupal development to UX design, we have the experience and expertise to help your organization succeed in the digital landscape.

Don't miss out on the opportunity to partner with a trusted and experienced team. Contact us today at [email protected] to learn more about how we can help you achieve your digital goals. 

At the beginning of the project, we need to understand the requirements of the client, then we adapt the design, update the components and after that, integrate it into Drupal.  

Here is an example to understand how we apply this solution and integrate it:

For example, if we have a card (web component molecule) that we want to integrate into Drupal, we need to figure out what information we want to show. Let's imagine that we want to display some short information about a blog content type. 

We can have different “types” of cards, for example, with an image, link, date, and/or with all the data that you want to show. In this case, we want to use a card where we have a title, an author, and a link to read the whole content. In the blog content type, we will use these “fields” to call inside the card, so in the case of the title of the card, we will use, for example, the “label”, and call it inside the template. And so on with all the information that we want to show.

This is how it is finally displayed:

Drupal 10 released in December 2022 and ever since, the community has been pushing its users to migrate to the latest version. 

As many as 54% of all Drupal sites are running on Drupal 7. 

Using an outdated version has downsides. Businesses miss out on technological advancements and new features that can speed up and safeguard their digital properties.

With the release of Drupal 10 and the fact that Drupal 7 will reach end of life in November 2023, it is crucial to migrate to Drupal 10 soon. Here’s why enterprises should plan their Drupal 10 migration now, and not wait until the last moment. 

Why should you migrate from Drupal 7 to Drupal 10? 

Drupal 10 brings automated updates, improved user experience, along with several other feature additions. These components will be more secure, user-friendly, and powerful. Let’s dive deep into why enterprises must plan their Drupal 7 to 10 migration. 

1. Community support: As an open source CMS, community support is what keeps Drupal's continuous innovation ongoing. With Drupal community prioritizing and actively focusing on security of newer versions, as and when Drupal 7 reaches end of life, the community support will seize. This primarily jeopardizes the security of your Drupal 7 website. This also means that contributed modules and themes that are currently used in your Drupal 7 website, will also lose support for maintenance. This would bring challenges in website maintenance.
    
2. New features and upgrades: Another consequence of not upgrading to latest version is that certain functionalities may cease to perform as intended. Or there may be better alternatives available. Not only can this cause extra annoyance among website maintainers, but resolving these issues may incur additional expenditures for your company owing to the time and resources required to do so. In Drupal 7, while developers had to manually upgrade/updates or search for modules from drupal.org , Drupal 10 has simplified this with Automated updates and Project browser, respectively. A lot of Drupal 7 features are either incorporated out-of-the-box in Drupal 10 or simply removed to maintain ease-of-use. 
   • Automatic updates: Drupal sites require manual upgrading, which may be challenging, time-consuming, and expensive. Delays in applying security upgrades can lead to hacked sites. The Automated Updates Initiative seeks to give Drupal sites safe, secure automatic updates. In order to minimize the total cost of ownership of maintaining a Drupal site, increase the security of Drupal sites in the wild, and lower the entry barrier for utilizing Drupal, a safe mechanism for automatically deploying updates in Drupal is to be implemented.
      
   • Project browser: Module installation and locating involve too many steps. Some steps call for you to navigate away from your Drupal site and visit Drupal.org. Other procedures, like utilizing Composer from the command line, need technical knowledge. For users who are new to Drupal and site builders, project browser aims to make it simpler to identify and install modules. This eliminates the need to visit Drupal.org or other sites. It is one of the primary Drupal strategic projects that determines the platform's development goals.
      
   • New themes: Olivero & Claro - The Drupal 7 "Seven" theme from 2009 gave off an out-of-date system impression. Seven was replaced by the new "Claro" theme, which was created in accordance with the most recent requirements. The front-end theme, "Olivero," was created to fit with features that are well-liked by users, such as the Layout Builder. The Olivero theme will be WCAG AA compliant.
     The simple finding and installation of modules should empower Drupal newcomers as well as "ambitious site builders" – Dries Buytaert
      
3. Technical Dependencies: Drupal work on current supported PHP versions. Recommended PHP versions are the best choice for building a Drupal site because they will remain supported longer. Drupal 10 is built on PHP version 8.0 while 7 isbuilt on PHP 7 which is also reaching end of life. This creates technical dependencies in supporting the platform better.
    
   • jQuery, jQuery UI, jQuery Forms- Drupal 7 includes old and unsupported versions of these libraries. jQuery's current version is 3.6.x. Drupal 7 includes 1.4.2. Other libraries have comparable challenges. You may minimize this little with the jQuery Update module, although the most recent version is 2.1.x. Drupal 8 and later (as well as many other content management systems) make it simple to provide API access to your content. In the age of "publish everywhere," this is a critical feature. Drupal 7 has some basic API support, but if you want a full-fledged API with write support, you'll have to create it yourself, which adds technical debt and possible vulnerabilities.
      
   • CKEditor 5 update from CKEditor 4 - With a thorough rebuild and an exciting new feature set, CKEditor 5 gives Drupal 10 a modern, collaborative editor experience. Users of programs like Microsoft Word or Google Docs will be used to the new CKEditor's interface. It also offers common tools for collaboration like comments, change suggestions, version histories, and other accepted editing practices. Additionally, it has outputs to.docx and.pdf files for straightforward conversion to print formats. Although the integration is still being worked on, Drupal core 9.3 already has an experimental version if you want to try it out.
      
   • Composer 2 and PHP 8 support - Although backporting of composer 2 to Drupal 8 was successful, PHP 8 compatibility was not. PHP 8 will be required for Drupal 10 because PHP 7 will be discontinued in November 2022.
      
4. Modules that have gone out of support: The Drupal 10 core will be updated to eliminate a few modules that are redundant or are not frequently used. For uniformity, these modules will be transferred to the Contributed Module area. Gathers and presents syndicated material from outside sources (RSS, RDF, and Atom feeds).
   • QuickEdit: In-place content editing
   • HAL - Serializes entities using the Hypertext Application Language.
   • Users may keep track of recent content with the activity tracker feature.
   • RDF – Enhances websites with metadata so that other systems may comprehend their characteristics.

You will have to leave Drupal 7 behind. Eventually, the opportunity cost of continuing to use software that is more than 10 years old is substantial, and once it is considered End of Life (EOL), the risk and expense of an uncovered vulnerability increases rapidly.

There are several possibilities available to you, and you have an additional year to choose and make plans for one of them. The ideal option will rely on the expertise level of your team, the amount of business logic you have included into Drupal 7, and your projected budget.

Conclusion 

Drupal 7 will reach end of life in November 2023, Drupal experts recommend that organizations begin migrating to Drupal 10 soon and not wait till November 2023.

If you want to migrate your website to Drupal 9 and prepare for Drupal 10, you may rely on our Drupal migration skills and expertise.

OpenSense Labs, as a Drupal partner, is committed to providing active support. Contact us at [email protected] for a long-term and fruitful collaboration.

The significance of SEO in digital business is no secret. Organizations invest thousands of dollars just to be on the top of the search engine result pages. Despite several tectonic shifts in consumer behavior, organic search delivers the most traffic. More on that later

SEO is more than just adding keywords.

An important part of doing SEO right is ensuring your technical SEO is set right. 

Apparently, organizations that have websites built on mature CMS like Drupal have to care less about technical SEO. All aspects of Google-identified site and page-level best practices are ensured out-of-the-box.

In this article, we’ll dive deep to understand different Google ranking factors and how Drupal ensures you stay on top of those trends.
 

SEO Objectives

Organic search remains the dominant source since budget restraints many marketers to opt for Google Ads for more visibility on SERP.

Best SEO practices not only ensure higher ranking but are also budget-friendly. 

According to research, 61% of Google traffic comes from organic searches. Before we move to understand SEO objectives, here's a look at organic SEO trends. 

Some of your SEO goals can be: 

• Brand Visibility: It simply means the rate at which your brand is visible to the target audience. SEO immensely helps enterprises to improve their brand visibility.

  The more people are aware of your brand online the better your chances of a higher conversion rate. In this digital age where people consume most of their information online, not having a solid online presence is simply not an option.

  Content marketing notably has a great role to play in brand awareness and when it gets infused with SEO it has the potential to make a significant transformation. 
   

• Better ROI: Good brand visibility paves the way to high ROI. If you use SEO strategically then your conversions will increase. On-page SEO is an effective strategy to rank higher on search engines and drive more organic traffic to your website.

  The more people visiting your website the more likely you will get better conversions. 
   

• Organic Traffic: Despite so many shifts in consumer behavior people still mostly use organic ways to search for any product/service.

  According to content marketing statistics 2022, quality content with optimized images can increase organic traffic by over 111.3%. On-page SEO addresses all of the tactics necessary for improved organic traffic.

  The improved technical aspects of your website contributed to a better user experience, ease to crawl, and thus increased organic traffic.

Let's understand some Drupal SEO modules that you can use to make your website SEO friendly and rank higher on search engines.
 

Site Level Factors & Modules

1. Advanced CSS/JS Aggregation: Slow website load directly affects the search engine rankings. Advanced CSS/JS Aggregation is a must-have module for websites with a lot of CSS/JS files which means this module compresses your frontend files and speeds up your website. 
2. CDN: A content delivery network is a distributed system of servers deployed in multiple data centers around the world. Website performance directly affects your search engine ranking and user experience. A website that takes an eternity to load will eventually lose most of its visitors. A CDN will distribute a load of your website across servers globally to reduce load time. This module will help the website in loading faster and thus improves user experience and website performance.   
3. AMP: AMP also known as the accelerated mobile page is an open-source framework launched by a joint initiative of google and several other tech companies. Accelerated mobile pages are lightweight and designed to give mobile users lighting fast and more engaging experience. This module converts web pages as per AMP standards and helps web pages to load faster on mobile and tablets. 
    
4. Search 404: 404 error occurs when a content of a URL is moved or deleted. It is considered bad for SEO as it hampers user experience and google bots also penalize such websites. When a web page is deleted or moved ‘search 404 module’ will do a search for URLs that are being moved or removed and show the result of the search instead of a 404 error. This improves the site’s SEO by making sure inactive URLs don’t hamper user experience by delivering the content as per the user’s query. 
5. Blazy: Lazy loading is a technique for waiting to load particular parts of the website, especially images- when needed. The Blazy module provides lazy image loading to save load bandwidth and help reduce bounce rate. It also helps in saving bandwidth for important information before the website load completely. 
6. Cloud Flare- This module helps your website load 30% faster, use 60% less bandwidth, and process 65% fewer requests. Cloud flare is a global network designed to make everything you connect secure, fast, private, and reliable. Fast content delivery and Improve SEO are some more features of cloud flare. 
7. XML Sitemap: In the simplest terms site map is an XML file that contains all your website URLs along with additional metadata about each URL. XML site map creates an efficient site map of your website that is easy to crawl and automatically gets added to search engines like google, bing, yahoo, etc. Site map links pertaining to the content, menu items, taxonomy terms, and user profile can also be added. 
    
8. Simple XML Sitemap:  This module helps your website in creating individual site maps for each webpage according to google guidelines and policies. Apparently, a simple XML sitemap helps your website get indexed faster on any search engine. This module creates multilingual site maps for entities, views, and custom links and it supports all Drupal’s content entities i.e. nodes, taxonomy terms, users, and menu links. 
    
9. Robots txt: A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. Use this module if you are operating numerous Drupal sites from a single code base and each one requires a distinct robots.txt file. This module produces the robots.txt file automatically and allows you to change it from the web UI on a per-site basis.
    
10. Schema.org Usage: Pages with micro formatting tend to rank higher on SERP. Schema markup help website create formatted pages that help search engines understand your content easily. This module specifies the mapping between content types and fields with schema.org types and properties. 

11. Menu breadcrumbs:  A website with a large amount of data would immensely benefit from the menu breadcrumbs module. As this module builds a navigational path for visitors that helps the website track users' exact behavior on the website and enhance user experience.

    
     

12. Easy breadcrumb: Navigational design of a website describes how different pages of a website are organized and connected to each other. When a site is easy to navigate it increases visit duration. The easy breadcrumbs module helps in creating an accessible navigational website structure that is easy to navigate. 

13. Link checker: This module is useful to detect broken links from the content. Both internal and external links can be checked via the link checker module. It occasionally removes broken links from your stored content by checking the remote sites and assessing the HTTP response codes. Broken links can easily be checked in the log/report section. In the “my account” section, author-specific broken links are stored. 

14. Menu attributes:  As the name suggests, this module helps you add extra attributes to your menu section like class, ID, name, style, relationship, and target. A well-organized menu helps users’ website accessibility and experience. 

15. Pathauto: User-friendly URLs are extremely vital for boosting your SEO efforts. Pathauto module allows you to generate a URL  based on your content. It is a must-have module for any website to make it SEO-friendly. 

16. Metatag: Search engines usually prefer websites with optimized content and meta description. The meta tag module creates structured meta tags for your website so that your website ranks higher on SERP.  In addition to that this module also provides support to meta tags from other social media sites. You can furthermore control how your content is going to appear on different platforms. 

17. Hreflang: Now if are not sure what hreflang is then it is an HTML attribute used to specify the language and geographical targeting of a webpage. When you have different geographies to target then your website should be multilingual. This module is best for websites with multilingual content. The Hreflang module automatically adds tags to your website’s enabled languages. 

    The multilingual website attracts a larger audience, improves the brand image, and has an edge over competitors. With only 25% native English speakers, it's a great opportunity to reach out to the rest 75%. 

18. External Hreflang: This module allows you to add hreflang for external sites to easily detect spammy and faulty websites. External links connecting spammy websites degrade the user experience and can damage your brand presence and online ranking. 

19. Redirect: Directing visitors and bots from one URL to another is called redirection. The key benefits of redirection are to improve user experience and help search engines better understand website content. The redirect module helps in merging websites, moving domains, deleting existing pages, and switching from HTTP to HTTPS. 

    301, 302, and javascript redirects inform the web browser that a page has moved from one URL to another and let visitors and users land on the right page.

20. Domain 301 Redirect: A 301 redirect sends all the requests from the old URL to the new one. Domain 301 redirect help in redirecting users to relevant pages and page relevance congruent with the user’s query help in good ranking. This module allows sites to 301 redirects to a domain that has been selected as the main domain. 

21. W3C Validator: HTML errors or poorly coded websites can hamper the site quality and bad site quality consequently damages your website’s SEO. W3C validator reduces the code size on your web page and adds value to your content. Small codes help your website loading speed on diverse platforms. It validates your HTML and CSS codes according to international coding standards.

Page level factors 

1. CKeditor: It is a rich text editor that helps users write or edit the content inside the webpage. It has a nice writing interface where you can easily format and style content like adding a head, sub-heads, and numbering and bullet feature for better readability. 
2. Disqus: Pages with lots of comments may be a signal of user interaction and quality. In fact, one Googler said comments can help “a lot” with rankings. Enabling comments on a blog has multiple benefits including the possibility. To engage with your readers and grow a strong community. Disqus module helps you integrate a comment feature on your website that helps your readers to better engage with your content.

   
    

3. Scheduler: This module can help content writers to plan and publish content as per their requirements. The scheduler module makes your overall publishing experience hassle-free and supports both Drupal 7/9. 

   Time Scheduling enables achieving your intended interest group in the circumstances they're on the web, regardless of the possibility of what that time is, hence it has a huge benefit in content marketing. 
    

4. Automatic Alternative Text: Alt text is basically an alternative text for images. The whole purpose of alt text is to improve accessibility by describing what an image looks like to the user who doesn’t have the ability to see it. 

   This module automatically generates an alt text for your images if you missed putting one. Interestingly google prioritize images with meaningful alt text and it can be helpful in ranking higher on google.  
    

5. ImageAPI Optimize: A blog with optimized images has always been the prime factor for higher ranking. Search engines prioritize images that have a proper title, description, alt text, file name, and caption. This module allows you to compress images without compromising image quality with flawless image optimization.
    
6. ImageMagick: This is an open-source software suite that helps edit, display, and convert picture elements and vector files. It’s also helpful in creating image thumbnails, color correction, and liquid rescaling which basically means rescaling the image without distortion. 
    
7. CKEditor Nofollow: A no follow link doesn’t authorize the website it is linking to. You can make no follow the link by Adding the “re=nofollow” code to your website. This module requires no modules outside of Drupal core and is used to add rel="nofollow" to links using CKEditor widget.
    
8. Linkit: Internal links are the inclusion of web pages connected to each other. It can increase the ranking of the other pages within your website. It helps both readers and crawlers to easily find your site. Linkit gives you a nice interface for searching and links to internal content on your website instead of you trying to look for URLs manually. Within the editor section, you can select which URL you want to interlink and you will get the asked result.  
    
9. Editor advance Link: This module helps you convert normal hyperlinks into a styled button. This module allows content creators and editors more control over link appearance or functionality. 
    
10. CKEditor Entity Link: Drupal entities (content, tag, files) can be easily linked with the help of CKEditor Entity Link. This module is compatible with Drupal 9 and with all content entity types. It allows you to choose which entity types and bundles to search for and also provides an autocomplete box to make entity selection easier.

Drupal SEO Checklist Modules 

1. SEO Checklist: This module is compatible with Drupal 8/9. As the name suggests Drupal SEO checklist module creates an automated SEO optimization checklist so that you can optimize your website hassle-free. If you are someone who likes to follow organized checklists for website optimization then this module is a must-have. 
    
2. Real-time SEO for Drupal: If you like writing your content according to SEO guidelines then this module is quite helpful. SEO is a great source for organic reach and a higher SERP ranking is the prominent source of it. While writing, real-time SEO for Drupal provides inbuilt SEO-friendly suggestions as per best SEO standards.
    
3. Requires on Publish:This module is required when your content is published or getting published. Requires on publish can be used when you have fields on your pieces of content, such as tags or SEO information, that editors don't need to fill up until the material is published. 

Conclusion

Drupal comes with countless SEO benefits and it delivers the best SEO results. All the modules that we discussed encompass all the features that can help you achieve the best quality results in 2023 and beyond. 

With changing Google updates and SEO trends, you need a technology partner that makes sure your digital game is top-notch. 

Our Drupal expertise ensures that your site measures up to Drupal’s capabilities in SEO and you leverage them for the top-most SERP rankings.

Looking to enhance your website’s visibility on Search Engines? Get the SEO results you want.

Contact us at [email protected] and let our experts help you out with SEO.

The Splash Awards are awarded each year to celebrate the best Drupal projects. The awards have taken place in the  Netherlands since 2014. In 2017 projects in German-speaking countries were honored with Splash Awards for the first time.

The Splash Awards are intended to honor not only Drupal service providers, but also the end users who do exceptional work. 1xINTERNET are happy to have been nominated in three categories for the German - Austrian Splash Awards.

At the DrupalCon Portland community summit, we discussed how local meetup organizers could support each other by maintaining a shared slide show for meetups. I have started a slide show and am looking for volunteers to join me in building it. Leave a comment on the issue in the Event Organizers Working Group if you can help.

Since Drupal 8 there Tour module is in core. It is very useful when you need to guide user within your application. We use it In EK management tools targeted at users with small to medium scale companies. They usually have limited resources and time to spend on back office trainings. This is where the Tour module is very convenient to introduce functionalities to users who can quickly grasp the functions available to manage their back office.

You can try the latest version of Tour with the demo application where many of the forms and pages have a tour guide for users.

Last week, I wrote about how free software has to break out of the customer-vendor mindset. The customer-vendor mindset doesn’t work with free software because users don’t pay and developers don’t provide customer service. The free software community works on a build-what-you-use model. I ended by saying that the build-what-you-use model is not enough to sustain hero developers—people who contribute at a level that cannot be sustained by their own use of free software. I suggested that hero developers are vendors and should sell their work to paying customers rather than releasing it to the community for free.

Another way hero developers can sustain contribution is by working for a large company. Large companies like Facebook, Apple, and Google routinely release free software to promote adoption of their products. When a company stops maintaining its free software, it is either abandoned or taken over by the community. Examples of projects being taken over by the free software community are XQuartz, LibreOffice, NetBeans, OpenBSD, and Firefox.

The problem with depending on a single large company is that the hero developer is vulnerable to a change in company priorities. Once a free software project stops being part of a company’s business plan, the company can no longer sustain the hero developer’s contribution. An example was Corel abandoning Linux as a condition of receiving investment from Microsoft.

Is there a way for the free software community to sustain hero developers? While the community works best with a wide base of contributors who are sustained by their own use of free software, there is massive value in the contributions of people who are motivated more by their love of a project than by what the project can do for them.

Sponsorship alliances

I believe contribution from hero developers can be sustained if users of their work form an alliance to sponsor their contribution. A free software project is an alliance of developers who have an incentive to recruit more developers so they can all benefit from each other’s work. Members of a sponsorship alliance would have a similar incentive to recruit more sponsors to the alliance because new members would increase the value of the alliance to existing members. If the alliance is large enough, the loss of one member will not affect the alliance’s ability to sponsor contribution from a hero developer.

There are many example of alliances being formed to support free software projects. After the Heartbleed vulnerability showed that the OpenSSL library had become unmaintainable, Google and OpenBSD both began working on replacement libraries. When the XFree86 project was unable to coordinate contributions from the community, the previously dormant X.org foundation took over stewardship of the X Window System. When OpenVPN was too difficult for many users, Linux vendors came together to release WireGuard in the Linux kernel. The Linux kernel itself is supported by the members of the Linux Foundation. All of these alliances were formed after deficiencies were found in the maintenance of projects that their members relied on.

If a hero developer is providing professional support for free, I would expect it to be difficult to build momentum to form an alliance. How then can hero developers encourage the free software community to form sponsorship alliances before their ability to contribute is exhausted?

My suggestion is that hero developers who want to do their work within the free software community withhold updates and support from their projects until they are sponsored. This is difficult for developers to do because they are always afraid of their work becoming outdated. To avoid that happening, hero developers should showcase their own work and incorporate the work of other contributors, but should not release their own work or support other users unless they are paid. This will highlight the extent of the hero developer’s contribution and the need for sponsorship to make it sustainable.

As a member of the Drupal community, I would suggest that our community could help with the formation of sponsorship alliances by providing a platform to set them up, manage their memberships, and link them to projects. I may examine the requirements for such a platform in a future article.

Yesterday I had my fears confirmed about the Drupal Automatic Updates initiative. It requires sites to be able to modify core Drupal files. While this makes it easier to fix vulnerabilities, it is not something you want when your site is actually being attacked. The best way to protect against someone exploiting a vulnerability to modify your Drupal core files is to change the file permissions so that your site cannot modify them.

The Automatic Updates team has done amazing work to make the update process itself trustworthy. The problem is that if you allow your site to modify core files, you cannot guarantee that only trustworthy processes will use it. I’ve seen a site that had malicious code added to almost all its files and had malicious files created in all its folders. I’ve been on an IRC chat with a Drupal site administrator who was trying to clean up a site that was being attacked so persistently that as soon as it came back up it would be compromised again.

There is a workaround. Instead of giving the site permission to modify core files, you can give that permission to a different user and run a command line script as that user. But you can already create scripts to update your site automatically. If you want to use the admin UI, it will not work.

What makes this frustrating is that a solution already exists. Starting in Drupal 7, Drupal has supported SSH file transfer. The Update module uses it to update contributed modules. If Drupal does not have permission to change a contributed module, the Update module checks for the SSH2 PHP extension. If it exists, it prompts for the user name and password of the user who has permission to change contributed modules. No credentials are stored in Drupal, so only an authorized use can modify files. It seems that this feature is so obscure and rarely used that the Automatic Updates team overlooked it.

I hope to get support for SSH file transfer added to the Automatic Updates initiative before it is finalized.

Drupal 8 performance: the Supercache module

Post date: 

Thu, 04/14/2016 - 00:00

Difficulty: 

Piece of Cake

The Supercache module is the result of an attempt to improve Drupal 8 efficiency when dealing with cache tag management and other design issues with several caching components that make it a pain to deal with Drupal 8 based applications that change a lot. 

An out of the box Drupal 8 install will issue about 2,100 database statements for a simple task such as performing a log in and creating two articles.

With a little setup and the Supercache module I was able to bring that down to 240 statements.

Here is a video proof that these numbers are real. The statement count is being measured real time thanks to the awesome SQL Server Profiler tool.

[embedded content]

The impact of the Supercache module - that was for a while a core patch - was benchmarked and proved to reduce wall times by about 25% and database queries by as much as 50% after things change (doing a cache write).

How does the Supercache module do this?

• Drupal's cache system got heavier in Drupal 8 at the expense of making it more precise thanks to cache tags. But there are situations where you simply do not need all that bloatage. The Supercache module introduces a new and sleeker cache layer (of course without cache tags). A simple cache tag stored in Drupal's cache system takes up 196 bytes. The new caching system only uses 12 bytes. This does not seam like a big deal after all, it's just a few bytes difference. But it translates to being able to store 65,000 cache tags in 1MB of APCu/Wincache instead of just 5,000, But that is not the only advantage of this cache layer:
  • Reduced storage size, up to x12 less for small cache items.
  • Levarage native functionalities provided by most storage backends such as touch, counter, increment, etc.
  • Faster processing due to lack of cache tags and other extras.
  • Scalar types are stored natively so you can batch operate on the cache items themselves if the storage backend allows you to do so (database, couchbase or mongo)
• Drupal 8 introduced the very useful ChainedFastBackend (that you can easily use in Drupal 7). But the current implementation of that backend has some design flaws - such as invalidating the whole fast backend when doing a cache write or not using cache tags in the fast backend. Supercache replaces the ChainedFastBackend implementation with one that solves those two issues improving hit rates in the fast backend on systems with lots of writes.
• Replaces the default cache tag invalidator services (that works directly on the database) for one that leverages a similar concept to the ChainedFastBackend.
• Introduces the ability for the key value storage to work similarly to the ChainedFastBackend.

To properly leverage what the Supercache module has to offer you should setup support for a centralized caching backend such as Couchbase

By: root Thursday, April 14, 2016 - 00:00