Taxonomy Term Glossary

New Drupal Modules - 23 December 2019 - 3:25pm

This flexible module uses a vocabulary (taxonomy) as a glossary.
it auto scans the fields (you configure it to) for uses of taxonomy terms defined in your vocabulary.

On save It will auto tags the recognised terms for use in a modal box (default but allows for your custom implementation).

Categories: Drupal

Commerce RNG 2

New Drupal Modules - 23 December 2019 - 1:55pm

RNG is an event registration module for Drupal, which provides support for events, registrations, registrants, groups, rules and more.

Drupal Commerce allows you to sell things inside Drupal.

This module provides preliminary support for integrating the two.

Based on a Sandbox module by MegaChriz, this version adds support for RNG 2.x (currently in development) and Drupal 8.8.

Categories: Drupal

Colorfield: Extract tokens from a Drupal database dump

Planet Drupal - 23 December 2019 - 9:15am
Extract tokens from a Drupal database dump christophe Mon, 23/12/2019 - 18:15 While working on migrations from Drupal 7 to 8 it could be necessary to convert tokens from formatted text fields + get an idea of how many of them are in the database for estimation, e.g. see if it is possible to rely on Token Filter or if there are custom tokens/filters.
Categories: Drupal

wishdesk.com: Language switcher as a vital feature of multilingual Drupal 8 sites

Planet Drupal - 23 December 2019 - 8:33am
A language switcher is vital for a user-friendly multilingual website. See how language switcher is created in Drupal 8 (with the video).
Categories: Drupal

Entity usage views field

New Drupal Modules - 23 December 2019 - 3:38am

Adds a views field displaying number of entities using (referencing) an entity.

Integrates with Entity Usage.

See README for how to use the field and configure modal dialog.

Categories: Drupal

GraphQL Fragment Include

New Drupal Modules - 23 December 2019 - 2:40am

A module to include fragments inside a GraphQL query, using the following syntax: # include path.gql.

This module is useful when:

  • You have a collection of paragraphs (or any other kind of entity) that is being used by multiple Content Types.
  • GraphQL is used to export content data (ideally by using Static Export module) and you find the same repeated data structure on multiple queries.

To avoid having to repeat the same query for every content type, you should:

  • use GraphQL fragments
  • extract them to files
  • use this module to include those fragment files into your GraphQL queries.
Categories: Drupal

Spinning Code: On Being Self-Taught

Planet Drupal - 23 December 2019 - 12:00am

From time to time conversations come up among developers, and other fellow travelers, about being self-taught vs getting formal training. Over time I’ve come to realize that the further and further you get into your career, the less the distinction means anything; eventually we are all mostly self-taught.

I’ve written before about the value of my liberal arts education and I stand by my assertion that what I learned in that setting was, and is, valuable to my life and work. But just because something was useful to life does not mean it was the only way to acquire the skills. It’s a good way for many people, but far from the only way.

For anyone in a technical field, and most professional fields really, to succeed over time you need to learn new tools, skills, and techniques. The tools I knew when I graduated college are all largely outmoded or significantly upgraded, and I’ve had to learn a variety of technologies that didn’t exist in 2001.

Within the Drupal community lots of people talk about being self-taught, sometimes with pride sometimes with embarrassment, but in truth very few people were formally trained on the platform. A CS degree is not required. Lots of very successful developers in the Drupal community (and beyond) have degrees in fields like religion and art history. In fact, I’ll argue that just about every Drupaler taught themselves most of what they know about Drupal. How they did that can vary widely, but we are a community with few formal training programs and lots of people who stumbled into Drupal trying to solve a non-technical problem (communications or marketing for an organization). Even advanced workshops at conferences dig deep into one small area and expect you to generalize that knowledge to your projects, which I count as self-taught. For example, I had a friend ask the other day about how to control the PDO connection settings in Drupal 7 — which I didn’t know how to do, but knew they were similar to Drupal 8 — so I sent him my Drupal 8 instructions and he figured it out how from there. He’s now taught himself how to do what he needed for that project and in the process generalized the approach for whatever he may need next time.

So then it is important for all of us to find, and hopefully share, techniques for self-teaching — even for those who have some kind of formal training. Here are my suggestions for people who are starting out and haven’t yet found the pattern that works for them:

  1. Assume you first solution is wrong. Most of us have, or will, stumble our way through a project where we don’t really know what we’re doing without a lot of support. We usually learn a great deal in the process, and launching those projects can feel pretty good cause you’ve succeeded at something hard. It is easy to get into the habit of assuming the solutions from that project were correct because they worked. In truth those projects are really rough around the edges, and just because we got it to work does not mean the solution was good. Assuming the first solution is good enough forever is how you come an expert beginner which then takes a lot of effort to undo. Once you have a working solution, step back and see if you can think of a better one, or if you now can guess better search terms to see if someone else wrote up a different solution to the same problem. Admit your work could be better and try to improve it.
  2. Learn a few more programming languages. Most people who are self-taught from the start, and even some who have a BA/BS in Computer Science, only know 2 or 3 programming languages (PHP, JS, and CSS+HTML are often the only languages new people learn at first). One of the courses I took by chance in college forced me to learn 8 in 16 weeks. It was grueling, miserable, and darned useful. I can still learn a new language in just a couple weeks and rarely do I hit a language construct I don’t recognize. You don’t need to go that far. When I first started out a mentor told me you should learn a new language every year, and for several I did. Some of those, not the languages I learned in college, are the ones I use most day-to-day. All told I’ve spent time writing code in more than twenty different languages. That many isn’t terribly useful but the more languages you learn, the more you learn to understand the elements of your primary language.
  3. Learn basic algorithms and to measure complexity. The kind of thinking that goes into formal algorithms will help you be a better developer overall; badly thought through processes is the place I tend to see the largest gaps between developers with and without formal training. Any college-level CS program will put you through an algorithms course that teaches a variety of specific algorithms and force you to understand their structures. If you didn’t go through one of those programs, this is probably the course that will help you the most. On the one hand most of us rarely rewrite these algorithms as on modern platforms some library or another will provide a better version than we are likely to craft for our project. But learning what they are, when they are used, and how to understand their performance is useful for any project that involves lots of data or processing. MIT has a version of their algorithms course from 2011 online, or find one through another provider. Even if you just watch the lectures (really watching, not just vaguely have them on while cooking and cleaning), you can learn a great deal of useful information. I learned a lot watching those lectures as it refreshed and updated my understanding of the topics.
  4. Find and learn from mentors. Notice I used a plural there; you should try to find a few people willing to help you learn your profession, and more generally help you learn to advance in your field. Most of us benefit from learning from the experiences of multiple people, and who we need to learn from changes over time. I had the great experience of having a few wonderful mentors when I was first starting out, and much of the advice they gave me still serves me well. Some of it contradicted, and resolving those contradictions forced me to learn to do things my own way and find my own solutions.
  5. Learn other platforms. This is both a protection against future shifts in the market, and also a way to see how things work from outside your current professional bubble. Drupal developers can learn a lot from writing a WordPress plugin, or better yet an add-on for a platform in another language (think about Plone, Gatsby, or Hugo). Or try to learn to work with a platform like Salesforce or AWS. Other platforms have different communities, different learning styles, and different patterns. Like understanding additional languages, different platforms help you broaden your understanding and provide insights you can bring back to your main work.
  6. Learn to give and take criticism. Part of learning is getting feedback on your work, and part of being on a team is sharing feedback with others. If you took art or music classes in high school or college you probably learned some of the basic lessons you need here, but if you didn’t, consider taking one now at your local community college or art center. The arts are wonderful for getting experience with criticism. For all art is often open to interpretation, it also requires specific skills. If you play off-key, it sounds wrong. If your sculpture collapses under its own weight, the project failed. If your picture’s subject is out of focus, you need to re-shoot it. Sure there are brilliant artists who can violate all the rules, but if you have never experienced an art critique you are not one of those artists. The experience of getting direct, blunt, and honest feedback will help you understand its value and have to give that feedback yourself.
  7. Share what you think you know. We learn a great deal with we teach others. Both because it forces us to refine our thinking and understanding so we can explain it, and because learners ask questions we cannot answer off the top of our heads. This can be user group or conference presentations, internal trainings for your team, mentoring junior developers, writing a blog, or anything else that gets your from learning to teaching. It’s okay if you’re not 100% right, that’s part of how we learn. A few years ago I was doing a joint project with a junior developer who asked me a lot of questions, and pushed hard when she thought I was making mistakes. When she asked why I was selecting a solution or setting a pattern, she was never satisfied with “because that’s the best way to do it.” She wanted me to explain why that was the best way. If I couldn’t walk her through it right away, I went back and hunted for reference material to explain it or if that failed I tested her counter ideas against my plans to see if I was missing something. While I was usually right, not always and we did make changes based on her feedback. More importantly it forced me to show my work in fine detail which was a good exercise for me and gave her insights to help her do better work.
  8. Find your own patterns. At the start I said this list was for people who didn’t have their own patterns yet. In the long-run of your career you need to figure out what you need to know to get to where you want to go next. Eventually you will need to find a pattern that works for you and the life you are living. No one can tell you what that is, nor how to learn it all yourself. Experiment with learning styles, areas of work, roles, and types of projects as much as you are able until you feel your way to the right solutions for you.
Categories: Drupal

Gizra.com: Translating Drupal User interface with Spreadsheets

Planet Drupal - 22 December 2019 - 4:00pm

Making multilingual sites is hard. I’ve been using Drupal since version 5 and I can say a few things about the evolution of Drupal multilingual capabilities:

  • First, Drupal 8 is – in my opinion – the first version of Drupal where someone could say that multilingual works, pretty much out of the box.
  • Second, the documentation about how to deal with different scenarios is quite good.
  • And third, from a user experience perspective, translating the user interface of a site is really hard.

In this post we will talk about the third point and what we did to manage that complexity.

Our Current Scenario

We are building a really complex site, and the main challenges we faced regarding multilingual are:

  • The site is a multisite architecture, one database using Organic Groups.
  • Each group represents a country, and each country needs its site in one or more languages.
  • We have several variations of the same language depending on the region this language is spoken in.
  • We don’t want to let content editors translate the site directly from the UI.
  • We don’t speak all the languages the site is in.

The last item is quite relevant, when you don’t speak a language, you cannot even be sure if the string you are copying into a textbox says what it should.

The First Attempt

We started with a translation matrix to store all the translations. A simple Google drive spreadsheet to track each string translation in each language.

Each column uses the language code as a header.

Using a tool to convert Spreadsheets into po files we get each translation file fr.po, es.po, pt.po.

We used wichert/po-xls to achieve this with good results.

Not So Fast

This initial, somewhat naive, approach had a few problems.

  • Drupal string translations are case sensitive. This means that if you made a typo and wrote Photo instead of photo the translation will fail.
  • Some strings are the result of a calculation. For example. Downloads: 3 is actually managed by Drupal as Downloads: @count.

But the more complex item is that Drupal 8 has two ways to translate strings. The first one is inherited from Drupal 7. The one that makes use of the well known t function for example t('Contact us.').

The other one is a new way that allows site builders to translate configuration entities.

The two scenarios that allow translation of a Drupal site. Translating Configuration Entities is Really Hard

To translate configuration entities, you need to identify which configuration needs translation, and find the exact part relevant to you. For complex configuration entities like views, this could be quite hard to understand.

Even for an experienced site admin this can be hard to understand.

Another problem that we had to solve was the vast amount of configuration alternatives you have when dealing with a medium-size Drupal site.

Each category has a lot of items to translate.

It was clear to us that in order to translate all those items we needed to find another way.

More problems… Identifying Which Strings to Translate is Hard

One thing to consider when dealing with Drupal translations is that it’s not easy to identify if a string is displayed somewhere in the frontend or if it is only a backend string.

Translating the entire codebase may not be a viable option if you want to keep a short list of translations reviewed by a group of people. In our case, it was important to make sure that translations are accurate, and that translators do not feel overwhelmed.

We don’t have a great solution to this problem yet. One of the strategies we used was to search for all the strings in twig templates and custom modules code using a grep search.

egrep -hro "[\>, ]t\('.*'\)" . | cut -c 5- # Get strings inside ->t(...) and t(...) egrep -hro "{{ '.*'\|\t" . # Get twig strings '....'|t egrep -hro " trans .*" . # Get twig strings inside trans

However, as we figured out later by reading the documentation, twig strings cannot be used as a source for translations. Internally, Drupal maps those strings back to the regular use of t('strings').

This means that strings like:

{% trans %}Copyright {{ year }}{% endtrans %}

Are actually converted to

t('Copyright @year')

And that last string is the one you should use as source of the translation.

At the end, we cleaned up the spreadsheet list using visual inspect, and so far it has been working fine.

How We Solved the Problems?

To recap the problems we had:

  • We did not want to translate all the available strings.
  • We did not know all the languages, therefore copy and pasting was a risk.
  • Translators were expecting to have a reduced number of strings to translate.
  • Configuration translations are quite complex to track.

As we mentioned before using the xls-to-po tool, we were able to obtain the PO files to translate one part of the strings that we needed to translate.

We also used drush_language to automate the process.

drush language-import --langcode=fr path/to/po_files/fr.po

This little snippet iterates over all of the po files in the po_files directory and imports the language using the drush command mentioned above.

find po_files -type f -name *.po | xargs basename --suffix=.po | \ xargs -I@ drush language-import --langcode=@ @.po

The xls spreadsheet has in the first column the Message Id, and the language codes of the system

By using conditional cell colors, we can quickly identify which translations are pending. Solving the Configuration Translation Problem

The second part of our problem was a bit more tricky to fix.

We used a custom script to get all the config entity strings that were relevant to us.

Here is a simplified version of the script.

$prefix = 'views.view.custom_view'; $key = 'display.default.display_options.exposed_form.options.reset_button_label'; $configFactory = \Drupal::service('config.factory'); $list = $configFactory->listAll($prefix); $rows = []; foreach ($list as $config_name) { $columns = []; // Add the unique identifier for this field. $columns[] = $config_name . ':' . $key; // Get the untranslated value from the config. $base_config = $configFactory->getEditable($name); $columns[] = $base_config->get($key); $rows[] = $columns; }

If you wonder how to get the $prefix and $key, they are obtained by inspecting the name of the field we want to translate in the Configuration Translation UI.

You need to inspect the HTML of the page, see the name attribute.

We print the result of the script to obtain a new CSV file that looks like this

The first column is a unique id that combines the prefix and the key.

Then, we copy and paste this CSV file as a new tab in the general translation matrix, and complete the header with the rest of the languages translations.

Finally we use a spreadsheet formula to find the translation we want for the languages we are interested in.


This will search for a match in the Strings matrix, and provide a translation.

Spreadsheet magic. Final step: Importing the Configuration Strings Translation Back to Drupal

Once we have all the translations we need. We export the CSV file again and use this other script (simplified version) to do the inverse process:

use Symfony\Component\Serializer\Serializer; use Symfony\Component\Serializer\Encoder\CsvEncoder; use Symfony\Component\Serializer\Normalizer\ObjectNormalizer; $filename = 'path/to/config_translations.csv'; $serializer = new Serializer([new ObjectNormalizer()], [new CsvEncoder()]); $configFactory = \Drupal::service('config.factory'); $languageManager = \Drupal::service('language_manager'); $serializer->encode($data, 'csv'); $data = $serializer->decode(file_get_contents($filename), 'csv'); foreach ($data as $row) { $name_key = array_values($row)[0]; list($name, $key) = explode(':', $name_key); // The languages we care start after the second column. $languages = array_filter(array_slice($row, 2)); foreach ($languages as $langcode => $translation) { $config_translation = $languageManager ->getLanguageConfigOverride($langcode, $name); $saved_config = $config_translation->get(); $config_translation->set($key, $translation); $config_translation->save(); } } Some Other Interesting Problems We Had

Before finishing the article, we would like to share something interesting regarding translations with contexts. As you may know, context allows you to have variations of the same translation depending on, well… context.

In our case, we needed context to display different variations of a French translation. In particular, this is the string in English that we needed to translate to French:

Our organization in {Group Name}

In France, this translates into Notre organisation en France. But if you want to say the same for Canada, due to French grammatical rules you need to say Notre organisation au Canada (note the change en for au).

We decided to create a context variation for this particular string using context with twig templating.

{% trans with {'context': group_iso2_code} %} Our organization in { group_name } {% endtrans %}

This worked ok-ish, until we realized that this affected all the other languages. So we need to specify the same translation for each group even if the language was not French

This is not what we want...

After some research we found the translation_fallback module but unfortunately it was a Drupal 7 solution.

Long story short, we ended up with this solution.

{% if group_uses_language_context %} {% trans with {'context': country_iso2_code} %} Our organization in { group_name } {% endtrans %} {% else %} {% trans %}Our organization in { group_name }{% endtrans %} {% endif %}

Which basically provides two versions of the same string. But if the group needs some special treatment, we have the change to override it. Lucky for us, xls-to-po has support for strings with context. This is how we structured the translations for strings that require context:

CA, in this case, is the ISO code for Canada Conclusion

For us, this is still a work in progress. We will have to manage around 20 or more languages at some point in the project. By that point, having everything in a single spreadsheet may not be maintainable anymore. There are other tools that could help us to organize source strings. But so far a shared Google Sheet worked.

We still use configuration management to sync the strings in production. The snippets provided in this post are run against a backup database so we can translate all the entities with more confidence. Once we ran the script we use drush config:export to save all the translations to the filesystem.

Continue reading…

Categories: Drupal

PHP Runtime Memory

New Drupal Modules - 22 December 2019 - 10:31am

This module help drupal admin to change PHP runtime configuration without changing php.ini.

Note: Since this module worked on .htaccess its better to take backup of your .htaccess file


Categories: Drupal

Social Tracking

New Drupal Modules - 22 December 2019 - 7:32am

This module provides an option to configure Facebook Pixel and Twitter conversion tracking in your site. The module is designed in such a way that it can be extendable to give support for any other social tracking in future.

For the initial launch, the module gives support for the PageView (all pages) event, further, it will provide options for different events.

Categories: Drupal

OSTraining: How to use the Slick Module in Drupal 8

Planet Drupal - 21 December 2019 - 9:00pm

One of OSTraining’s members wants to have a carousel slider in her site. She wants the carousel to show 3 image slides and some text below them, and the carousel to move only one position at a time when you click the “Next” button. 

This is possible to achieve, thanks to the Drupal Slick module which has several options and settings to customize this interaction with a couple of clicks. 

Keep reading in order to learn how to use this module!

Categories: Drupal

Social Auth Linkedin Api

New Drupal Modules - 21 December 2019 - 11:34am
Categories: Drupal

Social Auth Twitter Api

New Drupal Modules - 21 December 2019 - 10:08am

This module hasn't complete yet, don't use it now!

Categories: Drupal

ZURB Foundation Companion

New Drupal Modules - 21 December 2019 - 7:22am
Zurb Foundation companion

Zurb Foundation companion is a helper module for the Zurb Foundation theme.

  • Provides a command to generate a subtheme with Drush. drush generate theme-zurb-foundation

Due to relying on external PHP libraries from packagist.org to implement the subtheme generator the module can only be installed using composer.

Categories: Drupal

Cloudflare Image Style

New Drupal Modules - 21 December 2019 - 5:28am

This module is to serve the styled images using Cloudflare's service on production environment and to fallback to Drupal's default Image Style management for non-production / local development environments.

Read more about Cloudflare's image resizing service at: https://developers.cloudflare.com/images/about/

Categories: Drupal

Number Abbreviation

New Drupal Modules - 21 December 2019 - 3:17am

A simple module that provides the ability to abbreviate numbers with too many
digits to a shorter format (2k, 2.5k, 2m, 2.5m, etc) using a twig formatter.
It also provides a number field formatter to use with fields.
Other modules or hooks can use the service provided to shorten numbers.

Twig Usage
if you want to use it as a filter (1 decimal point)
{{ field__value|number_abbreviate }}

Categories: Drupal

SAML Authentication - Extra Attributes Mapping

New Drupal Modules - 21 December 2019 - 12:06am

Allows users to map saml attributes to Custom User profile fields.

Currently added support for textfield and taxonomy reference fields. Will be adding support for more fields type asap.

Categories: Drupal

Revision Delete Queue

New Drupal Modules - 20 December 2019 - 8:43am

This module implements a Drush command that finds releases older than a given time and pushes them to a queue so they can be deleted by a queue worker. It's query is based on the one that Node Revision Delete module uses, but simpler.

For example, to create a queue to delete article revisions older than a year, you would run this command:

Categories: Drupal

Palantir: Guide to the Drupal 8.8 Update

Planet Drupal - 20 December 2019 - 7:04am

Updating to Drupal 8.8 is the first step in preparing your site for Drupal 9.

In this post we will cover...
  • Changes required to update a Drupal 8 site to the 8.8.0 release
  • Contrib module flags
  • Troubleshooting this update

If you're currently running a Drupal 8 site and are interested in upgrading to Drupal 9 when it is released in the summer of 2020, the first step is to update to the recently-released Drupal 8.8. Drupal 8.8 contains both the deprecated APIs and the new APIs that will become standard in Drupal 9, so once your site is on 8.8, you can begin to review your contrib modules and update your custom code to move from deprecated APIs to the state of the art. No new features will be added in the 9.0 release, which means that 8.8 has feature parity to streamline the upgrade path between 8.x and 9.x.

The update to 8.8 is more involved than previous Drupal 8 point releases because 8.8 renames some configuration variables and changes the core drupal packages and dependency structure in composer.json, which means that updates need to be made to both settings.php and composer.json.

At Palantir, our team maintains many Drupal 8 sites in both active development and support, and we've documented some important tips that are important to keep in mind when updating your site to 8.8. We also want to give a shout-out to the folks at PreviousNext for their post on what they learned when updating to the 8.8 beta release.

Update process overview
  1. Contrib module conflicts: If your site is using the contrib modules Pathauto, Workspace, or Coder, update those first.
  2. Update settings.php: Change the temp and config sync directory variables settings.php
  3. Update composer.json: Manually update your composer.json
  4. Run the Drupal database updates
  5. Export changed config
Contrib module conflicts Pathauto

We use the Pathauto module on all of the sites we build, and Pathauto needs some handholding in this update process. If you don't update Pathauto while you're still on Drupal core 8.7, you could lose your path alias data!

  1. While your site is still running Drupal 8.7, update Pathauto to the latest release (8.x-1.6): composer require drupal/pathauto:^1.6
  2. Deploy the updated code
  3. Run the database updates: drush updatedb
  4. Begin your Drupal 8.8 update

Workspace isn't common on our sites, so running into an issue with it usually means doing some research. The contrib Workspace module has been moved into core, and renamed "Workspaces"; installing both modules on the same site creates code-level conflicts. Additionally, the Drupal 8.8 release introduces an incompatibility between core Content Moderation module and the contrib Workspace module.

As of December 2019, there is no ready-made upgrade path from the contrib module to the core module; the recommendation is to uninstall the contrib module -- which will delete all workspace content that is not yet live -- and then install core's module (documentation).


If you're using Coder to do automated code review against the Drupal coding standards, you may need to update. Drupal 8.8 requires a minimum of version 8.3.2.

  1. Check your coder version: composer show drupal/coder
  2. You'll see the package information with the version -- in this case, 8.2.10: [ 3:15P ~/repos/example] (develop) $ composer show drupal/coder
    name     : drupal/coder
    descrip. : Coder is a library to review Drupal code.
    keywords : code review, phpcs, standards
    versions : * 8.2.10
    type     : library
  3. Update the package: composer require drupal/coder:^8.3.2
Updating settings.php

First, find your settings.php file; this will be within your Drupal site at sites/default/settings.php, or may be an include file named like sites/default/settings.*.php.

Config sync directory

The config sync directory is where Drupal stores your exported configuration YAML files. Before Drupal 8.8, you could configure multiple directories for exporting config; now there's only one, and the variable name has changed.

Check settings.php files for the $config_directories variable:

$config_directories = [];
$config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sites/default';

Replace this (using your original path) with:

$settings['config_sync_directory'] = '../config/sites/default'; More information Temporary (temp) directory

The temp directory is usually specific to your host or the environment where your Drupal site is running, so you may need to set this differently for production vs. local development.

Check your settings.php files for the temp directory configuration:

$config['system.file']['path']['temporary'] = $_ENV['TEMP'];

Replace this (using your environment-specific path) with:

$settings['file_temp_path'] = $_ENV['TEMP']; More information Update composer.json

Drupal 8.8 introduced scaffolding in core and separated dev dependencies into a separate package. The scaffolding manages core files like index.php and .htaccess, which are required for Drupal to run but don't live within the core/ directory. You might already be using drupal-composer/drupal-scaffold for this purpose, which will need to be replaced.

Because these changes involve replacing existing packages and updating composer plugin configuration, they need to be manually applied to your composer.json.

Use the drupal/core-composer-scaffold package

Edit your composer.json and to the require section, add:

        "drupal/core-composer-scaffold": "^8.8",

This should replace the drupal-composer/drupal-scaffold package, if you were using it.

This is a composer plugin, and needs to be configured in the extra section of your composer.json. Add or update the drupal-scaffold configuration:

        "drupal-scaffold": {
            "locations": {
                "web-root": "web/"
            "allowed-packages": [
            "file-mapping": {
                "[web-root]/.htaccess": {
                    "mode": "replace",
                    "path": "web/core/assets/scaffold/files/htaccess",
                    "overwrite": false

Double check the web-root location and change web/ if necessary -- for example, if you're hosting on Acquia, set this to docroot/.

Also check the file-mapping section and make sure the value for path is correct. This file-mapping configuration will prevent your .htaccess file from being overwritten if you've customized it, but can be left out otherwise.

More information Add the new drupal/core-recommended package to your Composer requirements

This will install your core Drupal requirements.

Edit your composer.json and in the require section, replace the drupal/core package with:

        "drupal/core-recommended": "^8.8", Add the new drupal/core-dev package to your Composer dev requirements

This will install optional, development-specific core dependencies so that you can run things like automated testing.

Edit your composer.json and to the dev section, add:

        "drupal/core-dev": "^8.8",

This should replace the webflo/drupal-core-require-dev package, if you were using it.

More information Finally, run Composer

Now that you've updated your composer.json file, run Composer to update your packages. In order to update only the packages you've changed (and not every package all at once), run:

composer update --lock Troubleshooting Composer

After making these changes to your composer.json, you may see the following error when you run composer install or composer update:

Installation failed, reverting ./composer.json to its original content.
Could not delete /srv/users/serverpilot/apps/sandbox/drupal/web/sites/default/default.services.yml:

This happens because the scaffolder (which runs on composer install and update) is trying to write files to your sites/default/ directory, but doesn't have the permissions. You can resolve this with:

chmod +w web/sites/default

See Troubleshooting: Permission issues prevent running Composer for more details.

Running the update scripts

Finally, you'll need to do the normal Drupal update process: run the database exports, and export any config changes:

drush updatedb
drush config:export Troubleshooting the database updates

If you're testing the database updates multiple times on the same environment, you may run into this error:

[error] Update failed: system_update_8804

This happens because system_update_8804 creates new database tables. If you are using drush sql-sync to test and re-test the update against a copy of the production database, you'll need to clear your local database with drush sql-drop first, in order to delete tables created by a previous run.

What next?

Once your site has been updated to Drupal 8.8, you'll be in good shape for the upgrade to Drupal 9, which is currently anticipated on or around June 3, 2020. Between now and then, we'll be working alongside other Drupal contributors to make sure that key contributed modules are ready for Drupal 9, as well helping our clients make sure that custom code and modules on their sites are free of deprecated APIs. Stay tuned for more!

Development Drupal Support
Categories: Drupal

Prevent front page delete

New Drupal Modules - 20 December 2019 - 6:01am
Categories: Drupal


Subscribe to As If Productions aggregator - Drupal