Hi all,

Whenever I attempt to save changes to the "Restrict Visibility" settings of some menu item, whenever I return to the menu item, I find that those settings haven't been saved. Was there some intermediary step I missed, or otherwise am I doing something wrong?

It also doesn't spout any errors when I save changes.

Files: 

Comments

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

Version:6.x-1.2» 6.x-1.8

Sorry,

I messed up the Menu per Role version originally, I'm using Menu Per Role version 6.x-1.8, which should be the latest version.

Additionally, my changelog says I'm using Drupal 6.20.

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

Actually yeah, the upgrade to 6.20 was made fairly recently, you think that probably is the problem?

And no, I haven't upgraded to 1.8 - 1.8 was the first I downloaded.

Thanks again for the help.

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

Assigned:Unassigned» AlexisWilke
Status:Active» Closed (duplicate)

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

Status:Closed (duplicate)» Needs review

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

Alexis,

I installed and went through the same process on version 6.x-1.x-dev, and found the same problem to exist, namely that changes to those settings are not being saved.

I'm starting to suspect that something in my entire menu system is corrupted.

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

I'm not sure whether this was the right approach, but I applied the patch to the dev version and found no changes.

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

Yup, the selection was there: I checked off the anonymous box for roles I'd like to hide a menu item from. Have you possibly heard of problems from people who had previously used Menu Access Items? It somehow corrupted my menu system when I tried to uninstall it, so I reinstalled it and left there, but it is possible that that could have some part in this.

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:

<?php
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

Status:Needs review» Needs work

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.

Alexis,

Thanks so much for being supportive and trying to help me through this (that sounds suspiciously like this is some serious medical problem haha). I tried both suggestions and still no change. The error message appeared more than enough times to suggest that it worked, and after changing the weights in the database, the changes still weren't being saved.

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

Status:Needs work» Needs review

Switching back to needs review 8-)
See #20

Alexis,

Problem solved (kinda). Menu access comes into parts: menu access and menu item access. I discovered you can disable menu item access without crippling the system (removing menu access, on the other hand, completely disfigures the menu system). So now everything is wonderful.

Thanks so much for your help.

I think most of the blame on this one goes to Menu Access. In addition to the module not working and crippling my site upon removal, I have gotten absolutely no response from anyone, neither from the issue postings nor the developer himself, whom I've contacted several times.

Status:Needs review» Fixed

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

Status:Fixed» Closed (fixed)

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