Invalid page form discards blocks

[jimsafley]

When a block layout flags an error, the site page form correctly becomes invalid. The resulting page flashes the error message, as expected, but it also discards blocks under some conditions.

To reproduce, add an error to, say, the HTML block's Html::onHydrate():

$errorStore->addError('element_name', 'invalid block');

Then, on a new site page, add an HTML block and any number of other blocks, and save the form. The form shows the error, but all new blocks are discarded, including the HTML block. The expected behavior is to keep the new blocks.

Even more confusing and concerning is the behavior when there are existing blocks. Add any number of other blocks and save the form. Then, add a HTML block to the end and save the form. The other blocks remain, as expected. Now, add a HTML block and move it to the top and save the form. The HTML block remains, but the last block is discarded. The expected behavior is to not discard the last block.

This behavior only happens when a block adds an error during hydrate. We likely haven't seen this before because, as far as I know, no block layout validates the data.

[jimsafley]

This happens because, when updating the site page, SitePageAdapter::hydrateBlocks() follows a recurring hydration pattern of iterating the existing ArrayCollection of blocks, and re-using them in order they were received. This will overwrite existing blocks if they're submitted in a different order. If there's an error, the order of the resulting blocks on the page depends on the overlap between the original blocks and the submitted blocks.

Let's say the following blocks already exist on the page:

• Page title
• Media embed
• HTML

Then, a user adds a "IIIF presentation" block to the bottom of the page, submits the form, and there's an error in that block. The resulting page will be:

• Page title
• Media embed
• HTML

Which is more or less expected. It would be better if the "IIIF presentation" block carried over so it could be corrected, but that's another issue.

Then, the user adds a "IIIF presentation" block to the top of the page, submits the form, and there's an error in that block. The resulting page will be:

• IIIF presenttion
• Page title
• Media embed

Note that it discarded the "HTML" block! Not good. This is because the "IIIF presentation" block (the the other two) popped it off the original stack of three blocks.

What I don't understand is why Omeka doesn't preserve the new number of blocks. SitePageAdapter::hydrateBlocks() adds blocks to the ArrayCollection so I would expect subsequent calls to $sitePage->blocks() would reflect the new number. Something to look into.

[jimsafley]

What I don't understand is why Omeka doesn't preserve the new number of blocks.

More than likely, the culprit is the entity refresh in AbstractEntityAdapter::hydrateEntity(). Which reverts the array collections to their original state.