Hide child pages but use their data

[Can]

thanks for your detailed reply Wanze

I don't want to prevent 404.

I think I misunderstood totoff and thaught he wants to prevent 404..

I think I got it now, thank you

Can

[totoff]

You were unable to understand post #7 because my thinking was wrong at this time ;-)

EDIT: At the moment I think it´s best for me to have a page without template file and set state to hidden to have it different in page tree list

If you just need the page as an object that keeps data (as I did), than this is the best way to go.

[Can]

haha that's kind of funny ^^

thanks for "washing" my brain

Can

PW becomes nicer and nicer

[thetuningspoon]

A 404 means that the page doesn't exist, so it won't be indexed and it won't be visible, which is exactly what you want. So a page with a template with no template file is the way to go for sure.

[gebeer]

$pages->get() is an explicit call to retrieve a page. ProcessWire assumes that you want to get it, no matter if it's hidden or not

For my case this seems not to be the case. Or it doesn't apply to the children of the page you get.

I tried this code to retrieve children, including hidden ones, but it doesn't work. It only gets non-hidden children.

foreach ($pages->get($page->id)->children as $child) :

Before I had

foreach ($page->children as $child) :

which does not get the hidden children, either.

Only this gets hidden children for me:

foreach ($page->children('include=hidden') as $child) :

[adrian]

Your assumption is correct - using get only works for getting hidden pages for that one page that matches your selector. After that you still need to using include=hidden when trying to get hidden children of that page. This is intentional and logical. 

[gebeer]

Thank you for clarifying.

[Jonathan Lahijani]

There could be a situation where you want a Page with the following:

• it's published
• it's hidden
• it's template has a php file
• it SHOULD NOT be available to viewed on the frontend using it's URL

Now you might be thinking "Well if you don't want it to be viewable on frontend, then just delete the template php file!"... however the purpose of wanting to have a template file could be for partial/section rendering.  This is a pattern that I personally like to use.

Here's a perfect example... let's say you have a page called "About Us" and it has 3 sections that make up the page.  Based on how you want to structure that page, you decide that those 3 sections will be stored each as a child page of the "About Us" page, but when the "About Us" page is viewed, the page is built based on those 3 child pages (using a simple loop).

So, we can give this as an example:

• /about/ (about.php)
  • /about/philosophy/ (section-type-1.php)
  • /about/mission-statement/ (section-type-2.php)
  • /about/some-other-section/ (section-type-1.php)

and in about.php, you might have something like this (using direct output)...

<?php
foreach($page->children as $section):
  echo $section->render(['prependFile'=>'']);
endforeach;
?>

and in section-type-X.php you would have just your partial markup:

<section class="section-template-<?php echo $page->template; ?>">
  <header>
    <?php echo $page->title; ?>
  </header>
  <?php echo $page->body; ?>
  <!-- etc... -->
</section>

So the above works fine, but those child pages can still be accessed if the direct URL is known.

The way around this is one of the following:

Option 1:  In the partial file, detect if the page is being hit directly, as opposed to being rendered from another template like we are doing.  If it it being hit directly, then redirect somewhere or throw a 404.  You could do that by adding the following to the top of section-type-X.php.

<?php
// the pagestack is empty, which means the user hit this template file directly.
if( empty($options['pageStack']) ):
  throw new PageNotFoundException(); // show 404 page
endif;
?>

Option 2:  Don't assign an actual template file to the section templates.  Instead, use a partial file approach

So, you would rename section-type-X.php to _section-type-X.php (notice it starts with an underscore).

Then in about.php, you would use wireRenderFile/wireIncludeFile.  But now that I think about it, how would you best associate a section page with a template?

--

Anyway, hopefully the scenario I outlined above helps someone.

This occurrence, perhaps unbeknownst to @teppo may be happening on the weekly.pw site.  For example, if you Google for just one Issue (let's say #32), you get the URLs not only to Issue 32, but the page sections that make up that issue:

https://www.google.com/search?q=site%3Aweekly.pw%2Fissue%2F32%2F

Results:

https://weekly.pw/issue/32/

https://weekly.pw/issue/32/latest-processwire-core-updates/

https://weekly.pw/issue/32/new-module-service-ip-geolocation/

https://weekly.pw/issue/32/processwire-resources-of-the-week/

Is that a bug Teppo?  You may get docked for duplicate content depending on how you are handling canonical URLs.

[szabesz]

But now that I think about it, how would you best associate a section page with a template?

How about building these sections by using Repeaters? I'm new to ProcessWire, but as far as I understand, Repeaters are well suited for this type of page constructing task. Although, I do not know what happens, if you want to use a section on another page. Repeaters are kind of "hidden" in the admin too.

[Jonathan Lahijani]

How about building these sections by using Repeaters? I'm new to ProcessWire, but as far as I understand, Repeaters are well suited for this type of page constructing task. Although, I do not know what happens, if you want to use a section on another page. Repeaters are kind of "hidden" in the admin too.

Avoid repeaters.

One problem / limitation with them is that each repeated item is of the same template.  If you have a page with many sections that each have a different template, then repeaters are not the tool.  Instead, use a page select (page or pagetable).

The limitations of repeaters have been discussed throughout the forum.  Given the advances of PW in the last few years, I would consider the Repeater fieldtype's use case to be diminished.

[szabesz]

Thanks Jonathan, I have not yet used repeaters so far, but been wondering for a while when they could be used. Maybe for constructing simple select dropdowns  when enum would suffuce?

[szabesz]

To reply to my own question: for simple selects, this might be a better option, I suppose:

https://processwire.com/api/modules/select-options-fieldtype/

https://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/

[adrianmak]

First time to came across $options['pageStack'] this variable., as I could not find it mentioned in https://processwire.com/docs/

Is it a global pw's variable similar as other pw's api variable like $page, $pages, $templates and etc.

Any more details of this variable ?

[cstevensjr]

A couple  of posts:

https://processwire.com/talk/topic/5762-how-do-we-use-pagestack/

https://processwire.com/talk/topic/3660-what-page-was-the-caller-of-render/