Structure best practice / grouping in admin

[joe_g]

Hello,

I ran into a broad and general structural issue and I was wondering how you seasoned processwire developers get about this. The page based hierarchy in the admin immediately invites to create a structure that corresponds to the menu/website structure. This is how my projects usually start out. Step 2 is usually to put everything that doesn't belong in the navigation under, say, '/data'.

But now I'm facing a more complex structure that can't be mapped very well to the admin. I find myself wanting to structure the admin side hierarchy independent from the actual site structure. I understand the philosophy of the 1:1 mapping, it makes the cms incredibly easy to grasp! But what would be the best practices when this isn't practical?

In practice, the admin structure, in most projects, becomes (a bit messy) mix between actual website structure and logical parts. Two main ways to get about this is either to put all 'non structural/non visible' pages under /data, or put them as children to their logical parent, but then the admin hierarchy gets littered with a mix of visual and non visual pages, and you end up with very complicated paths that also are dependent on the website structure. (If site structure changes - all logic parts must be adapted)

If I go the route of putting non visual children pages under their visual parent, to make it easier for the editor, it would perhaps be a good idea if actual pages, and non visual pages could have some kind of different styling.

If I go the other route to separate pages from dynamic elements (non visual pages). I would want to sort my website under three main categories: 1. menu structure 2. page structure 3. data. Would this be even possible? It would require some advanced url routing.

I give these suggestions only to illustrate my point, there might be better ideas out there

thanks for listening

J

[apeisa]

I think you need to provide more detail. For the sites I have build I have always used the one /tools/ page which has many subcategories, like:

/tools/recipes/recipe-categories/

/tools/recipes/recipe-types/

/tools/tags/common-tags/

/tools/tags/events-tags/

/tools/cities/

etc...

Some of those are editable by client, others just for superusers.

[ryan]

I do the same thing that apeisa mentioned. However, I also prefer to keep other things in the site structure where possible, even if I don't intend to use them for front-end views. I often setup template files for these things for my own use (or the client/admin's use), and it can be quite useful. I've found that the approach scales very nicely and enables things to grow over time without becoming more complex.

I understand the philosophy of the 1:1 mapping, it makes the cms incredibly easy to grasp! But what would be the best practices when this isn't practical?

When not practical within the site structure, that's when you use your /tools/ structure.

In practice, the admin structure, in most projects, becomes (a bit messy) mix between actual website structure and logical parts.

It only becomes messy if you treat pages as buckets, and buckets are messy. If you treat it as structure and put thought into where something should go and why it should go there, what you end up is something extremely organized and purposeful.

Two main ways to get about this is either to put all 'non structural/non visible' pages under /data, or put them as children to their logical parent, but then the admin hierarchy gets littered with a mix of visual and non visual pages, and you end up with very complicated paths that also are dependent on the website structure.

If something is a non-visual page, does that matter? You see it in an administrative interface, where administration is the purpose. Where I would not want to see the non-visual page is on the front-end.

Another thing to consider is whether something should really be "non-visual". I prefer to implement template-files/views for nearly everything on my sites, even things I might consider non-visual in other platforms. The benefits become obvious once you start doing it. However, ProcessWire will happily maintain pages that have no output too. But experiment with implementing output for things you previously thought as non-visual and see where it takes you. It often opens up great new paths to information and is an excellent SEO tool for increasing cross references in your site.

For example, consider these pages from the modules directory that started out as non-visual. I went back and implemented an "author" template that does nothing other than show the modules by that author. Yet it's quite useful. This may be an obvious example, but the same concept applies to all kinds of situations.

(If site structure changes - all logic parts must be adapted)

This is only true if you code with a dependency on structure. The suggested route is to select by IDs, templates, relative references or some other field to depend on when you are dealing with potential structure changes. Selecting by path is just one way to pull from other pages, but far from the only way. We use it a lot in examples because it is the easiest to communicate with in the context of examples. But that doesn't mean it's always the right way. Ultimately what is right or what is best just depends on the situation.

If I go the route of putting non visual children pages under their visual parent, to make it easier for the editor, it would perhaps be a good idea if actual pages, and non visual pages could have some kind of different styling.

Using the "hidden" checkbox is a good way to immediately differentiate such pages. However, for something better and more automated, check out mindplay.dk's excellent Template Decorator module. I'm hoping he will add this to the modules directory soon!

I would want to sort my website under three main categories: 1. menu structure 2. page structure 3. data. Would this be even possible?

It is possible, but it's not something I would suggest. I think it's fine to create one-off structures for menus where you might want to vary from the page structure for specific situations like footer links, or even primary navigation in some cases (*see note). But if you build your entire strategy on that, you are adding a load of unnecessary complexity to a site, disconnecting navigation from structure, and ultimately creating a mess that could have been avoided with a little planning.

*I think page reference fields, combined with PageListSelectMultiple input are often times a lot better for this stuff.

[onjegolders]

Ryan, you make some excellent points but I share a lot of Joe's feelings about making some distinction between front-end pages and pages for storing data. This may be using the "hidden" attribute.

It may just be being able to manipulate the CSS somewhat which I did for one site using native PW CSS classes. I added margin to the first "data" page and styled it slightly differently.

I think thought there may be no separation between these types of pages for us lot, I think there still is for the average end user.

I'll check out mindplay's module, looks interesting

[ryan]

Ryan, you make some excellent points but I share a lot of Joe's feelings about making some distinction between front-end pages and pages for storing data.

One of the things I was trying to get across is that the majority of cases of these "storing data" pages really do have a place in the front end of a site, whether for you or the users. This is one of a few reasons why we use page references for selection fields too. Any time you've got a page that you are using just as a data container, consider the potential of what more it can be. It doesn't have to be prominent or even linked to anywhere if you don't want it to be, but most data deserves a view, IMO. There was a time when ProcessWire required a view (template-file) for every template, and I often think it was better that way. Though flexibility wins, so had to make it optional. I'll consider ways to alter the style of such pages. But in the short term, definitely check out mindplay's module as it accomplishes what you are looking for, and more.

[onjegolders]

One of the things I was trying to get across is that the majority of cases of these "storing data" pages really do have a place in the front end of a site, whether for you or the users. This is one of a few reasons why we use page references for selection fields too. Any time you've got a page that you are using just as a data container, consider the potential of what more it can be. It doesn't have to be prominent or even linked to anywhere if you don't want it to be, but most data deserves a view, IMO. There was a time when ProcessWire required a view (template-file) for every template, and I often think it was better that way. Though flexibility wins, so had to make it optional. I'll consider ways to alter the style of such pages. But in the short term, definitely check out mindplay's module as it accomplishes what you are looking for, and more.

Definitely this data can be be used front end too and having everything page based, I've learned (from using PW) is so much more flexible. For me, it's purely a CSS thing, they're all pages but it helps me distinguish between them. Perhaps something that gives us the power to sort them (like you did with fields - which is brilliantly simple).

Or just some CSS hooks for us to style ourselves.

[onjegolders]

Unfortunately Template Decorator (though great) is causing all sorts of problems when migrating a site. It gave me errors when installing a profile and template pages in the backend are blank.

I got an error "no class 'on'" or some such like?

[apeisa]

Template Decorator is for dev branch only, that is the reason why Mindplay hasn't added it into modules directory yet.

[pideluxe]

For styling your data-pages, you could add a specific class to your body-tag depending on template or status like this:

<body class="template-<?php echo $page->template;?>">

[onjegolders]

Thanks Pideluxe it was more that the module was throwing errors when I tried to go to the template settings page in the admin but as Apeisa says it's not for production. I really like the way it makes the page list look though

[Soma]

Template Decorator, it only works in php 5.3 and latest jquery > 1.8 I think "on" was introduced. I have a legacy version of it for my installs.

[joe_g]

Gone for a week and comes back to an amazing discussion of stuff I need to look into !

[joe_g]

Long time since this was discussed, I basically followed what I perceived was Ryans main point: Try to map things out within the PW hierarchy instead of trying to build around it. It's a lot easier for the editor to follow. For example: put 'data'-pages next to its 'visual' counterpart, instead of stashing it somewhere obscure under /data/ - I followed this in my last big project and it worked well.

This would be similar to organize your folder structure the best way possible, as "semantic" as possible (instead of abstract), mapped to your website / client / solution as possible.

[onjegolders]

I think you may be right Joe. I still find myself wishing there was some way to easily differentiate with CSS various things in the backend.

Another example are the tabs on a page edit screen.

I often add an SEO or SLIDES tab to my pages so that the client can add different content to the page but they are indistinguishable stylistically from the CHILDREN, SETTINGS, DELETE and VIEW tabs.

While that may make sense to us, it may not to a content editor. Even something as simple as having an option to italicize things would have a huge impact on telling editors where they need to be looking. (I don't want my editors touching "CHILDREN" ((that sounds weird)) or SETTINGS generally)

You could apply the same logic to some pages.