Registry alter does not keep proper order of [pre]process functions

Hello there,

Try something like this

function mytheme_preprocess_region(&$variables, $hook) {
  if ($variables['region'] == 'sidebar_first') {
    if (($key = array_search('well', $variables['classes_array'])) !== FALSE) {
      unset($variables['classes_array'][$key]);
    }
  }
}

Hello,

I'm trying to achieve exactly the same thing. But your solution (and it was my solution too) does not work for me.

Actually, I noticed that preprocess_region is called in my sub theme BEFORE it is called in the base theme. I followed the instructions on how to create a sub theme in the module.

Any thoughts?

Thanks in advance.

preprocess override at subtheme level is no longer working, as observed in #4, base theme is called later in the process.

This has been mitigated by transforming these into settings that can be overridden in a sub-theme's .info file:
http://cgit.drupalcode.org/bootstrap/tree/bootstrap.info#n66

Sorry to reopen this, this is not particularly on the "well".

Things that are tested not working:
- customize $variables['classes_array'], including removing a particular class or removing the entire $variables['classes_array']
e.g. remove "navbar-default" from content region, instead of "un-theme" it as it is required at other places
- cannot remove "question-sign" icon from help since it cannot be overridden in the preprocess_region

Same problem here.

I've this template.php on my subtheme:

/**
 * @file
 * template.php
 */

/**
 * Implements hook_preprocess_region().
 */
function subtheme_preprocess_region(&$variables) {
  $region = $variables['region'];
  if ($region == 'footer') {
    dsm($variables, 'subtheme variables');
  }
}

and i'm aspect that $variables['attributes_array'] is populated, but it isn't...

is absent also $variables['page']

Ok... I figured out how it works

same code of comment #8 wrote on region.vars.php (for my subtheme) instead of template.php... make me "happy"

I think that could be useful reads comments on http://cgit.drupalcode.org/bootstrap/tree/theme/registry.inc

@robertom yes we have to use the same filename in subtheme as in the parent theme to override functions.

If not, the function is called twice (first in subtheme, then in parent theme, if I remember)

Maybe you should close your issue ? EDIT : closed for you :)

Thanks

I sorry for my bad english

@robertom yes we have to use the same filename in subtheme as in the parent theme to override functions.

I don't think so... we could use hook_preprocess_HOOK function in subtheme's template.php as wrote in drupal theme documentation

If bootstrap theme would change "standard" functionality of drupal theme and would "force" us to write preprocess/process functions inside theme/$hook.vars.php ... I think that is needed a comment inside standard template.php for tell us this.

I've deepened a bit this problem and I could say that the "inversed" order of preprocess calling is due to "late" import of bootstrap *.vars.php

when _theme_process_registry() of "includes/theme.inc" is executed it does not know anything of preprocess/process function of *.vars.php and this code (line 611):

          foreach ($prefixes as $prefix) {
            // Only use non-hook-specific variable processors for theming hooks
            // implemented as templates. See theme().
            if (isset($info['template']) && function_exists($prefix . '_' . $phase)) {
              $info[$phase_key][] = $prefix . '_' . $phase;
            }
            if (function_exists($prefix . '_' . $phase . '_' . $hook)) {
              $info[$phase_key][] = $prefix . '_' . $phase . '_' . $hook;
            }
          }

don't works as it should

Was about to say the same thing, we should not supersede how core theming or drupal template/preprocess sequence. Subtheme preprocess should always override base theme's. It should not make a different if we override it inside template.php or other theme inc file.

I think I have a related issue, so adding to this thread.

I cannot override the function bootstrap_preprocess_table(&$variables). I am using7.x-3.0.

I've disabled my sub theme and it looks as if the base Boostrap theme's boostrap_preprocess_table function isn't even used because I don't see Bootstrap's "table" class attached to any of my table elements. Am I missing something? I assumed from table.vars.php that the Bootstrap module would add a "table" class to all my tables.

I can confirm that this is still a problem. I've attempted to override bootstrap_preprocess_page within my subtheme. The hook runs, but it runs before that of the base theme, leading to the code in the subtheme's preprocess being overridden by the base theme.

There's no patch, so there's nothing that 'needs work'.

Has anyone figured this out yet? I'm having a devil of a time trying to override stuff in my subtheme using standard drupal techniques, and nothing seems to be working. I've had to hack 'tabled-bordered' into the parent theme for now.

[EDIT]
Actually it's worse than that-- even hacking it into the parent theme's table.vars.php didn't work (i must have firebugged it in when i saw it working, lol).

I need very clear steps to reproduce this with a clean install of Drupal core, this base-theme and a sub-theme that is attempting to override.

Definitely... I'll verify on a clean install and post back with a copy of the subtheme as soon as I get a chance.

Comment #12 and my comments put it pretty clear I think, sub theme unable to override base theme following the normal Drupal practices. Customize .info does not cater for our need.

I need very clear steps to reproduce this with a clean install of Drupal core, this base-theme and a sub-theme that is attempting to override.

Hi Mark, sorry for my bad english...

this is the steps for reproduce the issue:

drush dl drupal --drupal-project-rename=public_html
cd public_html
drush si --account-name=admin --account-pass=admin --db-url=mysql://[db_user]:[db_pass]@localhost/[db_name]
drush dl jquery_update
drush en jquery_update
drush dl bootstrap-7.x-3.x
drush bss "Test Bootstrap" --set-default
cd sites/all/themes/test_bootstrap/
mkdir templates/system
cp ../bootstrap/templates/system/page.tpl.php ./templates/system/

now I would change the hardcoded size columns for sidebar and content...

with drupal_workflow.patch, the content columns class still remain col-sm-9
with bootstrap_workflow.patch, the content columns class is col-sm-10 as it should

AH! @robertom, thank you!!!

This is exactly what I needed. And please do not worry about your english, this is why I asked for steps to reproduce. Code is better for me to understand when there's a language barrier in an issue :)

So I see what's happening here, core automatically detects the functions in the sub-theme's template.php file and adds them to the registry. Bootstrap's registry alter doesn't take into account for that auto-discovery and just appends it's own functions when no .vars.php files are detected. Yes, this is a very serious bug indeed, my apologies.

So I see what's happening here, core automatically detects the functions in the sub-theme's template.php file and adds them to the registry. Bootstrap's registry alter doesn't take into account for that auto-discovery and just appends it's own functions when no .vars.php files are detected.

Exactly! this is what happens (comment #12), written in a perfect English ;)

Thanks for the awesome work you are doing with this theme.

Thanks for taking the time to document the steps to reproduce robertom --- you rock!

Is there a workaround for this? I'm trying to use a simple node preprocess function:

function tf2_preprocess_node(&$variables) {
   dpm($variables);
}

in template.php in my subtheme. It doesn't seems to fire.

Still no fix for this as far as I can tell. Any progress to report @markcarver?

I've been swamped with client work unfortunately. It would be nice if some other people could provide patches...

I know it won't help everyone, but I was able to provide a workaround for my particular issue reported in #24. I simply made a node.vars.php in my subtheme's 'theme' directory, or 'template' directory and put my SUBTHEME_preprocess_node there.

I think this sidesteps the issue though because there doesn't appear to already be a bootstrap_preprocess_node, so it may not work for other preprocess functions.

I'm happy to try and create patch, but I'm not really sure what I should be trying to do. I get the explanation in https://www.drupal.org/node/2098551#comment-9371921, but I'm not really sure how to translate that into code.

@mark-- if you could give me a quick overview of what the patch needs to do, I can at least take a shot at it.

I'll take a peek at this in the morning -- but for now I believe you can add your preprocess functions to system/page.vars.php (or similar for other hooks) in your subtheme and they'll be properly registered.

I would add a proposed patch

if someone would try this patch with an existent sub-theme, he must implement hook_theme inside template.php of sub-theme... see template.php of starterkits (after patch applied) or this snippet of code:

/**
 * Implements hook_theme().
 */
function yoursubtheme_theme(&$existing, $type, $theme, $path) {
  // Find theme function overrides.
  foreach (drupal_system_listing('/\.(func|vars)\.php$/', $path, 'name', 0) as $name => $file) {
    // Include the file now so functions can be discovered by core.
    // @see https://www.drupal.org/node/2098551
    include_once DRUPAL_ROOT . '/' . $file->uri;
  }

  return array();
}

test fail due to "drush token" {{ THEME }} inside template.php of starterkits...

The patch in #30 is not the right solution for this issue. This issue is not about template/variable files, it's about functions inside template.php.

I think the issue is about late include of *.vars.php and *.func.php

see _theme_build_registry of core https://api.drupal.org/api/drupal/includes!theme.inc/function/_theme_bui...

with patch #30 works both drupal_workflow.patch and bootstrap_workflow.patch

No.

#30 adds hook_theme() implementations to the starterkits to discover include files and is not really a true solution (and also a little bit redundant), it's a hack. Asking people to include something in their sub-theme's template.php file to get around how Bootstrap is altering the registry is not a viable solution.

Bootstrap's registry altering needs to be fixed so it injects it's own preprocess functions by searching for existing functions so it is injected at the right key index. It also needs to take into account the current theme (which may be a sub-theme) and ensure that the base-theme's (bootstrap) functions are injected before any of the discovered sub-theme functions.

This has very little to do with the includes of vars/func files, those work as expected. If I get some time this weekend, I will attempt to step through this (xdebug) to see if I cannot fix this issue, but no guarantees.

edit: @neardark, @WorldFallz, the above is what needs to happen if you happen to get to it before me.

cool thanks mark-- that's exactly the kind of description I was looking for. Now to find some time.... ;-)

Attached is a patch that re-sorts the theme functions in the proper order with sub-theme(s) taking priority over bootstrap base-theme functions. I've tested this with 3 sub-themes plus the bootstrap base theme and it seems to work well. Could use some review and testing for sure.

This is more along the right track. There's a few things I'm a little cautious about, but unable to make a total judgement call given the lack of context in the patch. I'll apply locally and review later tomorrow (possibly Monday).

Alright, I was able to step through this. My original concern towards #37 was that the array_splice wouldn't be sufficient. I've gone ahead and taken a similar approach, however using an associative array to keep track of the functions instead. This way it always ensures that the the sub-themes (and sub-sub-themes) will be added in the correct order. The array_splice had some inconsistent results as I was stepping through (especially when getting into a more complicated parent/child relationship).

Let me know what everyone thinks and if we get a good enough consensus, I'll commit.

This looks good to me, and yes, a better approach. I've done some quick tests, and it's working, though so was my previous approach, so my QA clearly needs some work. Anyone else like to take a peek before this gets sets to RBTC. @WorldFallz perhaps?

Cool, I'll mark it as RTBC and if others chime in that it fixes this issue, I'll commit.

Re-titling once more to actually describe the real issue

Wow... awesome progress!

I just tested with an old issue I have which I think is related to this: #2360851: can't change btn class on search block form button

I was able to verify that the behavior appears incorrect before the patch and correct after the patch (ie, the class is changed appropriately) with this code (CDN subtheme -- unmodified except for adding the following function to the subtheme's template.php):

<?php
function bootstrap_subtheme_preprocess_button(&$variables, $hook) {
  $variables['element']['#attributes']['class'][2] = 'btn-default';
  dpm($variables);  
}
?>

However, the source still shows the search button with a class of 'btn-primary'.

That could be because that's not the proper way to change button classes though. I'll try to test some other scenarios.

Re: #46, I'll comment in that issue.

Sorry for being killjoy but still having problems with node field preprocess (not with other field preprocess, ex bean fields )

How to test it:
- Bootstrap base theme and a subtheme (called mytheme)
- following code inside mytheme/template.php

 function mytheme_preprocess_field(&$variables, $hook){
     dpm($variables['element']['#field_name']);
 }

The node fields does not show up, while the bean fields are shown up. If I introduce a "return;" sentence at the begining of the bootstrap_theme_registry_alter all the fields appear, so the problem is in the registry_alter that bootstrap theme does

@desarrollo2.0 -

I installed a new instance of D7 with Bootstrap latest dev, created a Bootstrap subtheme using drush bss. Added project/bean and created a new bean and placed it on the page. Added preprocess_field to template.php and it reported both the bean (Another field) and regular entity (body) fields:

Devel shows botstrap subtheme as the final preprocess function for field.

Are there any steps I'm missing that may be causing your issue?

@neardark You are not missing nothing. Must be my installation problem. Thanks

[edit] Wrong issue