el7cosmos → created an issue.
In the case of module handler, even if without changes from
📌
Allow needs_destruction services to run on page cache hits
Needs review
, decorators that don't implement DestructableInterface will also fail in 10.2 if we apply
📌
Replace RequestCloseSubscriber with needs_destruction tag on ModuleHandler
Fixed
.
this just because the call changed from writeCache which declared in ModuleHandlerInterface to destruct which is new implementation.
As for
📌
Allow needs_destruction services to run on page cache hits
Needs review
, I don't think we can access decorated/original service from DrupalKernel, so even if we register the original service in kernel.destructable_services (eg hux.module_handler.inner) we won't be able to get it from the Kernel with $this->container->get('hux.module_handler.inner').
Perhaps, instead of a parameter we can create a service that can receive the original service as the argument, but that will initialize the instance and defeat the purpose of $this->container->initialized($id).
I can't see any other solution than:
- Implement
DestructableInterfacefrom the service's interface, not implementation, this will enforce decorators to implement that also. - Let it be the decorator's responsibility to implement
DestructableInterface, but the container will crash if it is not.
el7cosmos → made their first commit to this issue’s fork.
I created an MR to decorate the event dispatcher service instead, but this only works in 10.3.
If we want this on 10.2 also, we can create a compiler pass similar to https://git.drupalcode.org/project/drupal/-/commit/6e733866fe414d0521be3... that only works for <10.3 (eg using deprecation helper)
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → made their first commit to this issue’s fork.
el7cosmos → created an issue.
el7cosmos → made their first commit to this issue’s fork.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
@j-barnes the MR only affects when importing configuration during site installation, this won't handle running the config import after the site is installed
el7cosmos → made their first commit to this issue’s fork.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → made their first commit to this issue’s fork.
el7cosmos → created an issue.
This is still missing "Add More" button.
Also, not a duplicate of related issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
Create an MR to disable the module handler decorator during site installation. Really appreciate it if anyone is able to review and test it.
This is because Drupal rebuilds the container each time a module is installed. Since this module doesn't provide events during site installation I think it makes sense to disable the module handler decoration.
this is done as part of 📌 Add hook_entity_bundle_ implementation Fixed
el7cosmos → made their first commit to this issue’s fork.
el7cosmos → created an issue.
el7cosmos → made their first commit to this issue’s fork.
Left a comment in the MR
Can you provide a step to reproduce? I can't reproduce this on a clean install
el7cosmos → created an issue.
el7cosmos → created an issue.
sorry, wrong issue, this was meant for https://www.drupal.org/project/drupal/issues/3421010 📌 Convert ViewsArgumentValidator plugin discovery to attributes Active
el7cosmos → made their first commit to this issue’s fork.
el7cosmos → created an issue.
el7cosmos → created an issue.
el7cosmos → created an issue.
Thanks, @gaurav_manerkar, this looks very good, just one minor I left on the MR
el7cosmos → created an issue.
el7cosmos → made their first commit to this issue’s fork.