Add mechanism to have workspaces skip processing entity types

I tested and seems to work well!

Rerolled #2 for 9.5

I'm not sure if the proposed solution here actually makes sense. There is already an existing solution to enable/support entity types in, which are not publishable and revisionable, in workspaces by marking them as internal, see #3027598: Omit workspaces entity presave and predelete hooks for internal entities.

Given that possibility It feels relatively cumbersome to override the workspace manager just to allow some entity type to be handled inside workspaces, when compared to implementing hook_entity_type_alter() and marking an existing entity type as internal in a custom module, or even marking a custom entity type as internal right via the internal flag of the entity type annotation. IMO this feels much lighter than overriding a core service to support an entity type, so I'd personally close this as a won't fix.

If going for a solution like the one proposed here, I'd suggest to expose supported entity types via config or even on a settings form instead of hardcoding this inside an overridden service.

We already have something similar in place for config entity, which are supported via the wse_config submodule of the workspaces extra module. The corresponding code can be found here: https://git.drupalcode.org/project/wse/-/blob/1.0.x/modules/wse_config/w...

There is already an existing solution to enable/support entity types in, which are not publishable and revisionable, in workspaces by marking them as internal

Marking entity types as internal is just a temporary workaround until a proper API was created in this issue :) Also, it doesn't really work in all cases, see #3058224-3: Allow CRUD operations for Crop entities in a workspace

After getting more experience with how Workspaces is used in production sites, my proposal is to add four "workspace support states":

• unsupported - workspace processing throws an exception (e.g. non-revisionable entities, config entities)
• ignored - workspace processing allows pass-through (e.g. entities that don't affect the live site; e.g. paragraph, crop, file?)
• supported - workspace processing does its job for every entity of this type
• supported on per-entity basis - workspace processing needs to ask each entity if it's supported (e.g. non-reusable blocks)

These support states will come in a new workspace_information service, which would deprecate WorkspaceManagerInterface::isEntityTypeSupported(), ::getSupportedEntityTypes() and shouldAlterOperations().

Here's a patch based on the proposal above. Still needs test coverage for new service, but the code itself is ready for review.

Oops :)

Fixed that last fail.

Will this still need tests?

Could new functions be typehinted?

Didn't do a full code review (not as familar with workspaces)

Rolled this patch on top of #3092247: Prevent content from being deleted when there is an active workspace, for those who need it.

This definitely still needs some test coverage, I'll look into that next.

Same patch as above, for who needs it to apply against Drupal 9.5.x.

To apply the 9.5.x patch in #3101671-21: Add mechanism to have workspaces skip processing entity types I also needed to apply these patches before:
* #3129762-20: Creating an unpublished entity in a workspace does not set the workspace field on the revision
* #3092247-57: Prevent content from being deleted when there is an active workspace

For drupal core 9.5.x i'm getting
Cannot apply patch https://www.drupal.org/project/drupal/issues/3101671#comment-14976504 (https://www.drupal.org/files/issues/2023-03-21/3101671-21-against-deletable-9.5.x.patch)!
Any fixes for this issue. I also applied the patches from #22

@CedricL, see comment #22, you also have to apply two other patches before this one.

Rerolled #16 on top of latest 11.x.

Updated to the latest coding standards. Leaving at NW for adding test coverage.

Fixed a few deprecated usages.

Reroll #30 for 10.2.2, but would expect it to work on 11.x based on the minor change.

Hiding last patch, as it missed a directory

Trying this again as the last patch missed a directory.

Even with the updated patch plus #3092247-62: "[PP-1] Prevent content from being deleted when there is an active workspace", I'm not able to upload images in the non-default workspace.

I get the following error via Ajax:

Drupal\Core\Entity\EntityStorageException: This entity can only be saved in the default workspace. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php). workspaces_entity_presave(Object)
call_user_func_array(Object, Array) (Line: 409)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'workspaces') (Line: 388)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('entity_presave', Object) (Line: 416)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_presave', Array) (Line: 217)
Drupal\Core\Entity\EntityStorageBase->invokeHook('presave', Object) (Line: 900)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('presave', Object) (Line: 529)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 753)
Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object) (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 806)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 352)
Drupal\Core\Entity\EntityBase->save() (Line: 293)
Drupal\file\Upload\FileUploadHandler->handleFileUpload(Object, Array, 'public://hero_images/', 0) (Line: 658)
file_save_upload('field_content_hero_0_subform_field_hero_image_0', Array, 'public://hero_images', NULL, 0) (Line: 536)
_file_save_upload_from_form(Array, Object) (Line: 1007)
file_managed_file_save_upload(Array, Object) (Line: 76)
Drupal\file\Element\ManagedFile::valueCallback(Array, Array, Object) (Line: 337)
Drupal\file\Plugin\Field\FieldWidget\FileWidget::value(Array, Array, Object)
call_user_func_array(Array, Array) (Line: 1266)
...

@webdrips this patch only adds the possibility to "ignore" entity types in a workspace, it doesn't yet do it for the File entity type. That will probably happen in #3025785: Cannot create entity with image in a workspace.

Here's a fairly extensive update after using this patch in production for several years. The problem with the initial approach (using constants on WorkspaceInformationInterface) was that an entity type could not declare its workspace support when the Workspaces module wasn't installed, since the interface couldn't be loaded, so we're now using explicit entity handlers for supported and ignored entity types. Entity handlers can point to a non-existent class, because the class won't be loaded until someone tries to instantiate that handler.

Also added test coverage, so removing the tag. I'll convert the patch to a MR, then it should be fully ready for reviews!

Updated the issue summary and hid all the patches because we have an MR now.

Made a few suggestions but they can apply to a number of the files.

But is there BC concerns for marking previously not internal files as internal? I don't know the policy around that.

@smustgrave, thanks for reviewing! Fixed your suggestions, and after scanning the code again for similar changes that could be done to other constructors, I think I would prefer to "modernize" them all in a separate issue.. this MR is already big enough IMO.

Updated the CR as well.

FWIW, this is the #1 issue in the (somewhat short) list of blockers for marking Workspaces as stable, which I hope we can do in 10.3 :)

Changes look good and test updates. CR reads well

Adding a handler is a good idea, and the entity type/entity split handles block content entities nicely - flexibility but without a lot of messing about for entity types that don't need it.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!