This project is read-only.

Effect of "visible" on page

Topics: Developer Forum, User Forum
Apr 12, 2010 at 2:40 PM
Edited Apr 12, 2010 at 3:10 PM

I am running 1.30 and I have a problem with the visible check box in page navigation.

I read that the visible flag lets you hide a page from the menu, but it can still be reached by a link. This is what I want to achieve because I have a database search page where the user selects a master record, then can proceed to any of several detail pages that need the master record keys passed in the query string. I don't want the users to go directly to the detail pages without selecting a master key, so making the detail pages invisible in the menu is a good solution.

The behaviour I am seeing is, the page is still visible in the menu system to a loggedin user, but if the user selects it, the home page is displayed instead.

If the user clicks a link to the not-visible page from the master search page, the home page is displayed instead.


If the page is not ticked for visible and not ticked for anonymous users, then anonymous users don't see it, but logged-in users still see it.


It seems to behave the same whether using the MWPSK custom providers, or the SQL providers for membership and roles  and the standard XML sitemap provider.


Have I misunderstood the way this was intended to work, or is this a bug?



May 19, 2010 at 8:54 PM
lockh, Have you gotten anywhere with this?
May 20, 2010 at 12:12 AM
Edited May 20, 2010 at 12:23 AM


The short answer is No.


I have posted about this on the "Issue Tracker" list next door in the hope that a couple of people might vote for it and increase the chances of something getting done and included in an official release. So if it is a problem for you too, click on it to vote for it.


See also thread 209754.


There is another related problem in that I think sitemap security trimming does not work properly - the menu still shows you pages you are not allowed to go to. See thread 209047.  I have another post on Issue Tracker about that one too. You could vote for htat too, if you think it would help you.

Jun 7, 2010 at 12:35 PM
Edited Jun 7, 2010 at 1:27 PM

I have a partial solution for this.


The custom sitemap provider first of all checks if sitemap security trimming is enabled, and if not, shows all pages to any user.

Next it checks if the user is an administrator, and if so it allows access to every page  (even if sitemap security is enabled, and the sitemap requires a role which the adminsistrator does not have).

Then later, if this is a MWPSK virtual page, rather than a physical .aspx page, it grants access if either

(a) this is a power user


(b) the page is marked visible. 

Again, it does this even if the sitemap requires a role which the user does not have.


However if the user is NOT a power user, the page is not shown if it is not marked Visible.


If a non-visible page is shown in the menu because the user is an administrator or a power user, but the user does not have a role required by the sitemap, the user can see the invisible page in the menu, but is unable to reach it; he is redirected to the home page instead. So he complains that the site is buggy. And he is right.


The partial solution is, change a line in the App_Code\Providers\CustomXmlSiteMapProvider.cs  (it is line 55 in version 1.30)



                         return (page.Visible || page.EditPowerUser);


                        return page.Visible;  

That will stop it showing Invisible pages to Power Users, although it will still show them to Administrators.


So why should you care?

Because doing this allows you to use  the PowerUser flag and roles in the sitemap so that you can make one user a PowerUser for one area of the site, maybe for one department, and you can make another user a PowerUser for another department, and they will not be able to edit each others blogs or delete each others photos, etc.


It is possible to make another change to hide pages from the Administrators too, but then you would have to edit the xml sitemap if you wanted to make the page visible again.


An more complete alternative solution, which I prefer, is to change the web.config to use standard sitemap and roles and membership providers instead, but I'm doing that with SQL Server.



By the way, if this problem bothers you, please go to the Issue Tracker page in the menu above, and vote for this issue, so it has a better chance of being fixed in a future release.