Selectable layouts within a repeater

[guy]

Hi,

I was hoping to just get some advice on whether the method we're proposing for building certain site pages is the correct one when using Processwire. I've attached an image which gives an overview of the idea, i'll explain a bit further below:

We're building site pages which are broken down into multiple sections. These sections can be 3 different heights, have 3 base layouts for the positioning of content, can accept 4+ different types of user generated (page specific) content, alongside an override which would place a reusable block with its own template in a position. If that's not clear hopefully the image helps....

I am proposing the use of a repeater field to handle the content and placement for each section. This is where I am looking for either a thumbs up or a hell no......

I propose we create fieldsets within the repeater each of which handles 1 of the 4+ types of page specific content (video block, text block, link block etc...).

We would then have a page field which can pull in our reusable page templates (offers, USP's etc...). These are all stored in pages which are not customisable from this repeater, therefore they would just place their pages content into the page.

Now to get all this working I would have all of the above, 4+ page specific blocks & the reusable pages, within a single repeater, which in turn could then be added to the page x number of times.

Obviously this would look like s#it, and be a UI knightmare, so I would hook up another field at the start of the repeater which displayed 5 buttons, 1 per section type available. All 5 section types are then hidden by default (jQuery) and only upon selecting a button can you enter content (jQuery). Furthermore if these buttons are built from a single input then the value can be passed to the pages template and it'll know which of the sections to render. Hopefully this should remove issues like the users clicking all 5 buttons and entering content.

I'm a little concerned as to the size of this repeater as every repitition would be generating all the fields, even if the user can't see them. Other than that creating alot of excess blank data fields I believe this should work fine.

Being new to pw though I thought I'd push it out there so someone can tell me about the plugin I can download and save myself from typing such a long winded post ever again.....

[diogo]

Hello Guy,

It sounds that the repeater is just complicating things here. Everything that you can do with a repeater you can also with a group of normal pages. In your place I would step back and rethink your strategy from there.

[guy]

Hey Diogo, thanks for your thoughts. From an admin perspective would creating a page for each of a pages sections (perhaps 10 in some places) not look rather messy? I'm not saying its the wrong approach, just wondering how it could be laid out so it didn't look all a bit confusing for the end user.

If using sub pages for each of a pages sections, I'd assume it best to keep them directly under their parent so as to make the job of finding the part you want to edit as easy as possible. This would mean they'd be sitting next to actual sub pages and I worry that even if they are hidden the whole thing will look very cluttered. The site has over 130 pages so I want to keep its admin as simple to understand as possible, hence isolating a pages sections within a repeater only found on that page seemed more practical.

When I'd considered the pages root for each section I imagined the admin structure looking something like the following, would this be accurate?

• Page 1
  • section 1
  • section 2
  • section 3
  • section 4
  • Sub-Page 1
    • section 1
    • section 2
    • section 3
    • section 4
  • Sub-Page 2
    • section 1
    • section 2
    • Sub-Page 3
      • section 1
      • section 2
      • section 3

I can see this getting a little messy (some pages will have up to 10 sections) with a large number of pages. That said pw will only show the sub pages the users requested to see, so this would control the clutter a bit.

**********    I've had a thought    *********

Assuming the above model is acurate it may be possible to clean this up using just CSS and a bit of jQuery. Processwire places each page within a div and adds the template name to the end of a class, i.e. PageListTemplate_section-hero (the template for which is called section-hero). Therefore if we established a rule that all section templates were prepended with a string like "tbs-section-" (something a bit random) follwed by the sections name, these could be automatically hidden via the stylesheet:

[class^="PageListTemplate_tbs-section-"],
[class*=" PageListTemplate_tbs-section-"] {
 display: none;
}

Then we could pop a button onto the pages inline actions menu which would allow the user to toggle these pages on and off. Still thinking about how best to do this as I'd rather avoid changing the core modules of pw, the functions which would be good to hook with are in ProcessPageList. I'll look into this a bit more and post back what i come up with.

Feeling quite positive about this method,

Thank you again Diogo for your input, it really helped, hopefully the above sits better with you.

[diogo]

I confess I don't understand exactly what will be the benefits of changing the way the admin works, but I may not be visualizing it correctly. As I told you , I would try to achieve the best without changing the admin. If you can get everything to work without "hacking" it will be easier later to think of a good admin solution if needed. But again, maybe I just didn't understand exactly what you want to do.

It's good to keep the real page structure of course, but if you think the pages will be too deep in the tree you can organize them in any way you want by using the page field for relating the sections to pages. You can have, for instance, a "reusable sections" page where you organize all reusable sections as children.

But if you have a clear idea of what you want to do I may be just confusing things for you. Maybe you can explain in more detail what you want, like elaborating more on the image of the first post, and we can help you with the thinking

[Macrura]

just to clarify:

1. the number of sections is variable
2. each of those sections can choose from 1 of 3 'layouts';
3. and each of those sections+layouts can accept 4+ types of content.
4. in addition there is a possibility on a page, to include a 'reusable' block, in any of the said positions.

thinking about the structure of PW, it would seem that the best way to think of your sections is in fact with pages; because then your users can select a different template according to the type of content;

then when they are inputting/editing that content, you could provide a select for them to choose between the three layouts. When rendering each section, you could then easily include the necessary template for that item into the main page, and the from that include file, include the specified layout, or use classes to control the layout, use an if to check which layout they selected.

if it is not too complicated with the different content types, you could setup functions to render each content type, like with an include file containing all of the markup for each section..  (i'm not a super php guru, so this code may not be the most efficient...)

function renderSectionArticle($item) {

$out = " 
         <div{$item->class}>
         {$item->some_field}
        </div>
       // etc
  ";
return $out;
}

in the template

$items = $page->children;

foreach($items as $item) {
        if($item->template == 'article') echo renderSectionArticle($item);
        elseif($item->template == 'something') echo renderSectionSomething($item);
        // etc...
    }  

this would seem to solve 1, 2, and 3. As far as how intuitive this is, i think that's really just a matter of users getting used to the system, and I wouldn't bother hacking the admin;  the only disadvantage might be in not seeing the page as a whole when editing each of the separate pages.

I use this method a lot, meaning i have a page which is composed of various elements, each stored in a child page. 

As far as including that reusable block, that is something that might be best to be selected in the parent item; you could provide a page list select to choose the reusable item, and then have some way of specifying the order. You could use the import array to get that reusable section into your child pages array; then you could sort that array on a custom field, such as 'section_order' where you specify in that field the hierarchy; you could sort the pages in the admin based on that field; they wouldn't see the reusable section though in the admin, but it would appear in the right place on frontend..