I could see the most common use for this would be to tweak things a bit, not re-writing everything entirely. (maybe if projects need to do something completely different it would be easier to just take over the controller at that point?)
Agreed .. I just thought that it made the most sense to provide the module's default event implementation using the same mechanism provided to anyone else who might be interested. Of course, the original way works too and I can see merit to that as often there's just a tweak needed by a consuming module. FWIW, doing it this way helped me identify an appropriate place to fire the event.
Just please let me know if, after considering this, you'd still like to have the generated row implementation in the controller.
I don't think it's a super common pattern to do that, rather the module would still have its core business logic present to get those starter values, then dispatch an event with those values to allow other modules to alter them. Though, this method does make it easier for some other module to completely disable the main event subscriber if they want.
I agree that it's not super common, but the reason I chose to do this here was flexibility -- like you said to disable the main subscriber if desired. You could also disable the main event subscriber and override the "starter" subscriber if your use case allows for it.
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.
@bosborne -- looks like there's an issue at https://www.drupal.org/project/drupal/issues/2833378 → to create an interface for this exact problem.
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`.
We might be able to install the external dependency by creating a custom installer like so: https://getcomposer.org/doc/articles/custom-installers.md
partyka → created an issue.
Admin GUI to disable individual tests
The upstream JS library needs to support this first.
Hello -- I'm interested in leading an initiative/get help on the Editoria11y → project. Version 2.0 was just released, and looking for help with the project backlog (generally) as well as some DevOps stuff specifically.
Can also help with DDEV as needed.