Topic. I installed the module and hid a few menus, and that worked, but then I noticed all changes made to the website using any module or setting at all are suddenly not showing up unless I'm logged in as administrator. Since this website will be an informational one that doesn't use user accounts, the problem basically destroys its use (because it isn't finished). I cleared my cache and cookies and all that stuff on my browser, but that didn't fix it. Then I restarted apache and that didn't fix it. Finally I restarted my computer and went to the site using a different computer that has never seen it before. The changes made after using this module still would not show up.

Comments

I'm not too sure I follow you here... You hide stuff from anonymous users and later you change your mind? New menu entries will not be hidden unless they are in a sub-menu which parent is hidden. To unhide, you go to the menu entry and change the settings there.

If the module is a problem, you can uninstall it and try another one instead.

Thank you.
Alexis

This still sounds like a caching problem to me. If you are having this problem with other modules then it's probably not 'Menu per role's' problem. You said you cleared your browser cache but did you clear the website cache at /admin/setting/performance? That will make sure all changes are updated for anonymous users.

Menu per Role does not have a cache, however the Core caches menus. When you edit a menu, its cache is reset, so just editing the menu is enough.

I also would suggest to install the Mini module to reset the menus as required.

But what is describes sounds like a different problem.

If you have Boost installed, it could also be cached by boost.

Thank you.
Alexis Wilke

I know what you're saying, Alex. The cache SHOULD be reset by editing the menu but I've got to say... clearing the cache is still worth a try. Stranger things have happened to me where I didn't even have the core caching activated, for example, but I still had to clear the cache to see changes for users who weren't logged in.

What I'm saying is that after using the module to hide a menu item for anonymous users, suddenly all changes made to the website cannot be seen by anonymous users. The same old version of the website before a few changes I made is what the anonymous user sees every time on every computer, and I can't get it to update. The admin sees all the changes, but not a guest.

I tried clearing the cache in the Performance settings but it doesn't help. I also tried disabling and uninstalling the module, but that didn't help either.

Could you check your "Recent log entries" to see whether some module generates an error?

It could be a conflict with another module.

When you say "a few changes" do you mean changing the content of a page or adding a new page and put it in your menu?

Thank you.
Alexis

I mean both. However, it appears the problem is fixed. It's really weird. In the log entries was nothing out of the ordinary besides one saying that a guest attempted to run cron, which I did not do. Then I clicked on the View operations link and it took me to www.my site.com/drupal6, and suddenly, without being logged in, I could see the changes. Then I went back to site root.com/ and logged out, and I could see the changes once again!

EDIT: It's not fixed. Now the anonymous users can't see any change made to the site after THAT, and no variety of going to my site.com/drupal6 or running cron is fixing it.

EDIT2: And now the anonymous user CAN see the changes... I suppose it just takes a bit to kick in or something. I don't know what's going on but it seems to work in the end.

Priority:Major» Minor
Status:Active» Needs review

Status:Needs review» Active

So clearing the cache seems to fix it now. It looks like a description of the bug can be this:

Some websites, upon installing this module and using its settings, will go into a state where anonymous users can no longer see changes made to the site. Then the anonymous user will automatically try to run cron. At this point you must browse to yourwebsite.com/drupal6, and then back to your website, and this will bring the website into a state where clearing the cache can show changes to anonymous users.

This is not a bug. Do you have page caching enabled in admin/settings/performance? Or are you using a caching module like Boost or Authcache?

What you are describing is what happens when you have a cache enabled. Logged in users see changes right away but anonymous users don't. This is working as designed because these caching systems are for anonymous users.

Why are you pointing your browser to yourwebsite.com/drupal6? Is that where you have Drupal installed? It seems like after you clear the cache, refreshing the page should be all you have to do to see changes.

If you are doing development, it's best to disable your cache..otherwise you have to clear the cache everytime you make a change.

It was the Recent log entries page that pointed me to mywebsite.com/drupal6, not me. The main site is just mywebsite.com. By now I've run into the issue quite a few times, and I don't think it has anything to do with that module, and that you're right, and the fact that the cache messed with what I wanted to see at the time I installed the module was coincidence.

So I should disable the cache until this site is finished and goes live?

Cadeyrn,

The /drupal6 path sounds like you have two installations on your system. I'm not too sure why one would reset your cache properly and not the other, but there is nothing I know of in the Core or any 3rd party module that would support a /drupal6 path for anything.

In regard to CRON, if you have CRON installed it calls /cron.php once per hour or maybe more often (it depends on your installation, mine does it once an hour.) Also, CRON runs as an anonymous user (this being said, it can still change things that normally only an admin could change.)

You should look at your root installation to see whether you have a /drupal6/ folder. If so, then that's your explanation for that path. And if the CRON sent you there, then it means your CRON install runs against the /drupal6 install (i.e. http://www.example.com/drupal6/cron.php ) and not the correct system (i.e. http://www.example.com/cron.php ). So you probably want to revisit your CRON settings.

Now, changing such a thing may break some links, but in the long run, you'll be running a better installation! (especially if you where to not properly upgrade all versions as expected to run right.)

Thank you.
Alexis

Status:Active» Closed (works as designed)

I don't know why it happens. There are no folders named drupal6 in the root. The root itself is a folder called drupal6, but inside the root are folders that some pages successfully use by www.example.com/folder/filename, NOT www.example.com/drupal6/folder/filename. So obviously this /drupal6 site is a ghost independent of my folders and files. Beyond that, I know my drupal is a standard Ubuntu apt-get installation of Drupal 6, and it has not been changed by me in any way besides the look of Garland by a little bit.

Interesting... maybe the Apache2 configuration then...

I have Ubuntu as well, but I don't use apt-get since it's never on top and I need hundreds of other modules not available in apt-get. 8-)

I have had problems of the sort when I used some softlinks, but it still seems strange. Maybe the Apache system points in the drupal6 folder and there is something in your settings that auto-hides that sub-folder automatically.