CSM defines a function, csm_messages_alter(), which is an instance of the hook hook_message_alter defined by messages_alter.module.

When the Omega theme is set as default, hook_message_alter.module doesn't always fire.

Can be recreated by installing CSM and Omega on a clean D7 install, and setting Omega as the default theme. To get a more precise idea of how this bug occurs, install the attached test_sma module (make sure messages_alter.module is installed and enabled too). test_sma.module should put a message saying "The hook fired!" at the top of every page on your site; those pages where the message doesn't appear are the ones where hook_message_alter hasn't fired. Unfortunately it seems that it's precisely the times that we want hook_message_alter to fire that it ends up not firing!

I initially thought this might be something to do with overlay.module, but that appears not to be the case.

CommentFileSizeAuthor
#2 test_sma.tar_.gz345 bytesjim0203
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jim0203 created an issue. See original summary.

jim0203’s picture

Title: Messages don't change when the Omega theme is used » hook_message_alter() doesn't always fire when the Omega theme is used
Priority: Major » Critical
Issue summary: View changes
FileSize
345 bytes
jim0203’s picture

Ok, I've done some initial work on this. Here are some notes that might help someone fix this (my knowledge of the D7 hook and theme systems is not great):

test_sma_message_alter() is called by
drupal_alter (module.inc line 1140) is called by
messages_alter_invoke_message alter (messages_alter.module line 99) is called by
theme_messages_alter_alter (messages_alter.module line 68) is called by
theme (theme.inc 1161)

And theme() is called by a series of core functions that trace all the way back to index.php.

So, the point of contact between Drupal core and the module is when theme() calls theme_messages_alter_alter(array($display => null, $theme_hook_original => 'status_messages'). Once that happens, everything else should just work, so I suspect that theme() isn't being called as we'd expect.

jim0203’s picture

I've done some more work on this, and have tried to get my head round the theme system and the way that hooks are defined in D7. It seems that messages_alter.module works in a similar way to how csm used to work before I started using messages_alter.module to do the heavy lifting: messages_alter_theme_registry_alter() adds a new function (theme_messages_alter_alter()) to the theme registry, which then fires all the hook_message_alter hooks.

I suspect that if we look at the theme registry (via dpm(theme_get_registry) on those pages where CSM isn't working with Omega, we'll see that theme_messages_alter_alter() isn't present in the theme registry for those pages. I'll check this later, I have to go catch a train now.

jim0203’s picture

Status: Active » Needs review

According to #2197945: Status Message Contrib Modules Don't Work, this is a problem that many message-changing modules have when they are used with Omega. Basically, Omega defines its own theme function to change status messages, and Omega's theme function overrides any theme functions that are provided by modules.

I can't find a way to fix this from within CSM's code, but #2197945-7: Status Message Contrib Modules Don't Work and #2197945-8: Status Message Contrib Modules Don't Work propose solutions that involve adding a theme function to whatever Omega sub-theme you are using. #7 seems to be the best way forward, and would involve adding the following function to the sub-theme (I assume to template.php -- I'm not a themer, and talk of using a separate status-messages.theme.inc file in the subtheme folder doesn't seem to allow for the fact that that file would then need to be included via template.php):

function SUBTHEME_NAME_status_messages($variables) {
  if (module_exists('messages_alter')) {
    return theme_messages_alter_alter($variables);
  }

  return omega_status_messages($variables);
}

Can someone with more theming experience test this for me please, and make sure it works consistently across Omega subthemes? If not, can you propose a different solution?

jenlampton’s picture

Why is the altering happening in the theme layer? The theme layer is meant to take the data, and return it wrapped in markup. All altering should - in theory - be done long before the theme layer gets it's hands on the data. Messages are particularly tricky, since they need to be rendered very late in the page rendering cycle, but isn't that what the process layer is for?

template_process_page() calls theme_status_messages() which calls drupal_get_messages(). By that point all the messages should already be altered.

What's the point of the new theme function theme_messages_alter_alter(), and why can't that be done sooner? Conflicting theme functions is likely to always cause problems, that's why modules should be doing their altering before themes.

jim0203’s picture

I genuinely can't remember why we're doing things this way, Jen! I put this module together quite a while ago, and the code you're referring to was taken from a different module that we took over when its maintainer stopped working on it.

I do have a distant memory that I've had this conversation before, and there was some reason for things being done this way, however weird it might seem at first look. Maybe some limitation with how D7 was doing things?

If we can achieve what we're setting out to do a different way then I'd be more than happy to switch to a different approach, especially if it fixes this bug.