drupal 7

I just released Drupal VM 6.0.0 today, and it is the best version of Drupal VM yet!

The main goals for this new version are stability and compatibility.

Originally I was going to drop some features that are helpful for people running older Drupal 7 sites, but since Drupal 7's End of Life was just extended into 2022, I decided to extend the support for some features like Drush make files, as many users of Drupal VM still maintain Drupal 7 sites, or use Drupal VM to test the upgrade from Drupal 7 to Drupal 8 or 9.

The default PHP version was upgraded from PHP 7.2 to 7.4 in Drupal VM 6, and this new version should work great with almost any Drupal 7, 8, or 9 website (in fact, PHP 7.3 is Drupal 9's minimum requirement!).

May 19 Update: It was a total success, yay! This site is now running Drupal 8.

Over 100 days in, the big day has finally arrived—it's time to upgrade this website from Drupal 7 to Drupal 8! The entire process has been documented, one hour at a time, in my 'Drupal 7 to 8' live streams. Visit that link to view all the previous episodes, from setting up a new Drupal codebase, to running the first test drush migrate-upgrade command, to upgrading this site's theme from PHPtemplate in Drupal 7 to Twig in Drupal 8.

Some of the highlights:

I just finished delivering my CMS Philly How I am migrating JeffGeerling.com from Drupal 7 to Drupal 8 presentation, which summarizes the first 100 days (1-2 hours per week) migrating this website from D7 to D8.

.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

The slides are available from SlideShare:

Friend and former colleague Chris Urban and I will be presenting the results of the 2020 Drupal Local Development Survey at CMS Philly—which is now a virtual event—on May 1st. You can find more information about the session here: 2020 Developer Tool Survey Results. I'll also be posting the survey results on this blog soon after.

Chris also coaxed me into talking about my ongoing Drupal 7 to 8 migration saga in a separate session, so if you've missed the first 13 live stream episodes, check out the session How I'm migrating JeffGeerling.com from Drupal 7 to Drupal 8 to get caught up—then subscribe to my YouTube channel to see how it all ends 🤪.

It remains to be seen whether Chris and I will be wearing Hawaiian shirts during the session:

DrupalCon Minneapolis is two months away, and that means it's time for the 2020 Drupal Local Development Survey.

Local development environment usage results from 2019's survey.

If you do any Drupal development work, no matter how much or how little, we would love to hear from you. This survey is not attached to any Drupal organization, it is simply a community survey to help highlight some of the most widely-used tools that Drupalists use for their projects.

Take the 2020 Drupal Local Development Survey

Thoughts about Drupal 8, Drupal 7, Backdrop, the Drupal Community, DrupalCon's meteoric price increases, DrupalCamps, and the future of the framework/CMS/enterprise experience engine that is Drupal have been bubbling up in the back of my mind for, well, years now.

I am almost always an optimist about the future, and Drupal 8 promised (and usually delivered) on many things:

• Vastly improved content administration
• Views in core, and even better than ever
• Media in core
• Layouts in core
• Modern programming paradigms (fewer #DrupalWTFs)
• 'Getting off the island' and becoming more of a normal PHP application (kinda the opposite of something like Wordpress)

But one thing that has always been annoying, and now is probably to the state of alarming, for some, is the fact that Drupal 8 adoption has still not hit a level of growth which will put it ahead of Drupal 7 adoption any time soon.

Almost exactly a year ago, I wrote a blog post titled Solving the Emoji/character encoding problem in Drupal 7.

Since writing that post, Drupal 7 bugfixes and improvements have started to pick up steam as (a) many members of the community who were focused on launching Drupal 8 had time to take a breather and fix up some long-standing Drupal 7 bugs and improvements that hadn't yet been backported, and (b) there are two new D7 core maintainers. One of the patches I've been applying to many sites and hoping would get pulled into core for a long time was adding support for full UTF-8, which allows the entry of emojis, Asian symbols, and mathematical symbols that would break Drupal 7 sites running on MySQL previously.

My old blog post had a few steps that you could follow to make your Drupal 7 site 'mostly' support UTF-8, but there were some rough edges. Now that support is in core, the process for converting your existing site's database is more straightforward:

tl;dr: Drupal 8's defaults make most Drupal sites perform faster than equivalent Drupal 7 sites, so be wary of benchmarks which tell you Drupal 7 is faster based solely on installation defaults or raw PHP execution speed. Architectural changes have made Drupal's codebase slightly slower in some ways, but the same changes make the overall experience of using Drupal and browsing a Drupal 8 site much faster.

When some people see reports of Drupal 8 being 'dramatically' slower than Drupal 7, they wonder why, and they also use this performance change as ammunition against some of the major architectural changes that were made during Drupal 8's development cycle.

First, I wanted to give some more concrete data behind why Drupal 8 is slower (specifically, what kinds of things does Drupal 8 do that make it take longer per request than Drupal 7 on an otherwise-identical system), and also why this might or might not make any difference in your choice to upgrade to Drupal 8 sooner rather than later.

I wanted to document this here just because it took me a little while to get all the bits working just right so I could have a hierarchical taxonomy display inside a Facet API search facet, rather than a flat display of only the taxonomy terms directly related to the nodes in the current search.

Basically, I had a search facet on a search page that allowed users to filter search results by a taxonomy term, and I wanted it to show the taxonomy's hierarchy:

To do this, you need to do two main things:

1. Make sure your taxonomy field is being indexed with taxonomy hierarchy data intact.
2. Set up the Facet API facet for this taxonomy term so it will display the full hierarchy.

Let's first start by making sure the taxonomy information is being indexed (refer to the image below):

I spent about an hour yesterday debugging a Varnish page caching issue. I combed the site configuration and code for anything that might be setting cache to 0 (effectively disabling caching), I checked and re-checked the /admin/config/development/performance settings, verifying the 'Expiration of cached pages' (page_cache_maximum_age) had a non-zero value and that the 'Cache pages for anonymous users' checkbox was checked.

After scratching my head a while, I realized that the headers I was seeing when using curl --head [url] were specified as the defaults in drupal_page_header(), and were triggered any time there was a message displayed on the page (e.g. via drupal_set_message()):