Exclude pages from Pages field type using PageListSelect

[alkahest]

Having difficulty finding this question previously asked, but here goes:

I'm following Macrura's tutorial for creating custom menus (where the menus aren't a reflection of the site's page hierarchy). As a first step, I've created a page called Menus with children that use a template with a Pages field type. This is set to use PageListSelect as the input type, which lets me pick a specific page in the hierarchy from any parent tree.

Is it possible to exclude certain pages from being selectable in the tree? It notes that I can't use PageListSelect and restrict by page template, so how else might I go about it? These pages are already set to be "Hidden: Excluded from lists and searches" so I'm not sure why they still appear in the list of selectable pages?

[kongondo]

Is it possible to exclude certain pages from being selectable in the tree? It notes that I can't use PageListSelect and restrict by page template, so how else might I go about it? These pages are already set to be "Hidden: Excluded from lists and searches" so I'm not sure why they still appear in the list of selectable pages?

I don't think it is possible right-out-of-the-box, I could be wrong.

Exclude from lists and searches does not refer to the back-end but the front-end. A menu is a list after all I understand the confusion though...

Do you want to prevent the client from adding menu items? What's your scenario?

[alkahest]

Yeah, I imagine a scenario where the client is adding new items as menu items in the tree, but things like "Search" and "Menus" and even the 404 page (or any other pages that are children of Home but not actually in the site's hierarchy) would appear as options when they shouldn't be.

[kongondo]

You limit what the client can do in the back-end using Access (roles, permissions, users)....You can even "hide" pages as children of "Admin" and that by default will limit access to them...E.g., create a settings page under Admin and throw stuff there

In a rush, can't explain more now, but definitely, I think Access control can help get you there...

Btw, have you tried PageListSelect logged as a user with less privileges? Were some pages hidden from select?

[kongondo]

Come to think of it (am not thinking clearly hehe), in essence, what you are trying to do is limit access to a page (the Menu page). If your client cannot edit the page, he/she cannot add menu items(via Page Reference Field). So, you have at least two alternatives:

1. Create your Menu page (the one with the Page Reference Field) under Admin. Only you will be able to Edit that page (don't let Client be superuser ).
2. Alternatively, create the Menu page as normal, but limit access to editing it (the page) using roles and permissions + template access controls. Hope this makes sense. 

[alkahest]

Your first suggestion (to use Access control) seems to be on the right track: If I log in as any other role than superuser, the hidden pages are hidden. The only problem I see now is that even if I make a new role (say "Client") and assign her every permission except for the ability to edit templates and do admin things, she still can't edit pages? I must be missing something, because Guest and the new "client" role can only view pages. I've also tried giving Guest more permissions but it makes no difference.

To clarify: I do want the client to be able to edit/see the "Menu" page and menu item children (I don't have it set as hidden - sorry in my comment above I included it as one of the ones I intend to hide, but I'm not actually), just not other hidden pages like say "404" and "API" if those pages exist and were marked as hidden. So it looks like this would work, if only any other role besides superuser could edit pages.

[kongondo]

Yes, other roles can edit pages if you give them the permission...otherwise it will be meaningless to only have superuser edit pages, hehe...But, you also have to give them (the roles) permissions under Template -> Access
 
When editing a user, you see this at the bottom of the page:
 

User will inherit the permissions assigned to each role. You may assign multiple roles to a user. When accessing a page, the user will only inherit permissions from the roles that are also assigned to the page's template.

Btw, remember to remove those extra permissions you gave the Guest in your tests

Edit:

Visibility of pages for custom users depends on the permissions you give them (not really on "hide page" settings you see when editing the page)

Edit2:

One other thing, be mindful of role inheritance...

http://processwire.com/api/user-access/roles/

Edited July 26, 2013 by kongondo

[Wanze]

 Is it possible to exclude certain pages from being selectable in the

tree? It notes that I can't use PageListSelect and restrict by page

template, so how else might I go about it? These pages are already set

to be "Hidden: Excluded from lists and searches" so I'm not sure why

they still appear in the list of selectable pages?

Check out the settings of your Page field under the "Input" tab: Custom selector to find selectable pages

This means, you can also exclude things, e.g.

template!=admin, id!=1897, parent!=id_of_parent_of_children_that_are_not_selectable

[kongondo]

Ye, so versatile this PW, thanks Wanze...

Problem for him though:

NOTE: Not currently compatible with PageListSelect input field types.

He needs that Page Reference Field to use PageListSelect

Edit:

Silly me, of course, using the "Input" tab: Custom selector to find selectable pages...,he does not need to use PageListSelect; he can get all the pages he wants (and exclude those he doesn't want) using selectors..if he can live with lots of scrolling (Select rather than PageListSelect) if there are many pages 

[alkahest]

Ahh, I see - I'm going to try using the custom selector when I get to work on Monday. Sounds like that's exactly what I need, then I'll report back.

Thank you two for the tips.

[ryan]

The PageAutocomplete can be used with a custom selector. If we're talking about a potentially huge list of pages, that's what I usually use. If needed, you can also set the "label" field to be "path", so that you are still aware of where a page is in the structure.

[alkahest]

Okay, so I tried creating a role called "client" and gave it all permissions except for "Administer users," then I created a user "client" using that role. Interestingly the client can't do anything except view pages. The pages like 404 and search though are hidden for this user.

Next I tried using the custom selector like you recommended above...

My setup is:

HOME

- Page

- Page

- Page

- Menus (id 1057)

-- A Custom Menu

--- Arbitrary Link (uses a "menu" template)

--- Arbitrary Link

--- Page in Hierarchy

-- A Custom Menu

...

Menu templates have a field that lets them pick a Page or enter a URL. The Page field (ideally) would be populated with only valid pages in the hierarchy, so under Input I deselected "Parent" and "Template" and I set the Input field type to "Select". Then tried using a selector under "Custom Selector":

template!=admin, parent!=1057 (where 1057 is the Menus page, because they shouldn't be able to pick a Menu)

However the resulting Select dropdown is a list of everything, including admin pages. So I'm not sure what I'm doing wrong here...

(Ultimately I created a field on the homepage that lets them pick a child of the Menus tree, so they can basically choose a menu to go into a "Primary Menu Slot" - in a way this imitates how WordPress allows you to pick menus to go into template-defined slots.)

[kongondo]

Okay, so I tried creating a role called "client" and gave it all permissions except for "Administer users," then I created a user "client" using that role. Interestingly the client can't do anything except view pages. The pages like 404 and search though are hidden for this user.

Did you give "client" access in the templates themselves (see my previous posts)

Next I tried using the custom selector like you recommended above...

My setup is:

HOME

- Page

- Page

- Page

- Menus (id 1057)

-- A Custom Menu

--- Arbitrary Link (uses a "menu" template)

--- Arbitrary Link

--- Page in Hierarchy

-- A Custom Menu

...

Menu templates have a field that lets them pick a Page or enter a URL. The Page field (ideally) would be populated with only valid pages in the hierarchy, so under Input I deselected "Parent" and "Template" and I set the Input field type to "Select". Then tried using a selector under "Custom Selector":

I am not following. What do you mean you deselected "Parent" and "Template"? I get you, my bad

template!=admin, parent!=1057 (where 1057 is the Menus page, because they shouldn't be able to pick a Menu)

However the resulting Select dropdown is a list of everything, including admin pages. So I'm not sure what I'm doing wrong here...

So they shouldn't be able to pick "A custom menu", "Arbitrary Link", etc? In you setup, which pages should they be able to pick? I can't tell from your post.

(Ultimately I created a field on the homepage that lets them pick a child of the Menus tree, so they can basically choose a menu to go into a "Primary Menu Slot" - in a way this imitates how WordPress allows you to pick menus to go into template-defined slots.)

You must be doing something wrong somewhere but hard to tell at the moment..

[kongondo]

template!=admin, parent!=1057 (where 1057 is the Menus page, because they shouldn't be able to pick a Menu)

However the resulting Select dropdown is a list of everything, including admin pages. So I'm not sure what I'm doing wrong here...

Hmmm. I have tested this and I think you might have found a bug ( NOT A BUG; SEE BELOW)...The thing is using the ! declaration results in crazy results. E.g. template!=admin, like you've said, returns admin, trash etc. I am testing on dev branch (from a couple of days back). I'll test further before reporting as a bug...

Edit:

Tested further outputting content in the front end with a find call using a selector "template!=basic-page); If you are logged in as superuser, you will see all pages including trash, roles ,etc (since you are superuser). If not logged in (or logged in as a user with less privileges) you don't get to see those privileged pages (admin, etc.)...I'm guessing that's what's happening in the above case since Alkahest (I suppose) tried above when logged in as superuser.

As for parent!=1057, am still investigating that...

Edit 2:

parent!=1057 (for example), results in the same as above...modules, access pages, can be viewed...

I suppose it makes sense though, because the find is specific? Looks weird though in the Page Reference Field even for superusers 

Edit 3

I don't think this is a bug. 

@Alkahest,

If you use the "Custom Selector" approach, your client will not able to see those admin and setup pages etc in the Page Reference Field drop down since they are not superusers. Try and log in as "client" and you'll see what I mean

Edited July 29, 2013 by kongondo

[alkahest]

Ah I see, you can assign permissions at the template level - that fixes the editing problem for the "client" role.

RE what they can pick: They can pick anything that's not a menu (not anything under "Menus").

I've come to the same conclusion you have too - if you're a superuser, it shows everything regardless of what you've excluded as a selector. My client role, however, sees what's been limited by the selector (it doesn't show admin pages like you said), except that it's ignoring the parent!=1057, which should exclude children of the Menus page (I assume).

However, if we're specifying a selector that says "don't include these pages in the list" shouldn't it exclude them for the superuser as well? That seems like a bug.

[kongondo]

Regarding selectors, if you think about it, superuser means just that...there are no no-go areas for them . But, like I said, I would wish for admin pages not to be incuded at all (irrespective of selector) in the Page Reference Fields. I can't think of a scenario where even a supersuser, in a Page Ref Field, would want to select pages that should not be viewable at the front (modules, trash, etc.). Let's hear what Ryan has to say

RE what they can pick: They can pick anything that's not a menu (not anything under "Menus").
 
... My client role, however, sees what's been limited by the selector (it doesn't show admin pages like you said), except that it's ignoring the parent!=1057, which should exclude children of the Menus page (I assume).

Hmmm. That works OK on my end. When logged in as non-admin, I am not able to select children of parent = 1057 in my Page Ref Field...

Edited July 29, 2013 by kongondo

[alkahest]

I definitely agree on those admin pages. Though it seems to ignore excluding the parent, whether or not you're a superuser.

As for the custom list select thing, I don't think it's a question of access permissions - like, if I'm specifying just a set of pages to display in a list, I don't see how it should matter what role I am. For example, in the cheat sheet, it looks like you can specify role and access permissions as methods, so unless you specify those in conjunction with excluding pages from the selector's results, it shouldn't matter if I'm a superuser or a client role, don't you think?

[kongondo]

See my edit above. In my case (am on dev branch) it RESPECTS parent is not (parent!=123)

[alkahest]

See my edit above. In my case (am on dev branch) it RESPECTS parent is not (parent!=123)

Ooh, my bad - that's good news. Okay, let me get myself on the same branch and test it out.

[kongondo]

I'm not suggesting that it won't work in current stable release (2.3); I just haven't tested in that environment (yet).

Edit:

Tested with current stable (non-dev) version (2.3). It works as expected; parent!=1020 excludes children of 1020 from Select selection in Page Reference Field (tested with single Page Ref Field) when logged in as non superuser.

Meaning...that was not your issue...

Edited July 29, 2013 by kongondo

[alkahest]

Regarding selectors, if you think about it, superuser means just that...there are no no-go areas for them . But, like I said, I would wish for admin pages not to be incuded at all (irrespective of selector) in the Page Reference Fields. I can't think of a scenario where even a supersuser, in a Page Ref Field, would want to select pages that should not be viewable at the front (modules, trash, etc.). Let's hear what Ryan has to say

Hmmm. That works OK on my end. When logged in as non-admin, I am not able to select children of parent = 1057 in my Page Ref Field...

Okay, I can confirm this now - and it looks like it's excluding them properly regardless of access permissions. What was confusing me is that I was selecting a parent that was too high up. So for example, if I say parent!=1057, it excludes the bolded parents below (who are children of Menus - 1057), but not the grandchildren:

- Menus (id 1057)

-- A Custom Menu

--- Arbitrary Link (uses a "menu" template)

--- Arbitrary Link

--- Page in Hierarchy

-- A Custom Menu

--- Arbitrary Link

--- Arbitrary Link

--- Page in Hierarchy

So it seems like the only question that remains is, is it possible to exclude a whole tree?

[kongondo]

I was just about to ask you about that. AFAIK, in PW parent IS NOT same as grandparent. For grandparent you can use has_parent property (http://processwire.com/api/selectors/). Currently, you can only specify one value for each declaration of has_parent in your selector, so you can do has_parent=5, has_parent=15 BUT CANNOT do has_parent=1|87|90. I think there is another approach to querying grandparent ancestry relationships as well; I can't recall it atm.

Exclude a whole tree or a whole branch? Yes, you can do both...using ancestry and/or template association...

Edited July 29, 2013 by kongondo

[alkahest]

Cool, I'm going to mark this as solved because it seems like it's just a matter of selectors/ingenuity at this point. Thank you for the investigative help!

Edit:

In fact, has_parent!=1057 works for all grandchildren! Both the superuser & the client gets the restriction. The only weirdness that remains is that the superuser also sees all the little admin cluttery pages, but that's not a big deal for me because the client's list is clean.