Changes to visibility aren't being saved

You may want to try with a newer version of Menu per Role?

Also... What version of Drupal do you have? If you have a version before 6.10 then you need to install the patch provided in the tarball.

Thank you.
Alexis

Okay... did you just upgrade to 6.20? I still just have 6.19 and it works just fine for me... Or did you upgrade from 1.7 to 1.8 of Menu per Role recently?

Thank you.
Alexis

Some people say they have problems with 1.8 display, but not the saving of flags...

But I did not yet try with Drupal 6.20... I don't see why 6.20 would be a problem, but you never know. After all, before 6.10, the Core had a problem with this module! I should upgrade soon anyway so I'll have to remember to check this then.

Thank you for the feedback.
Alexis

Okay, you were right, saving of a new node would ignore the flags you'd set for menu per roles.

I applied a patch, and this is the same problem as in #948158: Use of "hidden from role" menu items in 6.x-1.8 causes Menu per Role to stop working (fixed) so I will mark this very issue as a duplicate of the other since more people are part of the other. Please, test with the dev version to see whether you still have a problem. I did not make any other changes since Oct 19 (i.e. version 1.8).

Thank you.
Alexis Wilke

Alexis,

I have tested the new dev version and used it to create a new menu item.

I had previously found there was some issue with the restrict menu visibility setting(s) not being saved consistently on the creation of a node that was also used as a menu item. I am not sure if that was happening all the time because it was not the real focus of my testing and concerns.

The new dev version seems to works fine on the test I have done.

However, this is not a duplicate of http://drupal.org/node/948158 which I will elaborate on in that thread. I am changing the status of this issue to needs review. I hope that is ok. It may be helpful if someone else can also test this so I did not change status to RTBC.

Izzy

Okay, got it! 8-)

An empty string generates an array of 1 item.

I wonder why I could not replicate the problem, but I will have a fix here soon.

Sorry for the trouble.
Alexis

Okay, a fix for that problem was checked in. I also attached a patch here.

Let me know how that works for you! I'm pretty sure that's the problem.

Thank you.
Alexis

http://drupal.org/cvs?commit=473060

Is the patch in #10 to be applied to 6.x-1.8 or to the latest dev ?

You cannot change a version once it was generated... It will be in the -dev version although it should apply against 1.8 too. So if you just wait for -dev you'll be all good. Both patches will be included in that latest version.

Thank you.
Alexis

cyberm4tic,

Did you verify that the selection was indeed there? I would imagine so, but I just want to make sure. In some cases, the flags would not get saved.

Thank you.
Alexis

From what I read, the Menu Access Items would do something similar to the Menu per Role.

Couldn't you just remove the Menu per Role and use the other module only (since it is broader)?

Or is the other module not working at all for you?

Also, a good way to work (not like I 100% follow it either...) is to have a backup of your database before you upgrade. That way, if you have a problem with an upgrade, you "should" be able to go back without much problem (i.e. simply by restoring the database you also remove the latest installed modules since that information is saved in the system table.)

The code of the Menu Access Items is not supported well though, but it comes from a University so you'd expect it to work right?!

Thank you.
Alexis

cyberm4tic,

Another thing I just thought about. By name, menu_access should be before menu_per_roles, in other words, whatever menu_access changes should be changed before the menu_per_roles module applies its own changes.

However, if they change the weight of the module to 1 or more, then it would be executed after. This means it could be stepping over the menu_per_roles changes and "restore" the "default" behavior.

To make sure, you should look at the current weight of the menu_access module (in the system table, search for the module and look at the weight column, there are some modules that give you access to that data if you want to.)

And either way, you could try to set the menu_per_roles weight to a number higher than menu_access (+1 is enough.)

This being said, it could also be that the callback that menu_per_role expects is somehow annihilated. To test that theory, you'd have to change the code as follow in menu_per_roles.module:

function menu_per_role_translated_menu_link_alter(&$item, $map)
{
drupal_set_message('Menu per role callback called.', 'error');

  // avoid checking the role if the item access is already false
  if ($item['access'] && _menu_per_role_access($item['mlid']) === FALSE) {
    $item['access'] = FALSE;
  }
}

By adding the drupal_set_message() you'll know whether our function is called or not. If not, then obviously it cannot have any effect on the menu visibility.

Thank you.
Alexis

I am using the latest 6.x-1.x-dev release dated 2011-01-03 and the changes to menu role visibility are not being saved consistently.

This has failed on existing nodes one which was converted to a menu item and the other which already was a menu item to which role visibility settings were added.

Usually the first save is failing and editing the node again the role visibility setting are still empty. The second save seems to always work.

Izzy,

Indeed. The problem is not whether the node exists, but the menu item. The item identifier (mlid) is known in the hook_nodeapi(), but not when the menu item callback is called.

So this means we do not need to have the callback for the node form, but we want to have the 'update' as well in the hook_nodeapi() function.

Now, as I was at it I checked the Preview and that fails. Grrr...

Thank you.
Alexis Wilke
http://drupal.org/cvs?commit=480134

cyberm4tic,

The newer version will be available within 12h. But I don't think that will help you yet.

Did you try to disable the Menu Access module? Just disabling it should prevent it from being loaded and thus from interfering. I guess that may not work if it plugged something in the system that causes problems if not removed when being disabled.

As long as you have direct access to your Database, you can fix the problem of WSOD, etc. by setting the status flag in the system table back to 1 (I'd suggest you back up your entire database first anyway, then just restore the system table if you have problems and cannot use Drupal anymore.)

Thank you.
Alexis Wilke

Switching back to needs review 8-)
See #20

Okay, the first problem (changes to visibility not being saved) should be 100% resolved in version 6.x-1.9.

Feel free to reopen the issue if you still have problems.

Thank you.
Alexis Wilke