This is the respective issue for https://www.drupal.org/project/drupal/issues/474684 (change record), and part of the #5317 meta-issue.
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the
admin/appearancepage, would allow designers building heavily customized themes to make safer assumptions about their target sites.A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.
Proposed solution
- Allow themes to add the dependencies to .info files
- Show these dependencies on
admin/appearance, and make it impossible to install without the requirements via UI or command line- Make it possible to install dependent modules and layout templates when installing a theme (either manually, or via the Project Browser/Installer)
- Validation is added to prevent installing themes that depend on uninstalled modules, and prevent uninstalling modules that are depended upon by installed themes. This is implemented at a level that prevents these installs/uninstalls from occurring programatically or via cli (Drush/Drupal Console).
User interface changes
- Themes listed in
admin/appearancewill list the modules/layouts they depend on and the ability to install/enable that theme will not be available unless those module/layout dependencies are met.- The module descriptions found at
admin/modulesandadmin/module/uninstallwill include themes in their "Required by" description.API changes
Themes will be able to define modules dependencies in their info.yml via the dependencies key.
Recent comments
Trying to push it to upstream 🤞 https://github.com/drush-ops/drush/pull/6621
Using Drush 8 with php 8
Wow, thank you!
Using Drush 8 with php 8
Hi folks, I went ahead and ported all drush 8.x stuff to PHP 8.3 and completely ripped out the legacy Symfony 2 internals. You can check out the exact details of what was done in the PR...
Using Drush 8 with php 8