Importer: Image Blocks can end up in a crashed state after import

[danielbachhuber]

One idiosyncrasy of the WordPress Importer is that attachment ids can change in the import process. If an existing WordPress site already has a number of posts, those existing post ids can conflict with the post ids included in the import file.

To accommodate the changing ids, the WordPress Importer has backfill_parents() (ref) and remap_featured_images() (ref). Both of these methods use a mapping of old=>new post ids to update existing references to the old ids.

Along the same lines, Image Blocks will need their attachment ids updated, otherwise they can end up in a crashed state. To replicate what the user will experience, simply insert an Image Block and change its attachment id reference to an invalid id:

[antpb]

As discussed in the #core-media meeting yesterday, we do not see any immediate ways that Gutenberg can fix this for importer. The change would need to happen on the importer side and it would need to compare attributes to validate the new ids.

The one thing that Gutenberg does need to do is have easy to consume attributes that allow the importer to query the information needed. We are currently in progress on PR #11540 that will expose the image ids for Gallery which would likely be a blocker to importer adjusting. I'll leave this open until that work is finished out.

[pbiron]

I've just been looking into what changes would be necessary to the importer to handle this.

I've got a working proof-of-concept mod to the importer that handles remapping the attachment ID in the Image block attributes (at least as implemented in GB 4.4.0) and was just coming here to ask if there were any other Core blocks that store IDs in block attributes that might change during an import...so that I can work on generalizing that mod to handle cases other than the Image block.

I see @antpb comment about #11540. It's hard for me to tell from that PR...does it implement exactly what is proposed in #8193?

The File, Audio, Video blocks also seems to store the attachment ID in the block's attributes. Are there any others? In particular, are there any that are not media-related?

[antpb]

I cannot think of any others that would need to store ids. I verified that the file block is storing the id as expected. That was the only one that had me worried. Categories and Latest Post will always be dynamic so we don't have to account for ids there either.

FYI #11540 has been merged so Gallery ids are now available.

@pbiron With that merged, is it safe to close this issue now that we have a way to map each block?

[pbiron]

@pbiron With that merged, is it safe to close this issue now that we have a way to map each block?

I will open a trac ticket on the mods necessary to the importer to support remapping of attachment IDs in block attributes (and reference this issue in that ticket).

Before closing this, let me ask one more question (the answer to which might be better handled in the trac ticket, but I'll ask it here first).

The proof-of-concept importer mods I have work only if the attachments in question are included in the same export/import as the posts that have blocks that reference them. For example, if you export posts separately from Media and do 2 separate imports the IDs are not remapped. If the attachments are not included in the same export as the posts that reference them, then the importer currently does not remap the URLs in post_content either whether the media is referenced in a block or in "classic" content (i.e., they still point to URLs on the exporting host)...so I do not think that is a major flaw in what I've written :-)

I do not see any way around that, but wanted to mention it in case anyone has any bright ideas...before this issue is closed.

[antpb]

Thanks @pbiron! I'm going to close this issue to keep our open issues number focused.

If anyone wants to add to the conversation, the trac ticket can be found here: https://core.trac.wordpress.org/ticket/45381

[pbiron]

I had meant to add a link to the trac ticket I opened, but forgot. thanx for doing that.