Theme preprocess functions do not get retained when using patterns
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | theme system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs work |
When using a pattern for a theme function (i.e, theme(array('foo__bar', 'foo'), ...);) the preprocess functions aren't being retained of the pattern has been declared.
The easiest way to replicate this is to install Views 2 alpha4. Make sure the frontpage view is enabled. Visit 'frontpage'.
Now, copy views-view-unformatted.tpl.php to your theme directory, and add a piece of text to it to identify our theming function. Clear your cache and reload. This works fine.
Rename this to views-view-unformatted--frontpage.tpl.php and clear cache. Now you'll see that the variables have disappeared.
This patch will ensure that previously discovered preprocess functions will get carried forward; and that new preprocess functions will still be discovered by keeping the 'original hook' name around and checking it during preprocess discovery.
(this is critical since it totally breaks the named-overrides that this feature was designed for).
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| fix-preprocess-patterns.patch | 1.68 KB | Idle | Failed: Failed to apply patch. | View details | Re-test |
#1
I couldn't replicate this bug on a clean install of 6.x-dev. I tried garland and a contrib theme (sky) and I was able to get my custom views-view-unformatted--frontpage.tpl.php to show up fine in both themes. I visited /frontpage, added views-view-unformatted.tpl.php and stuck some text in there, and went back to /frontpage. My text showed up fine. I then renamed it to views-view-unformatted--frontpage.tpl.php, changed my custom text, cleared cache, and went back to /frontpage... and my new text was there. Let me know if I misunderstood the process or if you need any more info.
#2
It isn't your text that won't appear, it's items that appeared in template_preprocess_views_view_unformatted. Which, actually, frontpage may be a bad choice because it doesn't do anything in the preprocess function. Change the view to a table, though. I picked frontpage because it comes with Views and should've actually tried that one myself.
#3
For more detail, see http://drupal.org/node/241405 -- which is the issue that made me realize this was happening.
#4
Thanks for the link -- I get it now. Yes, creating a table view does replicate the problem. It is a bit disconcerting to have all your content disappear. So bug replicated, patch tested, problem apparently solved. I even ran it through coder, just to be impudent. :)
#5
As long as I'm being impudent, I'll mark it RTBC.
#6
Reread, reviewed again and committed to 6.x. Still to be committed to 7.x
#7
Ok, it turns out (to my chagrin) that there was a problem with my previous patch. It turned out that adding the preprocess functions into the new hook now prevents preprocess functions from the theme from taking hold (so I ended up inverting the problem).
The reason for this is that if a theme sets preprocess functions specifically, it assumes that the theme did not want auto-discovery of the preprocess functions; so by copying them too early, we lose the discovery process.
The fix is to check to see if the original hook has preprocess functions and transfer them during the merge that happens after this check.
Sorry about this. I'll see if I can roll a merged patch for 7.x as well.
#8
Testing Drupal 6.2 with both patches from this issue applied, and Views beta2. I am able to create both a template file and a preprocess function for a specific field in a view, by name. (That is, both of the issues here are addressed.)
#9
Looking for another test before committing (to me, the patch looks just as good as the previous one looked :)
#10
these patches work for me using 6.2 and views beta2. Thanks everyone - especially Merlinofchaos, views is a wonderful addition to drupal. I can successfully create preprocess functions and views-view-fields--MYVIEW.tpl.php files to override theme settings.
#11
That's 2 confirmations.
#12
OK, committed the updated patch. Needs a reroll for Drupal 7 with both patches.
#13
I just realized that I don't have a PHP 5.2 installation to roll a patch for HEAD on, so I am unable to do this. Or at least I cannot test a HEAD patch.
#14
Attached patch combines both of the above, rolled against today's HEAD.
#15
I still don't understand how to "install" this patch... Are those directions above? They don't say where to place this code....
#16
see http://drupal.org/patch
#17
I applied the patch but it said 2 hunks failed and one succeeded. Any ideas?
#18
Are you applying this against HEAD?
#19
As of today, the patch in #14 applies perfectly to HEAD, so the author of #17 must have been applying the patch to something else.
#20
aclight: If it applies perfectly and works, please set RTBC so we can get this issue closed out. :-)
#21
@Crell: I didn't say I had tested it :) I didn't have time for that, just to see that it applied properly.
#22
#277626: Checking CCK nodes with drop down lists lead to SAX 0x0 parsing error might be suffering from this bug as well. For certain CCK types, Mollom receives a 0x0 ASCII/Unicode character which causes the server-side XML parser to barf with a error like
An invalid XML character (Unicode: 0x0) was found. Where that 0x0 would slip into the output string isn't clear yet but KarenS thinks there could be relation with his bug. We can only reproduce it with CCK node types.#23
Dries: I am confused how the two could be related. This thread is just about finding .tpl files. Have you done any sort of before/after checks with this patch to see if it affects the other? If not, then I don't see how they'd be related.
#24
Excuse my general ignorance, but I came to this thread from the Views support page because I'm having a problem with my Views page (called testimonials) not using the node-view-testimonials.tpl.php file it should be. It sometimes works, but when I change a configuration in Drupal, it breaks.
Using the Theme Developer (devel module) I can see that it's no longer even looking for my tpl.php file and has reverted to trying to find views-view-unformatted.tpl.php which isn't right.
I've tried applying the d7 patch from post #14 above, but that didn't work. The first two hunks succeeded and the second two failed. It looks to me like that code already exists (for the failed hunks) in the Drupal 6.3 theme.inc file but I'm not entirely sure what I'm supposed to be looking for.
What's the status of this problem? Or is the problem I'm experiencing nothing to do with this? Looking at the link merlinofchaos posted in #3 above, I think I'm on the right track...
Cheers,
Al
#25
Al: I think that the problem is that the preprocess_node that views is using in node.views.inc is not always loaded when the theme registry is rebuilt, which is why you run into that. AS a workaround, move that function from node.views.inc into views.module (which I think is going to be my eventual solution, but I haven't fully committed to that yet).
#26
Thanks merlinofchaos - I'll try that if/when I experience the issue again, but what I've done at the moment is the following:
- Taken your patch and applied it to my Drupal 6.3 (the first two hunks succeeded, the second two failed)
- Visited the modules page which should rebuilt the theme registry cache
This has fixed the problem this time around. I'm sure next time I make a config change to the server it'll lose it again, at which point I'll test your suggestion.
Much appreciated! I'll keep you posted.
Al,
#27
This is still not in 7. Will test.
#28
The last submitted patch failed testing.