Tech News

Direct .mp3 file download.

Donata Stroink-Skillrud, president of Termageddon LLC, licensed attorney, certified information privacy professional, and vice-chair of the American Bar Association ePrivacy Committee joins Mike Anello to talk about privacy (and other web site) policies (it's much more interesting than you think!) and why it is so important for modern web sites to have one.

• Termageddon LLC
• Are you an agency? Join Termageddon's Partner Program and receive a two free accounts - one for you and one for a client!
• International Association of Privacy Professionals
• American Bar Association

• Drupal Career Online - next semester begins March 1. Free information webinars on January 13, February 10, and February 24.
• Professional local development with DDEV - 2-hour, hands-on, online workshop held monthly (Tuesday, January 12).
• Local Web Development with DDEV Explained.

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher and YouTube.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Note: the Termageddon links above are affiliate referral links.

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.   
 

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):

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" 

Then,

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

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!

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.

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.

Direct .mp3 file download.

Brian Perry, front-end architect with Bounteous, joins Mike Anello for a beginners talk about front-end components, including Brian's advice for what the first steps are for someone who wants to get started using them.

• DrupalCon Global "An overview of Drupal 8 front-end component integration methods" presentation video
• DrupalCon Global "An overview of Drupal 8 front-end component integration methods" description
• Bounteous
• Components! module
• Emulsify
• Pattern Lab
• Storybook
• Brad Frost's Atomic Design
• Brad Frost - The workshop and store front blog post
• UI Patterns module
• UI Suite initiative

• Drupal Career Online - next semester begins March 1. Free information webinars on February 10 and February 24.
• Local Web Development with DDEV Explained.
• Termageddon

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher and YouTube.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

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. 
 

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.

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

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.

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:

• 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.

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.

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.

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).

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").

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.

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.

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.

• General HTTP headers documentation
• Pantheon hosting HTTP headers documentation
• Acquia hosting Varnish header documentation
• Cloudflare CDN HTTP headers documentation
• Fastly CDN 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.

• 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.

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 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:

All sites (CMS + non CMS)

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.

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.