As happens so often, real life has been getting in the way of making more progress on my attempts to migrate The Gallery Guide from Drupal 6 to 8.
Now that I’ve moved back to London, I’m not living like Alan Partridge any more, and I’m not cursed and blessed with ridiculous early mornings or evenings on my own, so this project has been on the back burner for a while. I have managed to find a little bit of time to start looking at it again - although unfortunately in short stretches, rather than in a long enough stint to really get into a good flow, but better than nothing.
As I mentioned in my last post, one of the node migrations is failing. For some reason, it’s now failing with a different error:
Migration failed with source plugin exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column [error]
'field_postcode_short_' in 'where clause': SELECT 0 AS delta
FROM
{content_type_gallery} t
WHERE (field_postcode_short_ IS NOT NULL ) AND (nid = :db_condition_placeholder_0) AND (vid = :db_condition_placeholder_1);field_postcode_short is a computed field on the gallery content type in the D6 site, which shows the first part of a gallery’s postcode, derived from the value entered for the address. The weird thing is the extra underscore in the SQL query. Perhaps there’s something odd about the way the Computed field module stores its data. The module does have a D8 version, but I’d like to minimise the number of modules I need on the site, and I’m not sure if this field is actually necessary. The other odd thing is that I can’t figure out where this migration is being registered. Digging through the database and the code, there’s nothing that seems to be relevant, and the migration seems to be getting registered automatically. I should probably start from scratch, and approach the whole thing in a much more scientific manner.
With the limited time available to me, I was getting frustrated with banging my head against this migration problem. I wanted to feel a sense of progress, so I switched to a different task, deciding to get some work done on the theme. It may not be how I’d approach things at work, leaving something half-done and moving on to something a bit easier, but I’m my own boss on this project, and there isn’t really a critical path.
One of the most useful little modules used on the old site is Prepopulate, which allows fields in node edit and creation forms to be filled based on items in the query string. For instance, on a gallery page, there’s a link to create a new exhibition at that gallery. The module has a dev version for D8, but it doesn’t currently support entity reference fields. I found an existing issue with a suggested fix, and put that into a patch which works perfectly for my purposes - the joy of open source.
With that patch in, I could start adding my custom links to node templates. Having worked on themes for Drupal 6 and 7 for so long, it feels very odd to be creating links and including text in templates, but following the Twig guidelines it seems to make sense. As with some of the other changes in Drupal 8, for people who have been working on the Drupal island for a while, there’s some unlearning to be done, and it’s important to try and approach things with beginner’s mind.
Here’s the first pass at the links in the templates. I think I should probably re-work them to generate the links using Twig functions, but they work for now:
{% if logged_in %}
<a href="/node/add/exhibition?edit?edit[field_gallery]={{ node.id }}">{{ 'Add a new exhibition at this gallery'|t }}</a>
<a href="/node/{{ node.id }}/edit">{{ 'Edit this gallery'|t }}</a>
{% else %}
<a href="/user?destination=node/{{ node.id }}">{{ 'Log in or register to edit this gallery'|t }}</a>
{% endif %}Sometimes you figure out a problem by not thinking about it for a while, and sometimes the best way to solve the problem is to figure out a way of not needing to solve it. Having left the migration issue to stew itself over in my mind for a few days, I realised that the short postcode field isn’t necessary, so the best thing to do is delete it from the Drupal 6 site. In an ideal world, I’d investigate more and fix the problem migrating that field, but just because a problem is interesting or challenging, doesn’t mean you have to try to solve it.
Having deleted that field, the migration could run to completion, and my local dev site now has 719 galleries for me to poke about with. Which is good, but now it’s on to the next problem - the link field in the old site didn’t necessarily store the http:// protocol. The migration didn’t choke on it, but when viewing the migrated nodes it causes a fatal error. So I’ll need to edit the value as part of the migration. But that can wait for another day…