Flexibility in page design

[thetuningspoon]

This also seems interesting as maybe also seen: http://madebymany.github.io/sir-trevor-js/

This looks great. Is this something that could potentially be integrated with ProcessWire or with the module you've built?

[apeisa]

Yeah, I think Sir Trevor is closest what I have seen from open source world as a RTE re-imagined. Looks very promising at least!

[felix]

WOW. I didn't know Sir Trevor yet and really love it!

[ryan]

Sir Trevor definitely looks interesting and a great idea. It seems like this could solve a lot of the bad-markup-from-RTEs issue. Though I'm not yet convinced this is better than an RTE for most. At least in testing it out here I found it to be more of a hassle inputting content... though maybe it's just something to get used to. I'm also looking for how to input headlines and not seeing the option to do so--I'm assuming they'd do that with one of the "+" plugins. But it does call into question how clients would go about pasting content in a convenient manner (probably the most common input methods clients use). But this does seem like a good project to keep an eye on. 

[Pete]

It's pretty similar to what some email marketing programs I've used in the past do. It's a neat way of saying as the admin "hey, you can play with these toys in any order you want, but we're still controlling all the containers" and it does make for something that's a bit more controllable.

It would certainly be of interest I think to people writing blogs or news articles - take an average article from this site for example: http://www.rockpapershotgun.com/2013/10/23/enemy-within-preview/ - text, image, text, image and now and then a video - and it really would allow people to write articles where they like - admin or frontend - and see the layout they'll get as they're writing it. There are other front-end editors of course, but this just looks so simple.

Anything like this that makes things like that simpler is going to be great, even if all it is really doing is constricting what you can and can't do - but for news and blogs that's where you don't mind having your layout controlled like that

Having said all this, you would have to wrap each bit of content with a div so when you go back and edit it the blocks all come apart nicely, but that's no big deal really unless you're trying to shave off every last byte from your page load. <div class='editor-image'> or something isn't exactly going to ruin your life.

[Pete]

Except it doesn't store HTML so wrapping blocks with divs isn't even a worry - silly me for not reading it further

[bfncs]

I also stumbled upon Sir Trevor a few days ago and immediately thought, that it would be a really great addition to Processwire, making especially that small area where it isn't awesome already - flexible content blocks - great. I think that a lot of users would appreciate having a tightly integrated module based on it.

To make it really perfect, though, I think it would need a mechanism for users to build own templates with partials to make up their own content types - ideally this would also work with the built-in types. A huge amount of work...

Still, I would really love to see an integration done and I think that it might attract a lot of users that didn't consider Pw before.

[owzim]

I just thought of yet another approach to flexible page design: Repeaters and the new Field Dependencies.

So you set up a couple of block types via a page select (text with image, three columns text, employee, gallery or whatever blocks you want to use), those options are available in each repeater item and according to what is selected you show and hide fields within the respective repeater item.

Then in the template you can use the new option to pass alternative template files to a page to render the blocks:

foreach ($page->repeater as $repeaterItem) {
    echo $repeaterItem->render("blocks/{$repeaterItem->type}.php");
}

This might be closest to what I would expect from patching a flexible page layout together.

[Soma]

@owzim see my post above where I explain this....

http://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=45581

But repeaters don't support field dependencies (yet) I just hacked it into to recognize dependencies and it would work.

and here I meant http://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=45565

[owzim]

But repeaters don't support field dependencies (yet) I just hacked it into to recognize dependencies and it would work.

Dang, where and when did you hack it into repeaters?

[Soma]

In InputfieldWrapper.php around #302 and looks like this

if(strlen($showIf)) {
    if(strpos($inputfield->name, "_repeater") !== false){
        $rep = explode("repeater",$inputfield->name);
        $showif_part = explode("=",$showIf);
        $showIf = $showif_part[0] . "_repeater{$rep[1]}" . "=" . $showif_part[1];
    }
    
    $ffAttrs['data-show-if'] = $showIf;
    $ffAttrs['class'] .= ' ' . $classes['item_show_if'];
}
 

I thought maybe Ryan would read this and implement support for repeaters too, but you know how it goes...

[owzim]

Cool, gonna try this out later.

[ryan]

Thanks Soma, I will add this too. I'm not totally sure I understand how it works, but have pasted it in here and will follow in more detail.

[thetuningspoon]

I just thought of yet another approach to flexible page design: Repeaters and the new Field Dependencies.

So you set up a couple of block types via a page select (text with image, three columns text, employee, gallery or whatever blocks you want to use), those options are available in each repeater item and according to what is selected you show and hide fields within the respective repeater item.

Then in the template you can use the new option to pass alternative template files to a page to render the blocks:

foreach ($page->repeater as $repeaterItem) {
    echo $repeaterItem->render("blocks/{$repeaterItem->type}.php");
}

This might be closest to what I would expect from patching a flexible page layout together.

Ooo, good call. Although, if I understand you correctly, something like this (although a little less elegant) can be accomplished already just using collapsed-only-when-blank fields inside of repeaters:

In your template code, you would just loop through the repeater children, checking to see which field was filled out and outputting that field.

foreach ($page->repeater as $repeaterItem) {
 if ($repeaterItem->custom_RTE) {
  // Code for outputting an RTE block
 }
 elseif ($repeaterItem->custom_img) {
  // Code for outputting an image block
 }
 else if ($repeaterItem->custom_gallery) {
  // Code for outputting an image gallery
 }
}

The place both of these fall short is when repeaters within repeaters are required (which is more often than you might think... think about bullet lists or more advanced image galleries). Although the better way around that may be to develop more field types to support some of these more specific content needs.

Edit: Can you use fieldsets in repeaters? If so, this gives you a bit more power to group multiple fields into single 'block types', which can be hidden when not in use.  

All of this would probably make poor Ryan scream

[ryan]

Edit: Can you use fieldsets in repeaters? If so, this gives you a bit more power to group multiple fields into single 'block types', which can be hidden when not in use.  

You can use fieldsets, but not tabs. 

[DV-JF]

This topic is really interesting, cause I'm asking myself too, how to manage site specific content. I reopened this thread before reading this topic.

I want to create a structure witch makes it easy for the editors to create "individual" sites without breaking the hole site or layout. Therefore I thought it would be nice to have some predefined "blocks of content", e.g.

• 1 column of text
• 2 columns of text
• 3 columns of text
• Block of Images
• Toggle Section
• 1 column text, 1 image beside
• and so one

The idea behind: If I could predefine such content blocks, then it would be very easy for the editors to structure their articles and sites the way they want it.

The idea behind using childpages seems obviously to me, but I worry that this concept isn't explainable to most of the editors.

Till now I haven't found a nice way to do this.

The way Soma described it, seems to be the clearest:

 It's just what I kinda "expected" from (the) repeatable page element, soI don't have to use child pages anymore. It can be very handy to be able to define "blocks" that can be chosen from, to build a page. TItle,Video, Text-Image, Linklist, Text.

How do you handle this?

Greets

[diogo]

Thinking of it now, it doesn't seem that difficult to do this with PW. Instead of thinking of different templates on each repeater we can just have a repeater with a field or more for each kind of content. If those fields are filed the code knows what to do with them:

foreach($page->repeater as $r) {
    if($r->image->url) {
        // image block;
    } elseif ($r->text) {
        // text block;
    }
}

May sound confusing to have many fields on a repeater block and tell the client to fill only one or two, but now we have http://processwire.com/talk/topic/4323-field-dependencies/,  so we just have to put a radio button with all our "templates" at the beggining and show the related field groups accordingly. This will make our guessing work even easier:

foreach($page->repeater as $r) {
    switch ($r->radio->name) {
        case "image":
            // image block
        case "text":
            // text block
        case "quote":
            // quote block
    }
}
 

[Martijn Geerts]

I like this approach from the admin edit side. Thank for posting this one Diogo !

One drawback is with search facilities for of the page. For the frontend, it's quit good doable, But don't know how to handle it with the Admin Ajax Search.

[diogo]

The problem I see is that repeaters don't seem to support field dependencies yet, but the search part doesn't seem difficult to me:

$pages->find('repeater.radio.name=text, repeater.text*=$query')

I think you don't even need the first part, but I put it there just for reference

[DV-JF]

[...] May sound confusing to have many fields on a repeater block and tell the client to fill only one or two, but now we have http://processwire.com/talk/topic/4323-field-dependencies/,  so we just have to put a radio button with all our "templates" at the beggining and show the related field groups accordingly. This will make our guessing work even easier [...]

Is it possible to use the field dependencies with PW 2.3.0 or do I have to use the dev branch in order to use them?

[Martijn Geerts]

Only available in de dev.

[Soma]

We already got through this guys ....

Here 

http://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=47083

and here above on this page

http://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=47085

[diogo]

[Soma]

When we at least get field/fieldset dependencies on repeaters I think it has shown that this could be one possible more or less solid way to go. I see them as nice to have and only for where it really fits the needs and maybe not all and everything should bebuilt using them. There's also Hanna code or Wysiwyg solutions. Or sometimes child pages do well.

Using a dropdown (page select or custom select) to switch between "fieldset", using dependencies (showIf), that represent a set of fields. This works out and would let you specify a couple (not unlimited) at max maybe 5 or little more block types. 

So you can benefit from a already existing interface and system with repeaters for searching them or creating them. They lack some features people requested and generally make sense to have them with repeaters (limit, title etc), it looks like it just takes some time for Ryan to catch up. 

So I think the two options I see

Options1

Rely on the repeaters and give them some love

Option2

Build a proprietary system that will be quite complex (at least for me) to build

and would have to be well built and thought out, I'm not sure it would end having something like repeaters anyway

I would probably go option 1 route

Although you can't use repeaters inside repeaters and also but most of the time if it gets this far there would have to be a custom fieldtype for such cases that fit.

I also think searching them can be either easy or hard depending how many types there are. But really this solution should only be used to build blocks with mainly text and images maybe video or galleries and not to build calendars or directories where other approaches are better suited.

I still use child pages for articles that require block layout and some options, although they're leaf pages on outmost level of tree so having child pages isn't that much of a problem, but still would like to get rid of them for various reasons we all know.

[Craig]

Another option I think, might be to build a module that integrates Sir Trevor and enhances it with ProcessWire-specific blocks