6.x version

Very nice library!!
I'm looking forward to using the plugin, thanks

subscribing

What else is left to do on the 5.x version to get it out of beta?

subscribing

That is interesting. Given the window of opportunity created by the spaces between posts above (ahem) :) I had already ported the b4 version of the module to 6.x the other night, but could not for the life of me figure out why the js was not appearing in the header...

Can you post the non-functional port you've created so that we can work with the same code, since you've now released a final 5.x version and I don't want to have to re-port that? I'd be happy to try and help with this issue...

Ok, I've got a working jGrowl on Drupal 6.x by changing hook_footer to hook_init—but presumably it suffers from the early loading issue that you're worried about. Can you give an example of a reproducible late error that this wouldn't catch, so that we can test any potential later-loading solutions against them?

And given this already catches many of the messages I get from Drupal each day, even this initial port with hook_init will be going into my site I'm working on... since presumably any late messages will just be displayed in the normal fashion since jGrowl fails to hide them from their standard display as well as failing to display them in the more pretty format. :)

Edit: Interesting. If jgrowl_system_messages() is loaded too late (e.g. via hook_exit) it does not load the necessary .js, but it does hide the system message(s) that would normally be displayed, resulting in the user not getting the message at all. Presumably though, an early load via hoot_init would not do this with subsequent messages?

While I have a working 6.x version, I still would be interested to work with your port if you can upload a copy somewhere... even if you just send me a link via my contact form. Just to ensure we don't have apparently "inconsequential" differences complicating things.

OK, I may have a lead on something but I need to go and prepare some dinner for the whanau—it is heading towards that time down here in New Zealand.

In the meantime, the attached patch brings the current HEAD up to passing all code recommendations from the Coder module, even for the most minor issues such as trailing spaces on lines... I find this to be useful to then be able to catch more major departures when making changes, and it's good practice to follow these standards anyway I guess.

I am stuck. I cannot seem to get this to work. I have been working on various iterations of things inspired by this thread but without any success. I cannot achieve anything more (in terms of the functional outcome) than what is achieved by simply changing jgrowl_footer to jgrowl_init, and that clearly isn't satisfactory.

The desired visible outcome could obviously be achieved by re-implementing all of the functional behaviour of the module in javascript rather than in the module itself, which could run using document.onload—in fact, I found two other modules yesterday that are doing things similar to jGrowl, one of which appears to do exactly that and is even using the jGrowl library under the hood! The other module that styles the system messages is Message Effects but I now find I can't locate the one that is using the jGrowl library unfortunately. That would of course remove the really nice functionality of the module currently, where the javascript is only loaded at all on pages where a system message is currently being displayed, so the vast majority of the time the user's browser does not have to load that content.

At present, jGrowl rolls its own code related to the messages in the session variables rather than using drupal_get_messages. I have wondered whether using drupal_get_messages might in any context lead to a different result, but have not been able to test this idea yet... Does it sound even plausible?

(The attached tiny patch corrects a single capitalisation error that is required for the correct path to the module to be found, and thus to see even the partial functioning jGrowl behaviour.)

Ah yes, editing a comment removes a patch. Here is it again.
(Is that the intended behaviour?)

OK, so the attached (extremely simple) patch moves the jgrowl_system_messages() call from hook_footer to hook_init. The net result of this is a partly-working Drupal 6.x version, which catches system messages that are early enough in the process, but not ones that are created late. This patch is being uploaded to accompany my plea for assistance, so anyone who wants to help can see exactly where things are at.

An easy example of the issue is to navigate to your /admin/settings/file-system page. If you delete your file system path and click "Save Configuration" you'll get a standard system message that is too late in the process to be caught by jGrowl when being initiated in hook_init. However, if you then re-insert a file system path and again click "Save Configuration" this time jGrowl will catch the system message and display it using your jGrowl preferences. Under Drupal 5.x, jgrowl_system_messages() was called from hook_footer and worked fine, but this appears no longer possible under Drupal 6.x.

At one point I thought perhaps mfer's code example with hook_preprocess_page was the answer and that this would enable jGrowl to again work correctly. If it is the answer, I obviously don't understand it properly (quite possible!) because I can't get it to work. Would love any suggestions or assistance...

(Note the above patch is against jGrowl HEAD; not sure if that is the same as the current dev version or not.)

subscribe

How is it going?

Hi,

Have you tried to override phptemplate_status_messages? It is the theme function that render the messages. Works well for me.

I've been working on the version of Message Effects referred to in #17, available here. I'm running into exactly the same problem. Contrary to the impression given above, Message Effects does check for the presence of messages before loading javascript.

In addition to the issues with validation above when your core version is old and the update module is enabled it will present a warning message on admin pages which does not have an effect applied. This applies to 5.x as well as 6.x.

I've found that a solution to both the validation and update problems is to use hook_help instead of hook_init (or hook_footer in 5.x). It has the unfortunate side effect in the Message Effects module of appearing to be called twice and doubling the messages with jgrowl effects (merely doubling the inline js with other effects), so that will take a little more effort to resolve. But for this module, due to the way it unsets the message session variable after its added them to jgrowl, that does not appear to be a problem.

subscribing

Will it be ever updated or all have just forgot about it?
Somehow i don't like Message Effects, keep it Simple, please =))

subscribing.

Check out http://drupal.org/project/purr_messages as an alternative. We've been using it for a good while now.

Not for you, not for me, not hook_init, neither hook_footer. Lets go into theme system and take control over message notifications, and jgrowl will be responsible of themeing these messages if there are any:

/**
 * Implementation of hook_theme_registry_alter().
 *
 * Allows the module to override the core status_messages function with growl
 * own message handler.
 */
function jgrowl_theme_registry_alter(&$theme_registry) {
  if ((user_access('access jgrowl'))) {
    if (!empty($theme_registry['status_messages'])) {
      $theme_registry['status_messages']['function'] = 'jgrowl_system_messages';
    }
  }
}

• Applied patches at #15 and #18
• Removed hook_footer in favour of hook_theme_registry_alter
• Committed to HEAD.
• Created branch DRUPAL-6--1 and new jgrowl-6.x-1.x-dev release

Thank you all for the good work.

I'd tag as 1.0, but prior testing is always welcome, so..

Oh.. A validation is missing, and although jgrowl notification of system messages can be disabled, they will not be shown with current implementation.

PD: rolled for current DRUPAL-6--1

No mind, just committed to finish the port.