hide pages in admin tree

[somatonic]

Hi Ryan

You didn't respond to my question/request in this thread

http://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=35111

So seven months later I'm just put a reminder here. :)

"If Ryan reads this and is still with me. Would you consider adding some hooks to ProcessPageList.module? Or do you think the JSON manipulation is a good way? ."

My hack to manipulate json from ajax just isn't really cutting it. https://gist.github.com/somatonic/5595081

Thanks.

[ryancramerdesign]

We actually already have a hook intended for this purpose: Page::listable (from the PageRender module). But we're not actually using it that way in PageList. However, we should be able to. Does this sound consistent with what you are looking for?

[somatonic]

Page::listable was added when?

And this is in PagePermissions not PageRender. I'm using this hook in MarkupSimpleNavigation so this might be good way.

This might sound good if that could be used to not list a page in admin tree.

Just tested this in admin.php

wire()->addHookAfter("Page::listable", null, "hookListable");

function hookListable($event){
    $page = $event->object;
    if($page->template == "shortcut"){
        $event->return = false;
    }
}

And the the page on 2th level with template shortcut still shows in tree.

But when doing a

if($page->template == "shortcut"){
    $event->return = false;
}

I get a alert that pages are not listable when trying to open /Admin branch. So it looks like it's already used in admin branch of page list tree? Strange, wouldn't expected that.

[ryancramerdesign]

Page::listable has actually been there since the beginning (carried over from PW v1). I never found it that useful, so PW v2 doesn't really use it anywhere particularly useful. Though it appears ProcessPageList does use it to check against the id of the page passed to ProcessPageList, but not yet for the individual items in the list. However, I think this is the hook we should tie into the individual items, as that would clearly be useful in this case.

[yckart]

Any updates on this?

[teppokoivula]

Thanks to @yckart for bringing this one up; would love to see this implemented! :)

[teppokoivula]

@ryancramerdesign Sorry for being a bit pushy here, but I would love to get this feature implemented, preferably soon; currently working on a project that really needs it. Thanks!

[ryancramerdesign]

For PageList, listable() is just used for the roots of each ajax-requested branch. If it's used on the children(), which is what I think is being requested here, then it can screw up pagination, because the listable() status can only be determined at runtime. Maybe that's an okay compromise though. We'll try it out in this week's dev version to see how it goes.

[ryancramerdesign]

Just another thing to mention when you try it (will be pushed with 2.6.9 is pushed later today): the listable() check is skipped for superuser, so when you test it, make sure you are testing with a non-superuser.

[teppokoivula]

@ryancramerdesign This might be what you were referring above, but.. this won't affect the child count in Page Tree (which is based on numChildren()), and clicking a Page with only non-visible children will also open it anyway, there's just nothing to show.

In my use case the end result is very confusing. I could probably solve this with additional JS (check if there are visible children in the tree, and if not, remove child count etc.) but that feels kind of hacky. Is there any way to make this part behave nicely at code-level?

For the record, I went and checked if I could find a clean way to do that; no luck so far. Currently this is checking the literal number of children, and as far as I know, we can't rely on run-time checks there. Looks like a real pain in the a*s, but perhaps you know something I don't.. :)

[adrianbj]

To add to this discussion. Along with hiding uneditable pages, I was thinking a new page status option - "Invisible" might be useful. Access to invisible pages would be for superusers only, or potentially also for roles with a "view-invisible-pages" permission.

Getting OT now, but I think it might be nice to be able to optionally set PageTable content pages to "Invisible" automatically - I think this could avoid a lot of confusion for users around the PageTable field when you want to keep these parents as children of the parent, but not have them visible in the admin or the front-end.

[teppokoivula]

@adrianbj I think I see your point, but perhaps this should be considered as a separate thing from being able to affect whether pages are "listable" or not – just to avoid confusing things too much?

Your idea sounds like it could be really close to what I was trying to achieve in the project I mentioned earlier, but it also sounds like it could get pretty complicated before it's usable: would "invisible" pages still be editable even if they're not viewable (is that even possible), how would they work together with secure assets, etc. etc.

[adrianbj]

Agreed - "invisible" would be an additional way to prevent a page from being listable. In my mind they would only be editable to users with the "view-invisible-pages" permission. I see it as a way to hide sections of the page tree from users that will just find them confusing - various settings pages, maybe also pagefield trees, etc? I definitely haven't thought through all the issues yet - just throwing an idea in the mix :)

[teppokoivula]

"In my mind they would only be editable to users with the "view-invisible-pages" permission" would be the most straightforward answer to the editing part.. and almost the opposite of what I would prefer :)

In my case I want users to be able to edit PageTable items, but they're never intended to be viewed with their real URLs, and preferably shouldn't show up in the page tree at all. There are a couple of reasons why I don't like the idea of putting all of these in one location (including scalability issues), and thus having them as the children of current page would be perfect.. except for the visibility part.

I was hoping that "listable" would solve this, but because of issues mentioned above (wrong counts, half-opening page trees, other weirdness) that doesn't quite work yet. The solution I've got in place for now is making those items visually different (greyed out), and preventing users from "activating" them directly within the page tree. It's just a visual trick, but works well enough in current (quite limited) use case.

[somatonic]

Apart from that issue but related. What about having multiple trees? Each corresponding to its own table.

[adrianbj]

@somatonic - that is exactly what I have done in the past - one grandparent for all pagetable pages and then separate parents for each pagetable field, with their children under each one. This helps to some extent, but it only separates the trees by pagetable, and not by the actual main page with the template that has the pagetable, so it still doesn't allow the level of organization that you get when the pagetable pages are directly under their parent page. It's also another step in the setup of pagetable fields, which is already fairly complex. Sorry for continuing the OT trend of this :)

[LostKobrakai]

I'm currently in the need for a solid solution for this as well. How about letting listable() be defined on a per template / per role basis, so numChildren can exclude them es well. It'll be better for clients to manage subpages via pagetables and not see the mess of children below the page, while still retaining all the right hierarchical structure, especially $page->parent, which is lost when using the "alternate parent" setting.

[ryancramerdesign]

An invisible status sounds like an interesting idea. Though I don't think we could just add a Page::statusInvisible and have it work with the existing status levels, because status levels are both a bit mask, and a number used for less-than/greater-than selects in the DB, to automatically exclude pages from find operations. For instance, the default behavior of $pages->find() is to exclude all pages with a status greater than or equal to Page::statusHidden, unless overridden with an "include=all" or "include=hidden". Because it's a bit mask, we are limited here, unless we start re-assigning what the statuses mean. Also, I'm not sure we should be using the status field purely for affecting the page tree in the admin.

But what we could do is add another low-number status that indicates a page is owned by another (Page::statusOwned?), even if outside the parent/child relationship, and ProcessPageList (in the admin) could automatically exclude pages with that status if the user isn't superuser (or doesn't have some related permission). That could be worthwhile for PageTable and potentially more things on the API side, both front-end and admin. And it wouldn't break anything elsewhere.

For other scenarios where you want to exclude a page in the admin tree from users, it seems like a ProcessPageList hook of some sort would be good. The listable() hook is no good here just because it occurs after the pages have been loaded and count determined, etc. It's worthwhile for very specific exclusions, like in the root of the tree, but not as much for the things I think you guys are looking for. It's not pagination friendly. In order to be pagination friendly, it would need to be something that lets you modify the selector used to find() the pages that will be counted or shown. That would enable you to add your own checkbox field to indicate a page as "invisible" and then implement a hook function (like in your /site/templates/admin.php file) that lets you modify that selector. In that way, you could exclude pages however you see fit, while still being pagination and count friendly for the admin page tree list.

On Sun, Sep 13, 2015 at 10:06 AM, Benjamin Milde [email protected] wrote:

I'm currently in the need for a solid solution for this as well. How about letting listable() be defined on a per template / per role basis, so numChildren can exclude them es well. It'll be better for clients to manage subpages via pagetables and not see the mess of children below the page, while still retaining all the right hierarchical structure, especially $page->parent, which is lost when using the "alternate parent" setting.

— Reply to this email directly or view it on GitHub https://github.com/ryancramerdesign/ProcessWire/issues/302#issuecomment-139879366 .

[LostKobrakai]

I didn't think of a status, because it's permanent, but rather an additional access setting like viewable/editable/…. So it would be possible to show the page(s) to superusers, but hiding them from some roles, which should always use the pagetable to edit pages or whatever alternative there may be.

[TomS-]

I would also love to see this feature. I'm currently working on a big project with our local council, and they had never heard about ProcessWire. I managed to sell it in and they are really looking forward to seeing the system.

I wanted to make the admin interface as clean as possible, so I have a top level called "documents" for example which is uneditable but they can add children and edit children. It all looks great and it's immediately obvious where to add content.

However there is also a feature to register/login and store favourites on the front end. These pages are purely there to create the url and display the template file. I think from their perspective, they might see login, or favourites in their page tree and believe it does something.

The local council here is huge, and there will be loads of people working on adding content. It would be hard to train everyone, so it has to be as simple as possible. I think many will be saying, I see favourites, how do I add a favourite. Then having to explain to them just to ignore it. Part of me wants to add a bit of copy on that page that they can edit just so it has a reason for being there to avoid this.

However I would love to hide pages from the tree on a per role basis. Would be absolutely amazing :-)

P.S: I've added "Powered by ProcessWire" on there, I'm really really hoping the council will let it stay.

[somatonic]

Any news on this? We need something to hide pages in the admin... still waiting.

[ghost]

Any progress regarding hiding uneditable pages by users. please help

[adrianbj]

@g-verma - not ideal, but have a look at this and associated posts: https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?do=findComment&comment=84916