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.
Problem/Motivation
Because of the configuration system, there is no reason for ThemeHandler::setDefault() to exist.
Proposed resolution
Mark ::setDefault as deprecated before Drupal 9 and replace usages with a configuration change, like this example from a test:
$this->config('system.theme')->set('default', 'bartik')->save();
Remaining tasks
User interface changes
None
API changes
ThemeHandler::setDefault() will be deprecated.
Comment | File | Size | Author |
---|---|---|---|
#57 | interdiff.txt | 2.47 KB | Manuel Garcia |
#57 | deprecate-2635784-57.patch | 17.94 KB | Manuel Garcia |
#55 | interdiff.txt | 4.96 KB | Manuel Garcia |
#55 | deprecate-2635784-55.patch | 15.46 KB | Manuel Garcia |
#51 | deprecate-2635784-51.patch | 10.5 KB | Manuel Garcia |
Comments
Comment #2
cilefen CreditAttribution: cilefen commentedComment #4
cilefen CreditAttribution: cilefen commentedComment #5
jordanpagewhite CreditAttribution: jordanpagewhite as a volunteer commented@cilefen Is there a reason that you're using $this->themeHandler in some methods and \Drupal::service('theme_handler') in others?
Comment #6
cilefen CreditAttribution: cilefen commented@jordanpagewhite Yes.
Some of those test classes don't have the themeHandler as a member. If any do, and I used \Drupal, those should be changed.
Edited: I meant "classes".
Comment #7
joelpittetGot them all:) thanks @cilefen
Comment #8
catchCommitted/pushed to 8.1.x, thanks!
Given this is a test-only change, I don't see why it couldn't go into 8.0.x too, but assuming this was put at 8.1.x for a reason. Moving branch and tagging for now.
Comment #10
cilefen CreditAttribution: cilefen commentedI did not realize it was test-only when I opened it. It is good to go if green.
Comment #11
gambryBackport to 8.0.x.
Comment #12
gambryThe patch is just a re-roll of original #2 version, just a small change on core/modules/ckeditor/src/Tests/CKEditorTest.php bit.
Setting the issue RTBC as I haven't really changed that match from the original patch (which has been already reviewed and tested).
Comment #13
ChandeepKhosa CreditAttribution: ChandeepKhosa at 2Toucans commentedComment #14
star-szrThanks but this does still need peer review :)
Comment #15
star-szrReviewed the patch, the only change is in the context, not the actual lines of the patch. I also re-grepped and didn't find any remaining occurrences after applying the patch. Thanks @gambry :)
Comment #16
alexpottI'm not entirely sure what is the point of this change. Given that the default theme is a configuration setting it should be okay to just change that. If something needs to happen because the theme default theme has changed then it should be done in a config listener so if anything outside of the Drupal site changes it then it is respected. In fact once we have config validation I think we should consider removing ThemeHandler::setDefault() as being unnecessary and potentially dangerous as it encourages doing things in a way that could break config synchronisation. Basically I think this patch should be reverted from 8.1.x.
Setting to "needs review" so people can respond to my comment.
Comment #17
star-szrThat's worth discussing then, thanks @alexpott. What I'm not clear on from #16 is how wrapping the config write in setDefault() would be different/more problematic than calling it directly.
I just interpreted this change as using our APIs consistently but if our APIs are or may be problematic then we probably shouldn't add more of such uses, even if it's only in tests.
Comment #18
alexpottWhilst setDefault only wraps config is it fine - but it encourages anything that overrides the theme handler to put additional logic there. Which would be wrong.
Comment #19
cilefen CreditAttribution: cilefen commentedCould we make the method final?
(edited for typo)
Comment #20
alexpott@cilefen but why? - my point is that
drush config-set system.theme default
needs to work because this is exactly the way that config synchronisation happens.Comment #21
star-szr@alexpott excellent point, I didn't quite get there. Then I agree with you, at least in tests it seems to make more sense to work with the config directly. I think discussing whether we want to deprecate setDefault() can be a separate issue.
Comment #22
catch#16 is a good point, deprecating the method makes sense.
I went to revert in 8.1.x, but it didn't revert cleanly, so here's a patch.
Comment #24
veerasekar89 CreditAttribution: veerasekar89 at UniMity Solutions Pvt Limited commentedComment #25
veerasekar89 CreditAttribution: veerasekar89 at UniMity Solutions Pvt Limited commentedI created a patch to fix
\Drupal::service('theme_handler')->setDefault()
Comment #26
veerasekar89 CreditAttribution: veerasekar89 at UniMity Solutions Pvt Limited commentedComment #27
arunkumarkHi,
The patch seems good and working fine for all themes, thanks.
Comment #28
alexpottWe should deprecate
ThemeHandler::setDefault()
for Drupal 9.Comment #29
alexpottThis issue is not needed in 8.1.x there is no bug here. Also the issue summary needs to the updated to explain the new approach.
Comment #30
cilefen CreditAttribution: cilefen commentedComment #31
cilefen CreditAttribution: cilefen commentedComment #32
cilefen CreditAttribution: cilefen commentedas much noise as possible...
Comment #34
sidharthapIs a new patch required against 8.2.x-dev here deprecating ThemeHandler::setDefault() ?
Comment #35
cilefen CreditAttribution: cilefen commentedYes, and replacing usages of it.
Comment #36
sidharthapHere is the initial patch against 8.2.x as per comment #35
Comment #38
cilefen CreditAttribution: cilefen commentedDeprecating is not the same as removing. It is a comment. And in this case, the interface must receive the comment.
Comment #39
sidharthapUpdated patch.
Comment #40
cilefen CreditAttribution: cilefen commentedThis is better. But we cannot advise people to use an object method they may not have. It should be \Drupal::config().
Comment #41
sidharthapThank You @cilefen
Updated patch as per #40
Comment #45
dawehnerI agree, this is a bit of an abstraction for the sake of it.
Comment #47
dawehnerComment #48
dawehnerComment #49
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer commentedRerolling...
Comment #50
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer commentedThe only conflict the rebase didn't handle was in core/modules/field/tests/src/Kernel/EntityReference/EntityReferenceFormatterTest.php
Simple one to fix though so here it is =)
Comment #51
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer commentedErm.. removing extra line I added. Let's keep it clean =)
Comment #52
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer commentedComment #53
joelpittetNice cleanup. There are a few others that are with
These are in tests mostly. Should we change these too? Otherwise good to commit.
Comment #54
alexpottYep we shouldn't have any usages for the deprecation to be correct.
Comment #55
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer commentedI think these were all that were left, please have a look.
Comment #56
joelpittetThanks @Manuel Garcia. There are a few more.
I just searched for
->setDefault(
in the code base and excluded the route ones to find them all.Comment #57
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer commentedAh good catch @joelpittet thanks!
Ran the same search I think these should be all now.
Comment #58
dawehnerGood catches!
The only remaining setDefault calls are on routes.
Comment #59
catchCommitted/pushed to 8.3.x, thanks!