Fake pages

Short description of the enhancement

The page tree is great, but when you want a different url structure it gets a little complicated.
For example, I'm building a music related site and the tree looks like this currently:

home
-artists
--artist-name
---song1
---song2
---song3

This would give me the following url structure example.com/artists/artist-name/song1, but I want it to be example.com/artist-name/song1. I know it can be achieved with url segments, but that just adds more complexity.

While thinking how to best organize my pages I got this idea of fake pages. They are just containers that help organize the page tree, they don't affect the url structure.

In the tree example above the artists page would be a fake page, but its "children" would be actually children of home, so this page has no other purpose than making the page tree cleaner.

Why would the enhancement be useful to users?

It would allow for a more organized page tree while keeping the url structure simple.

[ethanbeyer]

I second a request for this. It would be so nice to be able to toss things in Fake/Faux/Folder Pages without having to rewrite URLs.

I understand that a primary goal of ProcessWire is to have a URL structure that mirrors the structure of the site, but there are times (as @fbg13 has noted, and as I have run into several times, and as I am sure others have also) where you might want a page to be accessible from root, or with a specific URL, but there are thousands of pages that also fit that criteria - and so in the ProcessWire admin, you are left to choose between disorganization or an unwanted URL.

It can just get very dicey to have URL rewrites for this if there is more than one place where this needs to occur.

[clsource]

This maybe could be created using a module that hooks to
protected function ___pageNotFound($page, $url, $triggerReady = false, $reason = '');

in https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessPageView.module

Also these modules could become handy too 👍
https://github.com/apeisa/ProcessRedirects/blob/master/ProcessRedirects.module
http://modules.processwire.com/modules/process-jumplinks/

@clsource I assume you are talking about the example.com/artists/artist-name/song1 to example.com/artist-name/song1, while the page structure is still
home
-artists
--artist-name
---song1

How would the redirects help in this case? Redirect from example.com/artists/artist-name/song1 to example.com/artist-name/song1? But I would still have to use url segments to provide content on example.com/artist-name/song1? Am I missing something?

My point is that it would be way simpler to have these fake pages/containers, their only use would be to group pages together based on some common factor (template name or maybe a field). This grouping would be only for the page tree, to make it easier to find certain pages and keep things organized.

[clsource]

@fbg13 I do not know if is possible to create something like what you are trying to do without messing up what Processwire provides.

I'm assuming artist-name to be a variable as well as song1
To achieve something like that I think that you should implement a aftersave hook in the artist template. So it creates, deletes or updates a clone in the desired path. Put a special page reference to this clone template and view permissions by role.

home
-artists
--artist-name
---song1

Will become

home
-artist-name (hidden)
--song1 (hidden)
...
-artists
--artist-name
---song1

Then on this clone template just put something like

echo $page->reference->render();

I'm just throwing out ideas. That maybe a module could automate 👍

I do not know if is possible to create something like what you are trying to do without messing up what Processwire provides.

@clsource It shouldn't mess anything as it should only change the markup of the page tree, but this would depend on the implementation and the amount of configurability.

To achieve something like that I think that you should implement a aftersave hook in the artist template. So it creates, deletes or updates a clone in the desired path.

That's an interesting approach.

[ethanbeyer]

I do not know if is possible to create something like what you are trying to do without messing up what Processwire provides.

It's definitely possible, though it might require a new Core Class that extends the Page class in some fashion. This has been something I've wanted long enough that I think I am going to take a crack at it.

[clsource]

Maybe this could do the trick

/**
 * This hook modifies the default behavior of the Page::path function (and thereby Page::url)
 *
 * The primary purpose is to redefine blog posts to be accessed at a URL off the root level
 * rather than under /posts/ (where they actually live). 
 *
 */
wire()->addHookBefore('Page::path', function($event) {
  $page = $event->object;
  if($page->template == 'post') {
    // ensure that pages with template 'post' live off the root rather than '/posts/'
    $event->replace = true;
    $event->return = "/$page->name/";
  }
});

More info
https://processwire.com/talk/topic/5448-remove-parents-from-url/?tab=comments#comment-52921
https://processwire.com/talk/topic/3987-cmscritic-development-case-study/
https://processwire.com/talk/topic/17465-hide-parent-in-url/

But that only changes the way paths/urls are built, /posts/post-name/ to /post-name/, accessing /post-name/ will give a 404.

To display the content on the new url I still have to use url segments or something else, when I have only one url segment it's not a big problem, but if I have 2 or more it gets complicated.

If fake pages exist there is be no need for all this url rewriting and using url segments to display content.

home
-posts (fake page)
--post-1
--post-2

post-1 and post-2 are children of home so they are accessible from /post-1/, posts is just a container for the page tree, no other role.

I know there are ways to achieve what my suggestion tries to solve, but I made this suggestion because it would make it easier to achieve that while not changing/complicating the api.

How these are implemented depends on how customizable the fake pages would be.

[clsource]

Now it's more clear what you need.

I think this could be a module that provides.

1- Group Page Template
This template will act as a fake page. You have to configure what parent (pageRef field) the clones will have.

2- Clone Page Template
This template will act as a reference holder to the original page. Store that reference in the (pageRef field).

3- Clone Page View Permission
For hiding these clone pages in the tree listing.

4- Hook After Save
If a page is saved and it's parent template it's a fake page. Create a clone if not exists that is a child to the parentRef defined in the fake page. Assign the saved page as the parentRef in the clone page and stablish clone page view permissions.

5- Hook After Remove
If a page is removed and it's parent template it's a fake page. Look for a clone that is a child to the parentRef defined in the group fake page. If the clone parentRef is the same as the removed page, then remove the clone.

Knowing this all you need to do in the templates directory is providing a template for the Clone Page that renders it's parentRef field.

I think that could be done to fullfill the requirement for fake pages without altering the core by using a module.

If this kind of module exists,
will it solve the fake pages need?

👍

[Toutouwai]

Just a note to say that I have a module under development that should fill this need. Should be released in a day or so. It uses a different approach to what @clsource has suggested.

[Toutouwai]

And here it is: https://processwire.com/talk/topic/17520-virtual-parents/

[clsource]

@fbg13 if the module from @Toutouwai is what you were looking for,
please close the issue.

If not please give more details so we can find a solution 👍