Problem/Motivation
In #2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList, the responsibility of managing the list of themes and theme data is moved to \Drupal::service('extension.list.theme'). This issue is a follow up to deprecate ThemeHandlerInterface::rebuildThemeData() and replace it with calls to \Drupal::service('extension.list.theme')->reset() and \Drupal::service('extension.list.theme')->getList()
Proposed resolution
Replace all usages and deprecate ThemeHandlerInterface::rebuildThemeData() and trigger a silenced error. Also, when replacing the usages we should ensure that we don't unnecessarily rebuild the module list.
Remaining tasks
Review MR
From "Proposed resolution"
Also, when replacing the usages we should ensure that we don't unnecessarily rebuild the module list.
Review CR
User interface changes
None
API changes
None
Data model changes
None
| Comment | File | Size | Author |
|---|
Issue fork drupal-2942001
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
gaurav.kapoor commentedComment #3
gaurav.kapoor commentedI have worked a little bit on this much. Did changes at some places and also added @deprecated notice wherever. This patch is only useful once parent issue is fixed. Looking for a good review on this one.
Thanks in advance.
Comment #5
alexpottComment #6
alexpottHere's a start. Still need to sort out the ThemeInstaller. Ideally we wouldn't need the ThemeHandler there. But then we'd need to sort out issues with reseting the list in ThemeHandler.
Comment #7
andypostMaybe better to create common ThemeHandlerLegacyTest - it will be easy to remove it in 9.0
I'm Adding it in #3017231-4: Properly deprecate ThemeHandlerInterface install() and uninstall() also replace usage
Comment #8
andypostMoved install/uninstall patch to found #2776031-21: Properly deprecate ThemeHandlerInterface install() and uninstall() also replace usage
PS: issues related because also manages how extensions lists are rebuilded/populated
Comment #17
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #21
dimitriskr commentedComment #22
dimitriskr commentedComment #23
quietone commentedTo answer a question posted in Slack, this needs a separate change record. A change record is for documenting the first version and branch where the change was introduced. When you want to add related issues that can be done in the issue links fields or even in the description body.
For this issue, the changes to the existing change record should move to a new change record. And the new change record can refer to the older one.
I do know the existing change record does not follow what I describe above and it is on my list to update that.
Comment #24
prashant.cComment #25
dimitriskr commentedUpdated tasks in IS
Comment #26
dimitriskr commentedComment #27
smustgrave commentedLeft some small comments.
Comment #28
dimitriskr commentedComment #29
smustgrave commentedFeedback appears to be addressed.
Comment #32
catchIncludes constructor deprecations for things that need them and doesn't bother for things that don't. Had to read through a couple of times to check, but I think it's a good balance.
Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!
Comment #33
wim leersPublished CRs:
Comment #35
andypostThank you! the last bit is #2972153: Deprecate ThemeHandlerInterface::getBaseThemes and remove usages from core