i created a view to hide or unhide a couple of nodes at the same time (with Views Bulk Operations).
But it's not working. When I hide some nodes with VBO the View says that the nodes are hidden afterwards, but they are not.
Even so i noticed that the CSS-Class "node-is-hidden", which is added to the menu link after saving a node in hidden mode, is not removed after unhiding nodes with VBO.
The other way round i got the same problem. After hiding nodes with VBO the CSS-Class is not added to the menu-links.

Someone got an idea?

Thanks n0103



mallin’s picture

Category: support » bug

I think that might be a bug, I encountered the same problem but with Outline Designer. I hid all my book, then made it public again. Book is public, but every link (menus, breadcrumbs) has "node_is_hidden" class despite the fact that it's not hidden. I had to disable css class to make it normally visible. But now i don't know which nodes are hidden and which are public until i open the node.

Is there any way to delete the class from nodes that are not hidden?

komlenic’s picture

Title: Hidden Nodes CSS and VBO » CSS class "node-is-hidden" is not always updated on menu links

I can confirm that hiding and unhiding nodes does not reliably update the css class on menu links. Under what circumstances this occurs I have not yet identified, but I do have a site where one role can hide/unhide nodes and have the menu link css update properly, and another role cannot. (This is therefore likely dependent on some permission.)

All versions (6 and 7).

btopro’s picture

what type of caching projects do you have enabled? Possibly the menu cache needs to be flushed, targeting the book outline in use (per #1) or by looking at any menu that the current node is associated to (per #1 / #3)?

komlenic’s picture

In my testing, clearing the menu cache has no effect.

It appears that when Hidden Nodes is used in conjunction with the core Book module, one of two Book permissions must be granted in order for the link css class to be updated correctly: either 'add content to books' or 'administer book outlines'.

If either of these permissions is granted to a user, the css class on the link updates correctly. If neither of them is granted, it does not update the css class correctly.

I don't full understand why this is so, yet.

mallin’s picture

Clearing cache was one of the first things i tried, cleared all cache and it didn't help. I don't have any additional caching modules, just the core functionalities.

Users with roles allowing them to hide/unhide nodes have also "add content to books" permission. So i don't know if that's the problem.

However i noticed something else weird as i was looking at the page source and i think i may have found a solution to this bug. CSS class added to hidden node looks like this: class=" node_is_hidden". Notice the blank character in front of the name of class.

I took a peek at the hidden_nodes.module and found this starting at line 223:

          // If class is found, apply styling.
          if (strpos($row['#item']['options']['attributes']['class'], 'node_is_hidden') !== FALSE) {
            $form['table'][$key]['#attributes']['class'][] = 'node_is_hidden';
            // List this as a hidden parent if node_is_hidden is found.
            $hidden_parents[$key] = $row['mlid']['#default_value'];

And this starting at line 304:

  // Only process this if we actually found a node to act on.
  if ($nid) {
    // Need to directly access database as static cache of object is invalid.
    // This happens because page save would change the value of hidden.
    if (_hidden_nodes_get_status($nid)) {
      if (!isset($item['options']['attributes'])) {
        $item['options']['attributes'] = array('class' => ' node_is_hidden');
      else {
        $item['options']['attributes']['class'] = ' node_is_hidden';
    else {
      // Avoid potential conflicts with menu attributes modules.
      if (isset($item['options']['attributes']['class'])) {
        $item['options']['attributes']['class'] = str_replace(' node_is_hidden', '', $item['options']['attributes']['class']);

That second fragment of code has class name with space in front of it. I deleted that space, cleared cache and guess what? It works now. I made node hidden and then unhid it and class disappeared.

Can anyone confirm that this was the issue? My PHP knowledge is pretty basic and i don't know if i did the right thing.

komlenic’s picture

Thanks mallin for your observation and comment. I've tested the change proposed in #5, and it did not have the desired effect. (Tested only in D6.) It is my understanding that the space preceding the classname is valid, or at the very least, tolerated by browsers. You can see an example of this here: http://codepen.io/anon/pen/BhJcC

I suspect the space was included in the original module code, so that in the event of multiple classes being applied to the menu links the syntax would be correct, ex:

  <li class="foo bar baz">Some link</li>

Note the spaces between classnames.

mallin’s picture

Yeah, i'm aware of the fact, that classes need to have spaces between them. My CSS skills are way better than PHP :-) But i guess drupal core handles separing classes. In nodes that are not hidden i have something like this:

class=" active-trail active"

Hidden nodes module has nothing to do with this line and there's a blank space.

Anyway, maybe btopro can tell why removing this blank space worked for me.

btopro’s picture

Version: 7.x-1.1 » 7.x-1.x-dev
Component: Miscellaneous » Code

well, if removing the space works then I'm willing to give that a try. I'm not experiencing this issue personally and we use it quite a bit (though not with VBO). You reported this in version 1.1, can you try 1.x-dev since it's ahead of 1.1 or confirm that you were experiencing this problem and your remediation fixed it in the dev version? I'd like to know if it helps in the latest code in the repo, if yes, then I'll give it a shot.

It could be that other classes aren't being applied based on the menu / theme projects you are using where as in our builds we have them applying which could lead to the variance in result.

mallin’s picture

I did some further testing regarding css class (still using 7.x-1.1 version of hidden nodes). In my installation i use Menu attributes module. I turned it off and when that module isn't active, "node_is_hidden" class is applied and removed correctly. But i'm not able to say if it's a bug in this module or in Menu attributes module. Maybe you guys could it investigate it a little further.

btopro’s picture

Title: CSS class "node-is-hidden" is not always updated on menu links » conflict with menu qttributes module

Well that might explain things a bit more since menu attributes messes with class names as well.

mallin’s picture

Title: conflict with menu qttributes module » conflict with menu attributes module
komlenic’s picture

Title: conflict with menu attributes module » CSS class "node-is-hidden" is not always updated on menu links

As we have multiple reports of the class not being updated in multiple versions under differing circumstances, I'd suggest leaving the more generic title that describes the problem. (I have been experiencing this issue without Menu Attributes installed.)

komlenic’s picture

Issue summary: View changes

After some more testing I notices that the VBO is not working at all.

theMusician’s picture

Issue summary: View changes

I just had this error occur as well on a 7.27 site with hidden nodes.

Using a view I created I am able to hide and unhide content but the menu style stays stuck. If the node was not hidden prior to the VBO it stays without being crossed out but the node is hidden. If it was hidden prior to un-hiding the node it becomes non-hidden but the menu item is still crossed out.

Manually hiding/unhiding the nodes makes the menu item appear properly. The idea in #5 had no effect for me.

UnsettlingTrend’s picture

This seems to conflict with the menuux module as well.

btopro’s picture

Assigned: Unassigned » mmilutinovic1313

There appears to be a conflict between the way hidden nodes applies classes and when other menu modules are modifying the class / options blob of the menu item.


There is a faulty assumption in hidden_nodes_form_alter and hidden_nodes_menu_link_alter about the way menu item classes are stored in that it is assuming that hidden nodes is the ONLY project that will jump in and modify this object in the alter. This assumption needs corrected in both functions, especially in the menu_link_alter as this is where part of the confusion is coming into play.

Mark, putting you on the case.

mmilutinovic1313’s picture

Currently working on solving this issue. If anyone has screenshots of this issue that they could share, that would be great!



mmilutinovic1313’s picture

Fixed the menu display not updating issue. Added a check for if not done through the UI (for example other modules are interacting with node visibility changes such as vbo). If you have any questions, please message me and I will be happy to clarify!


btopro’s picture

Status: Active » Fixed

commit added w/ minor clean up to the structure of the comment itself and credited. great work tracking down! http://cgit.drupalcode.org/hidden_nodes/commit/?id=73bdff9

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.