On preexisting site, enabling workspaces leads to

Update here, I'm finding the that clearing of the plugin cache is not a permanent solution. The issue recurs when you make another edit.

I'm starting to thing that the proper path to a solution here is to extend the menu_link_content entity to explicity declare that it has workspace support instead of indirectly compute it's workspace support as a result of the revision support that it has.

adding a line to the entity metadata makes this clear:

handlers = {
 *     "storage" = "\Drupal\menu_link_content\MenuLinkContentStorage",
 *     "storage_schema" = "Drupal\menu_link_content\MenuLinkContentStorageSchema",
 *     "access" = "Drupal\menu_link_content\MenuLinkContentAccessControlHandler",
 *     "form" = {
 *       "default" = "Drupal\menu_link_content\Form\MenuLinkContentForm",
 *       "delete" = "Drupal\menu_link_content\Form\MenuLinkContentDeleteForm"
 *     },
 *     "list_builder" = "Drupal\menu_link_content\MenuLinkListBuilder",
 *     "workspace" = "Drupal\workspaces\Entity\Handler\DefaultWorkspaceHandler"
 *   },

Found the problem, when we introduced workspace handlers in 📌 Add mechanism to have workspaces skip processing entity types Fixed we forgot that we should also set them on the last installed entity type definitions.

I'll be able to test this patch tonight.

I think this needs an upgrade path as well, so the only useful testing atm is on a site where Workspaces hasn't been installed yet. Or at least uninstalled and then installed again :)

Thanks for always including test coverage, makes issues go by so much easier!

I re-ran the failures

Time: 00:12.169, Memory: 10.00 MB
    
    Workspace Handler Update Path (Drupal\Tests\workspaces\Functional\Update\WorkspaceHandlerUpdatePath)
     ✘ Run updates
       ┐
       ├ Failed asserting that null is identical to 'Drupal\workspaces\Entity\Handler\IgnoredWorkspaceHandler'.
       │
       │ /builds/issue/drupal-3491193/core/modules/workspaces/tests/src/Functional/Update/WorkspaceHandlerUpdatePathTest.php:55
       ┴

This keeps failing though.

That's a great failure, it shows that we're testing things properly. Fixed the update function.

Thanks for the quick turnaround, changes look good to me.

Should this issue also be concerned with the MenuLinkContent entity. In general, do we introduce harm to the platform by declaring support for workspace within the Entity definition vs having the system determine an entity's support for workspaces through it's current logic?

@cosmicdreams, the MR is handling all workspace-supported entity types. But it would be great if you could test it on your site for an additional confirmation.

cool. That's on deck for today.

I have a couple of concerns about the approach. We're moving code into the block_content module that depends on workspaces even though block_content does not depend on workspaces - are we sure this is the correct thing to do?

This is no different than entity types specifying \Drupal\views\EntityViewsData as their views_data handler, or even having entity type specific handlers (NodeViewsData extends EntityViewsData), without depending on Views :)