When migrating blocks, the BlockRegion process plugin, given the source theme name, attempts to map the block to the same region in the destination theme. If the source and destination theme are the same, the region is unchanged; otherwise, the plugin falls back on a static map provided to it in configuration. The problem is, the static map is not theme-aware. It would be better if it would look something like this:
region_map:
source_theme1:
region1: destination_region1
region2: destination_region2
source_theme2:
region3: destination_region1
region4: destination_region3
...and so forth. This would make the BlockRegion plugin more powerful and capable of handling more complex block migration scenarios. It'd also be a pretty easy change, although it could break backwards compatibility depending on how we implement it.
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | interdiff-2753939-15-27-8.2.x.txt | 5.12 KB | phenaproxima |
| #27 | 2753939-27-8.2.x.patch | 12.67 KB | phenaproxima |
| #23 | interdiff-2753939-19-23.txt | 3.06 KB | phenaproxima |
| #23 | 2753939-23.patch | 12.7 KB | phenaproxima |
| #19 | 2753939-19.patch | 12.63 KB | phenaproxima |
Comments
Comment #2
alexpottWell actually block region migration is fundamentally broken...
Comment #4
phenaproximaThis will break Migrate BC, but that's OK.
Comment #5
phenaproximaOkay, let's try this approach on for size. I fully expect this to break several Migrate tests.
This patch changes BlockRegion so that it extends StaticMap. That way, if the block cannot be migrated directly from its source region to a destination region, it falls back onto using the static mapping functionality. This means you can map the regions based on what the source theme is, or what the source and destination themes are. And if the bypass flag is not set, it throws MigrateSkipRowException -- exactly as StaticMap would. IMHO this approach is ten times more flexible than BlockRegion previously was -- keeping all the benefits, and shedding the flaws.
Comment #8
mikeryanIs this a BC break? If so, we should try to get it into 8.2.x.
Comment #9
phenaproximaThis patch tries to make the improvement, touching as few things as possible. Truth is, block migration needs a lot of work -- it's really janky, rickety, and prone to strange behavior because it's concerned with migrating the legacy data with as few changes as possible, rather than migrating things in a way that will make sense when the user looks at their migrated site. Nonetheless, the improvements I'd like to make are well outside of the scope of this issue.
Comment #10
mikeryanLooks good to me, but I'd like someone with a better knowledge of block/theme layout to also look at it for RTBC.
There should be a change record for the block_region process plugin.
Comment #11
phenaproximaChange record written!
Comment #12
benjy commentedThe patch looks good. Worth noting that we seem to have a split in core where sometimes we setup the map in the YAML as a pipeline when other times we extend StaticMap and make our plugin use the parent as the fallback.
Do we need to call
block_rebuild()in this test? That's what alexpott was doing in #2 for the failing test.Comment #13
phenaproximaGenerally I'm in favor of extending StaticMap. In my experience, these specialized mapping plugins (BlockRegion and BlockPluginId leap to mind) essentially depend on static mapping, or are designed to fall back on to it (i.e., they more or less expect to precede or succeed a StaticMap instance in the same processing pipeline). Point is, they're not really meant to work independently of a static map; therefore, in those cases I prefer to cut out the middleman and simply make them extend StaticMap.
EDIT: I'll add a call to
block_rebuild()to see what, if any, effect it has on the test. It's quite possible that a lot of things will break, because there are many more problems with block migration than just this snafu with the region mapping. But, fixing all block migrations is out of scope for this issue.Comment #14
benjy commentedYeah, lets add block_rebuild() call even if we don't fix it here at least we can open more follow-ups. After that, i'm +1 for RTBC.
Comment #15
phenaproximaAdded block_rebuild() calls to the D6 and D7 versions of MigrateBlockTest. They both pass on localhost, so fingers crossed.
Will kick this issue to RTBC if it passed Drupal CI.
Comment #16
phenaproximaGreat success! RTBC per #10 and #14.
Comment #17
alexpottThis patch needs a reroll and as a migrate BC break I think we should endeavour to fix this during the 8.2.0 RC window.
Comment #18
alexpottComment #19
phenaproximaSo the patch in #15 still applies to 8.2.x...this patch is a re-roll against 8.3.x. No interdiff due to rejected hunks.
Comment #20
alexpottWhy are we removing these status checks? Surely we should be checking the status after the migration?
Comment #21
phenaproximaEDIT: Never mind.
I had originally posted a hissy fit here, but having researched things a bit I see what's going on. There is a bit of a "conflict of intent" going on between the MigrateBlockTest classes in 8.3.x and the changes in #2513534: Remove the 'disabled' region from Block UI. If nothing else, they need to be better documented. I will post an updated patch.
Comment #22
phenaproximagit archaeology has revealed that #2513534: Remove the 'disabled' region from Block UI introduced changes that require this patch not simply to be rerolled, but retooled for 8.3.x.
Comment #23
phenaproximaRestored the status assertions and added a touch of documentation explaining why we are asserting that.
We are going to need a follow-up issue to address the fact that both the d6_block and d7_block migrations are skipping over blocks that are disabled in the source database -- now that block status is meaningful in 8.3.x, it no longer makes sense to skip those blocks. This is good, since it means we can migrate more data coherently.
Truth is, block migration is in fairly rough shape, because the migrations (and especially the tests) are ensuring that we migrate the block data verbatim, regardless of whether or not it's coherent. In Dublin and beyond, I intend to do a lot of work to bring block migration up to par.
In the meantime, here is a new patch for 8.3.x that makes the status assertion official.
Comment #24
phenaproximaKickin' it RTBC-style now that everything is passing on both branches.
Comment #25
alexpottCommitted 8d0d69f and pushed to 8.3.x. Thanks!
We now need a reroll of #23 for 8.2.x
Comment #27
phenaproximaRerolled against 8.2.x.
Comment #28
phenaproximaJust realized that I can, and therefore should, post an interdiff.
Comment #29
phenaproximaNow that the reroll has passed Drupal CI, 'tis back to RTBC.
Comment #30
alexpottCommitted 9f73d72 and pushed to 8.2.x. Thanks!