In this test case, the active admin theme is Blossom, a sub-theme of Seven.
The attached image shows that in seven_preprocess_html, the path_to_theme() function returns the path to Blossom's directory. This results in the two IE stylesheet files added through drupal_add_css() referring to non-existant files.
| Comment | File | Size | Author |
|---|---|---|---|
| #35 | 1125220-36-D7.patch | 3.1 KB | roderik |
| path_to_theme.jpg | 102.03 KB | jessebeach |
Comments
Comment #1
jessebeach commentedThis patch changes path_to_theme to drupal_get_path('theme', 'seven'), which always returns the correct path to the Seven theme's directory, regardless of sub-theming.
Comment #2
David_Rothstein commentedHm, this looks like a bigger issue (affects Bartik too, at a minimum)?
Comment #3
effulgentsia commentedThis looks good to me. Let's get bartik and garland into this patch as well. Note that for D8, this patch will be made obsolete by #522006: Conditional Styles in .info files, since drupal_add_css has it, but regardless of when that patch makes it into D8, we need this one in D7.
Comment #4
effulgentsia commentedComment #5
jessebeach commentedBackported to a 7.x-dev issue as well.
http://drupal.org/node/1125624
Comment #6
jessebeach commentedUpdated to include Seven, Bartik and Garland.
Comment #7
jessebeach commentedRemoved issue tag that a backport to 7 is need. Here's the backport issue: http://drupal.org/node/1125624
Comment #8
jessebeach commentedchanged status to needs review.
Comment #9
seutje commentedhmz, might this be related to #621008: "theme path" is wrong for theme process and preprocess overrides ?
Comment #10
David_Rothstein commentedPatch looks good to me. We should keep this all in one place, though, so I'm going to close the other issue.
Comment #11
effulgentsia commentedLooks good to me as well, but I'd like to see a review from a markup, bartik, garland, or seven maintainer before calling it RTBC.
Also, I asked for feedback on #621008: "theme path" is wrong for theme process and preprocess overrides for whether we can revert that issue, and if so, whether to add that reversion to this one.
Comment #12
effulgentsia commentedReroll for HEAD.
Comment #13
xjmTagging as novice for the task of rerolling the Drupal 8.x patch on account of #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.
If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.
Comment #14
jessebeach commentedRerolled against 8.x and 7.x HEAD.
Comment #15
jessebeach commentedSetting to need review.
Comment #16
xjmThanks for the reroll.
Is there any way to add an automated test for this bug?
Comment #17
jessebeach commentedI can't come up with a good test case for this issue. It seems to me that the
path_to_theme()anddrupal_get_path()functions both work correctly.For this issue, we simply have a case where
drupal_get_path()should have been used in the first place, although it wasn't apparent until a sub-theme was introduced into the mix. I can't think of how to write a test case for using the wrong function.Comment #18
xjmWell, the idea would be to create a test theme/subtheme that exposes the bug, and an automated test using that theme that fails without the patch and passes with it.
Comment #19
jessebeach commentedDo you mean just to illustrate the bug?
If the patch is applied to the existing core themes, then the fail state of such a test will never obtain unless someone changes the drupal_get_path function back to path_to_theme. This would be akin to changing any function in core to the wrong function.
Can you write this test that you have in mind? I really don't understand how one could write an automated test for using the wrong function. Sorry for being dense.
Comment #20
effulgentsia commentedI think what xjm is suggesting is to create 2 themes in core/modules/simpletest/tests/themes, one that's a subtheme of Seven, and one that's a subtheme of Bartik. Do not add an ie.css file to them. Then write a test that requests a page using each of these themes, and assert that the HTML contains a reference to the base theme's ie.css file, and not to a non-existent ie.css file within the subtheme folder.
Comment #21
jessebeach commentedThis doesn't need a test.
This is simply a matter of the wrong function being used. Requiring a test for this, which will not indicate anything more than drupal_get_path or path_to_theme, the functions, are broken (and I'm hoping these have their owns tests) is simply holding up a simple fix.
I'm not going to write a test because I don't think it adds any value. If I'm not understanding this and a test does add value, please someone who believes this to be the case write the test.
Until then, a bug lives in the base themes that will continue to vex anyone who creates a sub-theme of them.
Comment #22
effulgentsia commentedThe reason a test is needed is there is a functional bug, and if a test isn't added, it might regress in the future. For example, some future contributor might look at these functions and think, "drupal_get_path() is so ugly, we should use path_to_theme() instead", and if that person submits a patch to do what they think is a minor code cleanup, we want the automated tests to spot the regression. Retitling the issue to reflect the functional bug being fixed.
But it's certainly not the obligation of the person who submitted a fix to also write the test. Thank you very much for the fix. Hopefully, someone will come along to write the test. I may do so if no one else does, and I can find a spare chunk of time. In the meantime, unassigning, so someone else who's inspired can claim it.
Comment #23
jessebeach commentedOk, I wasn't understanding that the test is present to prevent changes by humans in the future, not to indicate that the drupal_get_path or path_to_theme functions have malfunctioned. That makes sense.
I want to see this patch get in. I'll try to write this test on Sunday at the Drupalcamp NJ sprint.
Thank you for explaining.
Comment #24
jessebeach commentedOk, I can reproduce the bug outside the tests, but when I run the test, the path to the the ie.css file is correctly printed as the path in the parent theme, not incorrectly printed as a path in the child theme.
The patch adds the test. I also attached two sub themes - one of Seven and one of Bartik.
STR
Now run the Sub theme resource inclusion test. These 404'd files will be correctly referenced as located in the sub-theme's parent theme.
I'm looking in to why the test gives different results for the same code. Please feel free to bang your head on this as well.
Comment #25
jessebeach commentedSorry, the patch in #24 is meaningless and I need to run for the moment. I'll post something meaningful shortly.
Comment #26
pwolanin commented14: drupal_get_path-1125220-14.patch queued for re-testing.
Comment #27
pwolanin commentedI think this should go in without the need for a convoluted test. If we are worried about future reversion, we should add some code comments in the patch and also to path_to_theme().
Comment #29
star-szrIs it just me or is this bugfix not relevant to 8.x any longer? There are only two calls to path_to_theme() in core. It's very possible I'm completely misunderstanding the bug at hand, but maybe this is 7.x territory now?
Comment #30
hussainwebI don't think this is relevant to Drupal 8 anymore. There are no occurrences of path_to_theme at all (not even the function definition. See https://www.drupal.org/node/2324935. This could be about D7 only now, and if not even that, then it could be closed.
Comment #31
lauriiiThis is irrelevant for Drupal 8 now since we have now
getActiveTheme()which works a little bit more the way its expected to.Comment #32
stefan.r commentedTagging this as novice for the tasks of manual testing and creating a reroll of the patch in #14
Comment #33
roderikPatch 14 is exactly the same as 12 except for some git-format-patch noise. So 12 should still apply; Trying to re-queue it.
Comment #35
roderikTrying de-fuzzed one. (Minimal changes in context lines only.)