While trying to fix another issue I noticed that on a default install, Garland was adding the following:

<!--[if lt IE 7]>
<link type="text/css" rel="stylesheet" media="all" href="http://127.0.0.1/themepath/modules/system/fix-ie.css" />
<![endif]-->

where this should obviously be

<!--[if lt IE 7]>
<link type="text/css" rel="stylesheet" media="all" href="http://127.0.0.1/themepath/themes/garland/fix-ie.css" />
<![endif]-->

after some pointers by DamZ on IRC I started digging for a good 4 hours and I think I've pinpointed where the issue manifests:

_theme_process_registry sets the theme path right at the top but then doesn't adjust this when a theme's preprocess or process was found (or at least that's what I think went wrong)

attached patch changes the path when a preprocess or process function was found in the theme, but I'm entirely unsure if this is the best way to do this, as I'm horribly unfamiliar with the whole registry shabang
it fixes the problem that originally caught my eye, but I have no clue what other implications it might have

CommentFileSizeAuthor
theme_path.patch556 bytesseutje

Comments

pbz1912’s picture

Works for me.

I'm fairly new, so not sure how to post stuff like this.

pbz1912’s picture

File changed but patch not applied in latest build. And bug still there.

Means IE style sheets still not working.

pbz1912’s picture

Status: Needs review » Needs work

Status: Needs work » Needs review

pbz1912 requested that failed test be re-tested.

ksenzee’s picture

Subscribing. I'll test this out and see if it breaks anything. It's quite a WTF to be debugging and have your path be "modules/system/whatever" instead of "sites/all/themes/mytheme/whatever".

aspilicious’s picture

This need to be committed first, before we can fix #676800: Fieldsets break design badly, cause the ie6.css in the seven theme is useless now...
I put this to RTBC because we tested it with a couple of persons while trying to fix the other issue and it worked!
And its one single line, doesn't need more review.

Or does it?

aspilicious’s picture

Status: Needs review » Reviewed & tested by the community

forgot to change the status

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ok, committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

effulgentsia’s picture

Version: 7.x-dev » 8.x-dev
Priority: Critical » Normal
Status: Closed (fixed) » Active

Can we revert this? I believe it was the wrong solution. The correct solution is in #1125220: Subthemes of core themes trigger an undesired 404 and fail to inherit their parent theme's IE styling. path_to_theme() should either point to the active theme (when called from outside the context of a theme() invocation), or else the module or theme that implements the invoked hook (when called from inside the context of a theme() invocation). In the case of the 'html' theme hook for which this issue originally started, that is the location of html.tpl.php, which was correctly 'modules/system' prior to this issue. Just because a theme implements a preprocess or process function doesn't make it the implementor of the theme hook.

Anyway, #1125220: Subthemes of core themes trigger an undesired 404 and fail to inherit their parent theme's IE styling needs to get in first. But, anyone have objections to reverting this? And if not, should we roll it into the other issue, or keep it a separate task?

effulgentsia’s picture

Issue tags: +Needs backport to D7

I need to get into the habit of setting tags before clicking "save" :)

dvessel’s picture

What effulgentsia said. This patch is not right. 'theme path' should be pointing to where the theme function or template was implemented, not a preprocess function.

Variable processors can be implemented on many levels, in many places but theme functions and templates effectively exists once per hook. Instead of giving themes a special case here, I think it was better to keep the theme paths consistent here.

lauriii’s picture

Version: 8.0.x-dev » 7.x-dev
Issue summary: View changes
Issue tags: -Needs backport to D7

I believe this problem doesn't exist anymore in Drupal 8. Correct me if I'm wrong.

  • webchick committed caacf80 on 8.3.x
    #621008 by seutje: Fixed 'theme path' is wrong for theme process and...

  • webchick committed caacf80 on 8.3.x
    #621008 by seutje: Fixed 'theme path' is wrong for theme process and...

  • webchick committed caacf80 on 8.4.x
    #621008 by seutje: Fixed 'theme path' is wrong for theme process and...

  • webchick committed caacf80 on 8.4.x
    #621008 by seutje: Fixed 'theme path' is wrong for theme process and...
amit0212’s picture

You don't need to implement hook_theme() if you just want to override an existing theme function.

I've just tried this code in my template.php file:

function MYTHEME_item_list(&$variables) {
// my custom stuff done to theme_item_list
return 'test';
}
And all calls to theme('item_list') now return the string 'test', and nothing else.

You'll need to clear Drupal's caches once you've implemented the function, that might also be an issue.

  • webchick committed caacf80 on 9.1.x
    #621008 by seutje: Fixed 'theme path' is wrong for theme process and...

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.