Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Apr 18 2021
Apr 18

Spring 2021 Drupal Career Online class photo

We're halfway through the 12-week Spring 2021 Drupal Career Online semester, with a wonderful group of nine Drupal students. We are just finishing up our spring break/independent study week, and looking forward to diving into module and theme development, followed by team workflows, the configuration system, and more before we confer their certificates at graduation on May 19th. During the first half of the course, we spent lots of time with information architecture (entities, bundles, and fields) as well as Composer, Drush, and Git topics. 

Some insight on this semester's class:

  • Includes students from 3 countries.
  • There are one or more Windows, Mac OS, and Linux users.
  • Some are brand new to Drupal, while others are Drupal content managers, and Drupal 7 developers.
  • They have varying levels of previous Drupal, command line, and Git experience.

Since different students have different goals, they are all taking advantage of the wide range of resources we offer to help each student achieve their personal/professional goals. This includes office hours to help students work through course or non-course related Drupal issues, screencasts for every lesson, and one-on-one community mentors for every student.

Our next semester of Drupal Career Online begins on August 30. If you know someone who might be interested in applying, they can learn more at one of our free, 1-hour Taste-of-Drupal information webinars.

Feb 22 2021
Feb 22

If you manage a Drupal site that has constantly changing content, you may have concerns about the size and contents of the /sites/default/files/ directory. For most Drupal site maintainers, this can often be a source of anxiety, not ever really knowing what it contains and what, if any of the uploaded files are obsolete. 

Any method you utilize to solve potential issues is going to be tedious, but the Audit Files module can help make it a little less painful. This module provides several reports (generated using some user-configurable parameters) that can help you wrangle things:

Audit files module screenshot.

As an example, the "Not in database" report will show you a list of files that exist in /sites/default/files/, but are not managed (have not been uploaded via a file field) in Drupal. This list might include files directly uploaded via SFTP or some other method, so be careful what you delete, but it will definitely give you a head-start on identifying files that might be safely deleted.

If you feel that your site's files directory is a bit out-of-control, this module may be a good first step in cleaning things up.

Feb 08 2021
Feb 08

This may be the quickest quicktip we've ever written - if your site doesn't require the "Request new password" functionality, the No Request New Password module makes it pretty easy to remove it. 


No Request New Password screenshot - before


No Request New Password screenshot - after

Also - the module doesn't just hide the "Request new password" link, it removes the functionality completely, so if a user navigates directly to /user/password, they'll be redirected back to the login page. 

Feb 03 2021
Feb 03

I was poking around the Drupal.org project usage page over the holidays checking out some trends and making sure there weren't any up-and-coming contrib projects that haven't been on my radar. Since Drupal 8 was released (over 5 years ago!) I've been bothered by the fact that this page can't be filtered by the Drupal core version.

Along the way I fell into a bit of a rabbit hole and decided to dig much deeper into Drupal.org statistics. But first, let's take a look at contrib projects.

Most installed contrib projects

An incomplete workaround to finding the most installed contrib projects by Drupal core version is to use the module search page and filter it by Drupal core version and sort by "most installed." While this provides a list of modules, it doesn't provide historical trends as the project usage page does. Regardless, here's some data:

Top 5 installed Drupal 8 and 9 contrib modules 

Top 5 installed Drupal 7 contrib modules

Top 5 installed Drupal 9 contrib themes 

Top 5 installed Drupal 8 contrib themes 

Top 5 installed Drupal 7 contrib themes

While this data is somewhat interesting, there really aren't any surprises.

Drupal.org usage statistics

For that, I recently requested, and received access to the Drupal.org analytics from the Drupal Association with the goal of looking at some usage statistics from 2020 and to dig a little deeper into what Drupal developers were up over the past 12 months.

I wasn't interested in doing a complete statistical analysis of the data and comparing it with historical data, rather I was just looking for things I thought were cool. Plain and simple.

All data below is for the time period of January 1, 2020 - December 31, 2020.

First off, I'm not a data scientist - I'm just a nerd who likes to look at data sometimes, so some of the assumptions I make below may be off-the-mark. If so, feel free to correct me.

Let's start off with some basic stats - in 2020, there were about 50,000 users on Drupal.org on any given weekday. Anecdotally, the daily December average was around 5,000 users/day higher when compared with January.

Who are we and how are we accessing Drupal.org?

Where are the users coming from? Not surprisingly, the largest percentage came from the United states, but more visitors came from India and China (when combined). Clearly, we need to do a better job in recruiting from these areas to be more involved in Drupal leadership. 


  • 20% US
  • 12% India
  • 11% China
  • 5% Sweden
  • 3% United Kingdom

Interestingly enough, when looking at the top 10 cities where Drupal.org traffic originates, 6 of the top 10 are from China and India. In order, they are: Beijing, unspecified, Stockholm, Chicago, Bengaluru, Chennai, London, Mumbai, Hyderabad, Pune

The majority of visitors' browsers report their language as English, with Chinese the next largest share. This seems to imply that many of the visitors from India speak English well enough to have their browsers set to use English.


  • 49% English (US)
  • 12% Chinese
  • 9% English (GB)
  • 3% English (unspecified)
  • 3% Spanish

Some other interesting statistics about who is visiting Drupal.org:

  • 85% are new visitors - this seems (very) high to me, and I'm going to attribute (at least a portion of it) to folks with privacy controls that make it seem like they're a new visitor.
  • Over 60% of visitors use Chrome, with almost 50% on some version of Windows, and 80% using a desktop browser.
  • Over 60% of users arrive via an organic search - this is not surprising to me at all, as I routinely (multiple times a day) use Duck Duck Go to search for content on Drupal.org rather than use Drupal.org's search tool.

What are we looking at?

Now for the data I was really I was interested in finding - which topics, issues, and projects we were actually looking at in 2020. To do this, I focused mainly on the top 100 most visited pages on drupal.org. 

Hash-tagged numbers indicate the page's position in Drupal.org's overall most visited pages ranking.

Most visited contributed projects

No huge surprises here, except I'm still amazed by the popularity of Bootstrap (keep in mind there are multiple Bootstrap-based base themes as well!) I was also a bit surprised at the popularity of Commerce, not because it isn't an amazing tool, but because I would've guessed other projects would be above it (Redirect module, for example, is #46).

It's also interesting that Webform was the most visited contributed project page, but didn't appear in any of the "most installed" lists above.

Most visited topic-specific documentation pages

Unsurprisingly, the top 2 most visited documentation pages (that aren't landing pages) were related to Composer. 

Most visited contrib project issues

This was probably the most unexpected and unexplainable data I found. No way I would've ever guessed that the most visited contrib project issue would be for the Commerce Braintree module. Luckily, it is marked as "fixed", I can only imagine that the traffic was primarily to access the patch? 

Then, the second most visited issue is related to the Image module for Drupal core version 5.x? It's traffic is pretty consistent for all of 2020. The only thing I can think of to possibly explain this is that the thread has a magic combination of keywords that put it high in organic search results (well over 90% of the traffic to this page originates from search engines).

Most visited forum post

How to login to Drupal admin panel (from 2017!) #84

Yes, the Drupal.org forum is still alive and people are still accidentally getting locked out of their sites.

Most visited page without a path alias

How to fix "The following module is missing from the file system..." warning messages (from the "Reference" section) #43

Oh yeah - I've definitely been someone who has searched for, and landed on this page.

Most visited Drupal core issues 

I didn't know what to expect when I went looking for the most visited Drupal core issue, but as soon as I found #216, it made perfect sense. I feel like you are in the minority of users if your Drupal core 8.8 update went smoothly.

Most visited Drupal core release pages 

I'm at a loss to explain why these core release pages were visited more than any others. Overall, there were 6 Drupal core release pages in the top 200 most visited pages.

Most visited pages overall

After the home page, the top visited pages were the project search, the download page, Drupal core, user Dashboards, the theme search, the User Guide, and Try Drupal.

None of these are all that surprising or interesting, at least to me, but included here for completeness. 

Finally, I was curious as to how many of the top 100 most visited pages were documentation pages (12) and contributed project pages (46).


A few things that I took away from this exercise:

  • Traffic to Drupal.org increased during 2020.
  • Composer continues to be a pain point in the community.
  • The contributed module ecosystem continues to be one of the crown-jewels of the Drupal community.
  • Pathauto should be in core (try to convince me otherwise)
  • Should the community consider tweaking metadata for pages related to older versions of Drupal core so they don't rank as high in search engines?
  • There seems to be an opportunity for new contributors to be provided with a list of the most visited forum, reference, and issue pages and convert those that make sense into documentation pages.
  • Why aren't a commensurate percentage of people from places with high numbers of users community leaders, and what can we do collectively to remedy it?

Thanks to Tim Lenhen from the Drupal Association for providing me with temporary access to the Drupal.org analytics.

Feb 01 2021
Feb 01

As part of the 10 year anniversary of Drupal Career Online, we're continuing a blogpost theme as we start off the year posts that involve lists of 10. 

As an organization that trains aspiring Drupal developers, evaluates individuals' Drupal skills, and provides skill assessments to potential employers, we’ve developed what we feel is some key insight into what makes a good Drupal job posting.

Over the past few years, as I've reviewed job postings for Drupal jobs on jobs.drupal.org and other job-related web sites, there are (more than) a few things that always make me cringe…

  1. Jobs advertised as junior and intermediate and advanced skill level. Which is it? All of the above? Job postings like this especially scare away junior developers (for fear they will be in over their head) and advanced developers (for fear they will not be challenged). If you're writing a job posting, be specific. If you're hiring for multiple skill levels, then post multiple listings.
  2. Not clearly stating the "minimum skills required". This is always really perplexing, especially when reviewing expert-level job postings. The list of requirements for a single job is often virtually unattainable by most applicants. I've been developing Drupal sites for more than 14 years and I often see advanced-level job postings that I'm not qualified for. If you're looking for someone with years of experience in Drupal, WordPress, Laravel, Symfony, Magneto, administering servers, Behat, site performance, SEO, React, Angular, then prepare to either be disappointed or pay top-dollar (if you can even find someone who meets your criteria). I recommend splitting up your requirements into a few groups: "absolute minimum", "willing-to-pay-a-bit-more-for", and "bonus".  If you're not willing to hire someone who only has the absolute minimum, then maybe you need to rethink the posting.
  3. Not clearly stating if the position is customer-facing or not. Some developers do not want to interface directly with customers. In some cases, interfacing with customers directly isn't in someone's skill set. By making it clear whether or not the developer will need to interface with a client (online via a ticketing system, for example) you can help avoid unwanted situations. 
  4. Junior-level positions that do not mention on-the-job training and/or mentorship. Here's a secret, junior level developers don't want to be junior level - they are usually hungry to learn and advance. If you want to hire a junior level developer, then your organization must be willing to invest in them to help advance them. 
  5. Not specifying if the position includes design as well as development. In this case, "design" may or may not include visual design as well as software design. There are some developers that absolutely love the design aspect of building sites (information architecture, class hierarchy of custom modules, etc…) and some who do not. Be specific in what is required.
  6. Junior-level positions that include front-end, back-end, site-building, project management, multiple Javascript frameworks, etc.. (you get the idea). There's a reason that junior-level developers exist - because they don't have all the skills and experience yet. Job descriptions like this do one thing very well - scare off talented junior-developers that don't want to be put in a no-win situation. 
  7. Advanced skill level positions that don't pay market rate. If you're looking for an expert developer then you need to be willing to pay for it. Drupal is (and has been for a long time) a seller's market - if you manage to find someone willing to fill an expert position at a far-below-market-value rate, you're going to be disappointed one way or another.
  8. Junior-level positions that require more than 1 year of experience. If you're looking for a junior developer with more than a year of experience, then you're not actually looking for a junior developer. More than likely, you're looking for at least an intermediate developer.
  9. Not providing benefits other than salary. As mentioned above, Drupal is a seller's market. Want to attract top Drupal talent, regardless of skill level - then beef up your offering to make it stand out. Most developers enjoy professional development - provide them with a budget and time to learn new skills that will benefit your organization - and don't double-book them with work while they are learning new skills. Another HUGE benefit to offer is to allow developers to spend company time making contributions back to the Drupal community. This is a form of professional development as well often a very healthy thing for remote workers to participate in. Finally, send your developers to Drupal events - nothing will accelerate your developers' skills than interacting with other developers. 
  10. Labelling a position as junior-level because it doesn't pay very well. Don't. Please just don't. 

Do you have a junior Drupal developer that you move into a more intermediate developer role? Then consider sending them to Drupal Career Online - it's only 2-3 times/week for 12 weeks, and you can be confident that they'll be learning best practices around Drupal development. 

Jan 28 2021
Jan 28

As part of the interview process for Drupal Career Online, we provide potential students with some background information about Drupal so that they can make a more informed decision about whether or not the program suits them. One of the things we communicate is the scope of the Drupal project and its pervasiveness in the web development industry.

As anyone who has tried to find reliable numbers to answer the "how popular is Drupal?" question knows, finding reliable data is often a difficult process. While working to update our recruitment materials this year, we thought we'd share the data we found and the conclusions we've made.


To answer this question, in the past we have relied on the W3Techs (Web Technology Surveys) - a subsidiary of Q-Success, an Austria-based organization. Their methodology seems sound (they monitor the top 10 million web sites), but as their disclaimer states, "This information may be incomplete and inaccurate due to the vastness and complexity of the matter in hand"

As of January, 2021, they report that about 1.5% of all websites they monitor are Drupal-based. This is 2.4% of all web sites using a content management system.

W3Techs does provide a breakdown of usage among the top 1 million, 100,000, etc… sites, but only as part of one of their products (999 €). 

W3Techs reports that Drupal 7 is used by 66.4% of all the websites who use Drupal.

So, how do these numbers compare with other data sources?

Built With

Built With is an Australian company that provides lead generation lists in addition to web development trends among a plethora of technologies. 

They currently report that ~618,000 sites are using Drupal, which equates to 0.97% of all web sites. This is 4th among content management systems after WordPress, WooCommerce Checkout, and Joomla. Their sample size is over 35 million sites.

Their data for the top 1 million sites has Drupal with a 3.28% content management system market share (3rd place), 7.73% in the top 100,000 sites (2nd place), and 12.56% in the top 10,000 sites (2nd place).

Built With also reports that of the ~618k site running Drupal, the United States is responsible for ~250k, with Russia next on the list with ~41k sites.


SimilarTech appears to be primarily a lead-generation company with offices in Israel and the United States. They state that their "proprietary technology scans more than 30 billion web pages per month."

For Drupal, they report that ~236,000 unique domains run Drupal, which equates to ~337,000 sites (I'm assuming that subdomains account for the significant difference in these numbers). 

One potential major problem with their reports is that they often separate Drupal into multiple categories, including "Drupal", "Drupal 7", and "Drupal 8".

While they report that Drupal is used on 0.483% of all sites, it is not clear if this refers to just their "Drupal" category or includes their "Drupal", "Drupal 7", and "Drupal 8" categories. They appear to also break up other content management systems in a similar manner, making it difficult to draw reliable conclusions.

In their list of the top 1 million sites, they report that "Drupal" is used on 2.55% and "Drupal 8" on 0.81% (they only provide the top 8 positions). 

SimilarTech reports that after the United States, Russian sites account for the most Drupal sites with ~32,000. 


So, which data can we trust? What is the real answer? As you might imagine, it is difficult to say…

Removing the SimilarTech data from the equation for reasons stated above, let's look at a summary of we've found:

Metric W3Techs Built With

All sites (CMS + non CMS)

- 0.97% All sites (CMS) - - Top 10m sites (CMS + non CMS) 1.5% - Top 10m sites (CMS) 2.4% - Top 1m sites (CMS) - 3.28% Top 100k sites (CMS) - 7.73% Top 10k sites (CMS) - 12.56%

Clearly, using no-cost data from W3Techs and Built With, it isn't possible for a direct apples-to-apples comparison. But, combined, the data does seem to make sense. If you make the assumption that higher ranked sites have greater complexity and budget, along with the fact that Drupal 8 tends to be focused more on enterprise solutions, then it makes sense that Drupal has a higher percentage of usage among more popular sites.

Can we answer the question "how popular is Drupal?" - well, the answer is "sort of." Often answers to questions like this need caveats, as the table above illustrates. 

So what's the answer? Based on these sources, we're going to extrapolate, and go with Drupal runs about 3% of the top 1 million sites using a content management system as this seems well supported by two independent sources.

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 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 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 11 2021
Jan 11

I like to think of this module as something you don't realize you need until you understand exactly what it does. With that in mind, let's start with an example…

Imagine you have a "Document" content type (or media entity) that you use to upload PDF files to your site. Document entities are then used as part of various other entities (often content types) on your site via reference fields. Now for the important bit: Document entities are not meant to be viewed on their own - they are only meant to be available as a part of another entity via a reference field.

When a site design calls for this type of situation, what happens to the "Full display" view (/node/[nid] or /media/[mid]) mode of the Document entity? Often it is ignored; not even styled for display. Under normal circumstances the full display view mode has no reason to ever be requested, but if developers never had to worry about edge cases, then our lives would be much easier.

This is where the Rabbit Hole module enters the picture - it allows us to specify (via the bundle's "Edit" page) that if someone tries to load the full display view mode, the Rabbit Hole module kicks in and directs the user to a specified path.

Rabbit Hold module screenshot

So, if you have entities on your site that aren't meant to be displayed on their own, it's best to use the Rabbit Hole module to ensure your site visitors don't end up on a page you're not expecting.

Jan 05 2021
Jan 05

10 Years!We're kicking off our 10th year of Drupal Career Online - the longest running long-form Drupal training program in existence. To help mark the occasion, we thought it would be fun to share some of the things we've seen over the past 10 years that our students (both DCO and private training clients) have shared with us that made us think, "yeah, you really should enroll in Drupal Career Online..."

  1. Not using Composer yet - this is more of a recent (Drupal 8+) development, but we're still surprised when we see folks not using Composer to manage their Drupal 8 codebase. The DCO teaches best practices for using Composer and the drupal/recommended-project core Composer template.
  2. Using the "Full HTML" text format for everything everywhere - it is just plain scary when we see this, as it usually indicates a lack of understanding of both Drupal core text formats and basic security practices. The DCO provides both instructor-led and independent-study lessons on text formats.
  3. Relying on a single layout tool - in Drupal 8+, there are multiple ways to layout a page. This includes block placement, custom templates, Panels, Paragraphs, and Layout Builder. Not understanding the strengths and weaknesses of each of the more widely used solutions can lead to "everything looks like a nail, so I'll use a hammer everywhere" solution, which can result in a poor implementation. The DCO covers the basics of each of these layout techniques.
  4. Fear of Drupal versions greater than 7 - "the drop is always moving” – Drupal is continually evolving (and so is the DCO!). Embracing emerging versions of Drupal, like 8+, keeps you current, makes you more employable and introduces you to modern web development techniques.
  5. Modules are enabled and you have no idea why - one of the primary skills the DCO teaches is how to find answers, mainly by helping you create and grow your Drupal network. From classmates, to the active DrupalEasy learning community, community mentors, to online Drupal etiquette; we show you how and where to efficiently find answers.
  6. Your site always has errors on the Status Report page - the DCO's "site maintenance" lesson begins with the Status Report page. We provide a step-by-step approach to troubleshooting Status Report (and other) issues that may appear on sites you maintain.
  7. Your available updates page has more red than green - updatings modules can be scary. Git, Composer, database updates, and testing methodologies can sometimes make the seemingly simple task of updating a module arduous. Maybe you're the type that "updates all the things at once" and then crosses your fingers and hopes everything works. The DCO provides a step-by-step methodology for updating both Drupal core and contributed modules.
  8. Your site has one content type that is used for everything (aka, "I have no idea what entities, bundles, and fields are") - this is often a red flag that the site's information architecture (IA) isn't quite what it should be. Our site-building lessons include a healthy dose of IA, focusing on Drupal core entities, bundles and fields and how to efficiently map an organization's data to Drupal.
  9. Pathauto isn't installed nor enabled - maybe you're not the type to get up every morning and scour Twitter for the latest Drupal news. Luckily, we are, and much of the best-practice-y stuff we find goes directly into Drupal Career Online. We'll talk about contributed modules that most sites should absolutely be using.
  10. You have no idea what cron is (or if it is running) - when we perform site audits, this is normally one of the first things we look for on the Status Report page. The DCO covers this and other topics focused on Drupal best practices. 

If you're reading this and it is hitting a close to home, consider joining us at one of our upcoming Taste of Drupal webinars where we'll spend an hour talking and answering questions about the next semester of Drupal Career Online.   

Dec 30 2020
Dec 30

After teaching folks how to use Composer effectively over the past couple of years, I figured it was time for me to (finally) update DrupalEasy.com to use Composer 2. I figured it would be a pretty easy process, and I was correct.

I've had a few people ask me about the process, so I thought I'd write up what it took to update this site to Composer 2. First a few facts about this codebase:

  • Dependencies are committed to the project Git repository.
  • The site is hosted on Pantheon
  • I use DDEV for local development.

So, the first step, prior to updating to Composer 2, is to ensure all plugins are ready for Composer 2. In this case of the DrupalEasy.com codebase, there were three Composer plugins to review:

  1. composer/installers - compatible with Composer 2 starting with 1.9.0
  2. cweagans/composer-patches - compatible with Composer 2 starting with 1.7.0
  3. topfloor/composer-cleanup-vcs-dirs - the "dev-composer-2" branch is compatible with Composer 2

So, while still using Composer 1, I did the following (on my local, of course):

composer update composer/installers
composer update cweagans/composer-patches

Then I manually edited the composer.json file and changed the version constraint for topfloor/composer-cleanup-vcs-dirs to: "topfloor/composer-cleanup-vcs-dirs": "dev-composer-2" 


composer update topfloor/composer-cleanup-vcs-dirs

Once that was done, I updated my .ddev/config.yaml file to use:

composer_version: "2"

After restarting DDEV, I verified that all was well by updating a couple of Drupal modules (non-security related maintenance releases) before committing all changes and pushing up to Pantheon.

Obviously, the most important step is to ensure all of your Composer plugins are compatible with Composer 2 - just remember to do this prior to updating to Composer 2!

Dec 10 2020
Dec 10

Office worker at computer.As we look forward to the vaccine-influenced future beyond COVID-19, one of the very few things we have lived over the past 9 months that may actually have a positive lasting impact on society is that often there are advantages to accomplishing things virtually. Working remotely, meeting via Zoom, online appointments, grocery delivery, even doctor visits have screamed past proof-of-concept for situations most of the world had previously not considered. 

So many more applications that rely on the web are more ingrained in daily life since COVID forced them on us. With this incremental leap in mass adoption of web technologies, web development (and for the purpose of this article, Drupal) will continue to play a major role as the world leverages online tools more, and for more applications. This suggests that Drupal positions (which total more than 1,600 listed on Indeed the first week of December this year), may open up even more in the future.

So, for those who conceive, create, and maintain current and future tools, or people considering these careers, the future looks pretty bright. Those of us in the community know that even beyond the new growth potential, Drupal and web development has a lot to offer; so, we humbly share these 5 great reasons you may want to consider 2021 as a good time to get serious about your Drupal dexterity if you want to expand your skills, get up to speed or even pivot your career to seize the day and opportunity: 

  1. Web Development Careers have a lot of opportunity! 

 It’s hard to find an article about promising careers without web developer positions seated in the upper tiers. According to recent article by CNBC, Web Developer careers are in the Top 15 High Demand jobs over the next 5 years. Indeed puts it at #10 for careers most in demand right now; and the US Department of Labor Occupational Outlook Handbook estimates that 2019’s total 174,300 web developer positions will grow by about 14,000 over the next 10 years, a higher rate than most vocations. 

  1. The Path to becoming a Drupal Web Developer is accessible. 

If you have the desire and commitment to become a Drupal professional, you can! Drupal training is available through go your own pace options like Drupalize.me, with focused training sessions live and online (Evolving Web, Mediacurrent) and of course, might we suggest the longest running, long-form career technical education program through DrupalEasy Academy; Drupal Career Online. There is also plenty of advice out there like DrupalEasy Career Resources and How to start a Web development career.

  1. Flexible schedules and virtual work are prevalent in the Web Developer World

Life in 2020 changed work for a lot of people, but remote working is nothing new in the world of web developers. Drupalists, both those employed by organizations and those who choose to freelance, have a long and successful history of working from home, or wherever they find great wifi and interesting surroundings, there are state of the art tools that support teams who are spread out specifically catering to this efficient, low-overhead way of doing business. Add “virtual” to your job search on Indeed or Career builder, and you can see hundreds of positions. 

  1. Salary Data for Web Developers compares pretty well

According to the U.S. Department of Labor Bureau of Labor Statistics, The median annual wage in May, 2019 for web developers was $73,760. It gets better if you choose Drupal, as Indeed reports that, based on 188 salaries reported as of November, 2020, the average salary for a drupal developer is $95,642 per year in the United States.  You will have to get some experience and hone your skills, but with commitment and patience, the high-wage jobs are yours to strive for. 

  1. Drupal Web Developers have a global community for support

Come for the code, stay for the community.  It’s not just a mantra.  The Drupal community has groups connected by topic, interests, service to the community and even outside interests.  There is nothing like it.  Even here at DrupalEasy, we have a micro community of past and current students that meet up every week to help each other work through projects, issues and provide support.  It’s our DrupalEasy Learning Community, and we like to think it’s a microcosm of the Greater, Global Drupal Community that makes our content management system, and the people who support it so outstanding. 

The next session of Drupal Career Online starts March 1, 2021, with the application deadline the last week in February. If you are interested in learning Drupal, honing your Drupal skills specifically in our longform Drupal Career Online, let us know, or sign up for one of our no-cost Taste of Drupal mini webinars coming up in the beginning of 2021.  


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