renobird

Hi alexmercenary, I can confirm that the following works, and will indeed create a single page website where the child pages are included in the homepage, and are not accessible via URL. You don't need to set the child pages to hidden, the template logic takes care of the 404. In my home.php template <?php include("./head.inc"); foreach ($pages->get('/')->children() as $p) { echo $p->render('children.php', array('isPartial' => true)); } include("./foot.inc"); In my children.php template (assigned to all children of the home page) <?php if (isset($options['isPartial']) && $options['isPartial'] == true): ?> <section class="arrow" id="<?=$page->name; ?>"> <h2><?=$page->title; ?></h2> </section> <? else: ?> <?php throw new Wire404Exception(); ?> <? endif; ?>

Steve, Your wife may have 2 orders.

ProcessWire wordmark on the front, new logo as a neck print on the back. American Apparel BB401 T's. I'll take 5. Discharge printing too - none of this bulletproof plastisol stuff.

That is weird. So if you just change the status to hidden it breaks? Even without adding hidden children to the $page->children pageArray? Seems like something else is happening to cause that. I can't recreate it here.

And that code will output any child pages that are not set to hidden — correct?

Can you post your code?

Found it. https://processwire.com/talk/topic/3145-multiple-views-for-templates/?p=32876

I don't think you even need to have your child pages set to hidden, they can be published as normal.

alexmercenary, Coffee kicking in now. I think you can pass an $options array to render (I know there is a post on this, but I can't find it). foreach ($page->children("include=hidden") as $c) { echo $c->render(array('isInclude' => true)); // render the pages } In the template file for your child pages: if(isset($options['isInclude']) && $options['isInclude'] == true) { // code for your section } else { $session->redirect("/"); }

Right. Sorry, I didn't have coffee today. I see, you need to set them to unpublished if you really don't want them accessible via URL.

alexmercenary, How complex is the navigation? Do you even need a module? Set the child pages to hidden, and then try this: <ul> <? foreach ($page->children("include=hidden") as $c): ?> <li><a href="#<?=$c->name;?>"><?=$c->title;?></a></li>
 <? endforeach ?> </ul> P.S. Welcome to the forums.

Can you post the resulting images with the lines commented out? I've learned to live with the limitations of GD library, but would be thrilled if there was a way to improve.

Resurrecting this topic. I need to establish an approval process for both publish and edit — it also needs a comparison feature like Pete mentioned. I'm looking into building an in-house module(s) to handle this — perhaps using something like PrettyTextDiff for the comparison. I'm wondering if anyone else has already developed anything that they wouldn't mind sharing. Save myself a little work.

Are those errors or just notices?

OK, so I'm fairly certain this is a dead horse, as Ryan already mentioned that he doesn't intend to support field dependencies in repeaters. That said, I feel like there is still a chance this could be fixed (at least for the = operator). The solution is likely over my head, but I'm going to outline what I know in hopes that someone might find a solution. The crux of the problem: Dependent fields within repeaters show/hide as expected, but they don't save. *Note: they can only be dependent on another field within the repeater. Here is the code for a textarea in a repeater without any field dependency (Saves as expected) <li class="Inputfield InputfieldTextarea Inputfield_body_repeater28589 InputfieldColumnWidthFirst" id="wrap_Inputfield_body_repeater28589"> <label class="InputfieldHeader InputfieldStateToggle" for="Inputfield_body_repeater28589"><i class="toggle-icon fa fa-angle-down"></i>Body</label> <div class="InputfieldContent"> <textarea id="Inputfield_body_repeater28589" class="FieldtypeTextarea InputfieldMaxWidth" name="body_repeater28589" rows="5"></textarea> </div> </li> Same textarea in a repeater, that is dependent on the value of another field (doesn't save). <li class="Inputfield InputfieldTextarea Inputfield_body_repeater28589 InputfieldStateShowIf InputfieldColumnWidthFirst" data-show-if="sidebars_repeater28589=27189" id="wrap_Inputfield_body_repeater28589" style="display: block;"> <label class="InputfieldHeader InputfieldStateToggle" for="Inputfield_body_repeater28589"><i class="toggle-icon fa fa-angle-down"></i>Body</label> <div class="InputfieldContent"> <textarea id="Inputfield_body_repeater28589" class="FieldtypeTextarea InputfieldMaxWidth" name="body_repeater28589" rows="5"></textarea> </div> </li> The only difference is the class "InputfieldStateShowIf" and the "data-show-if" Attribute. I suspect there is an issue with how these fields are interpreted by isProcessable() in InputFieldWrapper.php Of course, this may all be fairly obvious to many of you, and the problem may be a lot more complicated. I really don't know. Contemplating the actual process behind repeaters and field dependencies causes my mind to seize up, so I'm just leaving this information here incase anyone wants to jump and take a look. If this were to work (even for just simple = dependencies) the possibilities are huge!

Are you sure $page_id is being passed as expected? Perhaps echo $page_id to verify.

Vineet, You are getting the page correctly, try adding title to the end. echo wire('pages')->get("id={$page_id}")->title; ...and perhaps what onjegolders mentioned as well. I think omitted title should still output the page ID.

Very nice!

Ryan, Antti, (Avoine), I honestly can't thank you enough for this — this is a game changer (and that's not hyperbole). I'm giddy.

Good call Horst on (int) horst. Zahari, glad to help. My examples were a little slapdash, glad the work Joss did on the wiki pages came in handy. URL Segments are indeed "bloody brilliant!" A module to create an auto incremented field shouldn't be too difficult. I don't have the time now though.

Zahari, URL segments are pretty simple. Essentially you can add "segments" to your URL that don't actually resolve to a page. From the docs So for your needs, we are talking about anything after /videos/ in the URL. The more I think about it, what I suggested about adding a video_id field and using URL segments should accomplish exact what you are after.

You could add a "video ID" to the template: $pg = $pages->get("video_ID={$input->urlSegment1}"); if ($pg->id){ echo $p->video; // assuming the video field is named "video" } I'm certain there is a way to do this without relying on incremental page names. You can still use your page field to select video pages and display them in other pages this way too.

Hi Zahari, I think there are ways to do this without incrementing the page names though, which as Martijn mentioned can get you into trouble. My first thought is to go with URL segments (make sure they are enabled in your /videos/ template). In the template for your /videos/ page $pg = $pages->get("/videos/")->children("start={$input->urlSegment1}, limit=1"); // I think $pg will still be a pageArray with just one page if ($pg){ foreach ($pg as $p){ echo $p->video; // assuming the video field is named "video" } } untested, and off the top of my head. The idea is you get the child page by whatever number is in the URL. from there you output the video for that page. Page names aren't even involved. Edit (I guess you still get into trouble with this method if any pages are ever deleted or reordered.)

Why not just increment the video names in your template? $count = 1; foreach ($videos as $video){ echo "<h1>Video #{$count}</h1>"; echo $video; $count++; }

Running 2.4 on PHP 5.2.17 here. All is working fine.