Handle bogus/missing D6 format values [#2207823]

Well, I've tracked down why my content migrations in the UI (#2200379: Upgrade UI) error out. I'm getting

Drupal\Core\Entity\EntityMalformedException: The entity does not have an ID. in Drupal\Core\Config\Entity\ConfigStorageController->save() (line 312 of /Users/mryan/Sites/imp/core/lib/Drupal/Core/Config/Entity/ConfigStorageController.php).

in the d6_user migration. The culprit is the signature_format field - the d6_filter_format migration has picked up the 1 (filtered_html) and 2 (full_html) formats from my D6 site, but in the users table signature_format is 0 for most users (not sure if that's a standard D6 no-filter-set flag, or something messed up on my site). The migration process plugin, when it fails to find 0 in the d6_filter_format map, tries to create a stub and it craps out with the above error. A few different considerations here:

Not every destination makes sense to be stubbed - we should allow for destinations that don't support stubbing.
Thus, the migration process plugin needs to allow for failure to resolve a reference or create a stub and return NULL (so we can fall through to a default_value).
Can an incoming ID value of 0 ever mean anything specific? We might want to assume an incoming 0 ID represents emptiness/defaultness and just fall through (or not - probably valid for Drupal sources but not necessarily other ones).

So, I'd like to see the signature_format mapping in d6_user look like:

  signature_format:
    -
      plugin: migration
      migration: d6_filter_format
      source: signature_format
    -
      plugin: default_value
      default_value: filtered_html

Hmm, but the site might have started from a profile without filtered_html... We'd want the default to be somewhat more dynamic - probably the lowest-weight filter available to anonymous users.

Comment	File	Size	Author
#4	imp-fix-unstubbing-2207823-4.patch	2.19 KB	mikeryan

Comments

Comment #1

chx commented 2 March 2014 at 04:59

Priority:

Major

» Critical

Comment #2

chx commented 2 March 2014 at 05:01

In another report by penyaskito:

In Drupal6, we had a special filter format:

// This is a special format ID which means "use the default format". This value
// can be passed to the filter APIs as a format ID: this is equivalent to not
// passing an explicit format at all.
define('FILTER_FORMAT_DEFAULT', 0);

In Drupal 8, for the same behavior, the default is NULL.
So we need to map from 0 to NULL before passing the signature format to the migration process plugin.

Comment #3

penyaskito

he/him

Spanish

🧑🏽‍🌾 Seville 💃 Andalusia, UTC+2 🇪🇺

commented 2 March 2014 at 10:19

Defaulting to the lowest-weight filter available to anonymous users makes sense to me.

Comment #4

mikeryan

he/him

English

Pittsfield, MA, USA

commented 17 April 2014 at 18:24

Status:	Active	» Needs work
Issue tags:		+Needs tests

Status	File	Size
new	imp-fix-unstubbing-2207823-4.patch	2.19 KB

Addressing this in the stub handling of the migration plugin. First off, making sure 'no stub' is respected, and secondly returning NULL instead of throwing an exception if no match is found (because throwing out the whole imported entity for the lack of one field value is excessive, and this enables a later stage of the processing pipeline to take a shot at coming up with a value).

We need tests for the 'no stub' configuration, and also a specific filter format test for an incoming value of 0.