Preview, locking, versions, and multiple trees

[tsdtsdtsd]

Hi there,

first I like to thank you for processwire, awesome little CMS you made

[edit: I just saw that 1-3 were already mentioned... nevermind, but 4 is important ]

I have 4 wishes/ideas (not for christmas though), maybe take a look at them:

1. Preview

I guess this was mentioned already: processwires preview system is not that great. Main purpose is to have a preview of unsaved changes while editing a page.

2. Locking

I dont want to destroy the work of another user. So it should be possible to lock a page before start making changes, so other users in the backend dont start to edit the same page.

3. Versions

Processwire needs a history of changes that are done to a page. I just deleted something important? No problem, go back to the last version...

4. Multiple Trees (my biggest concern)

This is maybe the biggest change, but brings a huge benefit.

ATM we have one big tree with pages. My suggestion is to make it possible to create you own trees which have semantical purposes and separate pages from logical/structural data.

This is not easy to describe, so here is my real-worl example:

Currently I'm creating a company homepage for a friend.

Somewhere in the middle of some pages there will be a row with four little boxes/teasers which contain stuff like "product of the month".

The thing is, that he wants to include these teasers on multiple pages, some with same content others not. He wants to be flexible, tell the system "on this page, i want the same teasers, but only two of them with double width", or change the order and stuff like that.

Also he has multiple navigations.

My approach is this:

Instead of replicating the sitemap in processwire pages i'll do somethiong like this:

Root (this node cant be deleted at the moment, so i have to just leave it there)

- Main navigation

- - Home

- - Products

- - ...

- Footer navigation

- - Contact

- - ...

- Teasers

- - Product X Teaser 1col

- - Product Y teaser 2cols

- - Customers voice

- - ...

- Products

- - ...

So, the typical processwire pages are child nodes of "Main navigation" and "Footer navigation". Benefit here is separation and easier implementation of menu modules.

Child nodes of "Teasers" contain data for one teaser element. Benefit is again separation. This is what I would call a structural or data tree.

When I create the template for the homepage, i'll add a page reference field, where he can choose the teasers he would like to display on this particular page. So, he has the power to reuse these teaser on any page, change order and stuff like that.

As you can see, it's possible to create the flexibility needed. But it feels wrong to work with a page object where you should have a data object.

With multiple trees and multiple kinds of trees, we could separate stuff and build logical applications instead of just doing workarounds like I do.

The same with the "Products" node you can see in my example: childs contain data of one particular product. So you can reference to a product, use it's data, on any page or module.

I'm looking forward to get some opinions on this matter, what do you think about this? Any additional ideas?

Maybe I can even get Ryans opinion?

Thanks,

tsd

[Soma]

Hey tsd, welcome to the forum!

PW is designed to work flexible in many areas. Pages are, data objects, models what ever you call them. "Page" is more seen as an abstract term for what is a container for whatever data you want.

I ust built a big webpage, 3 domains, 3 websites each in 2 languages trees all in one PW. And there's all kind of reusable stuff, central download elements for all languages zentral and also local, many different types of accordion elements (done with subpages) so you can felxibly create them and sort them the way you want. And it scales and works very well, all things are used the same way and once you get on how to set up various things, and know all the tricks, you can't beat it. It's not a workaround, it's how PW is designed to work. It just feels wrong but you have to get rid of thinking it's a workaround mainly. So it's right to use page reference to have elements on "homepage" for example.

I see the way you want to go with the separate tree only for defining a navigation, will probably work very well, but why not use the structure to build the navigation. Though I think it's possible to use it like this, I think it could have some side effects on complexer sites.

Though, I agree there's room for improvement as with all, also as it's still a young project.  There will be many improvements here and there I guess, we soon will have things like flexible content elements on a page and many more to come. After a while you will realise it's not as a little software as you might thought. It's a Weightlifter in the body of a ballerina.

So I like to discuss such things, and share thoughts an experience between users how different things can be archived.

[ryan]

Welcome to the forums tsd! Thanks for your feedback. I've quoted and replied below:

1. Preview

Coming soon.

2. Locking

See Soma's 'Page Edit Soft Lock' module https://github.com/somatonic/PageEditSoftLock

3. Versions

Coming soon.

4. Multiple Trees (my biggest concern)

What you are describing is exactly how ProcessWire is designed to be used. But ProcessWire is a little different from any other CMS, so if you are in the mindset of another platform, try to look at it with fresh eyes. 

But it feels wrong to work with a page object where you should have a data object.

Don't feel wrong about it. A Page object is a data object and nothing more. It's what a Page is decorated with later that dictates what it's for and what it does. For example, a Page's template defines whether it's something that can be rendered as a webpage, not the Page itself. If a Page's template has no file, or if the Page's template has no roles assigned to it, then the page is just a lonely data container.

So, the typical processwire pages are child nodes of "Main navigation" and "Footer navigation". Benefit here is separation and easier implementation of menu modules.

There are a lot of different approaches that people like to use in managing their content tree. We try to leave all options open rather than dictating one over another. But the approach you describe is certainly possible now. However, best practices in ProcessWire are that it's preferable not to decouple your site's front-end and back-end structure. Doing so starts to use the tree as a bucket system, which is the system used by most other CMSs, and one we intentionally stay away from. But ProcessWire can be used as a very nice decoupled bucket system for those that need or want it (and I sometimes do), even if it's not a best practice.

When I create the template for the homepage, i'll add a page reference field, where he can choose the teasers he would like to display on this particular page. So, he has the power to reuse these teaser on any page, change order and stuff like that.

It's common to create a branch off the root to manage things like this. On the site I'm working with now, I have a /tools/ branch that is not a front-end page in the site, but a place where I keep components used throughout the site. For instance, /tools/ads/ has a collection of ads below it that the client can choose from to populate on various pages. The /tools/ branch is not a web accessible branch, but there are some things in there that I like to be able to render as pages. The ads I talked about before come in various formats: image, JS, Flash, etc., it could be anything. Rather than getting the other page templates involved in figuring that out, I let the ads render themselves (because the ad template(s) knows how). So I can do this to render a sidebar from my head/foot include, main include, or some other template:

<?php
foreach($pages->get("/tools/ads/")->children("sort=random, limit=3") as $ad) {
    echo $ad->render(); 
}

So while there are times when you just want to pull some data and handle it, there are also times when you want to let the data render itself. If you limit yourself to data-only, you lose the choice and gain no benefit.

With multiple trees and multiple kinds of trees, we could separate stuff and build logical applications instead of just doing workarounds like I do.

Whether something is a branch or a tree doesn't really matter here from my perspective. The type is defined by the template, not the tree or branch. Any branch can be a tree. But if we start pulling branches out of the context of a common root, then we introduce a lot more complexity to the API. That's why we've been de-isolating other data containers (users, roles, permissions, etc.) and moving them to be part of the tree. Now all of these things are pages (in the admin branch) and they are a lot more flexible as a result.

The same with the "Products" node you can see in my example: childs contain data of one particular product. So you can reference to a product, use it's data, on any page or module.

This is what ProcessWire is designed to do. If you can give me an example of exactly the output you are trying to achieve and where, I'll do my best with a structure and code example to better explain. I think code examples sometimes explain things easier than regular English can.

Thanks,

Ryan

[tsdtsdtsd]

Thank you both for the kind explanation.

Your answers enlightened my view on processwire. I think I know where you're trying to get me.

I thought about it and realized that only the word "page" irritated me. After 3 years of Zend Framework you get kind of addicted/obsessed by strict separation and proper wording.

After this mental knot is unraveled I'm starting to figure out.

Time for some serious testing

[apeisa]

I thought about it and realized that only the word "page" irritated me.

You are not the only one. Actually it seems that almost everyone has their itch with using pages as data objects. But after a while it feels just natural. Most of the time they really are pages and page is something that clients also understand - it just makes things easier to call them pages instead of something even more general like "nodes", "items" or "objects".

[Pete]

Nodes was the one that just popped into my head, but every time I think about it it would just make it more confusing to name them something other than pages, especially to an average user such as a business owner who just wants to be able to update their pages.

---

I did have a slightly-related thought - why not change the "Pages" link in the admin to "Content", and allow the wording for a "page" to be changed on a per-template basis? That way you could have a template called "Products" and tell that template to call each child page a "product" instead?

It's not a necessity by any means, but might make the workflow feel more... "right"

[diogo]

hm, I think Pete is right, "Content" would fit very well on the menu

[Soma]

... or maybe "Tree"

I agree, and good idea. As this is what I'm needing too, to define it per template.

We were already discussing such things. Also a good feature would be to have an icon per template that show in the tree.

[Pete]

Also a good feature would be to have an icon per template that show in the tree.

up - useful if you have a section for documents, or a section for downloads etc so it's easily identifiable as to what the section's content is (although it should be obvious anyway it's always nice to have additional visual indicators).