Jump to:

It's starting to become more widely supported to implement a hook_suppress($set = TRUE) that if triggered will not output anything 'special' that a module adds to a page (for us in modal callbacks, etc). This support is already implemented by admin_menu, admin, toolbar (via admin_select) and other modules. It would be good if we could universally support navbar as well. This hook is also used by the admin_select module to allow users to select the type of administration navigation they want to use if multiple options are available.

+++ b/navbar.moduleundefined@@ -123,3 +126,26 @@ function navbar_view() {+/**+ * Implementation of hook_suppress()+ *+ * Allows other modules to suppress display of Navbar+ *+ * This function should be called from within another module's page callback+ * (preferably using module_invoke()) when the menu should not be displayed.+ * This is useful for modules that implement popup pages or other special+ * pages where the chat would be distracting or break the layout.+ *+ * @param $set+ * Defaults to TRUE. If called before hook_footer(), the navbar will not be+ * displayed. If FALSE is passed, the suppression state is returned.+ **/+function navbar_suppress($set = TRUE) {+ static $suppress = FALSE;+ if (!empty($set) && $suppress === FALSE) {+ $suppress = TRUE;+ drupal_add_js(array('navbar' => array('suppress' => 1)), 'setting');+ }+ return $suppress;

I don't understand. If I pass FALSE, as in I don't want the navbar to be supressed, then $suppress will be set to TRUE and the JS navbar behaviors will be aborted, but the Navbar HTML will still be outputed?

And if I pass TRUE, as in I want to suppress the navbar, then nothing is suppressed and the Navbar behaviors are run?

Also, if we suppress the navbar at during the render stage, let's say in pre_render, we won't need to knock out the JS because it just won't be loaded.

Dave Reid, I don't quite follow. Is the point of hook_shutdown to completely prevent a module from adding to the render pipeline? Should we use hook_shutdown or hook_suppress?

Sun would probably be the better one to explain why hook_suppress() is so odd. I didn't establish that pattern. Basically, calling module_invoke_all('suppress', TRUE) should cause all the modules to not display their output. At the latest possible stage, the individual modules will check if (!mymodule_suppress()) before they add their output.

hook_shutdown() is my mistake in the original report when I meant to type hook_suppress().

I far as I understand, you end up delivering all the JS/CSS assets to the client and none of the HTML. I can't see a use case for this. Why would someone want to suppress output from any modules that happen to have this hook? It seems like you'd end up with a swiss-cheese page.

I fixed the issue summary to say hook_suppress() rather than hook_shutdown(). This hook should not be needed in D8, because there should be better ways of controlling what does/doesn't get rendered in different conditions. This issue is filed for 7.x-1.x though, and for that, it seems reasonable.

The usage is intended to ensure that we get a basic page, similar to overlay does without any kind of 'extra' stuff. This is also useful for modules like admin_select to allow specific users to pick which toolbar they have.

I don't see how the CSS and JS assets would be delivered if the suppression was enabled. The CSS/JS is added in the #attached library of the 'navbar' element type. That element is added in navbar_page_build(), which is where we're checking suppression. Am I missing elsewhere where any assets are added? Off hand this would like it prevents all JS from being added in the first place.