Aug 12 2019
Aug 12

Drupal has pretty good multilingual support out of the box. It's also fairly easy to create new entities and just add translation support through the annotation. These things are well documented elsewhere and a quick search will reveal how to do that. That is not what this post is about. This post is about the UX around selecting which fields are translatable.

On the Content Language page at you can select which fields on your nodes, entities and various other translatable elements will be available on non-default language edit pages. The section at the top is the list of types of translatable things. Checking these boxen will reveal the related section. You can then go down to that section and start selecting fields to translate, save the form and they become available. All nice and easy.

I came into the current project late and this is my first exposure to this area of Drupal. We have a few content types and a lot of entities. I was ticking the box for the entity I wanted to add, jumping to the end of the form and saving it. When the form came back though it was not selected. I could not figure out why. It wasn't until a co-worker used the form differently to me that the issue was resolved. Greg ticked the entity, scrolled down the page and found it, ticked some of the checkboxen in the entity itself and then saved the page. The checkbox was still ticked.

The UX on this pretty good once you know how it works. It could be fixed fairly easy with a system message pointing out that your checkbox was not saved because none of the items it exposed were selected.

I feel a patch coming on…

May 02 2019
May 02

Part of me is suspecting that I may be one of the lucky 10,000 today but I figure it's worth putting this out there because if I wasn't aware of this then there may be others too. It turns out that the version of Drush that you just installed may not be the version of Drush that executes your command.

So, as it happens there's a number of ways to install Drush. Older OSs may have it in the package management system, you may have just installed it globally using the instructions on the site, or, if your project is managed by composer it may have been installed as a site-local version. In my case I had messed it up just a little and had multiple versions hanging around and, despite having definitely downloaded and installed drush 8.2.3 to /usr/local/bin/drush and I confirmed that this was being called via which drush when I ran drush --version it informed me I was running version 9.6.2.

The thing that I didn't know... Drush will check the directory the site is in to see if there is a local-site version installed and pass off the request to that. So despite having Drush 8.2.3 installed and called from the command line the request was finding the local copy and returning results from that. If it wasn't for the fact that this was a Drupal 7 site and I'd inadvertently installed Drush 9.x locally via composer. If it wasn't for the fact that Drush 9.x doesn't support Drupal 7.x I'd never have known that this was how it worked.

Big thanks to Kirill for correcting my brain meat on this.

Oct 23 2018
Oct 23

Congratulations to Victoria Spagnolo (quietone) for winning the Open Source Contributor award at this years New Zealand Open Source Awards for contributions to the Drupal Project and Drupal Migrate.

As someone that has made regular use of the Migrate module and the IRC and Slack channels Victoria's contributions to the modules and willingness to answer questions and engage with those of us needing advice and help is very much appreciated.  It's nice to see that being recognised in this way.

Jul 16 2018
Jul 16

We have a very large migration project on at the moment and the nodes take more than a day to run a full migration.  We're at the point where we really don't want to rerun the whole thing and we're seeing some things that need updating. The quick solution was to fix these in the process plugins for the actual migration and then create a quick 'fix' migration that just does a simple SQL update on a field table.  The updated process plugin to fetch the source value was also a very lightweight SQL query that didn't require any entities or objects to be loaded.

The NoOp destination plugin was needed because the NullDestination plugin appears to not work on purpose. This left a situation where you could never have a migration without a destination.

Jun 18 2018
Jun 18

I had a Drupal 8 migration where there was some data that was available, but not available from the source DB. However, I was able to get this data in a separate CSV file and a value in the source db was available in this CSV file also. So I had a way around the issue.

This plugin allows for the CSV file to be parsed, cached and queried for a single column allowing for the single file to be used for multiple fields.

May 28 2018
May 28

This process plugin was created due to a dodgy source repository.  Not all the files were available and the default file_copy plugin would crash and burn if the source was not there.  This plugin can be used in the process section of a Drupal 8 migration like this;

  plugin: custom_file
  scheme: public
    source_base_path: ''
      plugin: concat
      delimiter: /
        - constants/source_base_path
        - filepath
      plugin: urlencode
      plugin: skip_on_404
      method: row
        - '@source_full_path'
        - uri
      plugin: file_copy

I really need to get my CSS sorted out for code blocks...

The plugin:

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