Flexibility in page design

[uliverse]

Hi,

I am a mostly happy user of Contao which I have successfully used for many projects. What I like about Contao is the great flexibility when creating pages/articles - each article is pieced together with content elements (text, images, galleries, accordions, modules...) in any way I like. Typo3 works very similar I believe. Especially for marketing websites this is extremely useful because in that case pages tend to be styled and designed very individually.

I have been "flirting" with PW now for some weeks but this is still my biggest question: can I achieve the same flexible design/layout approach for individual articles with PW as in Contao without having to create templates for each case? How can I p.e. have some text, then add an accordion, continue with text followed by a form and then add some images at the end - without pre-defining those elements in the template and frontend template? I understand I can do all this using plain HTML - but I can hardly expect that from clients.

Maybe this is a very particular obstacle to overcome in my mind that only applies for users of Contao and Typo3 - other systems don't offer content elements either. I always wondered how those users get to individually designed pages...

[Martijn Geerts]

You can add that flexibility with a little logic in your templates. Say you add 2 checkboxes, Display Album & Render Children. Then on the template you check if "Display Album" is true and count the images. If there are to less or none just display a photo or do nothing. When there are more then x items display an album. Same goes for child pages.  If you want it in between your page body, you can use php's str_replace.

But I think the easiest way right now is using Hanna code

A simple Album/Foto script for-example: 

modify it for your needs

!HannaCode:album:eyJuYW1lIjoiYWxidW0iLCJ0eXBlIjoiNiIsImNvZGUiOiJcLypoY19hdHRyXG50YWc9XCJcIlxuaGNfYXR0cipcL1xuaWYoc3RybGVuKCR0YWcpKSB7XHJcblx0JGltYWdlcyA9ICRwYWdlLT5pbWFnZXMtPmZpbmRUYWcoJHRhZyk7XHJcblx0JGNvdW50ID0gY291bnQoJGltYWdlcyk7XHJcblx0XC9cLyBzaG93IHBob3Rvc1xyXG5cdGlmKCRjb3VudCA8IDMgJiYgJGNvdW50ICE9IDApIHtcclxuXHRcdGZvcmVhY2goJGltYWdlcyBhcyAkaW1hZ2UpIHtcclxuXHRcdFxyXG5cdFx0XHQkdGh1bWIgPSAkaW1hZ2UtPndpZHRoKDYwMCk7XHJcblx0XHRcclxuXHRcdFx0aWYoJGltYWdlLT53aWR0aCgpID4gNDAwKSB7XHJcblxyXG5cdFx0XHRcdGVjaG8gXCI8ZGl2IGNsYXNzPSdpbWFnZSBwaG90byc+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIlxcdDxhIGhyZWY9J3skaW1hZ2UtPnVybH0nIGRhdGEtZnJlc2NvLWNhcHRpb249J3skaW1hZ2UtPmRlc2NyaXB0aW9ufScgZGF0YS1mcmVzY28tZ3JvdXA9J3skcGFnZS0+bmFtZX0nPlxcblwiO1xyXG5cdFx0XHRcdGVjaG8gXCJcXHRcXHQ8aW1nIHNyYz0neyR0aHVtYi0+dXJsfScgXC8+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIlxcdDxcL2E+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIjxcL2Rpdj5cXG5cIjtcclxuXHRcdFx0fSBlbHNlIHtcclxuXHRcdFx0XHRlY2hvIFwiPGltZyBzcmM9J3skdGh1bWItPnVybH0nIGRlc2NyaXB0aW9uPSd7JGltYWdlLT5kZXNjcmlwdGlvbn0nIFwvPlwiO1xyXG5cdFx0XHR9XHJcblx0XHR9XHJcblx0XHRcL1wvIHNob3cgYWxidW1cclxuXHR9IGVsc2UgaWYoJGNvdW50ID49IDMpIHtcclxuXHRcdGVjaG8gXCI8dWwgY2xhc3M9J3RocmVlX3VwIHRpbGVzJz5cXG5cIjtcclxuXHRcdGZvcmVhY2goJGltYWdlcyBhcyAkaW1hZ2UpIHtcclxuXHRcdFx0JHRodW1iID0gJGltYWdlLT5zaXplKDIwMCwyMDApO1xyXG5cdFx0XHRlY2hvIFwiXFx0PGxpPlxcblwiO1xyXG5cdFx0XHRpZigkaW1hZ2UtPndpZHRoKCkgPiA0MDApIHtcclxuXHJcblx0XHRcdFx0ZWNobyBcIlxcdFxcdDxkaXYgY2xhc3M9J2ltYWdlIHBob3RvJz5cXHJcXG5cIjtcclxuXHRcdFx0XHRlY2hvIFwiXFx0XFx0XFx0PGEgaHJlZj0neyRpbWFnZS0+dXJsfScgZGF0YS1mcmVzY28tY2FwdGlvbj0neyRpbWFnZS0+ZGVzY3JpcHRpb259JyBkYXRhLWZyZXNjby1ncm91cD0neyRwYWdlLT5uYW1lfSc+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIlxcdFxcdFxcdFxcdDxpbWcgc3JjPSd7JHRodW1iLT51cmx9JyBkZXNjcmlwdGlvbj0nXCIgLiAkaW1hZ2UtPmRlc2NyaXB0aW9uIC4gXCInIFwvPlxcblwiO1xyXG5cdFx0XHRcdGVjaG8gXCJcXHRcXHRcXHQ8XC9hPlxcblwiO1xyXG5cdFx0XHRcdGVjaG8gXCJcXHRcXHQ8XC9kaXY+XFxuXCI7XHJcblx0XHRcdH0gZWxzZSB7XHJcblx0XHRcdFx0ZWNobyBcIjxpbWcgc3JjPSd7JHRodW1iLT51cmx9JyBkZXNjcmlwdGlvbj0neyRpbWFnZS0+ZGVzY3JpcHRpb259JyBcLz5cXG5cIjtcclxuXHRcdFx0fVxyXG5cdFx0XHRlY2hvIFwiXFx0PFwvbGk+XFxuXCI7XHJcblx0XHR9XHJcblx0XHRlY2hvIFwiPFwvdWw+XFxuXFxuXCI7XHJcblx0fVxyXG59In0=/!HannaCode

[diogo]

Hm, if I understand you correctly there is still not a way to do it as you imagined it. I'm assuming you want the ability for the editor to add groups of fields in the page admin and fill them directly there, a bit as having repeaters with individual templates (this was discussed before somewhere).

You can go with Martijn's solution. Hanna code works very well. Or you can do the same directly in the page tree.

--page two

----block one (template=text)

----block two (template=accordion)

--page two

----block one (template=text)

----block two (template=images)

----block three (template=text)

The editor would create a new page in the tree, and those block as children of it. To choose what kind of block, they would choose the template while creating it (you can limit the templates selectable for pages of this kind).

To output it on the parent page template:

foreach($page->children as $c){
    echo $c->render();
}
 

[uliverse]

Thanks for the replies. I think repeater fields would come the closest to what I am looking for. Everything else still forces the output in a predefined order. But is it possible to repeat a group of fields with repeaters ( for example a group made up of heading, textarea, image, accordion, and whatever elements could be of use)? Then the author can use whatever field he needs, add another repeater and again choose what he needs and so on.

[uliverse]

Maybe I should be more specific with my original post. Just to clarify: I don't have to replicate Contao's behaviour. That's just one efficient way that I know. I am trying to find out how you guys avoid using Rich Text editors for content styling. I think you agree with me that RTEs are not the prime choice due to the messy markup they tend to produce and because authors have too many possibilities to create a mess. So - how do you do it in PW?

[diogo]

Uliverse, read my solution again. It doesn't work with RTE and doesn't force any order since editor can drag the pages(blocks) to order them

[totoff]

Hi Uliverse, I'm a long time Contao user too and I'm afraid you can't mimic the same behavior as in Contao. The above described ways are workarounds but not the same. In PW you have to be much more clear about your article structure from the very beginning. The advantage is that you have much more control over your markup. In Contao there are many if-than situations you can't foresee and thus not control. This applies mainly to site styling, e.g.a headline may be inserted inline or as a content element resulting in two different markup situations. Give PW a try. It is much more flexible in its own way than Contao.

EDIT:

But is it possible to repeat a group of fields with repeaters ( for example a group made up of heading, textarea, image, accordion, and whatever elements could be of use)? Then the author can use whatever field he needs, add another repeater and again choose what he needs and so on.

This is possible, but repeaters are sticked as "fields" to their template. Let's say you'll have three different kinds of repeaters each of which with another order of fields or different fieldtypes at all and you want your editor to be able to choose from each of the three options on any page. In this case you'll have to attach all three repeaters to any template edtiors may use.

Anyway, the described scenario is the one that comes closest to Contao. At least, as far as my understanding reaches.

[totoff]

Rethinking the case I don't think that repeaters will give you what you want. They are simply not meant for that. I would rather follow diogos advice.

[bcartier]

I've built a prototype page builder using Hanna codes. I create Hanna codes for different types of content blocks that you might want to display inline, inside of a RTE field. Don't forget that you can pass attributes to your Hanna code, which can be PHP and have full access to the PW API. In my example, I might have "Products" template with a bunch of categorized products, and I could set up a Hanna code called "product_list". The Hanna code accepts a parameter called 'filter' which is used as part of a PW selector in the product_list's Hanna PHP definition. This filters the products to display. Then a content editor could create something like this inside the RTE:

Tortor Tristique

 

Donec sed odio dui. Donec sed odio dui. Sed posuere consectetur est at lobortis. Etiam porta sem malesuada magna mollis euismod. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Nullam quis risus eget urna mollis ornare vel eu leo.

 

[[product_list  filter="color=blue,category=t-shirt,limit=5"  ]]

 

Vestibulum id ligula porta felis euismod semper. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas faucibus mollis interdum. Aenean lacinia bibendum nulla sed consectetur. Etiam porta sem malesuada magna mollis euismod. Donec id elit non mi porta gravida at eget metus.

 

[[product_list  filter="color=red,category=hat,limit=5"  ]]

 

Donec ullamcorper nulla non metus auctor fringilla. Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Nullam quis risus eget urna mollis ornare vel eu leo.

 

You can get very creative with this approach. For example you could also add a parameter to your hanna code called 'display' which accepts "ul" or "ol" to change the type of HTML list the Hanna code would output. Or maybe it shows just linked product titles by default but you want the option to show a short description with each title, you could can add a detail parameter of y/n to display the appropriate level of detail for a particular list. The possibilities are endless.

I also recommend providing brief help text in the RTE to let editors now what Hanna codes are available, and what the acceptable parameters are.

It's pretty amazing, really.

[uliverse]

Uliverse, read my solution again. It doesn't work with RTE and doesn't force any order since editor can drag the pages(blocks) to order them

That would technicaly work and provide a good level of flexibility. I wonder how the average editor would come to terms with it, though. Thinking of it diogo's solution might really be the best way to imitate the "content element model".

Rethinking the case I don't think that repeaters will give you what you want. They are simply not meant for that. I would rather follow diogos advice.

That's what I was guessing, too. I read somewhere that repeaters are not the best in terms of performance either.

Hanna code looks very powerful indeed. Definitely something to check out! Would be great to have a non-cryptic implementation for the technically challenged end users. Like a drag and drop way... That's beyond my modest skills, though...

I will definitely give PW a try if I have a project that fits. There are scenarios where Contao doesn't give you the powerful tools to enter and retrieve data in a very streamlined and customized way (out of the box at least, there are extensions though that do exactly that.) That's where PW seems to really shine. It does seem to come at the cost that the resulting pages should be highly standardized and follow a pre-defined "cookie cutter design" (well, that's what a template really is) - or much tweaking and workarounds are necessary. At least that's my impression so far. After all PW is meant to be a CMS not a site builder, I understand that.

[ryan]

I think you agree with me that RTEs are not the prime choice due to the messy markup they tend to produce and because authors have too many possibilities to create a mess.

I've never come across a client that didn't prefer a rich text editor to the alternatives. The reality is, they like RTEs because it's something they are already familiar with and it's easy for them to use. So I think a better goal is to give them what they want, but place limits upon it so that it can't produce a mess. Just because RTEs+clients can create a mess doesn't mean we have to let them do it. Both our TinyMCE and CKEditor rich text inputfields come very much restrained and prevent the client from creating a mess. CKEditor4 and it's ACF (advanced content filter) seem particularly adept at solving this problem. If you can convince a client to use an LML (Markdown, etc.) or some method of creating content in blocks, then that's fine. But once the next guy comes around showing them "look what you can do in my CMS–it's like using Word", you may be at a disadvantage. 

Other factors to consider: 1) content maintained by blocks may be significantly less portable through future CMS changes, web service/syndication feeds and such; 2) it may be more difficult to maintain site-wide consistency with the designer's original vision if a site's main content area is a mashup of content blocks. Personally, I would avoid trying to pursue a blocks strategy for most content editors, whether in a CMS that is built around the concept, or via trying to build everything around Hanna Codes. Instead, let the designer do their job and determine consistent and well thought placements for photo galleries, navigation, etc. I see Hanna Code as being better for the exceptions of needing something somewhere, and not something that editors should have to keep as part of their vocabulary. 

[diogo]

"look what you can do in my CMS–it's like using Word", you may be at a disadvantage

In my experience, clients understand and accept very well when you tell them that you created some constrains on purpose. The important is that they look at their website and their friend's website and see why theirs looks much better.

[MatthewSchenker]

Greetings,

When it comes to flexibility in layout, I can't think of a system that is better than ProcessWire.

Let me describe an example of what I had to do for a project I just completed for an arts organization with variations in their "event" pages. Sometimes, these events had multiple images, sometimes only one. Same for text: sometimes the event had text and other times it did not. Then there are combinations of these. (I'll be posting this as a case study soon).

Using the same template, I had to shift the layout depending on which combination is true for that event:

- Multiple images and text: I display text to the left and a lightbox gallery to the right of the text.

- Single image and text: I display text to the left and display a static, full-size image to the right of the text with no lightbox.

- Multiple images and no text: I display a lightbox gallery on the left (where the text woukd normally go).

- Single image and no text: I display a static, full-size image on the left (where the text would normally go) with no lightbox.

Because of the design freedom of ProcessWire, I was able to build some logic into my templates to detect what is going on and render different outcomes.

Of course, in my examples above I have coded these variations. I have not allowed the client (for example) to decide randomly where to insert text and/or galleries or single images. In my opinion, I would advise any client against this kind of strategy, as it actually ends up limiting -- not expanding -- each element, and I think it leads to messy sites.

As diogo said, there is value in explaining the need to constrain in some ways.

Thanks,

Matthew

[uliverse]

Thanks for all your comments! I agree that content blocks make it harder to migrate content to other systems. And if an author doesn't understand the basic intentions of the designer - I see that point, too - the freedom to quickly click together anything that looks cool doesn't help produce consistency. Besides those blocks even add lots of additional markup that somebody has named "DIVeritis". Still I have experienced over and over again how quickly I can achieve exactly the design I intend for a particular page with having those content blocks at my disposal. There are very few limits.

In the end I guess it boils down to two paradigms: a consitent, predictable look or creative freedom. Whatever works better in a particular case should be the method of choice. That's why I had asked in the first place, to find out how PW users approach this issue. Maybe the discussion also depends on if you ask developers or designers. I have come so much used to working with blocks that it is hard for me to think of a workflow without them...

[bcartier]

Great discussion! It's always interesting to hear how others are approaching similar issues.

I agree with Ryan. In the vast majority of sites, I would only use Hanna codes for the rare exception, rather than building out a site using them. 

The page-builder idea was born of the necessity for a high level of content re-use, and to provide more editorial control across thousands of pages on a large site. Editors didn't want to have control like MS word, but wanted to be able to combine inline static text like (limited RTE in this case) with dynamically generated blocks of content. In our case, maintaining visual consistency, cleanliness of code, and ease of maintenance, were actually our top reasons for using the Hanna code approach.

-Brent 

[ryan]

"look what you can do in my CMS–it's like using Word", you may be at a disadvantage

 

In my experience, clients understand and accept very well when you tell them that you created some constrains on purpose. The important is that they look at their website and their friend's website and see why theirs looks much better.

 

I'm not implying that we should be offering all the control of Word to the client. I totally agree with using and communicating the constraints. Our RTE's are very constrained in their default configuration, relative to most other CMSs using RTEs, and that's of course intentional. I've spent a lot of my development career being opposed to web-based RTEs. But over time have come around to feeling that a constrained RTE is about the ideal situation… clients have a high level of comfort with it, as a result of it having similarities to desktop RTEs (Word, etc.). I've now had clients using TinyMCE for years (and now CKEditor) and I like the fact that it reduces the support burden a lot. A well constrained, quality RTE is going to make it very difficult for a client to break things. I'm especially a fan of CKEditor 4 paired with HTMLPurifier, for this reason. In the past, I've tried to get clients to rally behind Markdown. Dictator CMS (which had no RTE) was built around it, for example. I like Markdown, but it unfortunately takes a special client to adopt and like Markdown, and a lot of extra support burden for me. HTML is allowed in Markdown as part of the standard, and this is inevitably what clients resort to when they can't figure something out... which creates a new and perhaps worse kind of mess. GitHub-flavored Markdown seems to be a improvement in this respect.

I'm sure there are both benefits and drawbacks to the blocks approach that's been mentioned, a compromise, like anything else. A CMS built around that is conceptually distant from ProcessWire, as we aim to keep layout concerns and markup generation out of the content management. In our environment, there is a clear separation between where and how things are output, versus management of content that is contained. Though for those cases where people do find the concept beneficial, ProcessWire also aims to be flexible, more than anything. 

[owzim]

Being able to compose a page of individual blocks on the fly has been requested a couple of times now. I remember asking for something similar some time ago (click).

I think the obvious and most comfortable solution would be that repeaters have no fields attached to them but rather templates, or only one template to have the same functionality as we have now. One step further would be that one is able to attach more than one template to the repeater, and then while creating content when you click add item a drop down appears with the template names you added. You choose a template and the next repeater item contains the fields of that chosen template. Next item could be another template and so on. This would be awesome. I would create this kind of behaviour with a module/fieldtype but my knowledge of pw module development and the related api work is not sufficient yet.

Sure this kind of structure can now be created with subpages but this is not convenient for clients, since they don't have all the content on one page.

One argument I've seen a lot is that there is too less of constraints for content creators/editors so they would mess up things or go nuts with laying out content. But the developer can exactly define which templates are assigned to that repeater. And those individual blocks/templates are very much under control of the dev so I strongly disagree with that argument.

[diogo]

repeaters have no fields attached to them but rather templates

Independently of this discussion, I find this a good idea.

[apeisa]

Single page designs are hard in ProcessWire. You either go with RTE-solution (like TinyMCE templates etc) or then with pages/repeaters solution. Neither of those solutions is close to ideal.

I think currently best solution can be found in  newsletter-systems like MailChimp and MadMimi. Drag and drop different kind of components (like header, images, images & text etc) to build your content.

There is of course obvious drawbacks in that kind of content building: you are mixing content and styling together. Sometimes that doesn't matter though (mostly small marketing sites or campaign pages etc).

[kongondo]

I think the obvious and most comfortable solution would be that repeaters have no fields attached to them but rather templates, or only one template to have the same functionality as we have now. One step further would be that one is able to attach more than one template to the repeater, and then while creating content when you click add item a drop down appears with the template names you added. You choose a template and the next repeater item contains the fields of that chosen template. Next item could be another template and so on. This would be awesome.

Sure this kind of structure can now be created with subpages but this is not convenient for clients, since they don't have all the content on one page.

Interesting...if there's interest in this and someone doesn't show us why this would not work, maybe we can start a new topic to discuss this? Just flesh out ideas, discuss drawbacks, advantages etc. This could become a non-core module. I'm getting ahead of myself though and haven't thought this through (e.g. searching the repeaters, memory resources, etc.)

[Soma]

I proposed this idea several times already in various threads... right in the repeater thread once it was published.

I played with the idea and even tried to work out adapting repeater module, but to no success yet as it gets a lot more complicated than first thought. Since there were no real response or interest I haven't spent more time with it. One try was also to build a block module, but haven't got the time to further develop this and it's in a proof of concept alpha stage, only front-end editing and not backend interface. Searching those seems one of the harder things to solve as it gets complicated, but if using a spider or something it wouldn't be a real problem. Scalability would be another consideration, as I can image people using this then to build vast websites with every block being a page, with repeaters inside resulting in even more pages. You get the idea.

[Wanze]

 One try was also to build a block module, but haven't got the time to

further develop this and it's in a proof of concept alpha stage, only

front-end editing and not backend interface.

I've seen it!

[Soma]

Haha, Wanze is right!

[adamspruijt]

This functionality would be very much like Advanced Custom Fields "Flexible Content" Addon (http://www.advancedcustomfields.com/add-ons/flexible-content-field/). Which is probably at this point the only thing I miss about building WordPress sites. I found that clients found it easy to use and I didn't have issues with clients making a huge mess. It is a controlled system so testing for issues is quite easy.

[ryan]

I think this type of thing would be a very different animal from a repeater. While there are similarities, I think the functionality would be a lot simpler to build as its own thing rather than extending repeaters. Not to mention, I'm not sure I'd want to add that complexity to repeaters either. I can't envision a use for this type of field in the sites that I build for my clients, so I'm not likely to build it. But I can see how others would find it useful, I do agree that the idea is fun and interesting. Here's how I think it could be built without getting too complex:

The Fieldtype itself would basically just be a FieldtypePage and may not need to be anything more. The Inputfield would be where all the action would happen, and I think a lot of it would be JS fun more than PHP code.  When you click "add", the Javascript would append an <iframe> with a "src" attribute pointing to /processwire/page/add/?parent_id=123&modal=1 where "123" represents the predefined parent_id where these pages would go. That "modal=1" in there tells PW's admin to just display the editor and no header/footer, etc., making it perfect for this particular Inputfield. The "add" screen would prompt them for the template, as it already does, and let them add the page there. You could of course restrict the allowed the templates the usual way in the template family settings. 

Some JS would also have to be used to communicate between the <iframes>s and the parent window. Specifically, when the Save button is pressed in the parent window, you'd have JS trigger the save buttons in the other iframes (which you might choose to hide with JS/CSS). Likewise, JS would need to be used from the parent frame to examine the ID of the iframe/repeater items so that it could be saved to the FieldtypePage. 

There wouldn't be any need to add new API level stuff, because I think that what's provided by FieldtypePage already provides what this field would need. 

There would be some other issues to resolve as well, but ultimately the whole thing would be simpler to build than the repeaters if the author is willing to take advantage of iframes.