Option to set a "home" child as admin menu link

[neosin]

While there is an existing module to add links to the admin menu, that module uses pages under "admin" page and custom template process files.

What about content that lives under "home" and works like regular cms pages?

Can you add option in page "settings" of pages, which would allow that page to have a nav link in the admin menu?

Let's say we have a page called "Streams" that cms users can add/edit children and visitors can view on the front end.

Streams live under "home > streams".

Use case

1. We want to add "streams"  to the admin menu because it is a primary content container.
2. We want cms users to be able to add and update "streams" but they must not see the admin page tree because it is full of things they don't need to see, ever.
3. We want the admin "streams" menu item to be "active" when a user is viewing the stream list, creating/viewing/editing a "stream" instead of "pages" being active in the top admin nav menu.

Currently to do this we hide the page tree from non-superadmins using the hide page tree module and then we also edit the UIKit admin theme to return null for breadcrumbs because we don't want users to see anything to do with the page tree. And lastly we use the admin page module to create the streams page under admin > streams and create a custom process file which basically duplicates all existing page code in core just to get the same functionality of the pages under "home > streams" which seems completely unnecessary. There has to be a better way.

So ideally, there would be :

1.  A settings option in all pages to add a selected page to the admin menu regardless if it lives in "home" or "admin".
2. A settings option in all pages to say "use this as default active item" when selected in admin nav menu.
3. A built in default option to hide the pages tree from non-super admins
4. A built in default option to hide the breadcrumb "tree" link from non-super admins

 

[louisstephens]

I have found that this article really helped me out on a recent project. It guides you through creating a new module that adds the Name/link to the nav bar at the top.

[neosin]

6 minutes ago, louisstephens said:

I have found that this article really helped me out on a recent project. It guides you through creating a new module that adds the Name/link to the nav bar at the top.

Right but it requires the page to live under "admin" page which is not the result we want. There is also an existing module https://modules.processwire.com/modules/process-admin-custom-pages/ to do this so you don't even have to create a module for this however it uses "admin" page as the parent.

[louisstephens]

Ah, I understand. However, I was referring to a screenshot halfway down the page illustrating that the new page could be accessed via a link at the top. With a bit of php, you could redirect a user with a certain role to the "Hello" tab, or "Streams" in your case.

 

[Robin S]

15 hours ago, neosin said:

There has to be a better way.

Add the following to the top of /site/templates/admin.php

if($user->hasRole('some_role')) { // Replace 'some_role' with the role you want to customise the page list for
    $wire->addHookAfter('FieldtypePageTitle::wakeupValue', function(HookEvent $event) {
        $page = $event->arguments(0);
        // Should be able to match 'Pages' page by ID
        if($page->id === 3) {
            // Change 'Pages' to 'Streams'
            $event->return = 'Streams';
        }
    });
    $wire->addHookBefore('ProcessPageList::execute', function(HookEvent $event) {
        $ppl = $event->object;
        // Start ProcessPageList from a particular parent page
        $ppl->id = 1234; // The ID of the 'Streams' page
    });
}

If you are already logged in as this role, log out and then log in again to clear the cached top-level menu.

[neosin]

@Robin S thank you but I can't get this to work, not seeing any error messages or anything. I created the admin.php in "/site/templates/" and pasted the code and made the necessary changes but nothing happens/changes after logging in-out and trying multiple roles. I am assuming this code will change "Pages" in the top admin nav menu to "Streams" and give it the right url but it's not changing anything in the admin nav.

 

On a side note, how does everyone else manage hundreds of thousands of pages in a tree list?

Curious to know if there is a way in admin to paginate the page list or certain pages in the page list somehow because I have 300000+ child pages under one page. It would be nice to paginate by 50 or 100 records at a time.

[alxndre]

34 minutes ago, neosin said:

On a side note, how does everyone else manage hundreds of thousands of pages in a tree list?

Usually we use the finder (Pages > Find) and saving bookmarks for commonly used filters. Other times, we create custom module for this if additional functionality is needed.

[neosin]

1 hour ago, alxndre said:

Usually we use the finder (Pages > Find) and saving bookmarks for commonly used filters. Other times, we create custom module for this if additional functionality is needed.

Thank you, it would be cool if the finder view was a settings option for parent pages to display the paginated list automatically or not for its children.

This brings up an important issue then for my original post, if pages is not available to certain roles, then how would a user even get access to the finder? I assume that I would have to add another hook to specifically add "finder" to the admin nav menu.

So now I am thinking that the solution to hide/replace pages will not be the way to go because the users would absolutely need to use "Finder" to paginate and find what they are looking for since pagination is not already part of page lists.

Is PW geared more for single user or very small team projects with simple content requirements? I ask because I find it unusual that there would be so much "work arounds" required to customize the admin for what appears to be simple things like adding new menus and paginating content lists and things like that which are pretty standard in most CMS nowdays.

I am seeing that I have 2 options if I choose to keep working with PW:

1.  Override lots of the current admin functionality using hooks/custom modules to change basic things like menus/pagination/etc.
2.  Create an entirely custom admin for my needs, bypassing the current admin completely using custom classes/modules/etc or an entirely different framework altogether but keeping PW for the wonderful pages functionality. But this entirely defeats the purpose of using PW as a CMS in the first place.

Ideally PW would allow by default:

1.  For an admin to select a page in the pages settings, to appear as a menu item in the admin top nav.
2.  For an admin to select if a pages children should display as paginated and by how much.
3.  For an admin to set in a page what admin roles can access/edit/etc this page in and/or its children directly in the page (not using the roles/permissions nav link). It is counter-intuitive to have to leave the page and visit "roles/permissions" to set permissions for a page. Also pages under "Home" appear to inherit the home permission so kind of useless at the moment if I have 2 roles one to edit the home page and one to edit streams but they can both edit each others content even if that is not the required permissions since "streams" is a child of "home". 

Don't get me wrong, I like PW but based on what I have understood/learned about PW in the last week it seems that it is more geared for small teams/small projects if you want to use it as is "out of the box" with minimal to no tweaking.

[neosin]

7 hours ago, Robin S said:

Add the following to the top of /site/templates/admin.php

if($user->hasRole('some_role')) { // Replace 'some_role' with the role you want to customise the page list for
    $wire->addHookAfter('FieldtypePageTitle::wakeupValue', function(HookEvent $event) {
        $page = $event->arguments(0);
        // Should be able to match 'Pages' page by ID
        if($page->id === 3) {
            // Change 'Pages' to 'Streams'
            $event->return = 'Streams';
        }
    });
    $wire->addHookBefore('ProcessPageList::execute', function(HookEvent $event) {
        $ppl = $event->object;
        // Start ProcessPageList from a particular parent page
        $ppl->id = 1234; // The ID of the 'Streams' page
    });
}

If you are already logged in as this role, log out and then log in again to clear the cached top-level menu.

This causes a strange bug with ajax on the admin side besides not working.

When I have this code in admin.php it does not clear "ajax notices".

I was switching between user accounts with different roles to test this code and I noticed that no matter what I did, failed login attempts ajax notices never cleared. So each login fail by another user would display each time the admin logged in even if they cleared the notices before logging out and back in.

When I comment out/remove this code, the ajax notices clear as intended for admin. I have no idea what is going on here.

[LostKobrakai]

You're dismissing the page-tree, which really is the primary tool for getting to visible/editable content in processwire from the start, but then wonder why it's so difficult to add functionality for editing content elsewhere because you just removed most of what was already there. That's a strange conclusion to draw.

21 minutes ago, neosin said:

•  For an admin to select a page in the pages settings, to appear as a menu item in the admin top nav.
•  For an admin to select if a pages children should display as paginated and by how much.

Setting up custom pages for sections of your page can be done with process modules as you've already gathered. People have been using custom page-trees or custom listers (lister pro if you don't want to get your hands dirty). The best example here is the core itself, where the listing of users is a custom process module, which handles all the additional needs for managing users and it's still just using the basic core lister module beneath.

To automate the process of creating any of these as actual pages in the admin tree I'd use something like this: 

22 minutes ago, neosin said:

It is counter-intuitive to have to leave the page and visit "roles/permissions" to set permissions for a page.

There is no such thing as "permissions for a page" in processwire. Permissions are granted to templates, which is why editing permissions makes most sense in the template edit section. 

[neosin]

6 minutes ago, LostKobrakai said:

There is no such thing as "permissions for a page" in processwire. Permissions are granted to templates, which is why editing permissions makes most sense in the template edit section. 

So if I understand correctly, I would need to duplicate "basic-page" template, set the child to the new template then set the permissions for the new template, as opposed to simply setting a permission/role directly in the child page which uses the same template as the parent currently or even having a list of all pages regardless of template where you can set permissions/roles.

So imagine this scenario - 100 child pages each requiring custom permission but all use same template as "home", they would each need a copy of the "basic-page" template and have the roles/permissions set for each one as needed, so now you have 100 templates that all do the same thing in your admin just different permissions. Instead imagine they can all use "basic-page" (1 template) and you assign the role/permission directly in the child pages itself.

Which option is cleaner?

 

[LostKobrakai]

13 minutes ago, neosin said:

Which option is cleaner?

This question does not really matter, as there just are no page level permission in processwire and propably never will be. ProcessWire is build around template level permissions reaching deep into quite a bit of core functionality and page-level permissions are not really a requirement for a simple cms anyways (we're not talking enterprice grade). Though there are actually quite a few 3rd party modules to make access management more granular in various ways.

[teppo]

3 hours ago, neosin said:

Is PW geared more for single user or very small team projects with simple content requirements? I ask because I find it unusual that there would be so much "work arounds" required to customize the admin for what appears to be simple things like adding new menus and paginating content lists and things like that which are pretty standard in most CMS nowdays.

[...]

Don't get me wrong, I like PW but based on what I have understood/learned about PW in the last week it seems that it is more geared for small teams/small projects if you want to use it as is "out of the box" with minimal to no tweaking.

Having built a number of complex projects with tens or hundreds of thousands of pages with ProcessWire, I can say for sure that ProcessWire works very well for all sizes of projects. That being said, it seems to me that your current use case does indeed differ quite a bit from how ProcessWire works right out of the box, and in that case it shouldn't be such a huge surprise that in order to get exactly the result you want, you'll need to modify the system in one way or the other.

My point is that it's simply not feasible to add settings for every single use case one might face – and since we're talking about a system such as ProcessWire that already provides a ton of hooks that allow you to modify its behaviour programmatically, there's really no need to do that either. Im not trying to deny that what you've suggested here makes sense, at least in your context, but that's still just one of the million use cases for ProcessWire.

Some things to consider:

• As others have explained above, in ProcessWire "admin pages" are Process modules. Creating a new Process module is surprisingly simple, so rather than customizing the Page tree I'd really suggest that you give them a try and then consider hiding the Page list for roles that don't need to see it.
• Like LostKobrakai pointed out above, depending on your permission related needs you might be able to get by with one of the third party modules already available – in your case I'd suggest checking out Dynamic Roles and UserGroups.
• You've mentioned that Page list should be paginated, and it already is. By default pagination is set to display 50 child pages (I think) before paginating the rest. This setting can be tweaked via ProcessPageList module settings.

If you have any specific questions, please let us know – we're always happy to help. That being said, if you're going to expect for the system to cater for every possible use case right out of the box, you're definitely going to be disappointed. Just like you'd be with any other CMS, for that matter

[neosin]

@teppo thank you, evidently I am unnecessarily over-complicating things for myself due to my lack of knowledge of PW intricate functionalities. I will build a smaller site to familiarize myself more with the system and read every single tutorial and doc I can find. I was "wishfully" assuming that I could jump right in and quickly rebuild something like CNN/Youtube/twitch in PW in a short amount of time.

On a side note, according to the captain hooks page, FieldtypePageTitle does not have a "wakeupValue" function, does this explain why Robin S example code above doesn't work for me, or is wakeupvalue inherited from somewhere else for FieldTypePageTitle?

[Robin S]

7 hours ago, neosin said:

I created the admin.php in "/site/templates/"

You shouldn't need to create that file - it is part of every core site profile and should already exist. If it doesn't then you must have deleted it at some point, which is likely the cause of the issues you mention. You could try creating a new admin.php based on the file here.

5 hours ago, neosin said:

This causes a strange bug with ajax on the admin side besides not working.

The hooks I mentioned have nothing to do with AJAX, and I can't reproduce any problem here. Incidentally, PW does not include any AJAX notifications by default. Maybe you installed the System Notifications module - if so, I don't use that module and I don't know anything about it apart from that it gave me a bunch of problems years ago when I tried it. Off topic, but frankly I think that a module that is clearly beta and labelled "currently in development"...

...has no business being in the PW stable core. It should be in dev branch only, or better yet a module outside the core.

36 minutes ago, neosin said:

FieldtypePageTitle does not have a "wakeupValue" function

That is a method of the base Fieldtype class that all fieldtypes extend.

[szabesz]

19 minutes ago, Robin S said:

System Notifications module - if so, I don't use that module and I don't know anything about it apart from that it gave me a bunch of problems years ago when I tried it. Off topic, but frankly I think that a module that is clearly beta and labelled "currently in development"...

That's strange. I have it installed on all my sites and I do not remember having any issues besides personal taste of its UI which is still far better than the default one pushing the whole page downward "all the time".

[Robin S]

48 minutes ago, szabesz said:

I do not remember having any issues besides personal taste of its UI

It's true that UI preferences played a part in my not liking the System Notifications module, but I'm sure I struck some problems also. Some forum topics indicate that others have too. Overall it seems like a module that was released partly finished with the intention of being completed (or at least further developed) but that went off the boil and it somehow ended up in the stable core despite its "under development" status.

[neosin]

3 hours ago, Robin S said:

That is a method of the base Fieldtype class that all fieldtypes extend.

ahh I see, is this documented somewhere?

Looking at the captain hooks page (https://processwire.com/api/hooks/captain-hook/) under "/wire/modules/Fieldtype/ FieldtypePageTitle.module" , this is not clear.

It only shows 1 method "getCompatibleFieldtypes" for this, the other FieldType modules have the wakeupValue listed though.

@Robin S ps. ty for your patience and help

 

[neosin]

just found the tut+ tutorials, I wish I had found these earlier lol. PW is becoming much clearer, like finding a Rosetta stone.

thanks everyone for your patience