if you declare a custom message type (ex. drupal_set_message('my message', 'custom_type');), drupal_get_messages will incorrectly return a single element array to it's related theme function (ex. theme('status_messages', 'custom_type');) in the case where no messages of 'custom_type' are set on a page load.

in the above case, the array returned to theme_status_messages from the call to drupal_get_messages is: array('custom_type' => NULL). this erroneously activates the foreach loop in theme_status_messages, which results in a string containing an empty div being returned from the theme call, instead of the correct value, an empty string

this is a real pain if you're trying to use custom messages, b/c if you're adding any message borders to the custom messages, you get these weird empty borders appearing any time a regular message is set!

attached patch fixes by correctly returning an empty array if the custom type doesn't exist in the $messages array.

note: this bug exists in drupal 5 as well.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Priority: Normal » Minor
Status: Needs review » Reviewed & tested by the community

This is indeed a bug which was able to lurk undetected for versions because phptemplate.engine calls theme('status_messages') without a second parameter so unless you call this theme function manually with a parameter, you will never see the bug and this is the case. Because of the obscurity I believe it's committable even to Drupal 5 though it's a very minor API change.

hunmonk’s picture

FileSize
1.31 KB

chx requested doxygen for the return value. included in the attached patch.

Dries’s picture

Status: Reviewed & tested by the community » Needs work

That function does not really support custom message types. You have to use the pre-defined types so they are themed properly.

The lines wrap too late. Try wrapping them at 80 characters instead.

hunmonk’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
1.31 KB

That function does not really support custom message types. You have to use the pre-defined types so they are themed properly.

not true. the theming is done entirely via CSS. a module wanting to use a custom type need only include the CSS for that type, and it's themed just fine. i'm doing it with a module i've written. :)

attached patch wraps the doxygen before 80 characters.

chx’s picture

I am with Chad -- clearly, both the drupal_[sg]et_message functions and then theme_status_messages default implementation is written in a type agnostic manner.

Dries’s picture

Version: 6.x-dev » 5.x-dev

I've committed a modified version of this patch to CVS HEAD. We might want to backport this, although it might be considered a small API change. I leave that up to Neil to decide.

hunmonk’s picture

@neil: just so you're aware, this change only affects the situation where no messages of the requested type exist. the patch fixes it so that an empty string is returned instead of a string containing an empty div.

the empty div is useless, and can cause cause problems w/ theming (specifically in the case where you're putting a border around your custom message type).

hunmonk’s picture

attached is the adjusted version of the patch that dries applied to HEAD -- applies cleanly to Drupal 5 w/ offset.

drumm’s picture

Committed to 5.

drumm’s picture

Status: Reviewed & tested by the community » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)