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

chx’s picture

chx CreditAttribution: chx commented
Title: Move the module provided theme to something not-hook and fast » Move the module provided theme to something not-hook and fast to detect
chx’s picture

chx CreditAttribution: chx commented

One wonders whether the bundle services could provide this...

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

This 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.

chx’s picture

chx CreditAttribution: chx commented

OK, special .yml it is.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

Hm. Actually, the originally envisioned path forward for this has always been:
#1292284: Require 'type' key in .info.yml files

chx’s picture

chx CreditAttribution: chx commented

Putting it into .info even if it becomes yaml is not fast either.

because that would require parsing every .info on rebuild which is something I want to move from.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

In 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...

chx’s picture

chx CreditAttribution: chx commented

It's not the cheapness, it's the hook_system_info_alter.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

I 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:

  // Allow modules to add further themes.
  if ($module_themes = module_invoke_all('system_theme_info')) {
    foreach ($module_themes as $name => $uri) {
      // @see file_scan_directory()
      $themes[$name] = (object) array(
        'uri' => $uri,
        'filename' => pathinfo($uri, PATHINFO_FILENAME),
        'name' => $name,
      );
    }
  }
chx’s picture

chx CreditAttribution: chx commented

To 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.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

That'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.

chx’s picture

chx CreditAttribution: chx commented

No, 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.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

Since it's been 11 years without movement wonder if this is still a valid task for 11.x?

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.