First Steps to Making New Admin Tabs?

[alkahest]

As an early foray into PW, I've been porting over a WP site I built not too long ago.

Needless to say it's been pretty amazing so far and I'm excited to keep going. The way the selectors work is a dream compared to WP, even if PW is in its infancy when it comes to the admin interface.

Now, there are probably more bad WordPress developers out there than good ones, and I know this having spent the past five years working in WP and making the transition, but one thing WP does have down right is the clear separation of content types in the Dashboard: Content types like Pages/Posts/Custom Post Types with taxonomies are organized differently than Menus or Sidebars & Widgets, and so on. By this I mean, visually, of course: that is, I go to a different part of the admin to administrate different types of data, and my experience with clients I've built installations for is that this visual separation of content makes sense to them, often without my having to explain anything when I release a build. This is of course as compared to say, the way Drupal organizes its content in the admin, which only ever gives clients headaches.

Anyway, I want to experiment with the Ergo admin theme and see what complexities are involved in adding new tabs to the main menu, potentially to create the illusion that specific pages and/or trees of pages are stored in separate parts of the PW admin. Has there been any talk in the forums about this?

If anyone can point me to discussions you've come across, that'd be great.

[MarcC]

Welcome! That's a really good & interesting question. One thing I'd suggest is to read this article and Ryan's comments below it: http://gadgetopia.com/post/7242

He talks about "bucket" CMS software, which is really part of what you're talking about, if I'm reading you right. So read what he says about how he prefers to arrange data and see what you think. It could be that you end up writing a really neat system on top of ProcessWire, and I've actually spoken about other CMS developers on that subject, but I think it's a good idea to understand ProcessWire's aims & successes first.

I'll hold off on admin tab advice because it's been a while since I've done that and my knowledge may be outdated.

[kongondo]

Having looked at several PW Admin themes, I can safely say creating a PW admin is quite "easy". It is just a page after all. I have been toying with some admin theme ideas lately (too many ideas, so little time!) but haven't finished (er, haven't started) on any of them. Down the pipeline (very long pipeline) I will do a tut on how to port different admin themes to PW. It is just a matter of outputting the content you want in the "section" you want...

I'm too lazy to search atm  but yeah, this topic has been discussed before. I think PW aims to remain simple to use. And because it is simple to use and build things with, stuff like admin themes can easily be built/customised by the user rather than provided in the core. Just my 2 pence  

[MarcC]

Hm, yeah, just making the tab is dead easy. I just made a new page under the hidden "Admin" page, published it, and I had a new tab. But it is asking for a process to associate with. So what I would recommend next is reading Soma's post, here: http://processwire.com/talk/topic/1272-new-page-nav-in-admin/#entry11276

[alkahest]

Sweet, I'll check that out tomorrow.

RE: the article; I appreciate the article's discussion of a "master geography" or single kernel of truth, suggested by the system, as the basis for all relationships between content types. I also agree with Ryan's comment in the article about how we need a master tree so that content doesn't get disconnected from the URL maps that the Web/Google depends on. 

I guess when I say I'd like to bucket out content in the admin, I don't mean to actually separate the content from the "home" tree. That is, it looks like all pages, no matter what templates they use, live off the "home" tree in PW and are connected to it, whether they generate real URLs or not. What I'd like to try and do is make separate tabs/admin pages for content like sidebars, widgets/blocks, and menus since they don't have URLs in the front end, and definitely do behave differently than regular pages in the system (since, for example, there are things like custom menus, global sidebars, and global widgets/blocks and so on).

I think this might be as easy as having a page called "Sidebars" in the hierarchy that's hidden from the "home" tree (excuse my lack of familiarity with the PW terminology here), but made visible, with all its children (presumably the individual sidebars that can be assigned to pages throughout the site, and their child widgets), if you visit a tab like "Sidebars" in the main admin navigation. Same for menus.

So really, for me, it'd just be a matter of making a new admin page that can be linked to from the main navigation, and then listing out a particular subtree of the home tree. As far as philosophy's concerned, my driver's really the client; my experience is that they have less success searching for stuff that behaves like an attachment to the real content in a tree than in its own cordoned-off little area.

[kongondo]

RE all pages in the tree looking the same, this module Template Decorator might interest you: http://modules.processwire.com/modules/template-decorator/

[MarcC]

I think I see what you mean. I don't want to give the idea that I'm against it, either--having created pages like that both in and outside of the admin area. But I had a few experiences where I made really weird decisions until I understood how Ryan's experience added up to a big picture where you get a system that seems to scale really well when it comes time to tweak the original tweaks.

[alkahest]

Thanks for these links & the advice guys, this board is pretty solid. 

[alkahest]

Okay, so here's what I came up with:

Goal:

Make a branch of pages in the Home tree completely hidden from a "client" role, say of Menus or Sidebars, but that is visible from a tab in the admin's primary menu so that the client is just dealing with pages in the "Home" tree. The end result being just "Pages," "Menus," and "Sidebars" in the primary admin menu.

Steps:

1) I make a template called "node" for any parent page that starts a branch of pages that shouldn't be viewable in the Home tree to the client role. This isn't necessary but I feel like it's helpful because now these pages don't resemble the regular page template if the user somehow stumbles upon them.

2) I make a page called "Menus" and assign it the "node" template in the Home tree. All my custom menus are children of this page.

3) I make a page called "Menus" as a child of the hidden Admin page in the Home tree. This causes PW to make a tab with the message about not having a process assigned to it.

4) I make a module that assigns a process to the new template: (http://processwire.com/talk/topic/1272-new-page-nav-in-admin/):

class UtilityMenuList extends Process {

	public static function getModuleInfo() {
		return array(
			'title' => 'Custom Menu List',
			'summary' => 'List all custom menus.',
			'version' => 100,
			'permission' => 'page-edit'
			);
	}

	public function execute(){
		$pl = $this->modules->get("ProcessPageList");
		$pl->set('id',1057); // or any other parent page
		return $pl->execute();
	}
	
}

Here we set the ID to the "Menus" page from step 2. This is the branch of pages we want to appear on the Menus tab.

5) We go back to the Menus admin page from step 4 and choose UtilityMenuList from the Process field. This makes PW show a Home tree that only includes the Menus branch.

6) Now we want to exclude the Menus branch from being visible on the Home tree, since that should only show "regular" Pages. I followed Soma's tutorial here for extracting branches from the JSON, since it's not apparent how to hook into ProcessPageList according to this thread: http://processwire.com/talk/topic/1272-new-page-nav-in-admin/. We create another module:

<?php
 
/**
 * Utility Hide Nodes
 *
 * Hides pages with a node template from display in the admin.
 *
 * ProcessWire 2.x
 * Copyright © 2010 by Ryan Cramer
 * Licensed under GNU/GPL v2, see LICENSE.TXT
 *
 * http://www.processwire.com
 * http://www.ryancramer.com
 *
 */
 
class UtilityHideNodes extends WireData implements Module {
 
    public static function getModuleInfo() {
 
        return array(
            'title' => 'Hide Node Pages',
            'version' => 100,
            'summary' => 'Example module to hide page in the admin per user per page.
                          Add a page field "pagelist_hidden" with a PageListSelectMultiple input type
                          to the user template. Select or add pages you want to hide in the admin.',
            'href' => '',
            'singular' => true,
            'autoload' => true
            );
    }
 
 
    public function init() {
        // only add hook only if the render parameter is set
        // (as used by ProcessPageList)
        if(!isset($_GET['render'])) return;
 
        $user = $this->user;
        $roles = $user->roles;
        // loop thru each role
        foreach($roles as $role) {
            if (!$role->pagelist_hidden) return;
        }

        $this->addHookAfter('ProcessPageList::execute', $this, 'pageListHiddenPages');
    }
 
 
    public function pageListHiddenPages(HookEvent $event){

        $user = $this->user;
        $roles = $user->roles;
        foreach($roles as $role) {
            foreach($role->pagelist_hidden as $hidden_page) {
                $hidden[] = $hidden_page->id;
            }
        }

        // make sure it's an ajax request
        if($this->config->ajax){
            // manipulate the json returned and remove any pages found from array
            $json = json_decode($event->return, true);
            foreach($json['children'] as $key => $child){
                if(in_array($child['id'],$hidden)) unset($json['children'][$key]);
            }
            $json['children'] = array_values($json['children']);
            $event->return = json_encode($json);
        }
 
    }
 
}

7) I altered Soma's code to make it work with roles. We go to the Role template instead of User and add a new field called "pagelist_hidden" of the type Pages, with the following settings: Details = Multiple Pages (PageArray) and InputFieldType = PageListSelectMultiple. This will let us choose specific pages to make hidden from the Home tree on a role-by-role basis.

8) In my case I have a "client" role, so I assign this field to the Role template and then pick my Menus branch on the "client" role.

9) If I log in as the client role, the Menus branch doesn't appear at all in the Home tree, but I can still see it in the branch that gets outputted under my new Menu tab.

So as a result we can add as many tabs as we need (potentially to create the illusion of more content types beyond pages) and hide as many branches thru the admin interface by simply adding them to the client's user role.

The Menus parent page still appears on this tab, which is unfortunate but not so bad. If this were a Blog section, it would still make sense visually. I just set the parent to be uneditable, that way the client can't mess with it, but the children are still editable.

Next step would be... can we somehow paginate a branch?  Anyhoo it's pretty neat so far. 

Edit:

Altered Soma's code to work with roles & not individual users.