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.

See related issues:
#675300: Provide a method to disable the output of the toolbar programmatically
#1125658: Add hook_suppress().
#1304540: Implement hook_suppress()
#1418930: Implement hook_suppress so olark isn't displayed in a modalframe.

Comments

Status:Active» Needs review
StatusFileSize
new2.03 KB

This patch adds support for hook_suppress().

StatusFileSize
new2.03 KB

Here is revised patch against the current dev branch.

I'm curious why the JS part is needed? Most implementation of hook_suppress don't actually use any JS.

I think that if someone calls the hook_suppress they don't want to display the unneeded JS either. This is the same way that hook_suppress is implemented in admin_menu.

Assigned:Unassigned» jessebeach

I'll get this in. Thanks for the patch!

Status:Needs review» Needs work

+++ 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.

Status:Needs work» Needs review

Issue summary:View changes

Fixed typo.

Issue summary:View changes
StatusFileSize
new1.98 KB

Rerolled patch against current dev

Status:Needs review» Needs work

+++ b/navbar.module
@@ -961,3 +964,26 @@ function navbar_convert_libraries_to_library($library, $options) {
+ drupal_add_js(array('navbar' => array('suppress' => 1)), 'setting');

Indentation is all wrong.

StatusFileSize
new1.98 KB
new445 bytes

Updated patch attached (though have found that Navbar broken in other ways atm)

Status:Needs work» Needs review

StatusFileSize
new1.82 KB

I took out the JavaScript code because these assets are not loaded if the Navbar element isn't placed in the render tree. So there's no need to alter the JS behavior.

Is that sufficient for what you need?

Status:Needs review» Closed (fixed)

Added in e3389576b2539d79d9546b6fbd9b35ddd37c98fd