> I had wondered about creating a contrib module to address the problem
I'm not sure that a contrib module is the appropriate solution to this, as this isn't a problem you're going to be aware of until it happens, the very definition of a bug. This is exactly what @bkosborne mentioned in #68 📌 Do not allow existing or reserved paths as aliases Needs work .
However, as other people have mentioned 📌 Do not allow existing or reserved paths as aliases Needs work , there certainly could be a use case for overriding a system path with an alias. There also could be a case where someone has inadvertently used this without realizing the implications. To address this, I added the permission. If this gets accepted into core, it should be clearly noted in the release notes.
@bkosborne's comment 📌 Do not allow existing or reserved paths as aliases Needs work made me realize thatt his issue can apply to any system route, so instead of using the proposed pattern matching in #67, it verifies if the proposed alias matches any of the currently available routes. This also means that no configuration changes are needed.
Still need to determine appropriate unit tests.
Looking at the most recent patch -- #67 I see that it adds `override url aliases` as a new permission. Which is, I think, correct. However, this does mean that, hypothetically, this could break for a user who is relying upon this ability. The classic "using a bug as a feature" scenario.
Since this is just a validation method, existing revisions would be unaffected. I think this makes sense. Does it make sense to reject this pattern on a new revision of existing content?
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.