| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | theme system |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | Increases learning curve, Issue summary initiative, needs backport to D7, needs profiling, Needs tests |
Issue Summary
I am having an issue where my specific preprocess functions are not getting picked up. In this case i have the tpl file views-view--test-preprocess.tpl.php. In the file I have a dpm("The tpl file is working"); to make sure that the tpl is getting used properly, which it is. I have then created a sitetheme_preprocess_views_view__test_preprocess function in my template.php which also has a dpm to see if that function is working properly. I cannot get this preprocess function to get picked up. My initial thought is this is probably due to all the theme changes that have occurred, which I have admittedly not been able to fully wrap my head around all that has changed, but maybe I am just missing something obvious. Does this relate to http://drupal.org/update/modules/6/7#theme_hook_suggestions_2?
I am running 7 beta as well as the Oct 8th views 7.x-3.x-dev.
I should also note that using the general preprocess function and tpl file, ie views-view.tpl.php works just fine.
Test view:
$view = new view;
$view->name = 'test_preprocess';
$view->description = 'Test';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = '3.0-alpha1';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
/* Display: Defaults */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';
/* Field: Node: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Field: Node: Link */
$handler->display->display_options['fields']['view_node']['id'] = 'view_node';
$handler->display->display_options['fields']['view_node']['table'] = 'node';
$handler->display->display_options['fields']['view_node']['field'] = 'view_node';
$handler->display->display_options['fields']['view_node']['label'] = '';
$handler->display->display_options['fields']['view_node']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['view_node']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['view_node']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['view_node']['alter']['trim'] = 0;
$handler->display->display_options['fields']['view_node']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['view_node']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['view_node']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['view_node']['alter']['html'] = 0;
$handler->display->display_options['fields']['view_node']['hide_empty'] = 0;
$handler->display->display_options['fields']['view_node']['empty_zero'] = 0;
$handler->display->display_options['fields']['view_node']['text'] = 'More';
/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page_1');
$handler->display->display_options['path'] = 'preprocess-test';
Comments
#1
Try this:
<?php
/**
* Implementation of hook_theme().
*/
function mytheme_theme() {
return array(
'views_view__page_1' => array (
'arguments' => array(),
),
);
}
/**
*
*/
function mytheme_preprocess_views_view__page_1(&$variables) {
dpm('This should be working');
}
?>
#2
You are right that the code that you provided will allow the specific views preprocess function to get picked up, but I should not have to declare each preprocess function in my theme by adding it to a hook_theme function. It should just get picked up if that tpl is in the theme.
#3
This seems to be a core
theme()behavior: if the 'base hook' property is set for a theme registry item,theme()will use the 'preprocess functions' and 'process functions' from the 'base hook' theme registry item. This means that currently, preprocess functions for the'views_view__test_preprocess'theme registry item will always get ignored in favor of the preprocess functions on the'views_view'theme registry item, since$theme_registry['views_view__test_preprocess']['base hook']is set to 'views_view'.gleroux02, I believe this is a change in behavior from using Views on Drupal 6? The 'base hook' theme registry property seems to be new in Drupal 7, and its presence is not documented in the hook_theme() docs (http://api.drupal.org/api/function/hook_theme/7). Inline documentation in
theme()indicates that the original theme registry item name is retained in$variables['theme_hook_suggestion'], so if the core behavior is correct, then maybetemplate_preprocess_views_view()could check there and execute any additional preprocess functions itself...#4
This issue is related to commit 344200 and #241570: Theme preprocess functions do not get retained when using patterns.
#5
Tracking. See my comment here: http://drupal.org/node/241570#comment-3679436
#6
I'm moving this issue to the core queue, in order to close out #241570: Theme preprocess functions do not get retained when using patterns. That other issue initially dealt with a related, but different problem, which was that hook_preprocess_views_view() wasn't called when views-view--page-1.tpl.php was being used. That issue was fixed for D6 in #241570-6: Theme preprocess functions do not get retained when using patterns and for D7 in #241570-50: Theme preprocess functions do not get retained when using patterns. The D6 solution made it so that both hook_preprocess_views_view() and hook_preprocess_views_view__page_1() would be called. The D7 solution intentionally made it so that only hook_preprocess_views_view() would be called. There has been further discussion in that issue requesting that hook_preprocess_views_view__page_1() be added to the D7 theme system, so that D7 doesn't represent a regression to D6 in this regard. I'd like that discussion to continue in this issue, so that new people joining the discussion don't need to read that issue's history, and can just focus on this particular question.
Here are some things I don't like about the way in which D6 implements suggestion-specific preprocess functions:
function mymodule_theme() {return array(
'views_view__page_1' => array(
'template' => 'views-view--page-1',
'original hook' => 'views_view',
),
);
}
And, you need mymodule_theme() to run AFTER views_theme(), which probably means you need to set the system weight of mymodule to 1 or higher.
'views-view--taxonomy-term-leaf.tpl.php' and 'views-view--taxonomy-term-leaf--page.tpl.php' files. When the 'views-view--taxonomy-term-leaf--page.tpl.php' file is used, I would expect mytheme_preprocess_views_view__taxonomy_term_leaf() and mytheme_preprocess_views_view__taxonomy_term_leaf__page() to both be called, but they're not. Only mytheme_preprocess_views_view__taxonomy_term_leaf__page() is.
IMO, the above WTFs make suggestion-specific preprocess functions more trouble than they're worth. To me, the following construct is preferable:
function mytheme_preprocess_views_view(&$variables) {if (in_array('views_view__page_1', $variables['theme_hook_suggestions'])) {
...
}
}
Although I realize that the above isn't as syntactically attractive as a targeted function name, in D7, this construct works without the prior WTFs:
Note, what I say above is not fully true yet, but requires #956520-16: Theme hook suggestions are only available when defined in preprocess functions to be made true. But that's a totally straightforward patch that needs to be committed to core anyway, and I'm confident will be pretty soon (maybe not before RC, but soon).
So, my recommendation is to mark this issue "won't fix" or kick it to D8, and to require the less attractive, but more robust, pattern to be used for suggestion-specific preprocessing in D7. Alternatively, a contrib module like ctools can implement hook_theme_registry_alter() to make suggestion-specific preprocess functions work in D7 (with all the limitations they have in D6, or maybe even fixing some of them).
But, that's my recommendation only. Please share your thoughts. If my arguments for why suggestion-specific preprocess functions are undesirable in D7 core aren't persuasive, and if the community really wants this D6->D7 regression fixed, I'll support a D7 core patch to fix it.
I'm marking this issue major, rather than critical, because this is something that can be done after RC, and even in a 7.1 release.
#7
Quite a summary :-D
My issue (elsewhere) actually was that this doesn't work:
$output = theme('links__node__comment', $links);
function exampleMODULE_preprocess_links__node__comment(&$variables) {
$variables['what-you-d-expect'] = 'yeah';
}
function exampleMODULE_preprocess_links__node(&$variables) {
$variables['what-you-d-perhaps-also-mayhaps-expect'] = 'um, yeah';
}
According to Jacine, this seems to work for themes, and possibly also for templates, but not for preprocess theme functions of modules.
#8
Yep, as per #6 (limitations 1-5), the equivalent of #7 doesn't work in D6 either. I'd love to see it fixed properly in D8. Now that we have a module_implements() cache, I think in D8 we can merge the way we do drupal_alter() with the way we do preprocess functions, simplifying the API and the theme registry building process, and reducing the size of the theme registry, shaving a few ms from each page request. But I'm not sure it makes sense as D7 material.
#9
+1
#10
Subscribing, asking if this can be fixed in Drupal 7 (because it would be lovely), but looking to do it right in D8 in any case. Frankly i think the examplemodule_preprocess_links__node() function should not only be called but override the template_preprocess_links() function, as you could easily call the general function from within your specific preprocess function if you want it.
#11
Subscribing
#12
Until this is "fixed" just do the following:
function mytheme_preprocess_views_view_list(&$variables) {
$view = $variables['view'];
$function = implode('__', array(__FUNCTION__, $view->name, $view->current_display));
if (function_exists($function)) {
$function(&$variables);
}
}
function mytheme_preprocess_views_view_list__VIEWNAME__DISPLAY(&$variables) {
print_r($variables);
}
#13
Subscribing and hoping someone can get to benchmarks on #956520: Theme hook suggestions are only available when defined in preprocess functions soon and then we can revisit this issue.
#14
Subscribing
#15
subscribing also
#16
Before in D6 when you had the tpl file like
views-view-fields--VIEWNAME--block-1.tpl.php
<?phpfunction MYTHEME_preprocess_views_view_fields__VIEWNAME__block_1(&$vars)
?>
the preprocess function was properly called.
the same thing for D7 is NOT working anymore...
if you do something like:
<?phpfunction MYTHEME_preprocess_views_view_fields (&$vars)
?>
it works fine like the above example,
but it DOES NOT work for specific view + display, like the example bellow:
<?phpfunction MYTHEME_preprocess_views_view_fields__VIEWNAME__block_1 (&$vars)
?>
any thoughts out there?
My temporary solution for D7 at this point:
<?php
/**
* Generic preprocess that is still working on D7
*/
function MYTHEME_preprocess_views_view_fields(&$vars) {
if (isset($vars['view']->name)) {
$function = 'MYTHEME_preprocess_views_view_fields__' . $vars['view']->name . '__' . $vars['view']->current_display;
if (function_exists($function)) {
$function($vars);
}
}
}
/**
* Then the specific preprocess that worked without the above code for D6
*/
function MYTHEME_preprocess_views_view_fields__VIEWNAME__block_1 (&$vars) {
// my specific preprocess code
}
?>
#17
subscribing
EDIT: I followed the instructions in comments #12 and #16 however it seems that I'm not able to get them to fire either from my base theme or my sub theme? Did you guys have to do anything special in the first place to get theme hooks to be called?
I've opened a separate issue for this problem as I realise it's probably off topic, but I was hoping you might have already trodden this path: #1160268: subtheme_preprocess_page not getting called
EDIT 2: Ok seems I've gotten around this problem without knowing how, thanks to #12 / #16 your advice is now working :)
#18
To carn1x...
This was my temporary solution I still don't know why on D6 the preprocess functions worked without the above code... and that's why I posted it here... I still want a proper explanation for that?
Thanks...
#19
Ah! I was looking for this issue. I posted in the wrong place but this patch will fix it.
http://drupal.org/node/956520#comment-4478448
There's a bit more info starting from that comment.
#20
The last submitted patch, specific_preprocess_hook_suggestions_ 939462_19.patch, failed testing.
#21
from effulgentsia overview #6:
The patch fixes this.
Also fixed. You don't even need the 'views-view--page-1.tpl.php file to exist at all. If the variable process function implements it, it will auto register the hook and inherit all the base elements.
This should also be fixed but I haven't tested this.
We have to draw the line somewhere and as I was writing the patch, there was an note in drupal_find_theme_functions() to "keep things simple". I could have written the patch to do what your expecting and I was considering it but it is most likely overkill.
You meanmytheme_preprocess_node__story? That would depend on howtheme()called and it's outside the scope of the theme function.EDIT: Actually, the same problems exists even with the change from 'template_file_suggestions' to 'theme_hook_suggestions'. Although the patch doesn't address this, I did find a workaround in a patch to a theme I've been working on: #1179656: Consistent availability of variable processor, file includes and auto registration for hook__suggestions. see point #3. I can update the patch to fix it in core but I think an entirely different approach in core should be made for 8. 'theme_hook_suggestions' being set from preprocess works against it.
#22
Lets try that again. That was an old patch.
#23
The last submitted patch, specific_preprocess_hook_suggestions_ 939462_21.patch, failed testing.
#24
Why is the test server getting a 404 on the patch?
#25
Eh, hidden space in the file name.
#26
#27
The last submitted patch, specific_preprocess_hook_suggestions_939462_25.patch, failed testing.
#28
Not sure what the deal is. It was tested two days ago and it passed. Passes locally also.
Fails on comment block but theme_comment_block isn't all that special.
#29
#25: specific_preprocess_hook_suggestions_939462_25.patch queued for re-testing.
#30
Anyone other than dvessel get a chance to test out the latest D7 patch yet?
#31
I'll try again by creating a patch for 8 then back port it to 7. Might get more attention.
#32
I've just applied the patch in #25 on my D7.2 installation and I can confirm that now my
function mytheme_preprocess_views_view__taxonomy_term__page(&$vars) {....
}
is now correctly picked up: YEAHHHH!!!
I was waiting for that for a long time:
Thank you very much!
#33
Same here, fixed the prob. Hope it gets into the code soon :)
#34
applied in D7.4 installation; confirmed that its working.
Here's are some numbers:
// first.module
/**
* Implements hook_block_view().
*/
function first_block_view($block_name = '') {
if ($block_name == 'list_modules') {
$list = module_list();
$theme_args = array('items' => $list, 'type' => 'ol');
$content = theme('item_list__first', $theme_args);
$block = array(
'subject' => t('Enabled Modules'),
'content' => $content,
);
return $block;
}
}
// example_chris.module
function example_chris_preprocess_item_list__first (&$variables, $hook) {
dpm(__FUNCTION__);
dpm(microtime());
dpm($hook);
}
function example_chris_preprocess_item_list (&$variables, $hook) {
dpm(__FUNCTION__);
dpm(microtime());
dpm($hook);
}
Here are the results:
example_chris_preprocess_item_list
0.31776300 1309472124
item_list__first
example_chris_preprocess_item_list__first
0.31799800 1309472124
item_list__first
#35
I think 3 people is enough for RTBC; I realize that this is theme.inc we are talking about, let me know if brief glances by 3 people is not enough for an RTBC, and what could we do to make this an RTBC. xhprof profiler benchmarking needed? I'll provide if asked.
#36
Yeah this one really needs so profiling, leaving at CNR rather than CNW since it may still apply to D8.
The main change here is theme rebuilds, so you would need to profile a page that is building the theme registry cache. xhprof should show the difference both in CPU and memory for that if it's done before/after. Main thing to watch out for the APC or other opcode cache if you're running that - should either be consistently warm or consistently cold (or just disabled).
As well as this, I can see a call to get_defined_functions() then array operations on that, can't see that doing anything other than increasing the memory requirements here but will need testing. I've been thinking about trying to move away from including files altogether and instead scan them with regexp at #1188084: Try to avoid loading every specified include file during theme registry rebuilds. although this has no code yet so shouldn't hold the patch up in itself.
Apart from that there's also an issue at #519940: Performance: optimize building theme registry by using get_defined_functions() instead of function_exists() using get_defined_functions() elsewhere in the theme registry rebuild process, not sure if that is applicable at all here (maybe the function_exists() calls that aren't removed?).
And there are no tests added in this patch but this ought to be testable I think.
#37
Subscribing.
#38
Subscribing
#39
#25 breaks drupal for me...
It seems that doing a git apply -v specific_preprocess_hook_suggestions_939462_25.patch on the root of drupal doesn't patch correctly the theme.inc file... (Using Git 1.7.6-preview20110708)
The warning I got after reverting to the original, seems to indicate an include path problem...
Warning: include(C:\www\apache\htdocs\mysite.com/page.tpl.php) [function.include]: failed to open stream: No such file or directory in theme_render_template() (line 1276 of C:\www\apache\htdocs\mysite.com\includes\theme.inc).
Warning: include() [function.include]: Failed opening 'C:\www\apache\htdocs\mysite.com/page.tpl.php' for inclusion (include_path='.;C:\php5\pear') in theme_render_template() (line 1276 of C:\www\apache\htdocs\mysite.com\includes\theme.inc).
I got lots of the same kind of warning for the block.tpl.php, toolbar.tpl.php, html.tpl.php file (same invalid file structure).
I presume the patch has a problem ?
#40
Tagging issues not yet using summary template.
#41
Sub
#42
#43
Tagging for backport.
#44
Subscribing.
#45
With the new Drupal version update (7.9), is needed a new patch to correct this problem.
#46
This will need to be rerolled now.
#47
tagging for learnability.
#48
(rerolled #25 for D7)
Assumption n°3 of comment 21 confirmed is also confirmed:
SUBtheme_preprocess_views_view__VIEWNAME_DISPLAYID(&$vars)is fired(without the template file)
This patch (almost) made my day, but ... I'm getting a bunch of notices:
Notice : Indirect modification of overloaded element of ThemeRegistry has no effect dans theme() (line 1008 in /var/www/drupal/includes/theme.inc).(the line is
unset($hooks[$hook]['includes']))#49
#25: specific_preprocess_hook_suggestions_939462_25.patch queued for re-testing.
#50
The last submitted patch, 939462-48.patch, failed testing.
#51
The patch does not apply. It needs to be created with git. :)
#52
Git version of the patch at #25
#53
We need to create a patch for D8 first, and then profile it as catch says above. (When an issue is fixed, the fix is usually backported to D7 around the same time.)
The patch above might apply to D8 from within the
core/directory so I'd suggest trying that in order to create a D8 patch.#54
I don't have a D8 to port this patch to,
but can someone elaborate on these ThemeRegistry warnings ?
#55
You can get D8 from git using these instructions:
http://drupal.org/project/drupal/git-instructions
#56
It looks like _theme_post_process_registry() is acting directly on the cached ThemeRegistry object, whereas it should be acting on the raw theme registry array which is created during the rebuild. I didn't look beyond this but hopefully that'll help you track it down.
#57
Here's a D8 Git version of the patch. I've commented out the line
unset($hooks[$hook]['includes']);as it did nothing except cause errors. The functionality it represents may still be required though. I'm simply creating the patch for D8 to help the effort along. Sadly I believe it will fail testing.
#58
Changing status for testbot.
#59
The last submitted patch, specific_preprocess_hook_suggestions_939462_57.patch, failed testing.
#60
The patch in #57 appears to be either old or against 7.x; it is missing the
core/directory.#61
I've been using this technique with great success. However, I would like to point out that the pass-by-reference forcing in...
if (function_exists($function)) {$function(&$variables);
}
...can cause "Call-time pass-by-reference has been deprecated..." errors in newer versions of PHP. Since your "mytheme_preprocess_views_view_list__VIEWNAME__DISPLAY" function makes a pass-by-reference declaration in the function parameter definition, you're still fine and get the behavior you want with out the PHP warning.
So it should be...
if (function_exists($function)) {$function($variables);
}
#62
Reroll.
This fixes my problem for D7, didn't try it on D8.
#63
To clarify, my problem was what sun described in #7.
#64
Thanks for the reroll.
Code style review:
+++ b/core/includes/theme.incundefined@@ -499,29 +499,47 @@ class ThemeRegistry Extends DrupalCacheArray {
+ // Add all modules so they can intervene with their own variable
+ // processors. This allows them to provide variable processors even
+ // if they are not the owner of the current hook.
...
+ // Theme engines get an extra set that come before the normally
+ // named variable processors.
...
+ // The theme engine registers on behalf of the theme using the
+ // theme's name.
Looks like these comments are wrapping a bit early.
+++ b/core/includes/theme.incundefined@@ -499,29 +499,47 @@ class ThemeRegistry Extends DrupalCacheArray {
- // overridden. Pull the rest of the information from what was defined by
+ // overridden. Pull the rest of the information from what was defined by
This change is superfluous to the patch.
+++ b/core/includes/theme.incundefined@@ -620,31 +631,90 @@ function _theme_process_registry(&$cache, $name, $type, $theme, $path) {
+ * This completes the theme registry adding missing functions and hooks.
The word "This" is not needed here; it should just begin "Completes..." Reference: http://drupal.org/node/1354#functions
Also, it would be better to have a comma after "registry."
+++ b/core/includes/theme.incundefined@@ -620,31 +631,90 @@ function _theme_process_registry(&$cache, $name, $type, $theme, $path) {
+ // Collect all known hooks. Discovered functions must be based on a known hook.
This line is one character too long; we need to wrap it a word earlier.
+++ b/core/includes/theme.incundefined@@ -945,14 +1010,13 @@ function drupal_find_base_themes($themes, $key, $used_keys = array()) {
+ // If called before all modules are loaded, we do not necessarily have a full
Also one character too long.
+++ b/core/includes/theme.incundefined@@ -1000,6 +1064,7 @@ function theme($hook, $variables = array()) {
+ //unset($hooks[$hook]['includes']);
We shouldn't have commented-out code.
Also, we still need a test here as well, and that profiling. Thanks!
#65
Oh, tagging novice for the task of cleaning up the code style issues in #64.
#66
working on in the Long Beach Contribute meetup tonight: http://groups.drupal.org/node/211453
(we're in IRC in #drupal-la and #drupal)
#67
Just encountered this issue. Seems to take too long to get this fixed imho. Subscribing.
#68
@bvanmeurs, you can help speed along the process by any of the following:
Thanks!
Edit @mike stewart -- I saw the complaint but not your comment. That's awesome; thank you so much!
#69
arg! new laptop ... spent too much of the meeting last night just getting setup. finally a working environment (late) to discover that the patch would no longer cleanly apply.
error: patch failed: core/includes/theme.inc:1008need to do a diff in D8 commits on that file to see whats new.
Also #62 @tim.plunkett's comment wasn't clear to me. He said this fixes his problem in D7 but not D8 -- but the patch is clearly a D8 patch, so I wanted to be sure thats where the re-roll belongs? (I assume yes -- but clarification would be nice).
I am busy for the next few hours, but hope to get back to this later today... but didn't want to prevent anyone else from working on, so I've unassigned. If no one else picks up ... I'll be back :-]
#70
@mike stewart, I was saying I'd only tested it on D7, not that it didn't work on D8.
#71
Is this related to http://drupal.org/node/1430300? Can anyone see if this is still required? I have attached the patch from #62 with comments from xjm in #64.
Additionally I can try to make a test for it if someone can provide basic instructions on what is required. If not I'll hand this back over to mike for the testing.
#72
The last submitted patch, drupal-939462-70.patch, failed testing.
#73
This isn't related to #1430300: Preprocess functions in an include file fail to get called when the theme implements a suggestion override, but you can extend the test from that issue which is now in both 8 and 7.
If in test_theme/template.php, you add a
test_theme_preprocess_theme_test__suggestion()function that adds a variable, and changetest_theme_theme_test__suggestion()to include that variable in its output, and include that in the assetion inThemeUnitTest::testPreprocessForSuggestions(), that would test what's being fixed in this issue.#74
Here is the patch for the test. It fails locally with or without the patch. Let me know if I made it wrong though. I've still new to testing.
The testbot probably kept failing because of the line unset($hooks[$hook]['includes']); which causes
Notice: Indirect modification of overloaded element of ThemeRegistry has no effect in theme() (line 1068 of /d8/core/includes/theme.inc).
#75
The last submitted patch, drupal-939462-74.patch, failed testing.
#76
Lets try again.
#77
#78
I'm not sure what happened with the last one but hopefully this one will finally apply but fail with the test. @effulgentsia Please let me know if I misunderstood what you were looking for in the test.
#79
The testbot queue is quite backed up ATM:
http://qa.drupal.org/pifr/queued
So TBH I'd give it at least a day.
#80
The last submitted patch, drupal-939462-78.patch, failed testing.
#81
+++ b/core/includes/theme.incundefined@@ -1008,46 +1073,25 @@ function theme($hook, $variables = array()) {
- // Include files required by the base hook, since its variable processors
- // might reside there.
- if (!empty($base_hook_info['includes'])) {
- foreach ($base_hook_info['includes'] as $include_file) {
- include_once DRUPAL_ROOT . '/' . $include_file;
These were the lines added in #1430300: Preprocess functions in an include file fail to get called when the theme implements a suggestion override, are you sure they should be removed?
#82
I'm not sure what the right answer is here. It probably shouldn't be taken out but since it is a nested if statement I don't know of a good way to leave it in while maintaining what the original patch in #62 did. If you let me know the proper way to handle this I can make a new patch that will apply and accomplish the goal.
#83
#25: specific_preprocess_hook_suggestions_939462_25.patch queued for re-testing.
#84
tim.plunkett,
This one still fails, but I added the code back in which fixed one of the errors.
#85
The last submitted patch, drupal-939462-84.patch, failed testing.
#86
issues:
#87
The last submitted patch, drupal-939462-86.patch, failed testing.
#88
Yeah, it actually broke installation. I've patched the patch to revert some changes.
#89
The last submitted patch, drupal-939462-88.patch, failed testing.
#90
I'm going to try to revisit this soon.
#91
Oh yeah I tried and failed hard. No idea.