Extend unpublish behavior to supported Entities

Ruslan Piskarov → made their first commit to this issue’s fork.

Hi @partyka.
Thank you for patch.
I tried it, it is works with simple nodes. However when I tried to replicate node with paragraphs I got the the fatal errors. I fixed a couple on d5f49bde, however still more work is needed.
I see not NotFoundHttpException when trying to replicate a node with paragraphs.
Could you provide your case? I will try to test more.

So, throwing `NotFoundHttpException` was just to provide a user-friendly-ish experience if there was an entity that didn't support an edit route. That may be have been overly ambitious, as I didn't consider how this would work with Paragraphs and similar entities.

I see the changes to check if the `setCreatedTime` methods exist. I wonder if there's a more object oriented way to check to see if the entity supports storing creation times. I'm guessing there is not, as for example, the setCreationTime is declared on `NodeInterface`, and `MediaInterface` and I'm not finding a `CreationTimeInterface`.

Interesting find RE: paragraphs throwing an error. I wonder what the best approach is there. We don't really want to set the cloned paragraph entities to unpublished. I can't think of any other common content entity type that are embedded like paragraphs are where that'd be a problem... Maybe just hard code a check for ParagraphInterface to prevent acting on them at all?

@bosborne -- looks like there's an issue at https://www.drupal.org/project/drupal/issues/2833378 → to create an interface for this exact problem.

Thank you @partyka and @bosborne.
Now it works without the fatal errors and redirect to node. However all paragraphs are unpublished.
For now added checking for ParagraphInterface. If you have better idea, will be great.

A concern about the check for `ParagraphInterface`. Since Paragraphs is another contributed module, there's no guarantee that the interface is actually there. However, as far as I'm aware, PHP won't complain that it can't find the interface in either the `use` statement or the `instanceof` statement. I confirmed this is the case for at least php 8.1.12 by adding completely made-up classes for a use and instanceof and there was no complaint.

This post on the PHP documentation suggests that this is expected, but in the absence of documentation of this behavior it seems like it shouldn't be relied on.

I'm trying to think of a "safer" approach to account for this situation, but so far I have nothing to suggest.

Yeah I'm not sure about that either. Instead of checking the PHP interface, I would instead call getEntityTypeId() on the entity, which in this case will be "paragraph".

Thank you @partyka and @bkosborne.

Automatically closed - issue fixed for 2 weeks with no activity.

This needs to be updated to also exclude non-reusable (e.g. Layout Builder) Block Content entities from being set to unpublished. I created 🐛 Block Content entities should not be set to unpublished after they're replicated Active to resolve.