Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jan 26 2021
Jan 26

Authoring content in one place and publishing it to multiple locations offers many benefits. Reducing the editorial effort needed to keep content synchronized across multiple locations is often the primary benefit. However, providing a consistent authoring interface, a canonical cross-brand asset library, and increasing monetization of existing content are often ancillary benefits that can be just as important.

We always get excited when we can partner with our clients to build a new publishing experience or improve an existing one, as we love to use technology to solve problems. However, the excitement can soon be tempered by the reality of potential challenges. Through our experience building syndication systems, we have solved many challenges and found some tactical approaches and strategic principles that guide us through the issues that must be considered along the way.


Should we even be doing this and is it really worth it? This should always be the first question. Sometimes the shiny new functionality might not actually be the best idea when all factors are considered. Some questions to ask while making this decision:

  • How much content needs to be shared?
  • How many places will it be shared?
  • How often will the content change?
  • How quickly do edits need to be synchronized?
  • How will associated media such as images and video be shared?
  • What are the costs/time considerations with manually keeping the content in sync?
  • What are the costs to build and maintain an automated system and how much complexity does it add for the editorial team and developers?
  • Is there an existing solution or will a custom approach be needed?


Depending on the complexity of the system, understanding what content is available and where it has been published is important, but can quickly become difficult to manage. Planning for this up-front will be essential to the long-term success of your system, ensuring a great user experience that scales beyond the proof-of-concept.

Providing contextual data on content edit forms that inform editors where a given piece of content has been syndicated to and where the current updates will appear is a great start. Filterable content listing admin pages with batch functionality built-in will also be valuable. This allows for editors to easily understand and change where content is published at scale.


Understanding the expectations around the syndication process is important for selecting the technology used and ensuring the system meets business expectations. If content needs to be live on consuming sites within 2 seconds, that is a much different requirement than 30 seconds, or even 5 minutes. Every layer between the end user and the syndication platform must be evaluated holistically with caching considerations also being taken into account.


Google isn’t a big fan of duplicate content, yet that is precisely what syndicating content seeks to do. Understanding this risk and mitigating it with a canonical URL and other measures is vitally important and can’t be an afterthought.

The creation and management of URLs is one of the primary challenges of sharing content and should be carefully considered from the start of a project. Some questions to consider:

  • Where are URL aliases generated?
  • What data is used to generate URL aliases?
  • Will the alias remain identical on all sites?
  • If the alias is different, do other sites need to know the alias for cross-site links?
  • Will there be cross-site search and what information will it need to build links?
  • How will sites know what site content lives on canonically and determine the domain?
  • Where will redirects be created and managed?

Editorial Interface

This is where things really get fun. There are many challenges and also many opportunities for efficiency, as reducing the editorial workload is likely what started this whole adventure in the first place. Some questions to consider through the process:

  • What level of control will be needed over the content on the consuming sites?
  • Will additional edits/updates need to be syndicated?
  • Are there any per site customizations? Do those take precedence over updates?
  • Where will curated lists of featured content be created and managed? Will that be syndicated as well?
  • Do editors need previews of the content on one or many of the client sites from the editing interface within the content syndication platform?
  • How will marketing pages built with Gutenberg or Layout Builder be shared and how will designs translate across sites?


There are a myriad of technical considerations and approaches depending on the requirements and the technology that is used. One of the first considerations should be to keep things generic and avoid tight couplings between the data models in the syndication platform and the consuming sites. Some field values can be mapped to identical fields in the client sites such as taxonomy terms and author information, as that data will likely be needed for querying data for lists. However, all other data can often be stored in a JSON field that can be decoded and made available to templates.

This all begins to border on a decoupled approach, and with this approach, it helps to set a project up for success if the front-end goes fully decoupled later. Or perhaps now is the time to consider going decoupled while a foundational evaluation of editorial workflows is already in progress.

Sharing is Caring

They say sharing is caring, but only share content if you can take the time to care about all of the details along the way. With thoughtful consideration at the very beginning, from challenging the very need for the functionality all the way to the technical details that set canonical metatags, analyzing each step of the process ensures a successful outcome. There is no easy answer, but hopefully this helps you avoid many of the pitfalls. If you have a project with content syndication coming up or have experience with it, drop us a line on Twitter @ChromaticHQ, we would love to hear your thoughts.

Jan 26 2021
Jan 26

As we look ahead to the end of the future academic year and what the future looks like, we see uncertainty clouding what is a typical admissions season for teams in higher education. 

Recently, we asked our partners in higher education to share their digital challenges. We heard that admissions personnel, as well as marketing teams at the college and university level, are feeling the pressure. They need to make sure the expectations of stakeholders are met or exceeded despite the unpredictable path ahead. 

Even though teams may face challenges ahead, one thing is certain: rethinking digital strategy to set your path forward will set your team up for success and your institution apart from others. 

The website is the heart of your digital strategy, and both should be built to adapt. That’s why many higher education institutions choose Drupal for their organization’s CMS. 

Below are five areas to focus your digital strategy, with some of our favorite tips and tools to improve campaigns moving forward.

Reevaluate Your Content Strategy

Universities used to enjoy a steady flow of students enrolling in programs. However, the future is now uncertain because of the COVID-19 pandemic leading many students to forego education or to choose online courses over taking classes in a traditional, physical environment. 

The uncertainty affected not just marketing teams at universities, but students as well. When the McKinsey higher education survey was conducted in April 2020, 37% of responding students were confident that things would return to normal by the end of summer. However, the 2020-2021 school year has thus far reflected much of what the previous school year 

Findings from our own client survey showed that uncertainty in the 2020 recruitment season led to several shifts in strategy to further help the user journey in the decision making process of choosing programs such as the following: 

  • Virtual tours rather than in-person tours
  • Live video conferences rather than in-person sessions
  • Website content to supplement brochures and physical marketing materials

Changes in academia lead to a shift in messaging, so teams need to evaluate if their content strategy is still working or if more needs to be done to cater to today’s student and their new priorities. 

Some ways in which evaluating content strategy can be done include: 

Persona research

 Although you may have a general idea of who your target audience is, more thorough research that includes user surveys can help create a better understanding of who your content should speak to. For instance, you may learn from user surveys that students and parents are uncertain about returning to in-person learning because they want to know more about what is being done to keep people safe in the classroom. With this information in mind, you might develop more content about COVID-19 cleaning protocols to give them peace of mind.

Content audit

Is your content resulting in growth, and does it cater to your users? If you are not getting the most out of it, an audit can help address gaps and find opportunities. 

Dashboard creation

Making sense of data is an important responsibility of a university’s marketing team. User-friendly dashboards can simplify the process of reviewing data and making decisions based on findings. Working with a digital strategy team with experience in higher education to improve your approach can yield results that allow your content to better serve student needs.

Give Your Marketing Team The Tools to Succeed

Giving the university marketing team agency in creating content quickly and efficiently is a top priority of many agencies that work directly with these teams. However, finding a CMS that provides the flexibility they want and a user-friendly editorial experience they need can be a challenge.  

RainU CMS can improve the editorial experience for content editors looking for a solution that allows for easier workflows that match with your existing design standards. With the ability to launch sites in 30 days or less, Rain helps both content editors and developers create flexible websites fast.

If your site is on Drupal, creating a decoupled solution with Gatsby may be just what you need. The business case for decoupled Drupal with Gatsby can help you determine if the cost and benefits are right for your university. Our developers are well adept at providing guidance in setting up GatsbyJS.

Using Drupal with Gatsby is a great way to get an enterprise-quality CMS for free, paired with a great modern development experience and all the benefits of the JAMstack, like performance, scalability, and security.


Make Smarter Use of Resources  

Unprecedented changes in higher education likely result in unexpected changes to budgets and priorities. Streamline the routine maintenance of your Drupal site to shift more budget toward new features. Here’s how Mediacurrent’s development solutions like Automated Updates and Multisite+ can help:

With Automated Updates, you can save hours of manual development work. Our automation services initiate pull requests, create JIRA issues, and stage updates within Pantheon’s multidev environment. Your team of project managers and developers can focus on productive work rather than administrative tasks when using Automated Updates for your project. 

Need to create multiple sites? Spin up new instances with Multisite+! With a shared codebase, your sites can go from concept to creation quickly and efficiently, and each has its own database, configuration, files, and base domain or URL to help with organizing your content. 

We have a wide variety of development services to meet your university marketing needs. 

Enhance Web Accessibility 

Universities cater to individuals of all abilities, so it’s important to make sure the digital experience is accessible to all. Using a tool like Siteimprove can help university marketing teams better understand how their site’s accessibility matches up to Web Content Accessibility Guidelines (WCAG) standards. 

SiteImprove dashboard with circular progress charts for QA, accessibility, SEO

SiteImprove's automated reports provide an easy way to measure and document progress toward accessibility goals

Failing to keep on top of website accessibility could lead universities to face warnings from the Department of Education as well as lawsuits. Mitigation measures such as using Siteimprove or working with a skilled accessibility team to audit and remediate your site allows your team to take steps that minimize the possibility of lawsuits as a result of your site’s digital experience. 

Launch New Campaigns Faster 

Colleges and departments within universities often need to launch campaigns quickly, and depending on the technology involved, expediency is integral. Teams must have a workable solution to accomplish the goals of an individual college or department.

Marketing teams can take advantage of RainU CMS to launch to market in 30 days or less. 

RainU CMS for Drupal homepage

Gain more control over your site with RainU CMS such as:  

  • Robust Security - Mitigate attacks from hackers - RainU CMS has several built-in security hardening features to help.
  • Flexible Content Feature-Packed - Build pages with a flexible, easy to use interface in RainU CMS for rapid development.
  • Component-Based Theme - Like with other Drupal sites, RainU CMS has reusable components and a built-in style guide which reduces design time.

Demo RainU CMS 

Ready to take your higher ed site and marketing campaigns to the next level? Explore how RainU CMS can get you there and check out the demo below. 

[embedded content]

Jan 26 2021
Jan 26

What’s common between Universities and Drupal? Both are powered by communities and both fuel community-based initiatives. In this article, we will look at some amazing educational websites built on Drupal and why they choose Drupal as their CMS.

Did you know every Ivy league school website is built on Drupal while 71% of the top 100 Universities around the world use Drupal? Numbers speak volumes about a good CMS, but we have many more reasons to prove that Drupal is the best CMS for educational websites. Read on to find out.

This list has been curated with information obtained from https://www.drupal.org/case-studies

Top 7 Remarkable Education Websites Built on Drupal

Why do top universities rely on Drupal

Top universities like Stanford, MIT, Oxford, and others alike, choose Drupal as their Content Management System. Universities are built on large communities – there’s the student community, the teaching staff community, the community of departments, the management, and other working staff. Being a community-driven CMS, Drupal helps knitting all these communities together. Drupal addresses issues in a way that streamlines information between each of its communities. 

  • Drupal allows for scalability to accommodate the ever-growing communities and varied web projects associated with them. The CMS is also well-known for dealing with a large user-base and high-traffic websites which is great for universities with a growing student base.
  • Drupal empowers educational institutes to build varied flexible solutions – from intranets to complex web applications to simple static web portals.
  • Drupal’s multi-site approach lets universities easily manage and create independent websites from a single codebase.
  • Features like multilingual, mobile-responsiveness, effective workflow management, access control, and others are now out-of-the-box with Drupal 8, thus making it an ideal choice for educational institutions.

Some Remarkable Education Institute Websites built on Drupal

1. George Washington University

Known best for producing some great leaders in every domain, George Washington University (GWU) relies on Drupal to create an engaging web presence for them. 

Why Drupal was chosen:

  • Drupal’s multisite feature now allows them to spin up new sites faster than ever before. 
  • Accessibility – GWU is committed to web accessibility and so is Drupal.
  • Responsive Web Design – The GWU website is completely responsive on all devices.
  • Ability to build scalable features and functionalities with customizable layouts.
  • GWU expected a reliable digital experience platform. And Drupal delivered.
George Washington University


2. University of Oxford

The prestigious University of Oxford has been at the top of the world university rankings for five years in a row. They offer over 250 different programs with a student population of over 24,000.

Why Drupal was chosen:

  • The open-source nature of Drupal worked out well for them financially and also meant that they will not have to depend on one company for all their development needs.
  • A global community of driven developers working towards making Drupal better every day.
  • To collaborate and work better with other units of the university who were already using Drupal.
  • Drupal’s list of quality case studies, including the White House, turned out impressive enough to make the final call.
University of Oxford


3. Rutgers University

Rutgers is New Jersey’s state university and is one of the highest-ranked public universities in America with over 71,000 undergrad and grad students. They moved their website to Drupal more than 10 years ago.

Why Drupal was chosen:

  • They wanted a design that looked great on all devices.
  • To deliver a consistent user experience among their various school locations.
  • Distinguish between their different schools yet provide a unified experience.
  • Allowed for fast and easy admission application at different university locations.
Rutgers University


4. Bookshare

Although not a university, we had to mention the Bookshare website because it does a fantastic job at imparting knowledge to the visually challenged and people with learning difficulties. There are different formats of accessing the books – audio, large-sized printed, or braille.

Why Drupal was chosen:

  • Web accessibility – They needed to have the highest level of compliance (AAA) to ensure accessibility by the visually impaired.
  • Multilingual capabilities – Bookshare is made available to people across the world and is currently available in 7 different languages (and counting), thanks to Drupal’s multilingual feature and translation modules.
  • To support deep integration with their existing APIs.
Bookshare Website


5. Georgia Tech Professional Education

Georgia Tech Professional Education is one of the many academic units of Georgia Tech, serving more than 36,000 learners globally. Georgia Tech is one of the top 10 universities in the US.

Why Drupal was chosen:

  • Its ability to integrate with various third-party marketing and communication tools.
  • Data security to protect student information.
  • Improved performance with smart caching.
  • To provide a user-friendly, easy to navigate and access website.
Georgia Tech Professional Education


6. UChicago News

The University of Chicago News office focuses on publishing new content ranging from student academic information to current affairs. They publish over 1000 stories every year that are later picked up and published by other media and publishing firms.

Why Drupal was chosen:

  • To improve website performance and speed during peak traffic events.
  • Powerful and smooth migration of their heavy websites with over 20,000 content nodes and over 10,000 taxonomy terms.
  • To be able to accommodate their growing number of pages, content types, and access control levels.
  • Easy creation and management of content with an effective workflow system in place.
University of Chicago News


7. University of Minnesota

Founded in 1851, this top university has more than 50,000 students enrolled in its programs. University of Minnesota is one of the very few universities that can boast about having a medical school, an engineering school, a law school, an agricultural school, and a veterinary school – all in one campus! They had 600 sites that needed to be migrated to Drupal, each of them heavy in terms of storage size with millions of monthly visitors.

Why Drupal was chosen:

  • They needed a flexible CMS that could handle their humungous number of visitors and content with ease.
  • To be able to quickly create new sites from standard design and features – using Drupal install profiles.
  • To build a centrally maintained, yet independently distributed platform that can be used across departments, satellite campuses, organizations, staff, etc.
  • To offer a secure platform with an extremely low tolerance for failure.
University of Minnesota
Jan 26 2021
Jan 26

We are pleased to announce that on December 30th 2020, Vardot was awarded ISO 9001:2015 and ISO/IEC 27001:2013 certifications for Quality Management Systems and Information Security Management Systems respectively.

Over the past year, Vardot’s processes and systems were thoroughly assessed and evaluated by LMS Certification Ltd and as such were awarded the aforementioned ISO certifications for the following Vardot key activities:

  • Web Design and Development (Learn more)
  • Web-based Software Professional Services (Learn more)
  • Professional Services for Web, Mobile and Enterprise Software Design and Development (Learn more)
  • Support, Maintenance, Management, and Administration of Online Digital Platforms (Learn more)
  • Delivery of Cloud-based Software Solutions (Learn more)
  • Enterprise Software Design, Development, Integration, and Consultation Services (Learn more)
  • Hosting Management of Digital Platforms, Websites, and Portals (Learn more)


What is ISO/IEC 27001?

ISO/IEC 27001 is an international standard that outlines the guidelines and requirements for establishing, implementing, maintaining and continuously improving an information security management system (ISMS).

The ISO/IEC 27001:2013 is the latest certification for this standard which verifies Vardot’s information security management systems maintain the highest standards with regards to confidentiality, integrity, availability, and traceability of data and information.

On our part, we always acknowledged that information security will always be a priority and foundation for any truly successful digital enterprise, hence our commitment to ensure that our clients always enjoy the best-in-class security services and solutions.

This certification recognizes Vardot as a reliable and strategic partner to enterprises that need hosting, migration, and managed services that support their digital transformation and projects.

Learn more about Vardot’s security measures here.

What is ISO 9001?

ISO 9001 is defined as the international standard that specifies requirements for a quality management system (QMS). 

Organizations use the standard to demonstrate the ability to consistently provide products and services that meet customer and regulatory requirements. 

ISO 9001 was first published in 1987 by the International Organization for Standardization (ISO), an international agency composed of the national standards bodies of more than 160 countries.

The current version of ISO 9001 was released in September 2015.

ISO 9001:2015 specifies requirements for a quality management system when an organization:

  • needs to demonstrate its ability to consistently provide products and services that meet customer and applicable statutory and regulatory requirements, and
  • aims to enhance customer satisfaction through the effective application of the system, including processes for improvement of the system and the assurance of conformity to customer and applicable statutory and regulatory requirements.

Tools, systems, resources, and processes that go into each stage of our project development and delivery process were evaluated and assessed to ensure that Vardot utilizes the best-in-class practices across all departments and stages of the project development lifecycle.

Going Forward

The certification is another milestone in our journey, and moving forward, we can clearly outline our priorities towards becoming a more agile value-driven enterprise IT solutions provider.

Vardot’s is committed to the ongoing enhancement of Varbase - the number 1 downloaded Drupal 9 distribution and CMS. Our UI/UX team is working hand-in-hand with our business intelligence and software development departments to create simpler yet dynamic digital experiences.

Our development team in turn is focusing on web and app performance from the earliest stages of project development - ensuring that our clients create the ideal digital experience for their target audience.

Vardot will focus on competencies - not just skills:

  • Adaptability - Demonstrating the required flexibility and agility to respond effectively to changing environments.
  • Business-acumen - Demonstrating awareness of internal and external dynamics with an acute perception of business issues.
  • Digital Dexterity - The ability to leverage information and technology in unique and  innovative ways.
  • Outcome-driven - Focus on delivering performance enhanced digital products and services that our clients will need to achieve their desired results.
  • Collaboration and synergy - Removing silos and blurring the lines between our various departments to create a more cohesive and interconnected ecosystem.

What is ISO?

The ISO accreditation is administered by the International Organization for Standardization, based in Switzerland. The certificates they issue are globally recognized and assert the quality of operations and service an organization provides.

Jan 26 2021
Jan 26

Having a basic understanding of caching is a requirement of being a professional Drupal developer. Unfortunately, there can be many layers of caching which can make it challenging to figure out exactly how best to configure cache settings and troubleshoot potential caching issues.

Web page caching can be thought of as moats around the castle, where each moat is a caching layer and the castle can be thought of as the site's web, database, and other origin servers.

HTTP headers provide a mechanism for the client (usually a web browser) and a server (usually a web server) to exchange information that is not visible to the end user, nor included in the HTML of the page. While there are few types of headers, cache-related headers are generally "response headers".

This blog post isn't meant to be a comprehensive guide to all layers of web page caching, rather we'll focused on common, cache-related HTTP response headers. Information in these response headers can help developers identify which caching layers, if any, were utilized in a given page request. Specifically, we'll be looking at how to view this response header information, and what it can tell us about Drupal page caching and content delivery network (CDN) caching activity on a per-request basis.

Keep in mind that there is not a constrained list of headers that can be added to a page request or response. While there is a common set defined by the Internet Assigned Numbers Authority (IANA) additional proprietary (custom) headers can be added by developers and vendors. It is also important to note that header names are case-insensitive, so the header names "Cache-Control" and "cache-control" are equivalent.

Instructions for viewing cache-related HTTP headers is included at the bottom of this article.

Categories of cache-related response headers

Cache-related response headers can be categorized as either "standard" or "proprietary". Standard headers are those defined by IANA while proprietary headers are added by developers and vendors. Below is a sample of some of the commonly-used cache-related response headers:

Standard (non-proprietary) cache-related response headers

  • Age: the time (seconds) that the object (file) has been cached.
  • Cache-control: general directives for caching mechanisms. For example, if this is set to "no-cache", then the file won't be cached.
  • Expires: the date/time after which the response will be considered stale, and then refreshed from the source. For Drupal sites, by default, this value is set to Dries Buytaert's birth date.

Common proprietary response headers

Again, these are not industry-standard response headers, and different vendors (hosting companies, content delivery networks) may have different implementations. It is best to refer to your specific vendor's documentation for additional details.

  • x-drupal-cache: Drupal-specific header set by Drupal core, values include "HIT", "MISS", and "UNCACHEABLE". Provided by the core Internal Page Cache module, applies only to anonymous users.
  • x-drupal-dynamic-cache: Drupal-specific header set by Drupal core, values include "HIT", "MISS", and "UNCACHEABLE". Provided by the core Internal Dynamic Page Cache module, applies to both anonymous and authenticated users. Allows for partial responses. See blog post by Wim Leers for more information.
  • x-served-by: this header is added by various tools to (normally) indicate the server that provided the response. This includes some (but not all) hosting companies and content delivery networks.
  • x-cache: in general, this indicates if the file was served by a CDN or the origin server. Multiple x-cache values often correspond to multiple "x-served-by" values.
  • x-cache-hits: for some CDNs, this value closely mirrors the "x-cache" value, only with a value of "0" being equivalent to "MISS" and any positive value equivalent to a "HIT" (the value being equal to the number of tries before a hit).
  • cf-cache-status: set by Cloudflare CDN, indicates the status of a cache request. Values include "HIT", "MISS", "DYNAMIC", "EXPIRED", and others. Note that in its default configuration, Cloudflare will not cache HTML - only things like static images.
  • cf-ray, cf-request-id: set by Cloudflare CDN to help trace requests through the Cloudflare network. Used for troubleshooting.

At this point, it is important to note an important difference between two of the more widely-used content delivery networks, Fastly and Cloudflare. Fastly is primarily a content delivery network built on top of the Varnish web application accelerator. While Fastly does have some web application firewall (WAF) capabilities, Cloudflare is both a content delivery network and a full, security-focused web application firewall provider. In some cases (including for DrupalEasy.com), both Fastly and Cloudflare can be used - Fastly for its CDN and Cloudflare for its WAF.


Below are a couple of examples of cache-related response headers along with a short discussion about what they mean.

Drupal.org cache-related response header values for HTML page

Authenticated user

Cache-Control: no-cache, must-revalidate x-served-by: cache-sea4481-SEA, cache-mia11376-MIA x-cache-hits: 0, 0 x-cache: MISS, MISS

Non-cached page served from the drupal.org "origin server" (located at Oregon State University) due to the "Cache-Control" value.

The "x-cache" values indicate that for authenticated users, Drupal.org's CDN (Fastly) did not serve the page. The first "x-served-by" value is the Fastly server closest to the origin server, while the second value is the Fastly server closest to the user loading the page. While "x-cache" indicates that a cached version of the page was not used, it was Fastly's servers that initially processed the request and ultimately retrieved the page from the origin server.

Drupal.org authenticated HTML request diagram

Anonymous user

Cache-Control: public, max-age=900 x-drupal-cache: MISS x-served-by: cache-sea4420-SEA, cache-mia11369-MIA x-cache-hits: 1, 4 x-cache: HIT, HIT

The "Cache-Control" value provided by the origin server indicates that the page can be cached for up to 900 seconds (15 minutes). The "x-cache" values indicate that the cached page was served by the Fastly server closest to the user ("cache-mia11369-MIA" in this example).

Drupal.org anonymous HTML request diagram

DrupalEasy.com cache-related response header values for HTML page

Authenticated user

Cache-Control: no-cache x-served-by: cache-mdw17368-MDW, cache-mia11364-MIA x-drupal-dynamic-cache: UNCACHEABLE x-cache-hits: 0, 0 x-cache: MISS, MISS cf-cache-status: DYNAMIC

DrupalEasy is hosted on Pantheon (which includes the Fastly CDN) and uses the Cloudflare CDN. The "x-cache" values indicate that for authenticated users, Pantheon's default CDN (Fastly) did not serve the page. The first "x-served-by" value is the Fastly server close to the origin, while the second value is the Fastly server close to the user loading the page. While "x-cache" indicates that a cached version of the page was not used, it was Fastly's servers that processed the request and ultimately retrieved the page from the origin (Pantheon) server.

The "cf-cache-status" of "DYNAMIC" indicates that the file is not eligible for caching by Cloudflare. This is normally a result of a directive from the origin server to never cache the file ("Cache-Control: no-cache").

DrupalEasy authenticated HTML request diagram

Anonymous user

cache-control: max-age=60, public x-served-by: cache-mdw17325-MDW, cache-mia11383-MIA x-drupal-cache: HIT x-drupal-dynamic-cache: MISS x-cache-hits: 0, 1 x-cache: MISS, HIT cf-request-id: 0775a92a710000e958291b2000000001 cf-ray: 60cfaaf0aa52e958-MIA cf-cache-status: DYNAMIC

For an anonymous user, the "x-cache" value of "MISS, HIT" indicates that the 2nd "x-served-by" value (the Fastly server close to the user) provided a cached response.

DrupalEasy anonymous HTML request diagram

DrupalEasy.com cache-related response header values for image (site logo)

Anonymous and authenticated users

Cache-Control: max-age=31622400 Expires: Fri, 31 Dec 2021 17:54:40 GMT x-served-by: cache-mdw17349-MDW, cache-mia11320-MIA x-cache-hits: 1, 1 x-cache: HIT, HIT cf-cache-status: HIT

The "cf-cache-status" value of "HIT" indicates that Cloudflare served this image. The "Cache-Control" value indicates that the image can be cached for up to 3162240 seconds (< 36 days). Note that the image was cached every step of the way on both Fastly and Cloudflare.

DrupalEasy authenticated image request diagram

Manually "bust" the cache

During development, sometimes it is necessary to "bust" the cache - that is, to request an uncached version of the content. While this can be done by clearing/purging/rebuilding caches at every level of the site's infrastructure (Drupal, Fastly, Cloudflare), it can also be done by adding a unique querystring variable to the content as they are cached according to their unique URL, including querystring variables. So, if you want to request an uncached version of "logo.png", simply append a meaningless querystring variable to it - for example, "logo.png?buster=2358973430985234895".


As the previous examples show, in order to be able to make sense of cache-related response headers, it is important to know which, if any CDNs are being used as well as which, if any, Drupal-level caching modules are enabled.


Viewing cache-related HTTP headers

All major browsers provide relatively easy access to HTTP header information, if you know where to look. Here's a quick guide:


  • Open Web Inspector ("Inspect Element" anywhere)
  • Go to "Network" tab.
  • Reload page.
  • Click on (usually) first entry in list of files - this will be the main HTML file for the page.
  • Click on the "Headers" sub-tab.


  • Open the network tools via the "Tools|Web Developer|Network" menu item.
  • Reload page.
  • Click on (usually) first entry in list of files - this will be the main HTML file for the page.
  • Click on the "Headers" sub-tab.


  • Open the network tools via the "View|Developer|Developer Tools" menu item.
  • Go to "Network" tab.
  • Reload page.
  • Click on (usually) first entry in list of files - this will be the main HTML file for the page.
  • Click on the "Headers" sub-tab.

Network tab in Chrome browser screenshot


  • Open Developer Tools (Crtl-Shift-I).
  • Go to "Network" tab.
  • Reload page.
  • Click on (usually) first entry in list of files - this will be the main HTML file for the page.
  • Click on the "Headers" sub-tab.

Thanks to Andy Giles from Blue Oak Interactive for reviewing this blog post.

Jan 26 2021
Jan 26

Learn more about the call for content and submit today! The session submission deadline is Sunday, February 14 at 11:59 pm EST (UTC -5). Send questions about DrupalCon (session submission process, logistics, etc.) to the DrupalCon team. Get tips and request proposal feedback anytime in the #session-help Slack channel.

A note from our fabulous 2020 program committee:

“Imposter syndrome” — something we seem to be hearing about more often. Not familiar with the term? Gill Corkindale defines imposter syndrome beautifully in Harvard Business Review

Imposter syndrome can be defined as a collection of feelings of inadequacy that persist despite evident success. ‘Imposters’ suffer from chronic self-doubt and a sense of intellectual fraudulence that override any feelings of success or external proof of their competence. High achieving, highly successful people often suffer, so imposter syndrome doesn’t equate with low self-esteem or a lack of self-confidence. In fact, some researchers have linked it with perfectionism, especially in women and among academics.

In 1978 clinical psychologists Pauline Clance and Suzanne Imes came up with the term “imposter phenomenon” after recognizing a pattern of feelings in graduate students. Through this research they created the Clance Impostor Phenomenon Scale (CIPS), which helps individuals evaluate their level of imposterness.

Many times, when a person considers presenting in front of an audience, imposter syndrome comes, too. We’ve chatted as a committee and have come up with a few thoughts to share. 

Why is this relevant to you?

Do any of the following sound like something you might say?

  • Everyone else around me knows so much more than I do
  • I’m not sure why [potential employer] would hire me when [someone else] is available
  • If I ask or talk about this, everyone will realize that I don’t know as much as they think I do
  • [Another Drupaler] is far more qualified than me to teach this subject
  • I should offer a discount for this job because I’m not as good at this as [insert someone else’s name here]

Chances are pretty high that, if you are reading this post at all, you are party to this pattern. Why do we feel confident making this assumption? Because you are curious enough to submit that you are paying attention to the resources, but you feel that you need to prepare yourself with more information before doing so. The very fact that you are interested in submitting content means that you have something valuable to share. And we want you to submit, as we want and need your voice.

The worst that can happen: your proposal is not accepted. Even then, however, you and your unique ideas are now top of mind for a collection of Drupalers, and our own journeys are anecdotal evidence of this directly translating into impact, personal growth and future opportunities.

And consider this: you probably think of the session selection team as experts in the field because someone thought we should be part of this team and invited us to join, right? Well, how is it that we are capable of writing this post if we are such hotshots? Frankly, because we have these thoughts every day. We are not hotshots, but simply people who took the scary step to put ourselves out there even though we doubted ourselves.

How does imposter syndrome come into play at DrupalCon?

It is common for Drupalers to think that whatever they may have to share is status quo and everyone knows it, but if you start asking around, everyone is always looking for better solutions. It is highly unlikely that two people will approach similar challenges exactly the same way, and your “basic” talk idea might be exactly what dozens or hundreds of people need in order to level-up their Drupal skills.

True story from one of our session team members: in 2010 Rain, then fairly new to Drupal, submitted “Views Demystified” because the very basic chapter on Views from Angie Byron (webchick) and Addison Berry (add1sun)’s book, Using Drupal, saved her hundreds of hours building Drupal sites. Rain figured it wouldn’t be accepted or attended because of course everyone else knew Views, but she submitted anyway.

This very simple beginner talk not only landed hundreds of attendees at the Con and was directly requested for many camps and meetups for years following, but it also had a lasting impact on many. To date, after nearly a decade, Rain continues to encounter people who tell her this talk changed their Drupal-lives.

When preparing your submission, think about what would be useful if you were in the audience of a potential session. If it’s useful to you, then someone else wants to learn about it too. Not every session has to be something new or cutting-edge; sometimes the most obvious topics are the ones people need most! 

Your idea, no matter how basic it seems, might be that key talk for future generations of Drupalers. 

Overcoming imposter syndrome in the moment

Imposter syndrome can also make presenting feel scary, especially when things don’t quite go as planned. 

Shaky Wi-Fi connection from an unanticipated windstorm? Dog decides to create a symphony with a siren? Mishaps happen. It’s helpful to acknowledge that things go wrong—it’s normal! You are supportive and have patience when mishaps happen to others, so show yourself patience. At DrupalCon in particular, remember that much of the audience have been speakers themselves. They understand and are rooting for you!

Don’t let it bother you if an audience member leaves or sign-off, there could be any reason for this. Perhaps they have an emergency to tend to, someone scheduled a meeting that overlaps with part of your presentation, or they realized the content wasn’t quite what they were looking for and they’d like to make another session instead. This is not a reflection of you, or your speaking. Focus on the people who are there and engaged.

If it all goes awry, be honest! If you’re nervous, say so. If you need help, ask for it. A session host will be there to support you and can help stimulate conversation with the participants while you adjust your slides or microphone. Team up with a friend and co-present. This tends to take some pressure off each person, and provides at least one guaranteed familiar face.

You’ve got this

If you’re feeling a dose of imposter syndrome, perhaps that means you’re surrounding yourself with people who motivate and challenge you. That’s admirable! 

Some powerful advice from Megan Dalla-Camina’s article in Psychology Today:

At the end of the day, remember this: You are here for a reason. In this job, your business, your life, you are worthy. You are better than you think you are. You are smarter than you think you are. You know more than you give yourself credit for. Remember that. And remind yourself as often as you need to.

Remember, you’ve got this!

Contributed by Esther Lee and Rain Breaw Michaels.

Jan 25 2021
Jan 25

If you've spent any time in the Drupal community (specifically the issue queues, forums, and Drupal Slack workspace channels), you may have noticed that while the vast majority of discussions are positive, every now and then tempers flare up or less-than-helpful comments are posted. 

To continue to grow a healthy community, we all must work under the assumption that no one intentionally uses language to hurt others. Even so, despite our best efforts we sometimes still use words or phrases that are discouraging, harmful, or offensive to others. We are all human beings who make mistakes, but as members of a shared community, it’s our responsibility to lift each other up and encourage the best in each other. 

When observing negative behavior in the Drupal community, it can be difficult and/or uncomfortable to interject ourselves and find the right words to get conversations moving in a healthy direction. To address this, starting with an idea discussed at a Community Working Group (CWG) workshop at DrupalCon Seattle, the CWG Community Health team has been working on a communication initiative for the Drupal community. It consists of a series of de-escalation templates we have dubbed “Nudges”.


The team has written five nudges that community members can use when they are faced with one of these uncomfortable situations in the Drupal community. We selected topics that we feel can have the most impact and are easy to understand. Each “nudge” provides context as to why the comment may be harmful and relevant links including our Code of Conduct and Values and Principles.

The “nudges” created to date are as follows:

Inclusive language - gendered terms

This discussion appears to include the use of gendered language in a comment. Gendered language can be harmful to our community because it can signal that we assume that people’s participation in the community is determined by gender.

The shift to gender-neutral language promotes gender equality. Please respect the pronouns that community members provide in their profiles.

For more information, please refer to Drupal’s Values and Principles about treating each other with dignity and respect.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Inclusive language - ableist terms

This discussion appears to include the use of ableist language in a comment. Ableist language can be harmful to our community because it can devalue challenges experienced by people with disabilities.

For more information, please refer to Drupal’s Values and Principles about treating each other with dignity and respect.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Gatekeeping knowledge

This discussion appears to discourage contribution from some participants by assuming a level of education or exposure to information. This can discourage folks that are new to a conversation from asking for help or getting involved. Consider providing the new contributor with links to help them learn the topic or concept.

For more information, please refer to Drupal’s Values and Principles #3 of fostering a learning environment: long-term contributors should be role models by admitting their own shortcomings and mistakes, being vulnerable, and by giving others the same respect that was once given to them. To keep learning read this article about not feigning surprise.

Principle #9 can also be useful here: be constructively honest, and relentlessly optimistic. You can be optimistic and supportive by giving suggestions for how to improve their contributions. By being helpful, you encourage people to accept feedback and act on it.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Cultural differences

This discussion appears to have escalated due to the inclusion of culturally-specific language. This may be harmful to our community as stereotypes can exclude or tokenize community members, devaluing their individual contribution and value. Please avoid language that imposes an identity on an individual or group.

We should be mindful that not all words and phrases translate to have the same meaning. Please be mindful that different cultures may appreciate different levels of directness in their communication styles and that may impact how words are presented or interpreted.

For more information, please refer to Drupal’s Values and Principles about treating each other with dignity and respect.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Escalating emotions

This discussion appears to include escalating emotions, creating the opportunity for miscommunication. The invested parties are encouraged to take a break from this discussion to help gain perspective. It is important to the community that all members are shown the appropriate amount of respect and openness when working together. Additionally, there are resources offered by the Drupal community to aid conflict resolution should those be needed.

For more information, please refer to Drupal’s Values and Principles of seeking first to understand, then to be understood. Assume best intentions of other contributors and suspend judgment until you have invested time to understand decisions, ask questions, and listen. Before expressing a disagreement, make a serious attempt to understand the reasons behind the decision.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Testing strategy

Over the next few months, members of the Community Health Team will be testing these "nudges” in Drupal.org issue queues, forums, and Drupal Slack workspace channels. For now, this will be done by copying and pasting the nudge text and formatting directly into an issue comment or Slack message. Our goal is to create a nudge widget that allows community members to insert one of the pre-written nudges via a token in issue queue and forum comments.

We feel that a gradual introduction to help prevent overuse of these nudges is necessary as overuse may produce its own sort of gatekeeping. This could lead to desensitization to the “nudge” initiative, negating our efforts. The CWG’s mission is to ensure a positive space that is inclusive to all of our members. 

These are early days for “nudges”. We are looking forward to hearing from other community members on how we can improve on this idea. We have been having weekly meetings for nudges and have been documenting everything we've been doing in the Community Working Group issue queue - let us know if you'd like to get involved!


Current community members who have been working on this task include: AmyJune Hineline (volkswagenchick), Neil Drumm (drumm), George Matthes (watsonerror), Darren Oh, Donna Bungard, JD Flynn (dorficus), George DeMet, and Mike Anello (ultimike).

Jan 25 2021
Jan 25

Newly engineered opportunities have opened the doors for Higher Education institutions to pioneer student, researcher, and funding recruitment. From deeper data applications to mass-scale live debates, the Higher Education sector is going through a digital transformation, with varying rates and approaches.

New data and accessibility regulations, as well as pressure on student recruitment from COVID-19, have required Higher Education institutions to accelerate these 'digital transformation roadmaps'.

Entire organisations have had to react and re-evaluate everything across technology implementation, face-to-face education, student recruitment, and community satisfaction.

The forces of change are drawing in at an unprecedented rate. But are universities equipped to make the quality, long-term adjustments needed?

Senior stakeholders from the University of West London, Manchester Metropolitan University, and Oxford Saïd Business School sat down with Paul Johnson, our Drupal and HE Specialist at CTI Digital to discuss their digital challenges and opportunities during a panel at DrupalCon Europe. We received a unique perspective on various UK organisations' challenges with differing cohorts, scale and complexity, age and legacy systems.

Watch the full panel here, and use the time stamps below to navigate:

[embedded content]

00:00 - Introduction with:

  • Chair and top left: Paul Johnson, HE Specialist at CTI Digital
  • Bottom left: Adrian Ellison, Associate Pro-Vice-Chancellor & Chief Information Officer at the University of West London.
  • Top right: Nick Holland, Head of Digital at Manchester Metropolitan University.
  • Bottom right: Iain Harper, Head Of Digital Marketing, Saïd Business School, University of Oxford.

05:29 - Why The University of West London chose to upgrade and continue using Drupal.

09:50 - How Manchester Metropolitan University built the business case to move to Drupal.

13:29 - Oxford Saïd Business School's experience of using Drupal 8 for multiple years.

19:30 - Managing "HiPPO" (Highest Paid Person's Opinion) and different stakeholders' opinions.

22:20 - Data-driven decision making to changes of an existing platform at Oxford.

24:58 - Managing governance for an entire platform change at MMU.

26:58 - Managing change to projects and their teams over multi-year projects.

33:54 - Lockdown and adapting working with staff and students remotely.

37:04 - Content governance and consistency.

38:54 - Designing and building a website for diverse audiences.

41:22 - What features or capabilities for Drupal should Drupal develop for HE's future?

If you're looking for a digital partner to support your digital transformation. We're the team you're looking for. Our full-service team can take your through discovery and user research to plan and define the underlining requirements that meet your business goals. Our content strategy and development team will then be available to make your digital roadmap become a reality—all under one roof, with years of precedented success.

Get in Touch

Jan 25 2021
Jan 25

If you're like most modern Drupal developers, you use the excellent Address module to collect country-aware address data on entities that require it. But, what do you do with the output of address data?

Granted, you can use the Geofield module ecosystem to turn that address data into embedded maps on your site, but if you're looking for a simpler solution, consider using the Address Map (& Directions) Link module - this module does one thing and does it well: it allows you to link the address to an external mapping service of your choice via additional settings on the default Address formatter.

Address Map Link module screenshot

So, the next time you use the Address field, consider this easy solution to improve the usefulness of that data!

Jan 22 2021
Jan 22

The way websites are perceived has changed a lot recently. The audience has started demanding more and more from the web and web developers have to provide for all the demands. What this has resulted in is the transformation of websites for the better. 

The features that today’s sites are packed with were hardly even imaginable a decade ago. A website, a web application or a mobile application, all can do wonders for the users, satiating them with their experiences. 

So, when building a website, you have to be extremely considerate of the software you use and the technologies that accompany it as it is these that will make an astounding difference in your site’s overall appeal. 

On the same note, I will try to enlighten you about one such software and technology pair that has made websites as appealing as both their developers and users want them to be, and that is Drupal and Angular. So, let’s get right on it.

Drupal’s Essence 

The Drupal logo is seen.

In essence, Drupal is a provider of innovative digital experiences that set your websites apart from the ordinary. 

Being a content management software, Drupal can make websites that actually set standards for others to follow. Convenient content authoring, impeccable performance and outstanding security are some of Drupal’s most renowned features. Whether you want flexibility and modularity or integrated digital frameworks, Drupal can ease your needs. 

With multiple add-ons;
With numerous modules; 
With several themes; 
With various distributions; 
And with multitudinal mix and match options, Drupal’s core abilities are magnified by a landslide. 

Now, the Drupal 9 has paved the way for an even more delightful web building experience. Known to be the easiest upgrade in over a decade, it is going to take Drupal 8’s innovative streak even further. Here’s everything you will want to know about Drupal 9.

NBC, MTV UK, Amnesty International and University of Oxford are some of the elite clientele of Drupal and their websites are a true epitome of Drupal’s abilities. 

“Make something amazing, for anyone”  - a motto of a kind should have been pretty self explanatory of Drupal’s essence, but it has acquired bragging rights and rightfully so. Hence, a little more elaborated boasting was mandatory.  

Taking the Headless Route 

Drupal’s abilities, features and all that it encompasses has made it one of a kind. At the top of the list of its unique abilities is its ‘headlessness’. I know this is going to sound strange, but it is a fact and a very beneficial one at that. 

Like I mentioned above, Drupal has all the features to make a web experience up and running and quite smoothly too. Having so many modules, themes and distributions, web builders would not find any need to look for additional features in their site. The entire web project would be placed inside Drupal and it would be entirely responsible for all of the project's needs. 

However, sometimes developers want to try more and Drupal lets them. It essentially removes its head, that is the presentation layer, to make room for a different one, that is other frontend technologies, and lets the developers only utilise it for its body, that would be its backend capabilities. So, in a truly Headless Drupal architecture, you would only use Drupal as a content repository and nothing else. This is also known as Decoupled Drupal, since you are going to be separating the couple, the frontend from the backend. 

When you go headless, you will be parting with Drupal’s frontend capabilities, but the separation does not have to be final. Decoupled Drupal comes with two options for you to choose from; 

  • One is the fully decoupled Drupal or the Headless Drupal. This completely segregates the two ends of a web project. Drupal takes command of the backend, while other frontend technologies, like JavaScript take hold of the frontend; both being connected by an API for the transmission of the information. 
  • Then there is the less final, progressively decoupled Drupal. In this architecture, you are still left with some of Drupal’s frontend capabilities. This means you can combine other frontend technologies to work with Drupal and get the most for your website, without losing Drupal out-of-the-box capabilities.  

Do you benefit from the going Headless?

Drupal has numerous benefits when you use it as a whole for building projects from the ground up; however, the decoupled Drupal comes with a tad more advantages. That is why it is becoming a vogue today, with several traditional Drupal sites converting themselves into the decoupled ones. 

So, yes, you will indeed benefit from taking the headless route. 

Aids in publishing on multiple platforms 

Going Headless makes it very easy to publish content on multiple platforms, be it your primary website, social media handles, intra sites or even print and media. The write once, publish everywhere features lets you capitalise all the IOT devices and publish on them.

Aids in maximising user experience 

The growth of your online business is directly proportional to the user experience you provide. The better the UX, the higher the conversions. UX is further dependent on your site’s performance. Having two separate ends enhances it, the request time is reduced with a client-side server and your site would be nothing but speedy.

Aids in making your team independent 

When you have a separated front and backend, that means you have the power to work faster. The frontend developers will only be focused on the user interface and the backend developers will only need to worry about those needs. Your teams can even make changes on their respective layers without having to worry about impeding the work of the other. All of this results in faster work speed and increased efficiency.  

Aids in enhancing creativity 

Drupal is a robust software, yet it can be stuff sometimes. You have to follow its guidelines and set standards or the work won’t get done. This hampers the development team’s creative flair. However, by adopting other, more flexible, frontend technologies through decoupling, you can let your creativity run free. 

Aids in faster upgrades 

Headless Drupal separation of concerns makes it simple to upgrade without impeding on your site’s current workings. It also gives you the opportunity to test on a dummy web service, which acts as a mockup, aiding you further in making revisions to your site.

Aids in taking advantage of JavaScript 

The final and probably the most compelling advantage of decoupled Drupal is the use of JavaScript. JS has the ability to make websites extremely interactive, with features like destructed assignment and arrow functions in the latest version. Since site interactivity with the user has taken precedence over anything else, decoupling has become more of a need. React, Angular and Vue are some of the most eminent JS frameworks that are used when going Headless. 

To know everything about headless Drupal and its suitability, read our blog, “When to move from monolithic to decoupled Drupal architecture.”

In Comes AngularJS

Now that we have discussed one part of the title, let’s move on to the second, which is AngularJS. You may know that a major reason behind going headless is the fact that it allows the user to incorporate other frontend technologies into Drupal and get the desired web building experience and the product as well. AngularJS is one such technology. Let’s get into its details.

The logo of Angular is shown.

What is AngularJS?

We ended the headless Drupal discussion at JavaScript, so it is only wise to begin the new one with JavaScript as well. AngularJS operates on JavaScript, being an open-source front-end web framework. It helps you create dynamic web pages through its structured framework. 

HTML’s template language is integral when building web projects. However, there is one problem with its use. HTML has proven its potential for static documents, however, when dynamic views come to play, it becomes lacklustre and chaotic. Now, in such a scenario, AngularJS comes in to save you. It allows you to extend the HTML vocabulary for your project, paving way for your developers to work in an environment that is expressive, readable and fast to develop. 

There aren’t many frameworks that have the ability to solve the HTML conundrum, what they do instead is abstract away HTML, CSS and JS or they might manipulate the DOM. covering up the problem is not really a solution and AngularJS provides an extension of HTML, making it worthy for dynamic views. 

The crowning jewel of AngularJS is its ability to adapt. It can easily be modified or replaced to make it suitable for any of your development needs. Whatever your workflow and feature require, AngularJS has the ability to provide. The fact that it is completely extensive and compatible with other libraries. 

Talking about the technologies Angular belongs to, it is part of the so-called MEAN stack. The MEAN refers to MangoDB, Express, Angular and Node.js. The combination of these four accounts for a firm ecosystem that is also backed by full-stack developers.

Let's look at AngularJS’ market share to understand its prominence even more. 

A list of the top industries using AngularJS is shown.(a)A list of the top websites built on AngularJs is shown.(b)A list of the countries is shown that use AngularJS with the number of websites using it.(c) | Source: SimilarTech

All of these numbers are pretty self-explanatory of AngularJS’ popularity in the market. 

What are the benefits?

Built in 2010 by Google, which is to this date responsible for its maintenance along with an entire community of developers and companies, AngularJS is quite a technology to utilise for your project’s development. It’s numerous benefits will make you believe me even more. 

Angular is flexible 

Angular by nature, or maybe its build, is extremely lightweight and concise. What this translates into is a working environment that is so extensible that you would be able to create things you never deemed possible. 

Angular uses directives 

Like we discussed above, Angular is unique because it is able to extend HTML. And this is possible because of Directives. Through these, special behaviours are assigned to the Document Object Model, which in turn enables your developers and engineers to use HTML and create dynamic and rich content. 

Angular binds your data two ways 

It is a known fact that Angular gives your developers the power of developing at a much faster rate. Multiple views, asynchronous technique, SEO friendly development are amongst a few of the immensely impressive features of Angular. And all these are possible because it works on the MVC architecture.  Because the Model-View-Controller framework synchronises the Model and the View, so when one changes, the other changes automatically. And work gets done faster. 

Angular injects dependencies 

When developers code, all the different pieces of that code have to interact with each other. This interaction also means that they are going to be affected by each other;s changes. This scenario is defined as dependencies. 

AngularJS solves this issue of dependencies in code simply by decoupling them using injectors. A dependency injector has the ability of making individual components easy to manage, test and reuse; maybe even more than before. 

Angular aids testing 

Lastly, AngularJS also makes unit testing pretty convenient for you. It has a built-in setup that makes testing the code much simpler and faster for your developers. 

The things you can do using AngularJS are much more advanced than Drupal’s frontend capabilities. So, combining the two is going to be a partnership that will make work wonders for your web project. 

The best of both worlds

The Drupal and Angular logos can be seen together.

Up until now we have been talking Decoupled Drupal and Angular individually and they have certainly been impressive enough. Both Drupal and Angular are equipped to build projects that will cater to any and all of your needs.

When paired together, they seem to be packing a punch. Your web projects will be able to accomplish so much more. Let’s have a look at some of the most intriguing features.  

Performance that will leave you spellbound 

A site’s performance is what sets it apart from others, it is what will keep your visitors scrolling through your pages and finally clicking on that coveted Buy Now tab. So, how do Drupal and Angular together help in improving your site’s performance?

If I talk about Drupal, it provides functionality in tons. Just working with drupal can make your site perform impeccably. Now, if you combine the Angular technology with it, you will end up with a performance that would be even better. That is because you will be able to offload business logic to AngularJS as it is client-side, you would not be able to do it completely, but even some part of the offload can be extremely effective. 

Furthermore, when you go Headless and take up Angular, you would use the latter for theming and presentation, while Drupal would only be responsible for the backend data source. This would enable you to move the display logic to the client-side, helping you in streamlining the backend. The resultant site is going to end up as fast as The Flash himself, for lack of a better metaphor.

Coding that will free up your developers 

When you use Drupal to build a regular, basic website, you would not need to write a lot of code and the development work would also be quite minimal. Yes, a basic Drupal site would not be feature packed and that is where AngularJS would enter. 

AngularJS will take an ordinary Drupal site and make it extraordinary, so to speak. Angular can make sites more interactive, more dynamic and richer in experience, and complex coding would not be a prominent part of this picture. 

By using directives, HTML, plain objects and other features, the JS framework requires very little effort from your developers in terms of coding. Despite the minimal efforts, you will still end up with the interactive pages that were only possible to get with a complete JS coding. 

Logic that will clean up your code structure 

You remember we talked about the MVC architecture in the previous section? I would have to be redundant and mention it again since it serves a lot of benefits when going headless. 

The Model-View-Controller architecture works on a principle that essentially segregates itself into three parts; 

Business logic;
Controller logic; 
And model logic. 

This results in a separation of your application logic from the user interface. And why is that essential? Because it aids in making the code structure cleaner, without much redundancy and more clarity. 

Imagine if one of your developers has to leave in the middle of your project. This could become devastating for your project, but an isolated code would make it extremely convenient for any other developer to pick up the left pieces and continue with the same effectiveness as before. 

AngularJS and Drupal also work well together because the MVC framework helps in eliminating a lot of backend logic from Drupal. Consequently, your site will turn out to be both extremely lightweight and efficient.

Security that will keep you shielded

Both Drupal and Angular are backed by a massive community. This means that there all the security features are always under scrutiny and the chance of things going sideways is slim to none. 

Add to this the fact the Drupal’s security protocol, if followed to the T will provide you an assurance of safety that not many CMSs can. Further adding to this, the combination of Headless Drupal and AngularJS will enable an extra layer of security to your site because there won't be any direct server-side interaction, the browser will only communicate with AngularJS.

The result of all of this would be that your site will become immune to malicious code that the notorious hackers are known to inject in your databases. And all would be well in the web world.

Everything about leveraging decoupled Drupal and different frontend technologies can be accessed here

Summing Up 

When decoupling is considered, tapping into the available frontend technologies is the paramount concern. JavaScript is most definitely at the forefront of the developers’ mind for the presentation layers. 

Angular is one of the flag bearers of JavaScript, and Drupal is a prominent name in the CMS world. Be it dynamic sites or interactive interfaces, the possibilities of with the combination of these two powerhouses. So, when are you taking them up?

Jan 22 2021
Jan 22

Paragraphs are one of the solutions competing for the title of the most convenient way to create content in Drupal. They are a great and consistent concept, however their UI leaves much to be desired. Thanks to the Geysir module, you will be able to improve your paragraph experience.

It is a module that cannot be easily ignored. We liked it so much that it has become one of the key elements of the Droopler distribution created by Droptica.


The first developer release of Geysir was introduced in September 2016, and the stable version was published exactly one year later. There were two major updates in 2020; many of the bugs they fixed were reported by our Drupal developers.

Module's popularity

Geysir is a relatively new module. According to the official statistics, it is used by about 500 websites. About 20% of this number are installations of the aforementioned Droopler.

Module's creators

The module has four maintainers from the Amplexor company, namely: Sander Vleugels, Jochen Verdeyen, Kevin Van Ransbeeck and Jan Lemmens. Together with 11 other developers, they have created 140 commits so far.

What is the module used for?

The module introduces a convenient interface for handling paragraphs, operating directly in the frontend part, bypassing the administration panel. Thanks to Geysir you can avoid the time-consuming browsing of the list of paragraphs. All you need to do is place the cursor over the content you are interested in and click the edit icon. In addition to editing, you can also add new paragraphs and move existing ones.

[embedded content]

For more videos on how Geysir works, check out our article on how to shorten time creating marketing campaigns using landing pages.


You can download Geysir at https://www.drupal.org/project/geysir - it has no configuration. The Paragraphs and Entity Reference Revisions modules are required for its operation. You can enable access for individual user roles via the "Manage Paragraphs from the front-end" permission.


Module's use

After launching Geysir, you will notice a "Paragraph overlay" button in the upper right corner of the page. It is used to switch between the edit modes.


Activate the button and go to the subpage with paragraphs. Note that from now on, you do not need to use the page edit form in order to change something. You can just use the icons provided by Geysir:


In the above screenshot from the Droopler distribution, you can see four new options:

  • Add a paragraph in the selected place.
  • Edit a paragraph.
  • Cut and paste a paragraph to move it within the page.
  • Delete a paragraph.

All these operations work via AJAX without the need to reload the page.

You will surely be interested in what adding and editing paragraphs looks like in this case. Well, the forms are launched in a modal window:


The advantage of this solution is the extraordinary speed of introducing changes. What is important, this method of content modification is much easier to understand, which makes training the employees responsible for the website easier. Try to create at least one website using Geysir, and I am sure you will notice a significant difference to the standard edit page.

Regarding the disadvantages of the Geysir module - note that the paragraph editing form above uses mostly the frontend skin. The skin of the administration panel (Seven, Claro, etc.) is sometimes overwritten here. Hence, functionalities such as views from the Media module require special treatment in order to ensure full compatibility and a consistent UI.

Hooks and integrations

The Geysir module provides one hook: hook_geysir_paragraph_links_alter () for changing the list of icons depending on the context of their use (paragraph type, parent entity and the reference field used in it).


If you use paragraphs, give Geysir a chance. It is a module that may cause some problems at first, but in the long run it will significantly speed up your work, which we can absolutely confirm in the case of many projects that we have carried out in our Drupal agency.

If you need a ready-made and proven solution, I encourage you to familiarise yourself with the Droopler distribution that we develop, which has a number of visual improvements to work between Geysir and Bootstrap 4. It is open source software and you can install Droopler yourself at no cost.

Jan 21 2021
Jan 21

Hello Drupal Association Member,
Last month, we completed the contract negotiations needed to pivot once again from the planned in-person conference to a virtual experience. With DrupalCon North America 2021 rapidly approaching on April 12-16, we are working hard to design an optimal online experience for our community and beyond. Our goals for the event include: bringing people together to share thought leadership around open source and ambitious digital experiences, providing professional development opportunities, and invigorating Drupal project momentum through education and contribution. 
Come together and contributeDrupalCon is enhanced through the time and talent contributed by volunteers, and we offer a number of opportunities to influence and support the design and implementation of the event. We’ve put together an overview of the volunteer opportunities for your review and consideration. If one or more of the roles aligns with your interests and availability, submit your interest form. If you’d like to be a member of the Program Committee, Summit Committee, or Marketing Committee, please be sure to submit your interest form no later than Friday, January 29, 2021. 
Come together and contribute
Another way to positively impact DrupalCon is by sharing your knowledge and insights as a speaker for the event. We are currently recruiting program content that emphasizes participant discussion and engagement. Visit the website to learn more and make a plan to submit your proposal before the February 14 deadline. 
If you’re planning to attend, be sure to register before February 4 to save $50 and secure the discounted rate. 

Our Diamond Sponsor


Our Platinum Sponsors


Need Help?

We’re here for you if you need anything. You can also find answers to common questions in our FAQ.
Jan 21 2021
Jan 21

Our community is in need of additional drupal.org site moderators (formerly "webmasters") to assist day-to-day site moderation tasks.

Over the past few years, the number of active site moderators in the Drupal.org site moderators queue has decreased significantly. Recognizing that this isn't a sustainable situation, the current active site moderators have embarked on an effort to recruit new volunteers.

Responsibilities of a site moderator

Site moderators are primarily tasked with responding to issues in the Drupal.org site moderators issue queue and the ongoing on-boarding of new community members. These tasks include:

  • Responding to issues in the Drupal.org site moderators issue queue.
  • Reviewing posts flagged as spam, deleting spam, and blocking users who post spam on Drupal.org web sites.
  • Confirming new Drupal.org users.
  • Responding to reports of projects posted on Drupal.org that do not meet community norms.
  • Other related tasks as described on the Moderation and maintenance documentation page.

Process to become a site moderator

In order to become a site moderator, there are a few easy steps:

  1. Familiarize yourself with site moderator responsibilities via the project https://www.drupal.org/project/site_moderators and the Site Moderator role description. https://www.drupal.org/community/contributor-guide/role/drupalorg-site_moderators
  2. Announce your intent to start participating in the #drupalorg-site-moderators channel in the Drupal Slack workspace.
  3. Begin participating in site moderator issues https://www.drupal.org/project/issues/site_moderators?categories=All. It is recommended that at first you ask questions and propose solutions to issues in a way that current site moderators can provide useful feedback.
  4. Once you have participated in the site moderator issue queue enough that you feel that you have a good handle on its various processes, create an issue in the queue asking for the Drupal.org "site moderator" role. It is highly recommended that you are active in the issue queue and Drupal Slack workspace channel, and have interacted with the other active site moderator before applying for this elevated role.

Why donate your time to Drupal?

If you've made it this far, then the obvious question is "Why should I become a Drupal.org site moderator?" Develop and exercise your people-skills while helping the Drupal community become a more sustainable, welcoming, friendly, and productive place. Regardless if you’re a developer, becoming a site moderator is a pretty straightforward way to build those skills.

In addition:

  • You'll work with other site moderators around the globe, building up your Drupal community network.
  • You'll have the opportunity to help nurture new community members in a meaningful way.
  • You'll have the opportunity to earn contribution credits.
  • Having the "site moderator" role is a position of leadership in our community. https://www.drupal.org/about/values-and-principles#choose-to-lead
  • If you or your organization uses Drupal and is looking for a way to give back, this is a small thing that will have a big impact.

First step

Interested? If you have any questions, pop into the Drupal Slack workspace #drupalorg channel and ask away. When you're ready, start with steps 1 and 2 above and start your journey!

Thanks to Donna Bungard (dbungard https://www.drupal.org/u/dbungard), Darren Oh (https://www.drupal.org/u/darren-oh), Jordana Fung ( jordana https://www.drupal.org/u/jordana), kiamlaluno (https://www.drupal.org/u/kiamlaluno), and Mike Anello (ultimike https://www.drupal.org/u/ultimike) for assisting with this blog post. 

Jan 21 2021
Jan 21

Mobile app development is not rocket science in today's day and age. Making a good mobile application, however, is a process that requires a very lengthy pre-planning process. It could be as simple as launching the IDE, putting a few items together, doing a quick round of screening, and uploading it to an App Store, all achieved in half a day's work, to create your mobile application. Or you can render it a deeply engaged process involving comprehensive up-front design, QA testing on a range of platforms, accessibility testing, a complete beta lifecycle, and then various forms of deploying it. Your vision is given form by the direction you chose. With that said, here is a look at the lifecycle of app creation and the priorities and obstacles along the way.

1. The Research

Even if yours is only for getting a mobile app presence, every app development starts with an idea. Refine the concept into an application on a solid basis. Make sure that your initial research covers your buyer persona's real demographics, motivations, activity trends and objectives. Keep the end-user in mind during each point of the process. Now, try to think of the lifecycle of your client, until their features are pinned. They need to be obtained, transformed, maintained and their loyalty nurtured after you meet them. In the end, you can understand how the digital product would be used by the client. Doing this will put you on a solid footing at the very beginning, and your transparency will give you and your investors much-needed confidence.

This phase is critical because you lay down the required groundwork during this phase for what is to come next. Before heading on to the next step, do your bit of intensive studies and strategizing. And evaluating competition is another essential part of this point. A thorough review of the software of your rival can assist you to find out what features are lacking in your software so that you can incorporate it into your app to make it pop out.

2. Wireframing

The next step is for the app to be registered and wireframed. While time is not on your side at this stage, it allows you to uncover usability problems by actually drawing thorough sketches of the envisaged product. Sketching does a great deal more than just tracing the moves. It can be a strong instrument for cooperation and interaction. Wireframing will help refine the concepts when you're finished sketching and organise all elements of the design correctly. In this initial step, you can resolve any technological limitations found in the context of back-end development. Now, try to build a better picture of how a working app can fuse the suggested designs and ideas. To show the relationship across each screen as well as how the users can move through the app, you can also establish a roadmap or a template. Look for ways to integrate the brand, concentrate on the user experience and take into account the variations in how people use a mobile phone app and a mobile browser.

3. Technical Feasibility Assessment

Now though, you may well have a good understanding of the graphics, but you must still take into account if the back-end frameworks would be able to maintain the interface of the app. You need to gain access to public data by accessing open APIs to know if the concept of your application is technologically possible. There will be various specifications for an app, based on its size (smartphone, tablet, wearables, etc.) as well as the system (iOS, Android, etc.). The team will have fresh concepts for the app by the conclusion of this phase or have concluded that some of the preliminary functionality is not feasible. Brainstorm a little at this stage, ask questions, and check the status.

4. Prototype

Build a simple prototype. The keyword here is Rapid. Before and until you contact the Software and see how it functions and flows, you can't fully grasp the touch experience. But, to see if it works with the most popular use case, create a prototype that brings the app idea into the hands of a user as soon as possible. For this step, use rough and not detailed wireframes. If you are bringing stuff in the right direction, this will help you see. Include in this phase the stakeholders, enabling them to access the prototype will offer you their input and apply it in your work. And, also, the prototype will provide the first look at your app to various stakeholders and will help you verify the data you have collected.

5. Design

You can plunge into programming once you get this phase-out of the way. The connection between design elements is architected by your user experience ( UX) designer, while the user interface (UI) designer creates the app's look and feel. With its various review steps, this is a multi-step process. Blueprints and visual direction are what you get, reminding the engineers of the final product envisaged and how interaction can shift, feel and flow. This design process can be done in a single afternoon or can take a team a whole lot of hours, depending on the project scope and app budget. And by playing around with the layout of control, buttons and other graphic cues, remember to make several variations of a computer. The more your product differs, the greater the chances that your UX will be original. Designing applications can prove to be a multi-step process, and the results should be simple visual instructions that provide the final product with an abstraction.

6. Develop

Generally, the production process begins very early on. In reality, a working prototype is created after an idea gets some maturation in the conceptual stage, validating functionality, assumptions, and helping to provide an understanding of the scope of work.

The app goes through a series of phases as the production progresses. The core functionality, while present, is not verified in the initial stage. Seeing that the app is very buggy, there is no non-core functionality at this stage. In the second level, most of the proposed functionality is implemented. Ideally, the software has gone through light testing and bug fixing, but there may still be some problems. In this step, for further testing, the app is released to a certain group of external users. The app will pass to the deployment stage after the bugs in the second stage are patched, where it is ready for release.

Make note of the agile approach if yours is a complicated task where user requirements change frequently. Flexible preparation, progressive growth, early implementation and continuous changes are supported by this. A large framework can be split apart into smaller components, and each of these minor bits can be added to agile methodology.

7. Testing

It's a good way to check early and often in mobile app growth. Doing so will keep your final expenses down. The deeper you go through the growth cycle, the more expensive it becomes to patch bugs. When building the different test cases, relate to the original design and development documents.

Application testing is comprehensive, so ensure all the relevant aspects of it are covered by your team. Usability, functionality, protection, interface tests, stress, and performance should be checked for the application. You explore whether or not your mobile app works with your intended users during user acceptance testing. To test this, provide a few individuals in your target audience with your app and ask specific questions. You know your approach "works" after your application passes the user approval test, and further make your application available for a beta trial, either by the registration of previously established groups or an open request for participants. The reviews you get from beta users will assist you to find out if the features of the app perform well in a real-world situation.

8. Deployment

Your app is ready for submission. Select a day and initiate a formal launch. The rules for the release of an app are appropriate for various application stores. And note, this is not the end. Creation of apps doesn't stop at launch. Input will flood in when the application gets into the hands of consumers, and you will need to integrate the input into future iterations of the software. Updates and new features will be required for any app. Usually, the development cycle starts again as long as the first version of the software is released. To sustain your item, make sure you get the resources. Bear in mind that it is a long-term investment, aside from the money spent in creating a digital product.

The key thing to note is that a constant and continuing phase is the creation of apps. It just doesn't end with the release of the final production, it's just the beginning. More reviews and suggestions will come in as the app gets more users, and you will have to incorporate the requisite improvements in the form of potential app updates. Follow the above steps to make your app hit the pinnacle of success if this is your debut attempt at app growth. The mobile app development process is very intricate. Mobile app development companies and agencies are in great demand because the customer base for it is large. The back end of your mobile app is made by app developers using specialised mobile app development software and tools. Developing the apps we love and spend our days’ scourging is being created with a lot of care by mobile app development companies. Mobile app development companies in India have greatly evolved and are at par with others on a global scale.

Jan 21 2021
Jan 21

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TODAY, Thursday, January 21, at 1pm ET / 10am PT. (Convert to your local time zone.)

No set agenda this month, so we'll have plenty of time to discuss whatever Drupal-related thoughts are on your mind. 

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org and open to everyone.

View notes of previous months' calls.

Jan 21 2021
Jan 21

Problem: The Power (and Pitfall) of Paragraphs

With great content modeling powers comes great responsibility for Drupal developers. 

While building a website, you may face the challenge of creating multiple paragraphs without much reuse. This can contribute to a poor content architecture that will burden you for the lifetime of your application. This issue can come about when a developer is building out paragraphs and decides to generate multiple paragraphs with similar fields or new fields that perform the same functionality as other fields. 

For example, let’s say a developer is tasked with building a normal Text Paragraph which is just one textarea field, which is simple enough. Now, let’s say a client comes to that developer and ask if the Text Paragraph could have a header field, and a subheader field. Usually, a developer might decide to just create a new paragraph, maybe call it a Card Paragraph, that has a new header field, subheader field, and a new body field. Well, what if you could just reuse the body field from the Text Paragraph? There is a way to do that by using Form Displays and the default Paragraphs reference field widget. Of course, the example above is simple, but there might be better cases which will be explained below.

Solution: Reuse Paragraphs and Form Displays

Mediacurrent’s Rain CMS  is an open source project that comes bundled with ready-to-use content types and paragraphs. One of those is the Card paragraph. The Card paragraph by itself might just have a title, media, body, and layout field. This is pretty useful as its own componentized item that can be reused on other components. Now let’s say you have another paragraph that is called a Breaker, which essentially is almost like a Card Paragraph but might have some variation. This Breaker paragraph might reuse the same title, body, but also has an extra field called right body for any text that might need to be put on the right column.

The way one can keep reusing the Card paragraphs, with other paragraphs that get created in the future is to add more fields onto the Card paragraph itself.

Drupal manage fields tab

As displayed above we have a ton of fields added on to the Card Paragraph. One might say that why are you doing this, wouldn’t all these fields get displayed on the frontend. Technically yes at first, but there is a way to limit what fields get displayed on the Card paragraph itself and then a step on getting the Breaker paragraph to utilize the same fields coming from the Card paragraph.

This method is using what’s called view modes in the Form Display configuration. What you want to do is go into Managed Form Display in the CMS for the Card paragraph that you just created and take a look at what displays are available.

Drupal backend - manage form display

As you can see above we already have some displays created in the Rain distribution we are using. We have the Default, Breaker, Carousel, Column, Card Compound, and Overlay Breaker. These are all Form Display’s which are used for other Paragraph variations. 

custom form display

Creating a new display is easy; you want to go to the bottom under the Default view mode and hit Custom Display Settings, which should drop down the above selection. As displayed in the screenshot there are some that are enabled and disabled. You can create a new one by clicking Managed form modes.

Now that we sidetracked a bit and explained how view modes work and how they are created, let's dive back in and talk about how you can now create this Card variation paragraph which is called the Breaker. Since we have a display already enabled for the Breaker what you want to do is click on the Breaker and see what fields are enabled by default.

Drupal manage form display

Shown above this has the title, body, and the new body right field which is technically still part of the Card Paragraph, but just using a different form display. If you compare this display with the default display you can see that different fields are enabled and disabled, which allows for flexibility for reusability. Now that we see that the fields needed for the Breaker have been created or enabled, let’s go create the Breaker paragraph.

create breaker paragraph

We then add a description and say that this is a breaker that will have content with two columns. If you remember above we have a body field and a body right, this is used to create these two columns.

When creating your Breaker paragraph make sure to add all the fields that are unique to this breaker like Line Break, and Show Two Columns which have specific functionality for the Breaker, but you also want to create a Paragraph reference field called Card which will allow you to reference a Card.

So how do you get it so this Card field shows the fields that you want from the Card Paragraph? Well, that’s why we worked on using the view mode on the Form Display for the Card Paragraph. What you want to do is the following.

Drupal manage form display card

Under the Breaker paragraph go to the Managed Form Display. Then under the Card field, you can use any widget that has the Form Display mode available. This will allow you to use the Form Display mode option in the widget to target the right display mode you want to use from the Card. Select the Breaker display mode.

select breaker display mode

Once this is done, hit save.  Now what you should expect is that whenever you go to create a breaker and you use the card field it should show the fields that are specified on the Card Breaker view mode.

card breaker

Building Paragraphs the Smart Way 

Now whenever you as a developer get tasked with building out a paragraph, make sure to ask yourself: What can I do to reuse fields and displays as much as possible? I hope this guide will help you to make smart decisions for a better content architecture going forward.

Jan 21 2021
Jan 21

It's essential that companies have a presence online in the digitalised global economy. Enterprise web development is thus, naturally, an important opportunity for a company to achieve online exposure and enter a broader audience. Web creation for business is essentially the method of creating a company-level website.
Enterprises run the gamut from mid-sized to large-scale enterprises and institutions (governmental, for-profit or non-profit) to organizations and collectives (healthcare, education, philanthropy, or any other group with a common purpose or similar goals).

Developing a company website requires a huge joint project with a web development firm, as the design of an organization website is extremely complicated. In this blog, we'll address what web commerce is, what it does and, most significantly, what it can do for your company.

Significance of Enterprise Web Development

Web creation provides a global platform essential for communicating the business model of a company to specific customers. Business websites are an excellent channel for the promotion of products, services and even ideas.

In addition, with a growing amount of business being done online, it is safe to assume that in the coming years a company without a high-quality website will find it extremely difficult to maintain itself.

A website is the initial point of interaction with prospective clients in the modern age, and having a beautifully crafted website can help to improve the brand and increasing customer retention. mid-to client website goes beyond advertising and helps companies to conduct a significant portion of online operations effortlessly.

They vary from receiving and executing requests to supplying consultancy services and responding to inquiries, to offering information via blog posts or video clips.

Because of advancements in web technology and increasing value of enterprise web development, websites and web applications are predicted to become more creative and offer companies and customers several more advantages.

Read more to understand how web development for enterprises will increase your business opportunities.

How Does an Enterprise Website differ?

Since the best enterprise website designs are usually designed for mid-to large-scale enterprises, it demands several more features and resources to address different needs than a standard website. This also varies in the kind of content management system employed.

The Enterprise Content Management (ECM) program used by business websites requires many tools, modules and functions that satisfy the plethora of detailed criteria of different stakeholders (customers, investors, partners, suppliers, and others).

An enterprise website also includes resources and approaches for branding, content creation and marketing approaches such as SEO and keyword rankings, inventory management, code incorporation and much more.

While the structure and efficiency of enterprise websites rely on the purview of a business, business websites are generally needed to accommodate increasing traffic, rapid surges in demand and need to be flexible to expanding operations in the long - term.

Scalability is also an essential factor as a website should be able to accommodate potential development without impacting the pace of the site and the user experience. Overall, a company website is considerably more sophisticated and comprehensive to meet the capability and a wide range of features needed for a business.

Therefore, enterprise website management is significantly unique and requires careful preparation. Enterprise web development involves resources which involve, but are not restricted to, UI and UX design technique, database building, content management system, website maintenance, customisation, brand assessment, and analytics configuration.

Bearing in mind the diverse problems and requirements of an enterprise website, it is important to cautiously choose a web development agency that can handle these nuances. In reality, it is strongly advised that you look for an agency that can modify the website of your organization after having considered its priorities, scale, long-term goals, vision, mission and value proposition for the business.

Some of the best enterprise web development tools are;


Chrome DevTools









Visual Studio Code

Sublime Text


1) Angular.JS

AngularJS can help you expand your vocabulary to HTML. HTML is fine for static documents but dynamic displays won't work. AngularJS can provide you with an environment that can be descriptive, readable, and rapid to create. It provides the toolset that will help you to construct the framework for developing your application.

This entirely extendable toolset is capable of interacting with other libraries. It offers the ability to modify or remove the features according to your production workflow.

2) Chrome DevTools

Chrome gives Web developers a selection of tools. Such tools are built into Google Chrome. This has the features of displaying and modifying the DOM and layout of a Tab. With Chrome DevTools, you can display notifications, run & debug JavaScript in the browser, edit on-the-fly pages, easily diagnose the problem and improve the pace of the website.

3) Sass

Sass is the most sophisticated and functional CSS-extension language. It will allow the use of variables, nested rules, mixing and functions. Sass will enable you to share the concept around and inside projects.

4) Grunt

Grunt is a JavaScript function runner, perfect for automation purposes. It will perform most of the routine work including mining, compiling, checking units, etc...

5) CodePen

CodePen is an online platform with the features and functions for front end design and distribution. You can use CodePen to build the whole project as it contains all of the IDE features in your browser.

6) TypeScript

The language of open-source coding is a typed JavaScript superset. For plain JavaScript, it will generate the code. It supports every client, host, and operating system. You can use the current JavaScript code and call JavaScript to the TypeScript code.

7) GitHub

GitHub is a Website for Software Development. It will assist in running the programs. GitHub will allow you to build a review system and incorporate it into the workflow for your application. This can be integrated into the software that you already use. It can be deployed as a self-hosting or cloud-hosting solution.

8) NPM

Using critical JavaScript software, Npm can help you create stunning stuff. This has Group Leadership functionalities. No configuration will be needed. It offers auditing security mechanisms.

It offers security expertise, de-duplicated growth, intrusion detection and unrivalled assistance for enterprise-grade solutions.

9) JQuery

This JavaScript library is designed to allow traversal and manipulation of HTML DOM tree simplified. This also allows for handling and animation of events. It is loaded with features.

10) Bootstrap

Bootstrap is the toolkit that allows you to create with HTML, CSS, and Javascript. Bootstrap is used to build mobile-first sensitive projects over the internet. This library of front end components is an open-source toolkit.

11) Visual Studio Code

 Visual Studio Code can run anywhere. It has IntelliSense technology, Debugging, Built-in Git, and plugins to include languages, templates, debuggers, and more. It supports systems running Windows, Mac and Linux.

12) Sublime Text

Sublime Text is a scripting language that is suitable for javascript, markup, and prose. It supports divided editing mode. You'll be able to modify files side by side with the aid of this feature. This may be accessing the same file at two different places.

This offers even more features such as customizing something and fast project move. Sublime Text allows Platforms for Windows, Mac and Linux to run.

13) Sketch

Sketch offers a smart interface to help you build flexible, reusable components that can be resized to suit the entire content. It comes with hundreds of plugins. It supports Mac OS and can be used to build animations on timelines.

7 Website Features That Help Businesses Grow:

Well-designed configuration of the site

Navigating should be simple and encourage visitors to find what they are searching for at a cursory look.

Efficient development and engineering

A growing number of visits to the site use portable devices such as mobile phones or tablets to search online. A customized web design that adapts to the user experience by changing the layout accordingly, such as the screen size, interface and rotation.

A website that appears appealing, whether accessed from a mobile phone or desktop and easily loads to all platforms (because mobile devices usually have lower internet speeds than desktop computers), would appeal to all consumers.

What Can Business Do For You

Defines explicitly what the business model of the company is and how it will benefit you.

Lead Generation and Participation

Create marketing leads from clients, inquiry forms and methods, and techniques specific to your company.

Notifiable material

Publish material not only promoting the goods but also offering information that targeted customers are looking for.


Including simple calls-to-action is a successful approach to enable clients to start a conversation. One of the best ways to increase the conversion level is to make it simple for customers to reach you or buy your product or service via direct calls-to-action.

Analysis and Tracking

This is important so that companies can evaluate data such as demographics, customer behaviour, purchasing habits, marketing and promotional campaign efficiency and other criteria.

Web-Based Enterprise Applications

Web-based corporate software, including client websites, are valuable business tools. A web-based business app is a program developed for mid-to large-scale organizations and that can be launched on the Web or intranet.

Apps are designed for various purposes, whether for internal or external uses. As an example, an organization may need a shared app of internal needs, such as communicating and exchanging project documents and information with staff located at various locations. Or a company can create an app for outside investors such as basic order placement and delivery program.

Or it may include an app for internal and external participants to collaborate on projects and participate in platform discussions from different places.

In addition, the software must communicate with existing systems, databases, and other technical entities for consistent access and smooth knowledge transfer. Since apps frequently contain and handle sensitive customer information, strict security procedures are also required to secure data, business information and operations.

Working with a skilled customized software company is the best way to develop web-based business apps.

Advantages of Web-Based Enterprise Apps


Staff members can access and send business details, wherever they are, making it much easier for employees who drive to or work from home to work with unlimited accessibility and even take care of the crucial business in order to guarantee accuracy and consistency.


Far more corporations are trying to make the most out of their online network to advertise and sell their products and services, and also to manage online transactions and processes. Companies creating technology applications to achieve corporate website development goals gain competitive advantage.


The interface and integration of an app with other devices and resources promote consistency which in effect allows for high compatibility between different platforms, systems and devices.

Installation, deployment, and maintenance are fast and cost-effective

Web applications can be built in a single operating system, resulting in cost-efficiency. They're all located in a single server from where they're open to all users. They can also be managed and modified from a central site that is open to users universally over the network.

Data Security

Since web applications are built and stored on stable, dedicated servers managed by security specialists, all company and customer information is stored securely.

Demand for customized web apps is only anticipated to increase in the future as more organizations continue to realize the advantages of a custom-designed app designed to match their processes and goals.

Emerging Web Development Trends

With recent advancements in web technology and the increasing requirement for enterprise web creation, websites and applications are anticipated to become more innovative and nuanced in terms of its functions, usability and presentation.

Emerging trends in web growth, such as Accelerated Mobile Pages (AMP) and Progressive Web Application (PWA), would concentrate on delivering a more engaging user interface, great potential for SEO rankings, improved safety, higher load speeds and increased traffic. Such developments will certainly boost market opportunities by enhancing new acquisitions and operations of customers.

The web development field is set to expand in the years ahead and provide an increasingly attractive and exciting digital space.

Jan 21 2021
Jan 21

Jamstack & Drupal, match made in heaven?

Developers, in our survey but also at DrupalCon, have put a huge focus on the integration between the new JAMstack world (Javascript, APIs & Markup) and Drupal itself. Drupal allows to push results directly to the browser. More and more we also see that components, built in React, Vue.js, Ember or Angular are taking over some of the responsibility here. To such an extent even that the Drupal core team has decided to build a react component for the menu in Drupal. In addition, concepts such as keeping Drupal 7, 8 and 9 up to date have also been discussed on several occasions with even the outlook of automatic updates being hugely beneficial!

Data is the new gold

Some developers are convinced that data is the new gold and this of course raises the concept of data ownership and the fear of being dependent on external vendors. There were a number of discussions at DrupalCon about how Drupal can deal with this and what standard privacy protection measures Drupal could take with new installations.

Rising star: DXP

What did come as a big surprise is that developers are not yet completely familiar with the concept of DXP. More than half of our surveyed developers said they had never heard of it. At Dropsolid, Drupal is a permanent pillar of content management in our DXP projects, and it has become our mission to put DXPs on the map!

Opportunities for Drupal developers in the future

From our research, the many conversations and responses to our sessions at DrupalCon, we noted that developers in general are less involved in the end-user experience and customer journeys of (potential) customers. They have a limited view on the different platforms a brand uses to connect with its customers and how exactly that happens. Not necessarily a problem? But also not that unimportant! Keeping the end goal in mind is important for every position in a company. The communication between the different departments runs smoother when this is clear to everyone, the noses are in the same direction and everyone speaks the same language. Just think of the gap between business and development: how do you get a concept really sharp without all departments having a clear view of the core objective?

It could be the perfect time, for you as a Drupal developer, to expand your horizon. If you, as a developer, have an overview of the end user's goal, show a healthy interest in the optimal customer experience for your client and understand the needs of this new market? Then you are already one giant step ahead. It’s precisely these profiles that fill the gaps in the current market and make big career opportunities possible.

3 things business owners can learn from this 

  1. A good connection between the different departments, in particular business and IT, is priceless and an absolute must for every company.
  2. The balance between customer experience and operational excellence has to be in harmony.
  3. A lot of agency owners are worried about the previously listed roadblocks, and yet there is an obvious solution that is emerging: a Digital Experience Platform (DXP).
Jan 21 2021
Jan 21

The dilemma of choosing the more suitable CMS from a range of possible CMS options can be overwhelming.' is a major question that comes to mind when thinking forward towards development.

Now, that alone relies on the requirements that you will come up with. For a blog-related website, WordPress might be one's choice. Similarly, for a website catering to e-commerce, Magento might be one's preference. The question arises why should Drupal be chosen over existing options. Why is Drupal the best CMS? Safety, 3rd party implementations, support networks, comprehensive, SEO friendly, open-source tools, support for Free Module / Plugin, etc. are the  contributing factors. If you have a query as to “Should I use Drupal?” These are some of the features that should help you make an informed decision.

Drupal Migration Services are also available and it is the simplest approach via which you can relocate your existing website to Drupal. The complexity of the database structure does not matter.

Some advantages that come with choosing Drupal are:

1. Community

The open-source structure of Drupal promotes consistent collaboration and development through the Drupal community's support and enthusiasm. Today, in 230 countries, there are over 1.4 million Drupal users who are committed to pushing Drupal towards success. The opportunity to generate extraordinary digital experiences extends far beyond what a single team of patented software developers could conceive of, with a pool of such varied experts working constantly to make Drupal better.

2. User Experience 

The new Drupal is a revolutionary digital platform that can be leveraged by developers and marketers to generate memorable customer experiences. The latest editions of Drupal have prioritized user experience (UX) to encourage everyone to strengthen existing customer experiences, from site editors to content creators. Some of Drupal's user interface improvements include:

Layout Builder - Provides an easy-to-use page building experience for content authors that allows editors to control the get-up of their content without relying on a developer.

The administrative theme of Claro provides a cleaner, easier-to-use site management, configuration, and authorship interface.

Mobile sensitive web features- out-of-the-box delivery of mobile-friendly themes, sensitive images, and mobile management.

3. Scalability

Drupal is an effective and future-ready CMS that gives companies the freedom to adapt to their needs. The versatile API architecture of Drupal facilitates the development of exponential content across a worldwide multi-site ecosystem. Drupal is optimized for many caching circuits that facilitate faster page loading, optimized bandwidth, and stronger web performance overall, even under high-pressure conditions. 

4. Security

Safety is the primary concern when it comes to creating digital experiences that people trust. Not conforming to digital security norms can both harm consumer relationships and cause companies to suffer heavy legal fees for heavily regulated and public-facing sectors such as government and healthcare. Security is taken more seriously by Drupal than any other CMS. That's why organizations such as Georgia State, Steward Health Care, and Fannie Mae depend on Drupal to safeguard their websites and hold their audiences' trust.

5. Accessibility

An inclusive web environment for all users is prioritized by Drupal's determination to accessibility standards. For any specific component and function added to the core, availability is a gateway requirement.

Drupal guarantees that all of its features and functionality comply with the out-of-the-box WCAG, WAI-ARIA, and ADA standards of the World Wide Web Consortium. Some of the characteristics of usability included in Drupal 8 and the Drupal 9 entail:

Color Contrast Themes and text size optimization 

Defaults of Alt Tag

Control Tab Order  

Mobile Responsivity

Aural Alerts For sectors, such as tertiary education, with the responsibility of providing learners from a variety of backgrounds with opportunities and knowledge, accessibility is a major issue. At present, over 70% of educational institutions including renowned institutions such as North Dakota State University, have opted for Drupal as their CMS of choice. Drupal stays true to providing everyone, regardless of their circumstances, accessible information, and positive digital experiences.

Some of the widely asked questions when it comes to Drupal is, Why is Drupal better than WordPress? What are the benefits of Drupal over WordPress? Which is the best, Drupal or WordPress? So, let's take a deep plunge and compare them one by one according to scenarios.

Drupal vs WordPress

There is no denying about the intricacy of Drupal in contrast to WordPress, but no one can refuse that Drupal offers advanced features. The interface of Drupal is much wider than that of WordPress and it mainly uses types of content, views, categorizations, etc. So, if the requirement in that situation is for multiple templates, Drupal is rated higher than WordPress.


Drupal is more versatile than WordPress as it is engineered by developers for custom software development.

Everything is freely accessible as modules in terms of capability and you can customize everything in Drupal with the assistance of a developer. In WordPress, plugins are obtainable in paid versions. WordPress is intended to be a blogging platform. So, to manage a large amount of content and consumers, it has limited functionality and is Drupal's backbone for handling thousands of data and customers at the same time.


Security is the primary concern for every customer who invests in building a website, and if their website is hacked, then everyone involved in the project will suffer a major loss. Drupal has enterprise-level security due to the large open-source community, which offers comprehensive security reports. The website of Whitehouse.gov or U.S. Govt is on Drupal, which demonstrates the trust in Drupal at the level of security.

In conclusion, you must first recognize the requirements of the customer and analyze them to choose which best fits your requirements. With the service component of Drupal 9 out now, developers have a complete object oriented structure for building websites, portals, e-commerce solutions, etc. Also, the answer to the question, “Is Drupal hard to use?” is NO. It is made for the ease of users and allowing yourself to be immersed in the experience is the surest way to make the best use of it.

Jan 21 2021
Jan 21

In the era of increasingly distributed architecture of applications and web portals, there is a need to provide flexible methods of authentication while maintaining convenience for the user. From this article, you will learn how to easily create an authentication server and client application in Drupal using OAuth2 and OpenID Connect.

Distributed systems, their scaling and maintenance is a problem for many clients who come to our company to take advantage of the Drupal consulting services. Very often, there is a need to implement a central login system for all platforms belonging to a wider federation of websites. Large companies and organisations have separate portals – we have created image-building websites, intranet systems and Drupal Commerce services for them many times, taking into account various functions. The need to register a separate account and log in by users in every single place separately seems to be an archaic way of dealing with the problem. After all, who among us does not make it easier for themselves to register on websites on a daily basis – for example by employing quick registration methods using an account on a social network or a Google profile?

Why not do the same, especially since – as it will turn out in a moment – using Drupal for this is very easy.

OAuth2 and OpenID Connect

In order to shed some light on the whole problem, one should, first of all, focus on the commonly used standards in web applications that are used in the authentication process.

The first is OAuth2, an open standard for authorisation that does not require sharing authenticators between applications. Access to resources (if it has been granted) is being verified on the basis of a token issued to client applications by the authorisation server.

As OAuth2 was designed with authorisation in mind, that is – with granting specific access to given resources; it is not really directly intended for a standard user authentication (logging-in) process. For this purpose, it was decided to propose an additional (authentication) layer to the OAuth2 protocol, which standardises this exact process in it. This technology is called OpenID Connect and – apart from the logging-in process – it also unifies the method of exchanging user profile data between applications. We will, therefore, take a look at how to employ both technologies in practice.

Installation of the modules

If you want to set up both the OAuth2-based authentication server and the client applications based on OpenID Connect, in Drupal, you can basically use ready-made solutions. In the case of a server, you have several appropriate modules, including the most popular one (simple_oauth). In our example, we will use the OAuth2 Server module. It is slightly less popular and has not yet been released as a stable version for Drupal 8 and 9, but it is supported by significant companies and organisations related to Drupal.

Additionally, the second client application module, OpenID Connect, is a project being maintained and developed by exactly the same organisations and development team. You can, therefore, be sure that both projects will be developed simultaneously and that no problems with their compatibility will arise at a later time.

The modules' installation is standard. First, you need to download and install the modules on our server:

composer require drupal/oauth2_server
drush en oauth2_server -y && drush cr

Then, in a similar way – for the client:

composer require drupal/openid_connect
drush en openid_connect -y && drush cr

The main dependency needed to install the server is the oauth2-server-php library which provides the basic mechanisms to fulfil this role. If you are using Composer in PHP, all dependencies are already terminated automatically for you.

Server setup

The setup of the OAuth2 Server module is mostly based on entities. Therefore, among the things it provides are the entity of the server, client, token, etc. Our setup must begin with defining the server. So, we go to the setup page /admin/structure/oauth2-servers.


And add a new server (Add Server). In the next step, we see the server entity form:


In the simplest configuration variant, we leave all the values selected by default and filled out. In addition, we check the "Use OpenID Connect" option as the default layer used in the logging-in process.

As you can see from the settings, the authentication and authorisation process takes place without the use of the authentication data sent by the client, but on the basis of an authorisation code – exchanged then for the access token and the refresh token, which are exchanged during the communication between the applications. The technical details of the OAuth2 protocol go beyond the scope of this article, so if you want to know more about how the individual options and the protocol itself work, you can do so using the official documentation.

In the next step, we should define the clients that can connect to our server. We must, however, have at least one client application in order to do this.

Client setup

OpenID Connect is a very user-friendly module also in terms of setup. To configure the clients you want to use, go to /admin/config/services/openid-connect.


As you can see, there is a list of clients in the form. The module, therefore, allows you to easily login using, e.g., well-known social networks. Each type of client is defined as a separate plugin (OpenIDConnectClient), which makes it easy to extend the project with completely new clients. Our example, however, is about connecting to our own server, so we will use the client for generic uses (Generic).

The configuration is quite simple because it consists of defining the client's name and the so-called secret key, as well as providing the server addresses:


While we are at it, we will add a small improvement, namely – replace the logging-in form with a login button using our authorisation server. It is very simple and accessible from the setup form:


Great! The client looks ready to use. The only drawback is the lack of a convenient option of changing the name from "Generic" at the moment without a bit of coding, but the result still looks great for such a quick setup:


Server setup part two

We have a pre-configured server, as well as a ready client. So, let us define our client in the server setup so that it knows it can connect to it and request access to its resources. Drupal is a very secure CMS compared to the competition, but the security is also based on its correct setup.

Always remember that it is up to you to verify and configure what client applications should be able to connect to the server and use its resources.

In order to add new clients, go to the Clients tab, and then click the button for adding new clients.


You should see a form, the data of which should be filled out in the same way as what you set up in the OpenID Connect module in the client application.


We save the form, and it is ready... almost. You still have to grant the appropriate permission, so that it would be possible to use the OAuth2 server at all. In order to do this, go to the /admin/people/permissions page and assign the Use OAuth2 Server permission for the anonymous user.



All is set. So, let us check the actual logging-in scenario. First, we will register the test user on our server so that they can log in into our other applications.


Go to the client's application (login form) and click the Log in with Generic button (form screenshot).

You are redirected to the server login page on the server along with the destination parameter destination


After correctly entering the login and the password (test:test), you should see this additional step ...

the form

...in which you decide as a logging-in user whether you actually want to authorise our client page to your user data from the server, on the basis of which a local user account will be created.

After approving it, you are redirected to the client application page as a logged-in user:


Success! We can now fully enjoy our central login system.


The possibility of creating a central login system is a more and more frequently occurring need among the clients who have various types of distributed services, sites, and applications. By choosing Drupal, you can focus on implementing specific business rules, instead of reinventing the wheel. Using the ready-made solutions, such as OAuth2 Server or OpenIDConnect, supported by well-known organisations, gives you the certainty that you will easily implement the mechanism you need – even without the need for detailed knowledge of the protocols used in them.

In our Drupal agency, we always use the already available solutions which we often extend, and we adapt Drupal modules to the specific business model. I hope that the above article and the modules used will also prove useful in your project.

Jan 21 2021
Jan 21

Accessibility design

The mission of accessibility design - to make digital work easier for people with disabilities and everyone who works with it, and grow the target audience this way. Voice assistant, subtitles, large fonts - for any content, you need to think about the user scenario of the user with a disability. 

If you are new to web design accessibility, please also have a look at our article, what it is, and why it matters.

Dark mode

This mode has become standard for sites and applications, and in terms of accessibility, this is one of the necessary functions.


The devil's always in the details. The slightest movement leads to some result and application’s or website’s response. For example, I press a button - it shows the download. Awwwards has a great collection of games and websites with micro-interactions that kill boredom and improve the user experience.

Instead of a conclusion

Sasha Lopatyuk, art director of IDT Corp:

"It seems to me that trends are shaped by trendsetters, technology, and culture. And here, we must understand that when we say - "influence" we are talking about the influence of somethings on designers and not on society as a whole. So, the basic user may not be interested in the cyberpunk theme, but its abundance over the Internet can push a designer to create the Tesla Cybertruck."

Maxim Desiatykh, member of the board of directors of Redmadrobot:

"Product design is now at the peak of popularity and demand. Companies and individual entrepreneurs create or try to create new digital products and services. It is a mass effect, like startups in garages at one time. And all design trends will come from this market trend.

With a lot of this kind of work today, demand for the product designers exceeds supply. For a business, if a designer owns tools, this is already a sign of a person who can do something and is ready to work in a team. Business is more interested in creating something in general and less interested in some visualization tricks. All products and interfaces are focusing on the business and metrics now, rather than on the design trends. It is the distinctive feature of the product design."

Do you want to make a trendy website already? Don't be shy - contact us!

Jan 21 2021
Jan 21

PHPStorm comes with a handy feature called live templates, which helps you avoid repetitive typing.

Let’s say that you are writing SASS and you find yourself repeating a breakpoint over and over:

@include breakpoint($breakpoint-md) {
    // Some CSS attributes.

With live templates, you can instead type a shortcode that will generate the breakpoint for you. In this example we'll be using ibk as an abbreviation for include breakpoint and we will generate another variant that includes the $breakpoint-md as an argument passed to the mixin.

ibk will generate @include breakpoint() with no arguments predefined and position the cursor inside the mixin parameter. ibk:md will generate @include breakpoint($breakpoint-md)

To begin setting up a Live Template, go to File -> Settings -> Editor -> Live Templates

You’ll see the following window with some live templates already available, depending on which plugins you have installed. For this example we will generate a new “Template group” by clicking on the “+” icon:

Live Template configuration interface

PHPStorm is going to prompt for a name for the new group. In this example, we will name the group SASS.

Once you have the SASS template group created, you need to click on the “+” icon again and add the actual live template.

You can now add the abbreviation ibk, a short description, and the code.

The cursor will be positioned on $breakpoint$ first and then to $END$.

Define the language as CSS, check the box “Reformat code according to style”, hit “Apply” and “OK” to close the dialog box. The result should look something like this:

Live Template configuration interface

The following shows the Live Template in action:

Live Template in use

If you want to save more time, you can avoid typing the breakpoint variable as well, with a variant of the breakpoint Live Template you’ve created.

Live Template creation interface

With this variation, you eliminate the need to explicitly typing $breakpoint-md as an argument for the mixin. See the Live Template in action below:

Live Template in use

Wrapping a Selection with Live Templates

If you need to wrap a selection in a breakpoint, you can add a new parameter $SELECTION$ to a live template:

Important: You need to use the keyword $SELECTION$ for this to work.

After editing ibk:md the code should now look like this:

@include breakpoint($breakpoint-md) {

You can achieve the following by selecting the code you want to wrap and using the keyboard shortcut Control + Alt + J.

Live Template in use

Live Templates are great for increasing development speed and productivity whenever you must repeat code. Reach out to us at @ChromaticHQ on Twitter and let us know how you have used them and how they have helped improve your development process.

Jan 20 2021
Jan 20

The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal. For more information please see:

Exploits may be possible if Drupal is configured to allow .tar, .tar.gz, .bz2, or .tlz file uploads and processes them.

Jan 20 2021
Jan 20

People today do not like to be confined, if I talk about development teams, they would hold up flags stating the same. Since development and innovation go hand in hand and constraint is the biggest enemy of innovation, you can’t tell me they are wrong to have that notion. 

Talking specifically about web developments, there are a lot of areas to explore and a lot of technologies to help you do that. So, why limit yourself, when you don't have to? Drupal has brought such an impressive trend forward that has simply satiated the developer’s desire for innovation and that is the headless approach

Unlike before, when your entire project had to be nestled inside one CMS, Drupal now gives you the opportunity to explore new technologies to your heart’s desire. This is possible because the presentation layer and the backend content become two separate entities. Drupal acts as the content repository and a frontend technology of your liking takes care of, of course, the frontend part of website architecture.

To provide a connection between the separated development aspects of the project, enters the API. An API layer is a necessity when going headless, because it transmits all the information from the front to the backend and vice-versa. 

And the three available APIs in Drupal, REST, JSON and GraphQL, are the reason behind me writing this blog. Although the purpose of all three is the same, they are quite different from one another. Today, we would be highlighting their meanings, their pros and cons and all the visible distinctions they have. So, let’s begin. 

Decoding the APIs 

The logos of GraphQL, JSON and REST are displayed horizontally.

REST, JSON and GraphQL bring in a similar outcome when they are used for decoupling Drupal. Yes, they are different too. And we would get into the difference between REST, JSON and GraphQL soon. Before that it is essential to understand their history, origin and what they were intended for because the differences actually start from there. 


REST was developed by Roy Fielding in the year 2000, the purpose behind its development was to provide a software architectural design for APIs. In simple terms, it provided an easy path for one computer to interact with another by utilising an HTTP protocol. The communication between the two computers is not stored on the server, meaning it is stateless; rather the client sessions are stored on a client-side server. 

There are six constraints necessary to implement REST in the complete sense. 

  • It needs a separated client and server; 
  • It needs to be able to make independent calls;
  • It needs to able to store cacheable data;
  • It needs to have a uniform interface;
  • It is a layered system; 
  • Finally, it needs a code-on-demand. 

REST offers a great deal of functionality without a lot of effort. For instance, if you are working on someone else’s RESTful API, you would not need a special library or special initialisation. Yes, your developers need to design their own data model using REST, but the HTTP conventions at play make programming a breeze. 

To know how REST plays a key role in decoupling Drupal, read our blog REST APIs in Drupal.


JSON stands for JavaScript Object Notation. Built in May of 2013, it was designed as an encoding scheme, eliminating the need for ad-hoc code for every application to communicate with servers, which use a defined way for the same. JSON: API, like the name says, is a specification for building APIs using JSON. 

With JSON: API, communication between the server and the client becomes extremely convenient. It not only formats the way a request should be written, but the responses also come in a formatted manner. The primary aim of JSON: API is to lessen the number of requests and shrink the size of the package, all using HTTP protocol. 

Broadly stated; 

  • JSON reduces the number of requests and amount of data being transmitted; 
  • It requires zero configuration; 
  • It uses the same JSON access scheme for every piece of data, making caching very effective;
  • It offers quite a few features and gives you, as the client, the opportunity to turn them on or off. 

To know how JSON:API plays a key role in decoupling Drupal, read our blog, JSON API in Drupal.


While JSON can work alongside REST, GraphQL was designed as an alternate to it and some of its inconveniences. Built in 2012 by Facebook, it acts as a cross-platform data query and manipulation language. Its servers are available in numerous popular languages, being Java, JavaScript, Ruby, Python, C#, amongst others. 

The features of GraphQL are that; 

  • It allows users to request data from multiple resources in a single request.
  • It can be used to make ad-hoc queries to one endpoint and access all the needed data.
  • It gives the client the opportunity to specify the exact type of data needed from the server. 
  • All of these add to its predictable data structure, making it readable as well as efficient. 

It was in 2015, after GraphQL was open-sourced that it became truly popular. Now its development is governed by The GraphQL Foundation, which is hosted by the Linux Foundation. 

To know how GraphQL plays a key role in decoupling Drupal, read our blog, GraphQL in Drupal.

Now that we know the basics of all the three APIs, let us have a look at their popularity status, before beginning the comparison. 

A bar graph shows the standing of different web services against each other.A glimpse at the popularity of the three APIs. Source: State of API Report 2020

REST vs JSON vs GraphQL 

Now let’s get down to the details and understand why choosing one over the other two could be in your best interest. Let’s start with the differences between REST, JSON:API and GraphQL.

How efficient is the data retrieval?

A distinction is shown between the three APIs, REST, JSON and GraphQL, in three circles with regards to data retrieval..

One of the most important aspects for an API is the way its fetches data. It could require one or more requests. Therefore, this aspect is also referred to as its request efficiency. Getting multiple data responses in a single request has to be an ideal, so let’s see how REST, JSON: API and GraphQL here. 


The REST API is innately built to capitalise one resource per request. This works perfectly as long as you only need to retrieve a single piece of data like an article. However, if you need more than that, the number of requests you would have to type in separately would be equivalent to the amount of data you need. 

One article = one request 
Two articles = two requests
Two articles and the author information stored in a different field = Two requests for the articles + a long wait for the completion of those requests + two additional requests for the author information. 

This sums up REST’s request efficiency to the T. You require to be equipped to handle a number of requests, which can ultimately stall your user experience, making it seem to go at a snail’s pace. No sugar-coating here, there are going to be a lot of round trips. 

And the problem with a lot of round trips is a lot of extra information you do not even need. This is because there is a possibility that a REST API endpoint might not have the required data for an application. As a result, the said application will not get everything it needs in a single trip, making multiple trips the only option. It's safe to say that REST over-fetches and the verbose responses can be a problem.


JSON: API does not suffer from the multiple request conundrum. One single request can give you everything you want, be it one article, two or ten along with the author’s information, I kid you not. 

This is possible because JSON: API implements a concept called ‘sparse fields.’ What this does is list the desired resource fields together for easy fetching. You can have as many fields as possible. If you feel the fields are too long and would not be cacheable, you can simply omit a few sparse fieldsets to cache the request. 

Another thing to remember is that the servers can choose sensible defaults, so your developers would need to be a little diligent to avoid over-fetching. 


Coming to GraphQL, it was also designed in a similar fashion to JSON: API and is competent enough to eliminate the problem of over-fetching and avoid sending multiple requests. 

GraphQL has its own queries, schema and resolvers that aid the developers in creating API calls with particular data requirements in mind. Moreover, by mandating clear-cut additions to every resource field in every query and ensuring the developers cannot skip any of it,  it is able to avoid multiple round trips. Thereby, making over-fetching information a thing of the past. 

The only problem here can be that the queries may become too large, and consequently, cannot be cached. 

How is the code executed?

The distinction between REST and GraphQL is shown with regards to code execution.

Using an API for calls involves the execution of a code on the server. This code helps in computing, calling another API or loading data from a database. All three of the APIs use a code, however, the code is implemented varies a little.


Route handlers are utilised for execution upon a REST call. These are basically functions for specific URLs. 

  • First the server receives the call and retrieves the URL path and GET; 
  • Then the functions are noted and the servers begins finding the same by matching GET and the path; 
  • After that the result is generated, since the server would have executed the function; 
  • In the final step, once the result is serialised by the API library, it is ready for the client to see. 


GraphQL operates in a relatively similar manner. The only difference is that it uses functions for a field within a type, like a Query type, instead of using functions for specific URLs.  

Route handlers are replaced by resolvers in GraphQL, they are still functions though.

  • After the call is made and the server has received a request, the GraphQL query is retrieved. 
  • The query is then examined and the resolver is called upon for every field. 
  • Finally, the result is added to the response by the GraphQL library and it is ready for the client to see. 

It should be noted that GraphQL offers much more flexibility as multiple fields can be requested in one request, and the same field can be called multiple times in one query.  The fact they let you know where you performance needs fine-tuning makes resolvers excellent trackers as well. 

This is simply not possible in REST and JSON. Do you see the difference in implementation? 

How do the API endpoints play a role?

Many a time, it is seen that once the API is designed and the endpoints are sealed, the applications require frontend iterations that cannot be avoided. You must know that the endpoints aid an application to receive the required data just by accessing it quickly in the view, so you could call them essential even. 

However, the endpoints can pose a bit of a problem for the iterations, especially when they need to be quick. Since, in such an instance, changes in the API endpoints have to be made for every change in the frontend, the backend gets tedious for no reason at all. The data required for the same can be on the heavier side or the lighter side, which ultimately hampers the productivity. 

So, which API offers the solution?

It is neither REST, nor JSON. GraphQL’s flexibility makes it easy for the developers to write queries mentioning the specific data needs along with iterations for the development of the frontend, without the backend having to bear the brunt.

Moreover, GraphQL’s queries help developers on retrieving specific data elements and provide insights to the user as to which elements are popular and which aren’t amongst the clients.  

Why doesn’t REST? 

The answer is simple, REST has the entire data in a single API endpoint. Being a user, you won’t be able to gain insights on the use of specific data as the whole of it always returned. 

How good is the API exploration?

A distinction is shown between the three APIs, REST, JSON and GraphQL, in three circles with regards to API exploration.

Understanding your API and knowing about all of its resources and that too quickly and with ease is always going to benefit your developers. In this aspect, all three perform pretty contrastingly. 


REST gives a lacklustre performance in API exploration to be honest. The interactivity is pretty substandard as the navigation links are seldom available. 

In terms of the schema, it would only be programmable and validatable, if you are going to be using the OpenAPI standard. The auto-generation of the documentation also depends on the same. 


JSON performs better than REST. The observation of the available field and links in JSON: API’s responses helps in its exploration and makes its interactivity quite good. You can explore it using a web browser, cURL or Postman

Browsing from one resource to the next, debugging or even trying to develop on top of an HTTP-based API, like REST, can be done through a web browser alongside JSON. 


GraphQL is indeed the front-runner here. It has an impressive feature, known as the GraphiQL, due to which its API exploration is unparalleled. It is an in-browser IDE, which allows the developers to create queries repeatedly. 

What is even more impressive is the fact the queries get auto-completed based on the suggestions it provides and you get real-time results. 

Let’s focus on schema now 

A distinction is shown between the three APIs in terms of schema using three circles.

Schemas are important for the development team, the frontend and the backend equally. It is because once a schema has been defined, your team would know the data structure and can work in parallel. Creating dummy test data as well as testing the application would be easy for the frontend developers. All in all, the productivity and efficiency levels elevate. 


REST does have an associated expected resource schema since it is a set of standard verbiage. Despite this, there is nothing that is specifically stated in them. 


In terms of schema validation and programming, it does define a generic one, however, a reliable field-level schema is yet to be seen. Simply put, JSON is basic with regards to schema. 


The fact that GraphQL functions completely on schemas makes it a pro in this regard. The schema used here is Schema Definition Language or SDL. What this means is that GraphQL uses a type system that sets out the types in an API because all the types are included in SDL. Thus, defining the way a client should access data on the server becomes easy. 

To conclude this point, I would want to say that when there is immense complexity in the schema and resource relationships, it can pose a disadvantage for the API.  

How simple is to operate it? 

The operational distinction is shown between the three APIs in three circles.

Operating an API essentially involves everything, from installing and configuring it to scaling and making it secure. REST, JSON: API and GraphQL, all perform well enough to make themselves easy to operate. Let’s see how. 


REST is quite simple to use, a walk in the park for a pro developer. It is because REST is dependent on the conventional HTTP verbiage and techniques. You would not need to transform the underlying resources by much, since it can be supported by almost anything. It also has a lot of tools available for the developers, however, these are dependent on their customisation before they can be implemented. 

In terms of scaling, REST is extremely scalable, handling high traffic websites is no problem at all. To take advantage of the same, you can make use of a reverse proxy like Varnish or CDN. Another plus point of REST is that it has limited points of failure, being the server and the client. 


JSON: API is more or less the same as REST in terms of its operational simplicity, so much so that you can move from REST to JSON: API without any extensive costs. 

  • It also relies on HTTP; 
  • It is also extremely scalable; 
  • It also has numerous developer tools, but unlike REST, JSON: API does not need customised implementations; 
  • Lastly, JSON also has fewer failure points. 


GraphQL is the odd one out here. It isn’t as simple to use as the other two. It necessitates specific relational structure and specific mechanisms for interlocking. You would be thinkin that how is this complex? Let me ask you to focus on word specific, what this means is that you might need to restructure your entire API with regards to resource logic. And you must know that such restructuring would cost you time, money and a boatload of efforts. 

Even in terms of scalability, GraphQL does not fare very well. The most basic requests also tend to use GET requests. For you to truly capitalise GraphQL, your servers would need their own tooling. If I talk about the points of failure here, even those are many, including client, server, client-side caching and client and build tooling. 

What about being secure?

The security distinction is shown between the three APIs in three circles.

The kind of security an API offers is also an important consideration in choosing it. A drastic difference is noted in REST and GraphQL. Let’s see what that is. 


REST is the most secure amongst the three. The intrinsic security features in REST are the reason for the achievement. 

  • There are different APU authentication methods, inclusive of HTTP authentication;
  • There are the JSON Web Tokens for sensitive data in HTTP headers;
  • There are also the standard OAuth 2.0 mechanisms for sensitive data in JSON structure. 


JSON:API is on a similar footing to REST in terms of security. The reason being the fact that like REST it exposes little resources.  


It is not like GraphQL is not secure, it is; however, the security has to be manually attained. It is not secure by default and it is not as mature as REST in this regard. 

When the user has to apply authentication and authorisation measures on top of data validation, the chances of unpredictable authorisation checks rise. Now, do I have to tell you that such an event is bound to jeopardise your security? 

How is the API design pinpointed?

The distinction for API design is shown between the three APIs in three circles.

If an API has to perform well for every use case, you have to make it do so. By creating such design choices that are a result of your understanding of the users’ needs. You cannot just go with the flow, evaluating how your users are going to be interacting with your API and getting an understanding of the same is key for your API’s design. 


For REST, this exercise of deciphering the user requirements must happen before the API can be implemented. 


As for GraphQL, this apprehension can be delayed a little. By profiling the queries, you would be able to tell their complexity level and pinpoint the sluggish queries to get to an understanding of user’s consumption of the API. 

What about their use in Drupal?  

The distinction for Drupal installation and configuration is shown between the three APIs in three circles.

Drupal is an important player when it comes to building websites and managing their content. With decoupling Drupal becoming more and more popular, it has become crucial to understand how the APIs perform alongside Drupal. 


Talking about the installation and configuration of REST, it can be complicated at best. The fact that the REST module has to be accompanied by the REST UI module does not ease the complexity. 

With REST, the clients that cannot create queries with the needed filters on their own, since the REST module does not support client-generated collection queries. This is often referred to as decoupled filtering.  


JSON:API module landed in Drupal core in Drupal 8.7. JSON:API’s configuration is as easy as ABC, there is simply nothing to configure. JSON is a clear winner in this aspect. 

Moving to client-generated queries, JSON does offer its clients this luxury. They can generate their own content queries and they won't need a server-side configuration for the same. JSON’s ability to manage access control mechanisms offered by Drupal make changing an incoming query easy. This is a default feature in JSON:API.


The installation of GraphQL is also not as complicated as REST, but it isn’t as easy as JSON as well. This is because it does mandate some level of configuration from you. 

Similar to JSON, GraphQL also offers decoupled filtering with client generated queries. A less common trend amongst GraphQL projects is seeking permissions for persisted queries over client-generated queries; entailing a return to the conventional Views-like pattern.

In addition to these three major Drupal web services, explore other alternatives in the decoupled Drupal ecosystem worthy of a trial. Read everything about decoupled Drupal, the architecture-level differences between headless and traditional setups, different ways to decouple Drupal, and the skills required to build a Decoupled Drupal web application to know more.

Concluding with the basics 

To sum up, let us look at the fundamental nature of the three APIs, which entails two aspects; simplicity and functionality. 

In terms of simplicity, REST is a winner. A second would be rewarded to JSON, while GraphQL would not and could not be described as simple, complex and that too immensely with major implementations coming your way would be a more accurate description. In terms of functionality, GraphQL does offer the most. If you choose JSON over GraphQL, you would end up parting with some of its features unfound in JSON. 

All three are powerful and efficient in what they can do for your application. The question is how much complexity are you willing to take up with that power?

Jan 20 2021
Jan 20

I was very happy (and proud) about this achievement – so decided to do it again in 2020! This time I encouraged other people to join the channel and try the challenge with me. More people jumped in and together, as a group, we contributed to the Drupal project and modules that we use in our day-to-day work. 

Not only Amazee developers and project managers joined the challenge. One job application we received referenced our #12months12patches Challenge blog from 2019. That applicant ended up joining Amazee Labs a few months after, and then, of course, became an active contributor of the channel!

Our contributions were focused mostly on Drupal modules, but we also worked on Drupal related projects (i.e.: Lagoon). We got some great ideas for new modules from the project managers ("Something like this would help the client to...") and shared tips on how to find issues to contribute to more often (i.e.: whenever you install a new module on a project, look in the issue queue and try to help with some of the reported issues).

Drupal Patches

Overall, it was a real team effort and a great experience. As you will see below, the number of patches grew considerably, compared to the first installment of the challenge. Let's have a look to see what each month was like. 

These are the different patches (and modules) made by different Amazee's throughout the year.













Again, I couldn’t be happier that we achieved the challenge goal, and best of all, we did it as a team – by encouraging and helping each other. Looking forward to doing it all again in 2021!

If you're also keen to contribute to Drupal, don't miss out on Drupal Global Contribution Weekend, 29 - 31 January 2021 - events are happening world-wide. Happy coding!

Jan 20 2021
Jan 20

Are your meetings falling flat lately?

For many, the realities of remote working are wearing kind of thin. We’re looking for ways to breathe more life into meetings and raise the bar for engagement, productivity, and yes, even fun. 

It’s easy to become frustrated with participants during a call when they’re on mute for most of the meeting, or texting, or only partially present. It’s true, of course, that this is business, and we’re all adults, and tuning out should not be an option. It’s also true that when the leader of the meeting gets intentional about a different approach to navigating group interactions, the energy and the impact of the meeting takes off in a new trajectory.

Remote meetings present distinct challenges, especially months into a global pandemic in which most everyone has been required to work remotely. Regardless of whether participants are sitting around the same table or separated by several time zones, there is so much that meeting facilitators can do to encourage all participants to lean in, actively contribute, and build upon each others’ ideas to come up with great solutions. 

Improv at Work

The rules of improv comedy can actually provide some great lessons for keeping meetings moving with all participants bringing their A-Game.

I had the fortunate experience of working with several coworkers at an interactive digital marketing agency who taught and performed improv comedy. I learned from them that the kind of hysterically funny, in-the-moment interactions present in improv is not as spontaneous as they may seem. Great improv results from a lot of study and practice. 

As it turns out, learning and following the basic “rules” of improv can have a significant impact on the energy and outcomes of business meetings. 

Here are a few improv comedy rules along with some thoughts on how they can be adopted for business. 

Rule #1: Say "YES"

“Yes AND …” along with “Yes ANDing” has emerged essentially as the catchphrase of improv. “Yes ANDing” is a skill that requires practice and, for many, a big mindset shift. 

The knee-jerk reaction during meetings tends to be either “Yes, BUT,” or a flat out “NO,” followed by all the reasons why a given idea isn’t feasible or isn’t based on adequately strategic thinking. 

  • “We tried that last year. It didn’t work.”
  • “Sounds good but have you thought about …”
  • “There’s no way we could get _______ to sign off on something like that.” 

While making someone else wrong might seem to represent discernment and critical thinking skills, the real impact is a gradual, or sometimes a swift, shut down of further contributions.

The objective of “Yes ANDing” is to validate, to be open to another perspective -- a Plan B or C -- to collaboratively build something together by adding to it.  

Here are some sample “Yes AND” responses:

  • “Interesting. I hadn’t thought about that, and this could be a good foundation for ...”
  • “We tried something like that last summer. That was when the market was very different  / or we didn’t do X, Y, and Z.”

The challenge, before shutting them down, is to help build out ideas, even if you don’t fully understand them or it wasn’t what you had in mind. For any number of reasons, the idea might not ever take shape, but taking the time to listen and learn, builds both productivity and relationships. 

Rule #2: Build up. Don’t break down. Keep it moving.

With improv, the second someone gets invalidated, the scene dies. A similar dynamic plays out in meetings when participants go quiet and they silently say to themselves:   “OK you figure this one out.”

Too often, poor participation and long silences stem from this kind of dynamic.

The genius of great improv is the pace. 

We don’t need to measure up to the lightning-fast wit of the improv pros from the likes of the TV show “Whose Line is it Anyway,” which ran from 1998 through 2007, but silence can kill the energy of a meeting, just as it does with improv comedy. Encourage participation and build from it.

For more leadership insights, SUBSCRIBE to the Promet Source Blog

Rule #3:  Don’t ask questions. Contribute new information. 

This one can be a challenge to put into practice. The standard is to expect participants to defend their ideas or lead them into the realization that their ideas will not hold water. 

Avoid the expectation that only fully thought out suggestions are allowed to be voiced. 

Instead of:

  • “How could we ever expect the dev team to take this on?”

How about:

  • “I was talking with Deborah in dev the other day and she seemed really eager to try some new things. This might be right up her alley.”
  • “Let’s talk further about how we can get the dev team on board with us on this.”

Rule #4:  No Wrong Answers

We’re all familiar with the “no bad ideas” premise of brainstorming and the objective of a free-flow of lots ideas that spark other ideas, as a few “best” ideas start to emerge. 

Rules of improv are also built upon an understanding that making people wrong is wildly unproductive. The difference is that brainstorming is inherently focused on a number of ideas with the assumption that the vast majority of them will never see the light of day. Sometimes, brainstorming is exactly what’s needed, but improv is a bit different. It’s about co-creation and collectively building something together as a team.

Another difference: with brainstorming in general, it’s possible for some participants to sit back and others to dominate. Improv -- similar to Promet's Human-Centered Design workshops -- draw  in the whole group.

Rule #5: Everyone participates and brings their A game.

Improv rises and falls on the dynamic of the group. It’s not about who has the best ideas or who is the smartest. It’s about knowing each other’s strengths and how to best leverage them. We can bring this same principle into our meetings along with the expectation that everyone who has been invited to the meeting is there for a reason. 

With improv, everyone is expected to bring their A-Game, stay in curiosity, let go of their ego, take risks, and have some fun.  

Try injecting some rules of improv into your next meeting! First, inform your group of how it works and see how following these practices can actually enhance and motivate your team to have more participation, provide more ideas, and work together to create some new possibilities.

Interested in witnessing first-hand the impact of our collaborative energy on discovery session outcomes? Contact us today. 

Jan 20 2021
Jan 20

Next week kicks off Drupal Global Contribution Weekend, January 29-31, a virtual worldwide event everyone can participate in from anywhere in the world.

Want to give back to the Drupal Community in the form of code but you're not acquainted with the new contrib process? Here’s your chance to get ready for the weekend. Now that our meetups are online, join the San Francisco community in learning how to create issue forks and merger requests.

Drupal Global Contrib Weekend - Introduction to issue forks and merge requests with Mark Casias

Learn the new workflow for the drupal.org issue queues. Previously, the main way to contribute source code changes to a Drupal project repository was through the patching process. In November 2020, a new and different workflow became available, similar to what open-source contributors commonly use on sites like GitHub.

We'll walk through the basics. There will be a demo followed by Q&A.

Thursday, January 28, 2021 - 3:30-4:30 pm PT on ZOOM
RSVP here

Join us on Social Media

Join us on slack: http://sfdrupal.herokuapp.com
Subscribe to us on YouTube: https://bit.ly/SFDUG-youtube
Follow us on Twitter: https://twitter.com/BADCamp

The San Francisco Drupal User’s Group wants to extend a special thank you to Kanopi Studios for donating resources, platforms, and organizing efforts over the past couple of years. They design, build and support websites for clients who want to make a positive impact.

Jan 20 2021
Jan 20

January 20, 2021

This post is aimed at web development teams and is not tied to a specific technology. We will aim to not get more technical than is needed, but rather to explore what Continuous integration (CI) is, and how it can help save teams money within a month of it being set up.

What is continuous integration?

Although several definitions of CI have been proposed, we will use the following definition in the context of this post:

Cotinuous integration (CI) is the practice of running any number of tests, automatically, on a project, periodically and/or whenever the code changes. For CI practitioners, the number one priority is for tests to always be passing.

A simple example, please

Here is the very simplest example I can think of:

Let’s say you’re maintaining an old-school HTML website (no fancy stuff like databases or PHP), your team may decide to set up CI to make sure a file called “index.html” exists in your codebase: if it exists, your test passes; if it is absent, your test fails.

Checks may be run every time your code is changed.

Your team might store code on GitHub, and link a cloud CI provider such as CircleCI to your codebase, having it trigger every time your code changes.

You will then define a script which is your definition of “what it means for your your codebase to pass”: checking for the existence of “index.html” is a one-line script.

A more complex example

Although the example above has value, it is very simple, and you may soon find yourself wanting to add higher-value tests to your script. This ability to add complexity over time is a powerful feature of CI: getting started is simple, and you can add as many tests as you want over time depending on your available resources.

Let’s say your team is maintaining a Drupal or Wordpress codebase with lots of complex code, your team may set up a CI server that:

  • checks for broken links on the live environment every so often;
  • checks every few minutes that the live environment is responding and has some expected keywords on its front page;
  • every so often, checks that the live environment adheres to certain Accessibility standards;
  • every so often, checks that the live environment is not reporting any errors;
  • on every code change, perform some static analysis on custom PHP code: for example, that a function which expects an array as an argument is never called with a string.
  • on every code change, make sure PHP code adheres to coding standards (for example, functions should have comments; and indenting should be correct).
  • on every code change, create a dummy Drupal or Wordpress site with a dummy database and make sure your site fires up, and run some end-to-end tests against it.
  • etc., etc.

A cloud-based tool such as CircleCI can work well to check the codebase when it is changed; and a hosted tool such as Jenkins might be a good fit for running periodic checks (such as a sanity check making sure the production environment works).

The above example corresponds to real-world checks I perform on lost of projects I maintain; and both CircleCI and Jenkins are tools I have been using for years.

So how much does all this cost?

“How much does this cost?” is actually the wrong question. “How much can I save?” is a better way of putting it. Consider the following graph, the horizontal axis is time, and the vertical axis is cumulative project cost.

  • The red line is business as usual: because we are not maintaining CI scripts or setting up tests, the up-front cost is low. But eventually you’ll lose control of your codebase and spend all your time putting out fires (I call this the “technical debt wall”).
  • The blue line is the CI approach, higher up-front cost to set things up, but eventually you’ll get less errors.
  • Where the two lines intersect, I call the “sweet spot”. That’s when you start saving money. Your “sweet spot” is not months or years away: I firmly believe it should happen within a month. If it takes longer than a month, you’re overengineering your CI system.

So what are these up-front costs?

The up-front costs are:

  • Creating a simple script which defines what it means for your code “to work”. If you find this intimidating, just have your script check for a file that must be present, as in the simple example presented earlier.
  • Make sure your code is tracked in GitHub or BitBucket.
  • Make sure your entire team accepts the principle that making tests pass is the number one priority. This is crucial. If you start accepting failing tests, then CI becomes a useless burden. This also means every member of your team must agree with every test that is performed. If a test is not important enough to warrant dropping everything when it fails, then you should not have that test in your codebase.
  • Integrate a simple, free CI cloud provider like CircleCI and make sure it works.

All of the above, together, can take between an hour and a day.

How about the ongoing costs?

Ongoing costs are closely relate to the complexity of your CI setup. If you are just testing for an “index.html” file, your ongoing costs are close to zero, but may include:

  • dealing with errors and updates in the CI script itself. Don’t forget the CI script is computer code, and like any computer code, it needs to be maintained.
  • updating the CI script to deal with API changes in the cloud CI provider.
  • fixing false negatives. For example, someone may change the filename from index.html to index.htm, which might require you to fix your test script to also test for index.htm in addition to index.html.
  • onboarding new team members to understand the importance of making sure tests always are passing.

If your tests are super simple (such as checking that an “index.html” file exists), the above costs are low, probably less than one hour a month.

If your tests are complex (as in our second example, above), you might set aside 5 to 10 hours a month for ongoing costs.

Obviously, if your ongoing costs are higher than your savings, then you are “over-testing”.

So what are the benefits?

The fundamental trick of CI is to keep your benefits higher than your costs. Let’s go back to our simple “index.html” example:

  • We have already established that there are minimal up-front and ongoing costs.
  • There are also ongoing savings: once you know that your index.html file is guaranteed to exist, your manual testing time decreases.
  • The cost in lost revenue, lost confidence, and debugging time in case someone accidentally deletes index.html from your website would be considerable high.

Based on the above, you can conclude whether it’s worth implementing CI.

Continuous improvement of your CI setup

Checking for “index.html” is probably of very low value, but once you’ve done that, you’ve also set up the foundation to improve your script. Every time you feel your CI script has a positive cost-benefit ratio, it is time to improve your CI script. In practice, I have found that in projects under active development, the CI setup gets constantly improved.

Specifically, any time a problem makes its way to production, it should be a gut reaction to introduce a fix, along with a test to make sure the problem never happens again.

The key is making incremental improvements, making sure your cost-benefit ratio is always positive.

Docker and containerization

Docker, and containerization generally, embed software and configuration in computer code along with your project code.

The widespread adoption of Docker and containerization in recent years has been crucial for CI. Without containerization, let’s say you want to run PHP static analysis, start a database with a Drupal site, run end-to-end tests, you need to install a bunch of software on your CI server (or your laptop), make sure the versions and configuration are in sync with your local development setups. This is simply too expensive.

Docker makes all this easy: simply put, Docker abstracts all the software and configuration, making software act the same on any computer that has Docker installed.

If you are not using Docker and you’d like to see how simple this makes things, install and launch Docker Desktop on your computer, give it 6Gb RAM instead of the default 2Gb in its preferences, then you’ll be able to run all tests on my Drupal Starterkit project, without any additional fiddling with configuration of software:

cd ~/Desktop && git clone https://github.com/dcycle/starterkit-drupal8site.git
cd starterkit-drupal8site

It should take about 10 minutes to run all tests and it will not add any software to your computer; everything is done on throwaway “containers”. (In general, tests become a lot more frustrating to developers as they take longer to run; which is why I have a policy of not accepting tests which take more than 20 minutes to run.)

The amount of software packages and configuration required to run all the tests in this example is enormous: database servers and configuration, passwords, permissions, PHPUnit, the right version of PHP and Apache or Nginx…; however it’s all defined in Docker files and in code, not on host computers.

Which is why you can run the tests in three lines of code!

This makes it possible to run these complex tests on your computer without installing any software other than Docker.

This also makes it possible to run these exact tests, sans extra configuration, on CircleCI or other CI providers which support virtual machines with Docker preinstalled. In fact, that’s exactly what we’re doing with the Drupal Starterkit. CircleCI even provides a cute badge to indicate whether tests are passing.

Click on the badge below to see test results on CircleCI, which should be identical to the results on your computer if you ran the the above script (you’ll need to log in with your GitHub or BitBucket account).



Whether you are using a cloud service such as CircleCI, or hosting your own CI server with Jenkins or other software, be aware that it adds a potential attack vector for hackers, especially because by design, CI software needs access to your codebase.

In early 2021, a vulnerability was discovered in JetBrains TeamCity (Widely Used Software Company May Be Entry Point for Huge U.S. Hacking, New York Times, January 6th, 2021) in relation to the major SolarWinds hack.

Make sure you have a solid security policy, including the Principle of Least Privilege (POLP) and other industry-standard security approaches; also make sure your codebase, even if it’s private, does not contain any sensitive data, including API keys.


With continuous integration (CI), you can let computers do the grunt work of looking for bugs in your codebase, liberating your developers to do more productive work, reducing the number of bugs that make it into production, and increasing the level of confidence of all stakeholders in your software, and deploying frequently.

And, above all, saving money.

CI can be as simple or as complex as you need: start small, then let your CI process grow as your team becomes more comfortable with it.

Please enable JavaScript to view the comments powered by Disqus.
Jan 19 2021
Jan 19

As a designer and front-end developer, the infamous designer-developer handoff has often been between me and myself. Having spent a lot of time in both roles, as well as having worked closely with other designers and developers, I’ve learned a few practices that help me to answer developer questions right from the start.

Responsive Design

The first question to think about in the visual design stage is how a design will translate from a static idea to something people will use. In the real world, people are using all kinds of devices to interact with a website. There are a number of different use cases to think about here. For example, mobile users may be accessing a webpage without internet access, making an autoplaying video a concern for data usage. However, the most common and notable case to think about here is simply different screen sizes.

It’s pretty common to see mobile, tablet, and desktop designs handed off to a developer. If done well, these are generally enough for defining most of a website. Developers usually are working from 320px up, so it’s important to create mobile mockups at this size. From there we widen the browser to make sure the website still looks correct at the sizes in between what was provided in the mockups. The design for the mobile will be applied all the way up to one pixel below tablet size, and the tablet design will be applied up to one pixel below desktop (you may want to specify this for your developer).

For the most part, we want a consistent experience for each of these devices. If, for example, a user opens the website on an external monitor instead of their laptop, it shouldn’t look like a different website. That said, with some layouts the right breakpoint (browser width at which a component changes) is not right at one of the defined device sizes. As you’re designing, check if any of your components or page layouts need to switch at a more specific browser width. A good test of this is to create an artboard that’s a tiny bit smaller than tablet, and put everything in the mobile layout at that width. If anything looks off, consider defining a different breakpoint for that particular component.

Another case to consider is when the website gets extra wide. The last thing you want is to present the final website to your stakeholders and find the components in disarray on a big TV. Generally I’ll define up to two widths for this. One is the content maximum width, and the other is the website maximum width.

The content maximum width is the size at which the components (such as text or an image) on the website stop increasing in width but the backgrounds (such as a background color or image) keep going. If your content maximum width is particularly large, keep in mind how all your components look stretched to that width. For readability and accessibility of any text on the website, remember that optimal line length is 45-75 characters. 

This width may be all you need, but you can also define a website maximum width if you want something like an image background or full width slideshow to stop growing at a wider point. This may just apply to those full width components that are using images, or (less common in modern design) to the whole website. When deciding on whether or not full width components should keep stretching infinitely wide, think about how you want images to look on very large screens. Unless it’s a background image that is matching the height of that component, the wider an image gets, the more vertical space it will take. Also consider if you want large images to look clear at very large sizes or load quickly at normal and smaller sizes. Limiting the width an image component can reach is one way to strike a balance.

One last thing to define is the padding on the sides between tablet and desktop. When the width gets close to your content maximum width, how much padding stays on the sides as the content begins to shrink? I usually leave 16px between mobile and tablet, and 32px between tablet and the content maximum width (technically the content maximum width plus 64px so I don’t lose the padding too early).

Other common responsive considerations are typography and hover states. For typography, you’ll likely want to define heading sizes for mobile, tablet, and desktop. Also pay attention to line height, as well as spacing above and below a heading. For hover states, just remember that a mobile or tablet user can’t hover, so make sure none of the functionality is lost because of this.

Other tips

This covers most of the important points to keep in mind, but here are a few others:

Try to use a consistent base for sizing, preferably based on the body text size. I usually make my base font size 16px and then try to make typography and spacing stick with multiples of 4px.

Never type with caps lock. Always type in lower or sentence case and use your design software to transform the text to uppercase. This will help if you need to change that style without having to retype, and it allows developers (depending on your method of sharing designs) to copy and paste your text rather than retyping it. It also can be a good reminder to the developer that they should be using css to make text uppercase for accessibility (screen readers read text typed in all caps one letter at a time).

Make sure your images and text are flexible. If you have an image that perfectly lines up with the text overlaying it, be aware of how that component might be used and if the content editors will be changing the image or text. Similarly, be aware of the amount of text a content editor might add to any component. Character counts can always be limited, but it won’t hurt to supply that or show how the component should respond to having more text, especially if that text area is highly dependent on browser width.

One thing that can be easily overlooked is hover and focus states for any interactive elements of your website. For a website to be accessible, it has to be navigable with a keyboard. Focus states are what you see if you tab through a page, and if the difference isn’t notable it will be difficult to do this. Often, hover and focus states can be the same, but there may be some cases where you want to separate them. A form, for example, is an important place to have focus states defined, but you may not need hover states to work the same. Focus states that aren’t specified will generally be automatically provided by the browser, resulting in different appearances between browsers.

One last thing to establish while working with developers is a shared language. A paragraph or a block may mean something different to you as a designer then to a developer working in a content management system. Work together to make sure you have a common understanding of what some of these terms mean. A design system, or even a component library, is a great way to document this. We usually use Invision DSM to share a design system between designers and developers.


To review, remember the following things as you’re designing:

  • Design mobile at 320px
  • Define a content and website maximum width
  • Create font styles for mobile, tablet, and desktop
  • Use a consistent base for sizing, based on your body text size
  • Get in the habit of using your UI to transform your text to uppercase
  • Make images and text flexible whenever possible, and show components with varying amounts of content
  • Provide hover and focus states
  • Establish a shared language

When working with developers, it’s important to keep in mind the gaps between design and development when creating a website. While small design details may be obvious to you, a developer may be less aware of pixel distances and small color variations, focused instead on building the website in the best way possible. Ideally, design handoff is not one moment in a months long process, but a continual collaboration. Getting developer feedback while in the design process can save you from wasting time going down an unfeasible pathway, and getting across clear design patterns can ensure a developer makes the right assumptions from the beginning. Understanding a little of each other’s world can help make the whole process a lot smoother.

Jan 19 2021
Jan 19

Drupal's toolbar second level of menu options and dropdown not showing? Look for "Uncaught DOMException: The quota has been exceeded." errors, as viewable in the Firefox web console. If you see them, the problem is likely due to sites sharing a top-level domain—which is likely if you are using a local development environment like DDEV, and you working on way too many sites at once—combined with a pretty bad Firefox bug that will be fixed in the next release.

To quote Nathan Monfils:

  1. Everything from your public domain (abc.tld) counts against your quota, even if it is in a seemingly unrelated subdomain (e.g. my-app.example.com and intranet.example.com).
  2. The quota is not recomputed properly, requiring a firefox restart after clearing your data on other subdomains

Note this may affect all sorts of applications, not just Drupal, when you have them running on multiple subdomains of the same top-level domain. So this isn't just about local development environments (and i dislike that DDEV shares their own top-level domain across all the instances you are working on, and while it can be changed i've accepted its way of doing things so i'm on the same page with other developers by default).

Sure, closing more tabs and restarting Firefox could (predictably) have fixed this—and a lot else that's wrong with me, according to everyone i know—but why do that when i can open more tabs and learn precisely how broken everything around me really is?

A drawing of a laptop with open tabs extending outside of the laptop as horizontally tiled windows.

I am very happy the bug is fixed and this blog post will be obsolete in mere days! Usually this sort of technical noodlings get relegated to our raw notes, currently hosted through GitLab, but figured at least a few other Drupal developers would want to know what has been going on with their toolbars.

Image credit: "Too Many Tabs" by John Markos O'Neill is licensed with CC BY-SA 2.0.

Jan 19 2021
Jan 19

“Update before you get outdated”. 

PHP 8 is here and is now supported in Drupal 9.1 and its dependencies! November 2020 saw the big release of PHP 8. We call it a big release because of the exciting new features and optimizations it comes loaded with (which we will be talking about shortly). 

Drupal 8.9 and 9.0 are however marked incompatible with PHP 8. They are still compatible with PHP 7.3 and PHP 7.4 – which happens to be the last major PHP update. PHP 7.4 will stop receiving active support from the community from November 2021. And thus, updating your website to Drupal 9.1 will be a good idea now.

Drupal 10, which is scheduled to release in June 2022, will mandate compatibility with PHP 8. Read on to find out about the amazing features PHP 8 has to offer and how you can check if your Drupal version is compatible with PHP 8.

Drupal 9.1 Compatibility with PHP 8


What’s new with PHP 8 (Notable Changes)

    1. JIT Compiler

JIT stands for just-in-time compilation. Starting from PHP 5.5, Zend VM became part of PHP. But 8.0 introduced JIT to address some long struggling PHP performance issues. For better performance PHP was based on OPCache using OPCode. This is precompiled code given to the processor as commands. However, it is not very native to the machine language. On the other hand, JIT provides actual machine code with a mechanism to work together with OPCache. JIT does not work automatically. We need to configure this in the php.ini file.

    2. The null safe operator

You must be familiar with the null coalescing operator (??) which worked as:

$value = $var1 ?? $var2

It checks for the null value of $var1 and returns it. If it is not null, it returns $var2. But it does not work with method calls. Here, the null safe operator comes into the picture.

$value = $obj->getData()?->getValue();

Here you can call the getValue() method; even if no method $obj->getData() returns null, the code will not crash. It will return null. On the other hand, using the null coalescing operator:

$value = $obj->getData()->getValue() ?? null; 

..will throw an error.

    3. Named argument

PHP 8 allows you to now pass named arguments to functions. It does not depend upon the argument order. Instead, you can pass the argument name.

function named_arg_example(String $arg1, $string $arg2, $string $arg3) {}

      arg1: ‘arg1 value’,
arg3: ‘arg3 value’,
arg2: ‘arg2 value’,

    4. Match expression

Match expression is like the switch statement, except that it does not require a break statement.

$value = match($check) {
0 => ‘Value is zero’,
  1, 2, 3 => ‘Value is non zero and less than 4’’

There are many other great new features added to PHP 8 like the constructor property promotion, Attributes, Constant type errors for internal functions, Saner string to number comparison, etc. More details can be found here.

How to perform a Compatibility Check with PHP 8 on Drupal

You can use this method to check if your version of Drupal is compatible with PHP 8 or not. For that, you will need to first make sure you have the required package – phpcompatibility. For more information on this, visit here.

Next, you should already be having Drupal installed. If not, you will need to install Drupal 9 in your system. Using composer to install Drupal is the recommended way. For information about composer installation please refer this document

STEP 1: Drupal Installation

Use this Composer command to install recommended version of Drupal

composer create-project drupal/recommended-project [my_site_name_dir]

You will need to change [my_site_name_dir] with the folder name you want to install Drupal into.

STEP 2: Installing the required Package

After installing Drupal, you will have composer.json in your Drupal root directory. Open it in text editor and add the following code:

"require-dev": {
    "phpcompatibility/php-compatibility": "*"

If you already have require-dev section in your composer.json file, just add

"phpcompatibility/php-compatibility": "*"  to the list.

Next, you need to provide location info to the PHP code sniffer by adding the following lines to composer.json

 "scripts": {
    "post-install-cmd": "\"vendor/bin/phpcs\" --config-set 
installed_paths vendor/phpcompatibility/php-compatibility",
    "post-update-cmd" : "\"vendor/bin/phpcs\" --config-set 
installed_paths vendor/phpcompatibility/php-compatibility"

And then run:

 composer update --lock

It will install phpcompatibility and other required packages.

STEP 3: Compatibility Check

Now, use this command to check PHP compatibility for the project 

vendor/bin/phpcs -p [directorypath] --standard=PHPCompatibility 
--runtime-set testVersion [php version] --extensions=[file extensions] 

You need to replace the directory path with the directory path that the test will run on. In our case it is ‘.’ because we want to run the test in current directory (All Drupal files and folder). You should also replace the [php version] with the version you want to check compatibility with - which in this case will be 8.0. Replace the [file extensions] with file extensions like php, module, inc, install, etc. The report-full gives you the flexibility to store the report log in a file. So you will need to provide the path for the log file.

So, for our case, the command will be: 

vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set 
testVersion 8.0 --extensions=php,module,install,inc 

It will take a few minutes and you will get a drupal9-php8-compatibility.txt file, where you can check the reported log.

Jan 19 2021
Jan 19

19 Jan

Nick Veenhof

A new year also means some new predictions. When it comes to innovation in the web technology industry, innovation is, as always, moving faster than expected.

In this blog I will share a couple of items that we should keep an eye out for in the next 12 months within the web development world. As with any prediction, I can’t see in the future - so judge for yourself. :-)

Cloud IDE’s will disrupt local development flows

One of the first major innovations that I see happening in 2021 is the adoption of Cloud IDE’s. Cloud what? In short, a development environment that doesn’t need anything on your local computer to make changes to a specific project.

Let’s take Drupal as an example, Drupal requires PHP, A form of database like MySQL, Caching technologies like Redis or Memcached, Reverse Caching technologies like Varnish and to top it of, indexing technologies like Apache Solr or Elasticsearch. Next to that, it also requires in many cases “xdebug” as a means of stepping through the code. And it isn’t finished yet, as we also need an editor or also known as IDE. Some very common IDE’s are PHPStorm or Visual Studio Code.

For someone that is just starting out, this is a very daunting task, and most often requires help from senior profiles to get you started. Translate this to classroom tasks and you can see why more often than not, this kind of complexity is not taught. It would take more time to set it up on the variety of laptops around then the actual teaching. I’ve seen this firsthand myself, when I did some guest lectures.

Luckily there are solutions out there that try to make local development easy, such as Dropsolid Launchpad, DDEV or LANDO but all of them still require certain knowledge and at the very least a powerful computer that can run Docker.

Disruption wouldn’t be called disruption if this model could see itself being threatened. Cloud IDE’s are this disruption. Imagine logging in to your development platform and be able to click edit on the respective environment you would want to work upon. This button opens up a window with an IDE, tuned to your preferences and with all the extensions you need, and with all the connections already setup. You are able to make a change, enable debugging and go through the issue step by step, make a change, commit it and deploy. All within the browser and with the compute power greater than any consumer laptop.

Some might say this will never take off - but then again, people said the same of video game streaming services like Stadia. Stadia is outperforming many local gaming rigs today at a performance level that has never been seen. If this works for games, I’m certain it works for development environments as well.

Only time will tell.

Jan 19 2021
Jan 19

We set up an internal ask me anything session with Nat, the Drupal core maintainer that works at TAG that we sponsor to contribute to Drupal core every day and let our engineering team ask him anything they wanted. We got into some very deep topics and had learned some things that quite surprised us. Below is a transcript of the most interesting bits of the conversation. 

Read on for insights into Drupal 8 and 9!

How do you decide what to work on?

I start my day, and really spend all my time, on the Ready and Tested By the Community (RTBC) queue on Drupal.org. Typically there are always 40-100 issues waiting to be committed. I think it’s been empty just once in the past five years. Some of the issues are small and some of them are huge 200k patches. So really at 9 AM I get on the queue and work the issues, kicking some back for additional refinements and committing some to core.

At the end of the day, there might be more in the queue than when I started. It’s a bit Sisyphean.

In addition, I believe it’s crucial as a Core Maintainer to do client work because you need that perspective from using Drupal in the wild for real client uses. I think that informs our work on core better. I spend roughly half of my time doing client work for these reasons. So it does happen that something that annoys me on a client ticket I will look at improving it in core.

I’m also jointly responsible with xjm for the release schedule. This means keeping an eye on issues that we’re hoping to get done for the next minor release, as well as identifying blockers (and sometimes unblocking) for Drupal 10, which means trying to plan a year or three ahead. This could be features, critical bugs, or dependencies like Symfony.

Is working on Core really just like an issue queue for a contributed module, just bigger?

Essentially. There are always core initiatives happening, some of which have their own teams and funding, so function more like a contributed project within a project. But, at the end of the day, all of that work ends up as an issue in the queue that I work on. Every change in core needs to be worked on by at least three different people (the patch or merge request author, a reviewer, and a committer), so there is no directly committing code for core maintainers, it’s always a collaborative process whether you have commit access or not.

How do you handle strategic long term concerns, when things could go in two different philosophic directions, and conflict?

We don’t have an official guidance document or anything; we really just try to hash things out. There are long-running ones. Often with these big decisions we make a meta issue and hash it out there, and at some point, consensus starts to push it in one direction or the other.

Events versus hooks is a good example of a major issue that as yet has not been resolved. In Drupal 8 we added a Symfony events system because it was needed by core functions like routing. We then started adding events in Drupal Core that contributed modules could take advantage of. We also kept the hook system in place, in parallel.

Some people want to deprecate hooks entirely and use only events. Others, like me, prefer to modernize the hook system and drop the event system entirely. We don’t yet have a consensus on this issue, but I’m confident at one point we will. Until then we’re stuck with both, but while this might be an annoyance sometimes, it’s not really broken.

When there are important bug fixes that are also blocked on architectural changes things can become a bit more urgent, although this doesn’t always mean they’re resolved faster. Having said that, it’s rare that architectural disagreements are what holds an issue up for very long. What tends to take most of the time is ensuring that changes in one system don’t break another and that people are able to move from old APIs to new ones smoothly - more like city planning than architecture.

What are the shortcomings of turning ideas in the issue queue into Drupal functionality?

It’s better than it used to be. In Drupal 6 and 7, it was challenging because the release cycle was 3-4 years and no new features could go into Drupal 6 or 7 after their first stable release. So if new functionality didn’t make it into Drupal 7, that was often kicked back or punted to Drupal 8.

With our six-month release cycle, we now have a clear, quick process to get new functionality into the next release of Drupal or set it on a clear path for a future release, no more than a year away usually. With experimental modules, it’s also a lot easier to introduce things in stages, while keeping the overall system working

We have a lot of technical debt in core so there have been some occasions where two groups of people will work on different issues, not knowing the other issue exists, and not knowing that these two issues are actually duplicates. Work can get wasted, buried in those unknown duplicates.

There is a new initiative called Bug Smash that is trying to address this, cleaning out old issues and cleaning up the past. It’s been a great success so far to reduce technical debt in Drupal, but it’s still resolved hundreds of issues in a backlog of thousands.

Getting more people involved in core is great, but it’s required to add more structure to how issues progress. I think this speeds up throughput overall since it’s easier to see at what stage any particular issue is at, what’s left to be done, what should be tackled in a follow-up or parallel issue etc., but at the cost of additional steps for each individual issue compared to core development say ten years ago.

What are your favorite things to come out of Drupal 8 & 9?

The two major ones for me are the Entity System and the caching layer.

The Entity System changes in Drupal 8 compared to 7 have been great. It actually is a coherent system now. We added automated Entity schema updates late in Drupal 8, which introduced upgrade path bugs at the time but made the system much more powerful. It feels solid and complete now.

Cache tags and context, the new caching layers in Drupal 8, was one of the first things I worked on in core. Lots of people implement the system wrong, I notice this in client work, but when you implement it right you have a really powerful, granular caching system at your disposal that works with edge caching layers.

What is the right way to use cache tags?

When you add stuff to the cache system you have a cache ID (like an Entity ID). A unique identifier for the thing that you are caching. The context, when you are rendering, is not the identifier for the thing, but things that come from the request, like the current user, or time zone, etc. So even if you’re rendering the same content teaser, contextual links may or may not show up depending on permissions, or the author name may or may not link to their user profile depending on whether you’re allowed to access it. The combination of cache ID and cache context affects which actual cache object the render API will retrieve when building a page.

Cache tags are stored with the cache items. So a list of ten nodes might have cache tags for each node in the list, as well as the authors of each node and any media items. When a node is updated, we invalidate its cache tags, and the next time that list of nodes is rendered, the tags are checked and it’ll be a cache miss. The list of nodes has to be rerendered, the node we updated has to be rerendered, but the other nine nodes in the list will usually be retrieved from the cache because they don’t have that cache tag.

The combination of cache contexts and cache tags means you’re showing the right thing to the right people at the right time.

Where people tend to get it wrong are areas like access checks. For example, if I’m implementing an access check depending on the author of a node, someone could come along, edit the node, and change the author, and my access check is still based on the old author. These bugs can be hard to track down because by the time a developer goes to look at the information being displayed, the cache may have been invalidated for some other reason.  By using RefinableCacheableDependencyInterface :addCacheableDependency($node);, when the node is updated, the access result cache will be invalidated too via cache tags.

Another area that people get wrong, or rather often don’t know exists, is placeholdering. So if you have something that is per user, ideally you want to placeholder that and we have a Placeholder API in the render system. If you have 200,000 users on a site, you don’t want to cache your entire site header 200,000 times - you want to cache as much as possible once, and their username separately, even though it’s rendered as part of the header. You can take advantage of the placeholdering API almost for free - it just requires using a #lazy_builder callback in a render array for the content that is per-user, instead of putting everything in there directly, then the render API will figure out that this is content which needs placholdering almost by itself.

Jan 18 2021
Jan 18

What I needed to do

I develop and maintain several Drupal websites. I do some development on a server running cPanel (in a Linux account that is totally isolated from the account running any production sites), most notably theming work.

I wanted to develop a custom subtheme of the Drupal base theme Barrio (a Bootstrap implementation). Because I like using Sass as a CSS pre-processor, to give me maintainable source files, I wanted to use the Barrio SASS Starter Kit theme as a starter. (It is itself a subtheme of Barrio).

That starter kit uses Gulp to generate the final stylesheets.

So, to do any theming work from a cPanel account, I had to find out how to run Gulp scripts from within cPanel. Gulp runs on node.js.

What I'm about to describe will work with other Drupal themes that use Gulp, and will also work for Drupal themes that need other tools (such as Grunt).

The Red Herring

For cPanel hosting, I have used Veerotech for several years. They are excellent and I highly recomend them. Technical support, when needed, is timely day or night. You talk to actual techs employed by Veerotech themselves (never outsourced). As someone who is fairly competent in web hosting (having run servers myself using various control panels, and no panel), if I need help I'll ask a question that is phrased in the correct technical terminology. Unlike some other providers, they engage me on that level, read and understand the actual question asked, and almost always resolve first time.

In particular, they offer two things, that I thought might have been enough. 1. With only a helpdesk ticket and a five minute wait, any account can have console / shell access. 2. Their CloudLinux setup includes the tool to create a Node application within the cPanel UI, including allowing you to run it from an external (sub)domain if you want an actual website powered by Node.

I don't need public access, but I hoped that this access to Node might give me a way to run the Gulp script from my Barrio subtheme.

Alas, no. The cPanel / CloudLinux Node application system assumes you'll be running Node only from within the directory where you create your app. If I tried to run the Gulp script for my theme, it couldn't see dependent modules (like PostCSS). So this was not the answer.

But I found a solution that works, and it's really quite easy when you know how. In fact, it's elegant and cleaner than creating a Node application that is accessible (but does nothing) from the public internet. Here's how:

Node Version Manager

Node Version Manager is a package that, in its own words, "a version manager for node.js, designed to be installed per-user, and invoked per-shell. nvm works on any POSIX-compliant shell (sh, dash, ksh, zsh, bash), in particular on these platforms: unix, macOS, and windows WSL."

The important bit is "per-user". It is installed by the user wanting to run it, in the shell they wish to use. Root permissions are not needed.

Step 1: Install Node Version Manager

The docs tell you to run one of these two commands.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

Personally, I never pipe curl or wget straight into a shell command. Should the download be corrupted or fail to finish, you could accidentally run half a script and leave things in an unstable state. So I did this:

wget https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh
bash install.sh

The version number (0.37.2) was current at the time I ran the install script. Obviously, use the download current when you run it.

This will install Node Version Manager into a directory within your home named .nvm , and attempt to append lines to your .bashrc file that sets up the environment and path for future use. It also prints to screen how to run those commands yourself, in case you don't wish to log back into the shell (or source .bashrc).

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Step 2: Install Node.js

In theory, you just run

nvm install node

I tried that first, but hit a problem. The gulp script for the Barrio subtheme calls node-sass.

In particular, it called version 4.14.1 of node-sass, which threw an error because that version does not support 15.x releases of Node.js. By the time read this, a different version of node-sass may be called (5.0.0 does support Node.jx 15). So you may be able simply to run the command above.

In my case, I had to look at the release notes for node-sass 4.14.1, and see that the highest supported version of Node.js was 14. I then went to the table of releases for Node.js where I saw that meant installing Node.js 14.15.4. That should be possible with

nvm install 14.15.4

but for some reason that hung without completing. The release table also told me that 14.15.4 was the current long-term support version, so I ran this command without any trouble:

nvm install --lts

Step 3: Install the required modules for the project

I was now able to call the commands on the Barrio SASS project page. Install both Bootstrap Barrio and Barrio SASS, run the command included with Barrio SASS to create your own subtheme, navigate to the your custom theme directory, and run these two commands:

npm install --global gulp-cli
npm install

Step 4: Call gulp

Now, you just go to your custom theme directory and run:


That will pick up gulpfile.js in the project directory and compile the theme resources. It will then stay running, because the gulpfile includes gulp-watch, which means it will watch for when you change any of the .scss files and instantly rebuild the theme. So you may prefer to run

gulp &

to keep it in the background.

The Gulp script will also think you're running a full version of Node.js, which means it will attempt to launch a web serving process listening on a particular port on the localhost interface. None of that will work in a shared hosting environment. That's OK - you don't need it to. You just need Gulp to assemble the css files for your theme, which it will do.

Jan 18 2021
Jan 18

If you're a Drupal developer who designs information architecture (IA) for your organization and/or clients, then hopefully by now you're thinking in terms of entities, bundles, and fields, not limiting your thinking to only content types.

This article isn't going to dive into a lesson explaining what entities, bundles, and fields are as there is plenty of great documentation about that.

Back in the Drupal 7 and earlier days, it was common to look at an organization's data and map it almost exclusively to only content types (maybe a few vocabularies as well). With Drupal 8's and 9's Entity API now fully mature, it's time to check yourself and make sure you take into account all of the amazing entity types that are available in both Drupal core and well-used and -maintained contributed modules. 

With that in mind, the next time you are designing the information architecture for a Drupal site, be sure to consider the following entity types.

  1. User (core) - one of the original core entity types - still fieldable, but still not bundleable. For that, use…
  2. Profile (contrib) - this useful module allows you to create various "profile types" that can be associated with each user. Examples include "author" profiles, "contributor" profiles, and "VIP" profile.
  3. Vocabulary (core) - another original core entity type (if it ain't broke…)
  4. Content type (core) - the original and still the best, but often overused. 
  5. Block type (core) - new in Drupal 8, replaces Drupal 7 modules like Bean and Boxes that provided custom, fieldable block types. Block types are great for lightweight, reusable content that doesn't need a dedicated path on your site. Block types are great for supporting content. 
  6. Media (core) - starting with Drupal 8.4, media entities are now part of Drupal core. These are incredibly useful fieldable entity types if your site includes things like PDF files or videos (both locally-hosted and remote). For example, no longer do you need to create a "Document" content type to upload documents that are related to various other entities on your site. 
  7. Paragraphs (contrib) - this popular and well-maintained contributed module allows authors to mix and match various "paragraph types" (fieldable entities) in an effort to create custom layouts of (often) nodes. In this author's opinion, Paragraphs module is best used as a WYSIWYG replacement for the body field, and not as an overall page layout tool. The power of Paragraphs module lies in the fact that a site designer can create and style various paragraph types that site authors can then utilize to provide creative layouts for their content. 
  8. Drupal Commerce (contrib) - another extremely well-maintained contributed module provides several entity types related to ecommerce, including product types, orders, and more. 
  9. Comment types (core) - new to Drupal 8, allows your site to have different types of comments. This can be very useful, but in our experience, not used all that often.
  10. Contact forms (core) - new to Drupal 8 and similar to the Drupal 7 Entityform module. The idea was to create a Webform-like entity type, but in our experience, Webform still continues to be a better solution in the vast majority of use cases.

While this list isn't exhaustive, we believe these are the ones that most Drupal developers will most likely utilize. 

Drupal Career Online, our 12-week, twice-a-week, online Drupal training program teaches not only most of all of these entity types, but also how to figure out when to use each one. We also focus on how to work with various project stakeholders in validating the IA design early in the development process in order to keep costs and future changes to a minimum. 

Jan 18 2021
Jan 18

Websites have entered a new playing field now, at least compared to what they used to be a few decades ago. They are not one-dimensional anymore. They represent a multitude of different business agendas that are essential for growth and visibility.

Websites are not just limited to words, their world has widened progressively. From animations to social media integration, websites today can do it all. A major reason for these advancements in websites and their build is the software they are built on. And that is going to be the highlight of this blog.  

We will talk about the Content Management Systems and the Static Site Generators and shed light on their uses, their suitability and whether they can work in sync or not? So let’s begin. 

Understanding a CMS 

There is a time line showing the emergence of various open source CMSs.Source: Opensource.com

Commencing with the veterans, CMS or a Content Management System have been around for almost two decades (Drupal, one of the world leaders in web content management, was initially released on 15th January 2001). Despite being that old, the conventions they are built on and the features they have been added with over the years have resulted in CMSs being as modern as modern as can be. 

From easing the workload off of the bloggers’ shoulders to making newspaper editors happy; from catering for corporations and their digital marketing team to aiding numerous government departments online and transparent, a CMS has a wide audience. 

If I had to define a CMS, I would simply call it the one-stop destination for all your website’s content needs. It manages, organises and publishes web content. What is more impressive is that content authors can create, edit, contribute and publish on their own, they do not need to be dependent on developers for that. A CMS offers a collaborative environment to build and present websites, allowing multiple users to work with it at once. Terms like Web Content Management and Digital Experience Platform are being thrown around today and they are nothing, but a modern variant of a CMS. 

Getting into the meaning of CMS a little further, you would hear two versions of it and they are essentially its break down. 

  • First would be the Content Management Application. This makes marketers, merchandisers and content creators self-reliant. They can do the contextual heavy-lifting on their own with a CMA without the requirement of a code, so, none of the guys or girls from IT would be needed. 
  • Next is the Content Delivery Application. This is basically the foundation for your content; the back-end aspect that placed your content into templates to be further presented as one website. So, what your audiences see is provided by the CDA. 

Both of these together make a CMS whole for your use. 

Moving further, after the meaning, it is time to get a brief understanding of the various categories of a CMS. Based upon different categorisations, there are seven in all.

Based on the CMS’ role 


Most often, a traditional CMS is used on really simple marketing sites. I have used the term simple to describe it because it is just that, be it the layout or general functionality. You can create and edit your content using a WYSIWYG or HTML editor and it would display the content as per the CSS you have used.

With a traditional CMS, your entire site is encompassed by one software. The frontend and the backend are closely connected through it, hence, it is also referred to as a Coupled CMS. 


Unlike its traditional counterpart, the decoupled CMS separated the frontend from the backend. This means they work independent of each other and a change in the presentation layer does not necessarily affect the backend repository. Through decoupling, you get the features of more than one software to base your site’s architecture on. 


A headless CMS is more or less similar to a decoupled one. When you take up a headless CMS, your content would always remain the same, however, each of your clients, be it an app, a device, or a browser, would be obligated for the presentation of the content. 

The code in this instance is not in the CMS, rather it is an API that is used for communication and data sharing amongst the two software. This way developers can consume content through an API and content authors can start adding content at the same time. If you are looking for the ‘one size fits all’ approach, this is where you will find your answer. 

Based on cost and ownership 

Open source 

Open source CMSs are the ones that are free of cost, at least initially. You do not need to pay for any license fee for its installation; however, there can be costs that you may incur for add-on templates and more such features. 

Open Source CMSs are pretty popular today, the reason being their thriving community of developers. This results in the veterans redistributing and modifying the code, which not only leads to perpetual software improvements, but also helps the newbies in making progress. 


A proprietary CMS is the exact opposite of an open source CMS, meaning it is commercial and mandates a licensing fee along with annual or monthly payments. In return for the payments, you would get an out-of-the-box system to meet all your companies requirements, continuous support and built-in functionality.

Based on the location 

On premises 

As the name suggests, this is a CMS that has a physical presence within the company’s premises. The high degree of control it offers to its users is the reason for its popularity. However, the humongous investment and the chances of human error dampen its potential. 


The name gives it away. Such a CMS is hosted on the cloud and delivered through the web. It is essentially the combination of web hosting, web software components and technical support. It provides fast implementation and deployment along with accessibility from across the globe on any device.

Why choose a CMS? 

Moving further, let’s now delve into the multitudinal features that are packed inside a CMS making it a suitable choice for you and your organisation’s virtual needs.

If I had to broadly categorise all the features of a CMS, I would end up with three major categories, which will sum up the true potential of this software. 

Content and its production needs

Producing content is the primary reason anyone takes on a CMS. It is true if you are a blogger and it is also true if you work for an educational institution and its online persona. It is the content that speaks for itself, when it comes to your site and it needs to be pristine, for lack of a better word. And CMSs help you achieve a level of control over your content production that you desire.

  • Starting with the edits, the WYSIWYG editor could be deemed as the heart and soul of a CMS. It provides you formatted text in paragraphs with quotes, superscripts, underlines as well as images and videos. Your authors would not have to work around codes for sure. 
  • Focusing on the media, images are an important part of it. Every CMS has room for them, they can be uploaded directly from your computer or archives, either within the content or you can add them in the page itself. The same is true for pdfs, animations and videos. Videos also have the option of being embedded through Youtube. 
  • Furthermore, CMSs also support multilingual and multi-channel sites. This eases the pressure off of the content authors and makes localised projects easy to run. 

Content and its presentation needs

Presentation is all about design, how it is done and how it would be showcased to the end user. There are a lot of design considerations that a CMS can help you with. 

  • A CMS would have you sorted with the right font and its size and the right colours and contrast. 
  • A CMS would have your sorted with the right responsiveness for your site. 
  • A CMS would have you sorted with the right URLs and URL logic. 
  • A CMS would have you sorted with the right templating tools to change your layout. 
  • A CMS would have you sorted with the right hierarchy for your site as well as provide the right prominence to the aspects that need it. 
  • Finally, a CMS would have your site sorted for all the right accessibility protocols to make it universally accessible. 

Content and its distribution needs

Once the content is produced, its distribution comes into play. This has a direct impact on your site's visibility. And CMSs ensure that you get the most out of it. 

  • The foremost part of distribution needs is metadata. This helps in tagging, categorising and describing your content. It includes everything from keyword insertion to identifying the distribution channels and placing access restrictions on the content. 
  • Secondly, CMSs also come equipped with automated marketing tools like analytics and A/B testing that help you understand user behaviour and help you capitalise it. You would just have to define the parameters and the automation would do the rest, be it publishing on your site or email marketing. 

Content and its management needs

Then comes the management of your content, it is a perpetual process that helps in providing an ease to the editors and developers that streamlines the builds and updates of a website. 

  • For one, a CMS helps you plan and execute the publishing of your content. You can actually schedule when and what to post and where to post it. You can also decide when something would be available for the audience to see and when it won’t be like an events’ post. Once the event has happened, it won't need to be on your site anymore and a CMS helps with that. 
  • CMSs also help you to figure out user roles and implement them. This helps in ensuring that sensitive information is only accessible to the users who have the clearance. A manager and a director are going to have different roles, so does a premium member and a regular member of your site. 
  • Finally CMS helps you in avoiding instances where you delete something important and its recovery becomes impossible. Version control and revisions are a feature that has to be in your CMS, if you want the powers to bring back the lost content. 

Apart from these main categories, CMSs are also renowned for their security, their scalability and user friendliness. There is one more thing to add and that is the fact that a CMS can go above and beyond it capabilities by integrating itself to third-parties and combining their features with its own, a headless CMS is an example of the same. Drupal is one of the most popular CMSs, when it comes to going headless. Read our blog, Decoupled Drupal Architecture to know more about it.

Understanding a new vogue: Static Site Generators 

Before understanding a static site generator, let’s shed some light on static sites, since these are what it builds. A static site is the one that is designed in a way that it remains static, fixed and constant, during its design, its storage on a server and even upon its delivery to the user’s web browser. This is the attribute that differs it from a dynamic, it never changes, from the developers desktop to the end user’s, it remains as-is.

Coming to Static Site Generators or SSG, in the most basic of terms they apply data and content to templates and create a view of a webpage. This view is then shown to end users of a site. 

Now let’s get a little technical, you know that an SSG will only create static sites, it does so by creating a series of HTML pages that get deployed to an HTTP server. There would only be files and folders, which points to no database and no server-side rendering.

Developers using an SSG, create a static site and deploy it to the server, so when a user requests a page, all the server has to do is find the matching file and route it towards the user. 

If I talk about the difference between an SSG and a conventional web application stack or a CMS, I would say that it is in the view of webpages. While an SSG keeps all the views possibly needed for a site at hand well in advance, a traditional stack waits until a page has been requested and then generates the view.

Why did SSG come along?

Static Site Generators act differently than a CMS, they are more aligned with the needs of static sites. However, their emergence has a bigger story to tell. 

Yes, CMSs are quite popular today, yet there is a drawback to that. With the rising acclaim of CMSs, some of them have become more prone to cyberattacks. The lead in security hacks goes to WordPress, with almost 90% of all hacks being experienced by it as reported by ITPRO reports of 2020. But, Drupal is considered the most secure CMS as can be seen in Sucuri’s 2019 Website Threat Research Report.

Then there is the issue of performance. CMS sites operate mainly upon their servers, meaning they do the heavy-lifting. If a request is sent, it would mean the server taking the charge of the page assembly from templates and content every time. This also means that for every user visiting your site, the PHP code would have to be run to start up, communicate with the database, create an HTTP response based on the recovered data, send it to the server and then finally, an HTML file is returned to the user’s browser to display the content after interpretation. All of this may impede the performance of the site built on CMS when compared to the one powered by a static site generator. But, it’s not like CMSes give you low-performance websites. They do have provisions for delivering high performance websites. It depends upon which CMS you go with. If web performance is your concern, Drupal can be your go-to option.

An SSG is a solution to these two conundrums, hence, it emerged with a bang. 

What can a Static Site Generator do for you?

there is clock in the middle with the benefits of a CMS written around it.

Static Site Generators solve a lot of the issues that a CMS cannot, consequently they can provide you a lot for your site’s well-being. 

SSG means better security 

In an SSG, the need for a server is non-existent and this is the reason it provides more security. As we have already established that an SSG is rendered well in advance and its ready-to-serve infrastructure helps remove any malicious intent upon your site. This infrastructure essentially eliminates the need for servers, they do not need to perform any logic or work. 

Apart from this, with SSG, you would not need to access databases, execute logical operations or alter resources for each independent view. As a result, there is an easy hosting infrastructure as well as an enhanced security because of the lack of physical servers required for fulfilling requests. 

SSG means elevated performance 

A website’s performance is concerned with its speed and request time, and SSG provides in this area as well. Whenever a page is requested, it involves a whole bunch of mechanism to get it displayed for the visitors. There is the distance it has to cover, the systems it has to interact with along with the work that those systems do. All of these take up time, shadowing your performance. 

Since an SSG site does not mandate such a lengthy iteration per visitor request, it reduces the travel time. This is done through delivering the work directly from a CDN, a distributed network of caches, which aids in avoiding system interaction. Resultantly, your performance soars 

SSG means higher scalability 

When an SSG builds a site, it is often considered pre-built. I mean that is what building all the views in advance of an actual request could be defined as, right? So, with a pre-built site, you have less work on your hands. For instance, a spike in traffic would not mandate you to add in more computing power to handle each additional request, since you have already done all the work beforehand. You would also be able to cache everything in the CDN and serve it directly to the user. As a result, SSG sites offer scalability by default. 

When should you choose a Static site generator?

Now that you know how an SSG can benefit you, it is time to understand the scenarios that would mandate taking up a static site generator and all its advantages. 

When building complex site is the goal 

If you want your website to deliver more complexity, in terms of the kind of features it provides, SSG becomes a good choice. There are many that come equipped to provide you client-side features that are ready to go. 

When creating and displaying content is the only goal

Here SSG is a suitable choice because it would generate pages and URLs for you. And these pages would give you a 100% control over what is being displayed, meaning the output would always be in your hands; content pages need that. 

When generating numerous pages is the goal 

A static site generator can create pages at a great speed. It might not be seconds, but it is quite fast. So, when creating websites that would need a lot of pages to be created, SSG’s speed comes in quite handy. 

When templating needs are complex as well 

An SSG is a powerful software, it has the ability to assess your site’s visual style and content along with its behaviour and functionality. This feature becomes fruitful, when building a website with diverse templating needs. Vue and React based SSGs would definitely help you get the versatility you need on your website, along with the standard use of concept of code reuse on your site. 

I would like to add just one more thing, and that is the fact that your team must be familiar with the static site generator that you are going to end up using. There are a lot in the market. If your team is familiar with .net, use and SSG powered with it. On the other hand if it finds JavaScript more familiar territory, go with an SSG based on that. Let your development team be a part of the discussion, when the suitability of a static site generator is being decided. 

Are Static Site Generators always the right option? 

Coming from the suitability, you would think that an SSG is a great choice. Don’t get me wrong, it is. However, it isn’t a universal software. There are instances when it may not be the right choice. So, let’s delve into these scenarios.

Not when you do not have development experience 

Static Site Generators become a tad bit difficult for amateur developers. Your developers ought to have experience to reap all its benefits. The building process is considered to be more difficult than that of a CMS, something that finding plugins for pre-built pages acn become a chore. Furthermore, there isn’t a huge community out there to help you in the development part, if you are a beginner. 

Not when you need a site built urgently 

You have to understand the urgency and SSGs are not the best of friends. From learning the build process to developing the template code, everything needs time. 

There are development scripts to be me made;
There is the complication of customised them;
There is the additional process of creating and setting Markdown files;

All of these account to more time requirements for the development process. Think of it like this, you are going to be doing all the grunt work beforehand, and that would necessitate more time. 

Not when you need server-side functionality 

When partnering with an SSG, you would be parting with some, if not many, interactive functions on your site. For instance, user logins would be difficult to create, so would web forms and discussion forums. However, there are certain options like lunr.js search and Disqus commenting to help you with your sites interactivity. I would say that these options are pretty limited.

Not when your site has to have hundreds of pages

You might think that I am contradicting myself, however, I am not. Static site generators can create a website with a thousand pages, yet the process can become tedious and awkward. For a thousand or so pages, the content editing and publishing would be cumbersome. Along with this real-time updates could get delayed and like I mentioned before build times rise consequently.

Not when website consistency is a priority 

Lastly, SSG sites offer a lot of flexibility. That should be a good thing, however, it does have a side effect and that is on your site’s consistency. This is because anything that is found in the Markdown files can be rendered as page content. Consequently, users get the chance to include scripts, widgets and other undesired items. 

Can a CMS and an SSG work together? 

Yes, a CMS and an SSG can work together and pretty efficiently at that. However, that partnership is only possible in a headless CMS. This is because a headless CMS gives room for other frontend technology to come and play and in this case that technology is found in static site generators. 

A headless CMS is pretty versatile, choosing a static site to go as its head could help you get most of the benefits that both, the static site and headless CMS, come along with. This partnership indeed has a lot to offer. Let’s find out what that is. 

Two hands shaking can be seen on the left, with the benefits of a CMS and static site generators' partnership.

Proffers easy deployment via APIs

SSGs are quite straightforward to use, especially with an API, which is the connecting force between the SSG and the CMS. Pulling data from an API for generating and deploying a static PWA to any web host or Content Delivery Network is a breeze. 

Proffers ease to the marketing team 

When you work only with an SSG, you would face difficulties as it puts a lot of boundations on the marketing team. This isn’t a problem when you partner with a CMS. 

Proffers easy editing and workflow 

Conventionally, SSGs do not have a WYSIWYG editor or workflow capabilities for the tracking and collaboration of content. You might think that it is only needed for dynamic sites, but that isn’t the case. Static sites also need that. Since CMSs have that capability, they become ideal for content before actually running the SSG; the perfect contextual partnership. 

Proffers easy updates to sites 

With a CMS, you can easily change and update the content. With an SSG, the same changes can be pulled up through the APIs and a new static site can be generated every time they are incurred. All the developers have to do is set a tool up for content pulling and generation. As a result, your site would always be up-to-date and the users would not need to be processed whenever they visit your site. 

To check out some examples of how CMS and SSG can come together, read how Drupal and Gatsby can be leveraged for developing blazing fast websites. You can also go through the benefits of going ultra-minimalistic with the combination of Metalsmith and Drupal.


In the end, all I want to say is that both a CMS and an SSG have their own set of features and capabilities that make them excellent at what they do, making their users more than happy. However, when it comes to getting the best out of both of them, there is only one kind of CMS that can help you reap the benefits of this dynamic. It is up to you to decide whether you want to use them together or individually.  

Jan 18 2021
Jan 18

What does it mean for our clients?

Choosing a technical agency to work with, no matter what the project may be, can’t be left down to a quick flick through page 1 on Google?

You take time to research your impending investment, making sure it right for your needs otherwise it’s your head on the chopping block. 

Our whole work ethic is based around websites being about people, not just an online presence. 

Working to develop our teams’ skills is an essential part of training, to provide the best level of service to every client we work with. It’s important to be able to have the skillset clients can rely on. 

Alongside our even more advanced specialists in the team who have achieved the ultimate title of  Drupal 8 Grandmasters - Paul Jones and Andy Rigby - our clients have the highest level of technical experts, both within Ixis and the country, working on their sites daily. 

Our team have a whole host of Acquia certificates across our departments & the grind to achieve more doesn't stop!

Jan 18 2021
Jan 18

Human-centered design is a concept that gained traction in the 1990s as an approach  to developing innovative solutions based on a laser-sharp focus on human needs and human perspectives during every phase of a design or problem-solving process. Building upon the principles of human-centered design, Promet Source has served as a pioneer and leading practitioner human-centered web design. 

At the core of our approach to human-centered web design is a deep level of inquiry that questions all assumptions and engages key stakeholders in various exercises that call for letting go of individual preferences and moving toward an empathetic focus on optimizing the experience for the user. The results reveal new possibilities on multiple levels.

With an overarching emphasis on empathy, we look to open new opportunities by understanding the needs and expectations of the people who actually use the website. Sometimes this sparks a mindshift, that reorients the site architecture away from an organization’s internal structure, and focused instead on user journeys.
Too often, websites are architected from the perspective of insiders -- organized by department, without stepping back to ask: 

  • Who visits the site? 
  • What kinds of information are they seeking? 
  • How can we align the navigation of the site around what makes sense to users? 

The best web experiences leverage empathy, and begin with human-centered design processes that dig deep and question any all assumptions about how users’ interactions with the website can it be designed to ensure that they and easily find the information they need and that their experience of visiting the site is both engaging and value added. 

At Promet Source, we approach human-centered web design as a seven-step process.


1. Build empathy with user personas

The first and most essential question: For whom are we building or redesigning this site? Following the identification of the key persona groups, we proceed to dig deep, asking “why” and “how” concerning every aspect of their motivations and expectations.

2. Assess what user personas need from the website

Understanding of and empathy for user personas dovetails into an analysis of how they currently use the site, how that experience can be improved, and how enhancing their experience with the site can drive a deeper relationship. 
This level of inquiry at the front end might feel excessive or out of sync with what many are accustomed to, but as Tom Gilb, noted in Principles of Software Engineering Management, getting it right at the outset pays off tenfold over the cost of fixing after the site is released.

Ensuring that projects get off to an excellent start is at the core of what human-centered design is all about.


3. Map their journeys through the site to key conversions

Just as user groups do not all fit the same mold, what they are looking for from your site will vary, depending on what phase they are in relative to their relationship with your organization – what we refer to as the user journey. 
Too often, website design focuses on one aspect of the user journey. It needs to be viewed holistically, taking the perspectives of all user groups into account.


4. Identify Obstacles in their path.

Next step: identify challenges. We map user journeys through every phase, aiming for seamless transitions from one phase to the next.
This step calls for continuous inquiry along with a commitment to not defend or hold on to assumptions or previous approaches that may no longer be optimal, while pursuing answers to questions such as:

  • What have we heard from clients? 
  • Where have breakdowns occurred in conversions and in relationships?
  • How can we fix it with the messaging, design, or the functionality of the website?  

5. Brainstorm objectives

Our facilitated workshop setting is structured to build upon a productive flow of ideas via several exercises that draw upon stakeholder perspectives and expertise from multiple angles.

6. Prioritize solutions

While there are “no bad ideas in brainstorming,” in the real world of budgets and time, questions such as “how,” “what’s the cost,” “where to begin,” and “what will have the best impact,” need to be considered. 

As ideas are synthesized, these answers will begin to take shape.  

7. Create a roadmap for development

Too often, web design and development begins at this step. 
With human-centered web design, a depth and breadth of research, persona development, empathetic insights, journey mapping, solution gathering, collaborative energy, and excitement about what’s to come have already been invested when we get to this point. 
As a result, clients have the advantage of moving forward with a high degree of alignment among stakeholders, along with a conviction of ownership in an outcome that will enhance both the experiences and relationships with the humans who visit the site. 

Human-Centered Design Activities

The above steps help to define the “What” of human-centered web design. The “How” of human-centered web unfolds during facilitated workshops. Here are some of the activities that we leverage in the process of bringing human-centered web design to life.

Persona Development

Persona development example

Identifying individual personas helps to define the range of differing user needs and expectations, for purposes of tailoring solutions accordingly. 

Giving every identified persona a name helps to humanize the exercise and reinforces empathy for the actual users of the site. It also serves as a ready reference point or shorthand for further conversation for questions such as: 

  • What else is Joshua going to expect from this page?
  • Will this navigation make sense to Alexis?


This exercise is designed to quickly gather a significant amount of data in response to specific and essential questions. Adopted from a Luma Institute collection of exercises, participants are given brightly colored Post-It® notes and asked to write everything that they view as an advantage or a plus on a pink (Rose) Post-It. Challenges or downsides are to be written on a blue Post-It (Thorn). Green

Post-Its are for collecting input on potential or emerging for opportunities (Bud). 
Every participant’s opinion ranks equally as responses are gathered and grouped on a white board according to identified categories. 

Affinity Clustering

Affinity cluster example

During this next step, the “Rose-Thorn-Bud” input is organized according to agreed-upon groupings, to reveal patterns, surface priorities, bring order to complexity, and spark productive conversation.

The use of different colored Post-Its is particularly useful in revealing that within a particular category there might be a mix of challenges, opportunities, or advantages. Participants might also have differing opinions as how to characterize a particular attribute.

For example, some stakeholders might view the current site architecture as a Plus (Rose), others might view it in terms of the inherent opportunity or potential (Bud), while others might be largely focused on the challenges of the and ways that the site’s architecture falls short (Thorn).  

In all cases, this exercise sparks engaging conversations and reveals new opportunities for achieving consensus.

Stakeholder Mapping

Stakeholder mapping results in what is essentially a network diagram of people involved with or impacted by the website. Typically, there are considerably more stakeholders than originally thought, and stakeholder mapping evaluates all the possible users of a system to then identify and prioritize needs and expectations. 

Abstraction Laddering

During this exercise, we guide teams through the process of deconstructing a goal as dig deeper into questions concerning “How” and “Why” for purposes of advancing toward greater clarity and specificity. 

Let’s take the example of the statement: “We need to get more visitors to sign up for a demo?” which on its own does not offer much context to develop an action plan. 

During a human-centered design workshop, we’ll move up the ladder going at least three deep to record answers to “Why” and down at least three deep recording answers to “How.” 

Importance / Difficulty Matrix

importance difficulty matrix

Inevitably, some of the ideas that emerge will spark excitement for the strategic leap forward that they could represent. The required time and resources to move forward with them, however, might exceed current capabilities. Other ideas might fall into the category of Low Hanging Fruit -- initiatives that can be achieved quickly and easily.

Plotting every idea on an Importance / Difficulty Matrix is an essential group activity that sparks conversation and accountability concerning Who, How, and When -- transforming good ideas into action items.

In the current environment, organizations tend to be defined by their digital presence. The stakes for getting it right are high and the margin for error is low. Optimizing ideas and perspectives at the outset, and continuing to iterate with feedback creates a strong starting point that serves as a superior foundation for web solutions that are capable of heavy lifting over the long haul. 
Interested in learning more about the possibilities for a human-centered design workshop in your organization? Contact us today.

Jan 16 2021
Jan 16

Drupal's Problem With Decorative Images

Decorative images are those that should not be described to assistive technology like screen readers. A simple example is a fancy image of a decorative border that you insert at the end of a news article.

Supporting decorative images in Drupal is quite straight forward. Images fields can be set to collect alternative text but not require it. When left blank, Drupal will output an empty alt attribute for the image element, indicating to screen readers the image should be ignored. Editors that want to convey that an image is decorative can then simply leave the alt text blank.

The problem with this approach is that it might encourage editors to leave alt text blank even if the image is not really a decorative. It's easy to pass right by the alt text field without even thinking about it. This is especially true for those that are completely unfamiliar with how important alternative text is for accessibility.

There's a small effort underway to resolve this problem in Drupal core. After some great discussions, particularly with Andrew Macpherson, a leading voice in Drupal accessibility, we landed on a potential solution (thanks Andrew!).

A Potential Solution

Instead of simply leaving the alt text field blank to the image is decorative, a checkbox labeled "Decorative" is introduced beneath the field. This checkbox must be checked if the editor wants to leave the alt text blank. This effectively makes the choice explicit rather than implicit, forcing the editor to pause for a second and consciously affirm that the image is truly decorative.

To let this solution incubate and evolve a bit, I contributed it as small module called Decorative Image Widget. It's quite flexible as instead of providing a brand new image widget, it modifies any image widget that is based on the default one provided by Drupal core.

Check it out and please provide feedback in the module's issue queue!

Jan 15 2021
Jan 15

20 years ago, the Drupal project started in a dorm room—today it is a billion dollar industry.

PORTLAND, Ore., U.S.A and LOCAL AREA HERE, January 15, 2021—Drupal, the world’s leading open source digital experience platform (DXP), celebrates 20 years of community-driven innovation. Since its founding 20 years ago, Drupal has touched millions of lives. One in 30 sites on the web is powered by Drupal, and that means most users of the web have experienced Drupal—even if they don't know it. 

Drupal has pioneered the evolution of content delivery across multiple channels. Whether powering conversational user interfaces (CUI) for smart devices, pushing content to digital signage for New York Metropolitan Transportation Authority (MTA), or serving as the core content store for augmented reality experiences, Drupal’s sophisticated architecture and platform stand ready for the future of digital content. 

Redefining digital experiences

7 years ago—on the eve of Drupal's birthday—Drupal founder and project lead, Dries Buytaert, laid out his belief that the web was entering a new era. 

Mobile had transformed the web, but I believed this was just the beginning. The mobile web was the first example of a new web defined by digital experiences that conform to a user's context and devices,” says Buytaert. “Since then, Drupal has defined itself as the leading platform for ambitious digital experiences, and as channels and devices proliferate, Drupal will continue to lead the open source DXP market.

Powered by a global community of innovation

As part of this 20 year milestone, we celebrate our community of more than 100,000 contributors who made Drupal what it is today,” says Heather Rocker, executive director of the Drupal Association. “Success at this scale is possible because the Drupal community exemplifies the values of open source and proves that innovation is sustained by healthy communities. One of our key goals at the Drupal Association is to convene the resources necessary for continued project innovation, and we do that through the collaboration of a global community that continues to grow year after year.

In fact, Drupal contribution increased by 13% in a year when many industries contracted due to the COVID-19 pandemic. Drupal's open source model has built a robust and thriving ecosystem of individual contributors, professional service providers, and end-user organizations that is well positioned to capitalize on the next 20 years of digital innovation. 

Drupal continues to evolve, serving needs around the globe and expanding into new markets.  Future-looking priorities include a continued positive impact on the Open Web, the cultivation of a diverse and inclusive open source community, and an increased focus on editorial experience and usability—to make the power of the Drupal digital experience platform even more accessible.  

2021 will be marked with year-long celebrations happening around the world with particular focus at DrupalCon in April. Related 20th birthday events can be found on social media through the hashtag #CelebrateDrupal and at CelebrateDrupal.org.  

About Drupal and the Drupal Association

Drupal is the open source digital experience platform utilized by millions of people and organizations around the world, made possible by a community of 100,000-plus contributors and enabling more than 1.3 million users on Drupal.org. The Drupal Association is the non-profit organization focused on accelerating Drupal, fostering the growth of the Drupal community, and supporting the Project’s vision to create a safe, secure, and open web for everyone.

For more information or interview requests contact Heather Rocker,  [email protected]


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web