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.
Given how little this functionality is used, anything goes. I am thinking of a special named YAML file in the module directory, really. No point in making it into CMI. Putting it into .info even if it becomes yaml is not fast either.
Comments
Comment #1
chx CreditAttribution: chx commentedComment #2
chx CreditAttribution: chx commentedOne wonders whether the bundle services could provide this...
Comment #3
catchThis is supposed to be limited strictly to testing - so modules can provide themes to run tests against. Given that a very specific .yml seems good to me. If it's in the bundle then it'll be run-timey so less keen on that.
Comment #4
chx CreditAttribution: chx commentedOK, special .yml it is.
Comment #5
sunHm. Actually, the originally envisioned path forward for this has always been:
#1292284: Require 'type' key in .info.yml files
Comment #6
chx CreditAttribution: chx commentedbecause that would require parsing every .info on rebuild which is something I want to move from.
Comment #7
sunIn relative terms, the parsing of .info files is extremely cheap though. I profiled these parts of the system quite a lot in the recent weeks, and the .info file parsing never played a significant role.
Btw, this issue will also clash with #1067408: Themes do not have an installation status...
Comment #8
chx CreditAttribution: chx commentedIt's not the cheapness, it's the hook_system_info_alter.
Comment #9
sunI think you meant
hook_system_theme_info_alter()
.hook_system_info_alter()
is a different story.With #1292284: Require 'type' key in .info.yml files, the hook_system_theme_info_alter() for altering-in module-provided test themes would go away — i.e., this part:
Comment #10
chx CreditAttribution: chx commentedTo recap: this issue is part of #1833592: [META] The road out of module build circular dependency hell. We want to get rid of info parsing while messing with modules and themes because info parsing is followed by the infamous hook_system_info_alter hook and this creates the circular dependency. Sorry, I was not clear enough.
Comment #11
sunThat's a completely different topic than the issue summary focuses on.
To remove
hook_system_info_alter()
, you will have to present a very large and very good and elaborate list of arguments, for why that is needed, including solutions for how to achieve the same without the hook.In short, that's a completely different issue than this one here.
Comment #12
chx CreditAttribution: chx commentedNo, I am not removing that hook, I am moving it to be fired once the module rebuild is complete and the info is read by system_get_info or something like that. The whole meta issue is about not firing hooks during module rebuild. One of the hooks is system_theme_info, the other is system_info_alter. We need to make sure neither is fired during module rebuild. This issue is about removing system_theme_info but it can't be removed in favor of something that forces the firing of system_info_alter.
Comment #25
smustgrave CreditAttribution: smustgrave at Mobomo commentedSince it's been 11 years without movement wonder if this is still a valid task for 11.x?