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.
Comment | File | Size | Author |
---|---|---|---|
#8 | drupal_get_messages_2.patch | 1.1 KB | hunmonk |
#4 | drupal_get_messages_1.patch | 1.31 KB | hunmonk |
#2 | drupal_get_messages_0.patch | 1.31 KB | hunmonk |
drupal_get_messages.patch | 472 bytes | hunmonk | |
Comments
Comment #1
chx CreditAttribution: chx commentedThis 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.
Comment #2
hunmonk CreditAttribution: hunmonk commentedchx requested doxygen for the return value. included in the attached patch.
Comment #3
Dries CreditAttribution: Dries commentedThat 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.
Comment #4
hunmonk CreditAttribution: hunmonk commentednot 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.
Comment #5
chx CreditAttribution: chx commentedI 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.
Comment #6
Dries CreditAttribution: Dries commentedI'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.
Comment #7
hunmonk CreditAttribution: hunmonk commented@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).
Comment #8
hunmonk CreditAttribution: hunmonk commentedattached is the adjusted version of the patch that dries applied to HEAD -- applies cleanly to Drupal 5 w/ offset.
Comment #9
drummCommitted to 5.
Comment #10
drummComment #11
(not verified) CreditAttribution: commented