Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Postponed on #2941757: Extension System, Part IV: Properly register all installed extensions/namespaces during container generation.
Cache backends are now defined in the DIC.
To have something available in the DIC as a service, it needs to be registered in a services.yml
Only modules can provide services.yml
Previously, you could enable memcache (or another session/cache/lock/queue backend) entirely via settings.php without having to enable a module at all. Now the service would have to be defined services.yml in memcache module, then settings.php could do the rest.
This affects both large multi-sites where you want to configure every site to use memcache just once (via a shared settings.php or whatever), and also potentially dev/staging where services might want to be different based on the environment.
Not sure what to do about this, when discussing with Damian we thought about sites/*/services.yml (and/or allow settings.php to specify a file location).
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | interdiff-2044137-4.txt | 1.44 KB | damiankloip |
| #4 | 2044137-4.patch | 1.47 KB | damiankloip |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedSo the main problem is that we can't register any namespaces here, so adding stuff to the container will not help.
The code in DrupalKernel::discoverServiceProviders() currently allows to add service providers and yaml files when the container is getting built. So for instance, we could create a ServiceProvider and load that, but we need more to use something like a cache backend in the DIC.
Comment #2
sdboyer CreditAttribution: sdboyer commentedsites/*/services.yml jumps out as the simplest, sanest approach to me - it sticks with the yml-based approach, and is situated at a level on the filesystem that makes it clear that its logical container is a site.
problem with it is that it's not easy to expand that into something which varies by env (unless you're capturing different environments via multisite, aka DOING IT RONG).
hmm...i'll ponder a bit on that.
Comment #3
damiankloip CreditAttribution: damiankloip commented#2, we can already add serviceProviders/yaml providers from settings.php to get included when the container is built.
ok, so as mentioned in #1, I think what we really need to tackle is being able to add namespace prefixes from settings.php. The rest I think we can deal with, as we can either add a service provider class or a Yaml services file in settings.php. As long as we have namespaces, we can load the services we need.
Depending on which issues lands first, this or #2060571: Inject Settings class into DrupalKernel, this should be converted to use Settings() instead of $GLOBALS.
Comment #4
damiankloip CreditAttribution: damiankloip commentedok, speaking to msonnabaum on IRC for a bit; Let's just use settings in the kernel, injecting it is probably not needed. atleast not an this stage.
Added a settings method to DrupalKernel, this just returns Settings::getSingleton(), then if we need to change anything later, none of this code needs to change.
Comment #6
damiankloip CreditAttribution: damiankloip commented4: 2044137-4.patch queued for re-testing.
Comment #7
damiankloip CreditAttribution: damiankloip commentedComment #8
Anonymous (not verified) CreditAttribution: Anonymous commentednice. do we need anything else to RTBC this?
Comment #9
damiankloip CreditAttribution: damiankloip commentedI think just maybe a test for this really.
Seems like it might be a good idea to wait for #2021959: Refactor module handling responsibilities out of DrupalKernel, then continue with this. As testing etc... should be easier then anyway.
Comment #10
mgiffordLooks like this may have hit a serious snag and have to be redone #2021959-36: Refactor module handling responsibilities out of DrupalKernel
Comment #11
chx CreditAttribution: chx commentedIsn't this solved with sites/default/services.yml introduced?
Comment #12
BerdirYou still need to have the module enabled for the namespace to be loaded. This issue adds a workaround for that.
However, I don't really see the problem of having to enable a module. Cache backend modules have always been very weird in the way they work and different from all other modules, so why not just live with it?
Comment #13
dawehnerI agree with berdir, running code which is not supposed to be run originally can lead to all kind of weird sideeffects so we better don't support it in the first place?
Comment #24
quietone CreditAttribution: quietone at PreviousNext commentedThis was postponed on an issue that was closed as a duplicate of #2941757: Extension System, Part IV: Properly register all installed extensions/namespaces during container generation, so it is now postponed on that.
Comment #25
BerdirNobody seems to disagree with my comment from 2014, so lets see if someone disagrees with closing this.
Note: You technically can do this now, you can add to the classloader directly to load code from a module and that is done for the bootstrap container definition for example which is possible to put in redis.
See #3007374: Document bootstrap_container_definition in README and #2644450: Document bootstrap_container_definition for issues on documenting that.