Flexibility in page design

[roderigo]

Would tHis could be good way to manage online menu for my restauranto Roderigo Kitchen? Maryla always yell we need online menu we need online menu now customer want to order online and pick up but many customer want pick up Marya she must know. I want customer to come to Roderigo Kitchen for food but  want to keep customer happy but Maryla pastor Goodwin say no breast for customer anymore so business need online menu. I  say we give customer special surprise after they yelp.com reviews for Roderigo Kitchen. Seem to me this flexibillie page design sound like let me you build menu no? Would cemente5 software be to look at well?

[Macrura]

@roderigo, maybe this might help you?: http://www.edcinteractive.com/

[renobird]

Maryla pastor Goodwin say no breast for customer anymore so business need online menu

I can't. I don't. I'm crying.

[teppo]

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.

Whether repeater or not, this sounds just like the solution we've been missing.

I'm always worried about giving editors too much freedom, as I've seen how that often leads into bloated sites with very little structure (and eventually it's all so messed up that starting over from scratch is only solution), but by maintaining the control of what can be inserted and where this sounds like a very good compromise between giving the user enough freedom while still not letting her create a mess.

Just for the record: I'm not too interested in small "campaign style" sites consisting of couple of pages, where any kind of mess is still controllable. Sites I'm worried about are those with hundreds, thousands, or even tens of thousands of pages. That's when things can very easily get out of control unless proper constraints are in place.

PS. Reading that post made me spill coffee all over my laptop. Not sure if that's a sign of me being totally excited about this or simply a reminder to avoid any and all activities requiring hand-eye coordination before actually having that first cup of morning coffee.

[ryan]

but by maintaining the control of what can be inserted and wherethis sounds like a very good compromise between giving the user enough freedom while still not letting her create a mess.

This is why I always configure the settings on the "family" tab of each template before delivery, at least for sites that will ultimately be managed by a client. Presumably these same settings would be applicable for a Fieldtype/Inputfield module that pursues this multi-template repeater strategy. 

Sites I'm worried about are those with hundreds, thousands, or even tens of thousands of pages. That's when things can very easily get out of control unless proper constraints are in place.

This was always one of my concerns with repeaters in the first place. It might be a bigger concern with a multi-template repeater. I don't see 1-screen page editors as something that should be scalable like this, at least not too far in quantity. Whereas the page tree is, and should be. Though at some point I would like to introduce pagination into repeaters for the admin UI, but a little worried that might encourage more bad repeater behavior. I do like repeaters, but it does seem like they get used for more things than they should, at least based on questions that have sometimes popped up in the forums. They introduce ambiguity into how to solve a particular problem. Before repeaters, it was always easy to answer how to solve any problem: use pages. After repeaters, the answers aren't as easy. Though for the places that repeaters are the right answer, they are a nice time saver. But I rarely find a use for them in my own projects. 

Shifting gears back to append ideas to my previous message, and maybe thinking of something different: one idea could be to have a checkbox on each template that says "Children tab shows: 1) links to child pages; 2) editors to child pages". If they select "2" then the children tab would show those iframe editors to each child page in a repeater-like format, and an add button, like mentioned in my previous post. It would show that rather than a PageList. An option for pagination would be a must have though. 

[owzim]

Has anyone fiddled around with one of Ryan's suggestions yet?

[Soma]

Coming back to this. As mentioned I'm hard thinking a brewing something since a long time, just haven't been able to pull it off yet. It's often good to wait and sometimes it just makes click, also growing with PW and it's ability can make a big difference. Yes even I am still learning,

I got something I think would be a good way to build flexible content blocks, it's just not that far yet to really release it.

What Ryan has proposed with iframes sound good in theory but I think would be not a good option at all. It could work but I'm not excited about it because of scalability in the admin, scrolling etc and it would be more of a mad hack with JS IMHO.

But the idea with using a page field made sense to me and I was thinking a lot about how to bring the concept I have to the admin, so you can add and edit "blocks" on the page. Until now I only got a really rough proof of concept and was working on front-end only, and not at all complete so you could add blocks etc (I created them manually)

After some more testing and coding: So far this is how I got it setup/working: (much like repeaters work)

- you create templates for the blocks (partials kinda)

- you create a template for the parent page of the blocks in the admin, where you also use family settings to restrict children template to the block templates you create

Backend

- the module creates a custom page field using the input ASM select multiple, you then add to templates you want to have those blocks

- the module sets up a parent page in the admin branch for the page you create with this field

- the module hooks into the ASM select to add a "+ Add new block", with a click you open a modal where you have the add page screen and template select. Once create you close the modal and the ASM select will have that new option added. You can sort them as usual

- the module enables the editlink modal for the selected blocks (much like selected fields on template context)

Front-end

- the module uses Fredi and it's own script and markup you can use to render the blocks (simply: echo $blocks->render()

- the partial templates are located in a subfolder /blocks where you script the output same as you would with a normal template

- the blocks have a little toolbar you can move blocks up and down (saved on the fly via ajax), and a Fredi edit link that lets you open and edit the block in a modal

- the idea is that you also could also output the blocks manually

As said this is all still rough and slowly taking shape, and many details still need to be taken care of, but just wanted to mention.

I think a alpha/beta testing is possible very soon but don't want to make it public until it's more marinated and stable. Also if somebody interested in helping out drop me a message.

[arjen]

I would love to help out and I have some spare time to test until end of this month.

[owzim]

soma, thanks that you took the time and effort to dig deeper into this. Sounds great. I'll glady help with testing too.

[Soma]

For those interested for now, I created a github repo along with some description how to install and use it:

https://github.com/somatonic/BlocksContent

Thanks

[Soma]

Just wanted to mention, I made first little update to show the select dropdown again (was set hidden with JS before) just for now. I made last minute changes and haven't really thought about it, that I just had a case where the block was lost and I couldn't reselect it.

Updated readme with some additional infos.

That being said, consider current state early alpha and a start to get a feeling if this would work out all well. Still many details that need to be addressed.

Thanks

[owzim]

soma, some great progress so far, thanks.

Had some initial problems setting everything up, but I recommend everyone reading the readme on github carefully =)

_____________________________

Tested this:

two block templates:

block_person.php (title, body, email)
block_gallery.php (title, images)

added new block_galley via "Add new block"
appears as new sortable item and appears in input-select (greyed out)

added new block_person via "Add new block"
appears as new sortable item and appears in input-select (greyed out)

everything fine, also the block rendering on front end works as expected

_____________________________

I initially had the following problem (could not reproduce it again yet):

after saving the container page, both blocks disappeared and went back into the input-select

I had to do the following a couple of times:
selecting them form input-select (and therefore adding them as items in the ASM list) and saving the container page
then one of the items disappeared completely (out of ASM AND input-select)
 

_____________________________

I don't know what your roadmap is so I wrote what comes to mind:

Do you plan on implementing the blocks "inline" like in the repeater field or will you stick with the ASM select?

The modal when creating (custom by module?) is different from the one when editing (default by PW)

Had an error on a different fresh install. Haven't dug deeper into it, since I got it working on another install. May be some faulty setup.
It comes up on page edit when pages have that pwbc_blocks_select assigned:

Error: Call to a member function children() on a non-object (line 2 of /pwtesting/wire/modules/Inputfield/InputfieldPage/InputfieldPage.module(155) : eval()'d code) 

Why prefixing the blocks with block_ when they reside in a directory called blocks already?

[Soma]

owzim, thanks having a look and testing.

I initially had the following problem (could not reproduce it again yet):

after saving the container page, both blocks disappeared and went back into the input-select

I had to do the following a couple of times:
selecting them form input-select (and therefore adding them as items in the ASM list) and saving the container page
then one of the items disappeared completely (out of ASM AND input-select)

I don't really know, as saving the page doesn't remove or modify the ASM list, just delete blocks that aren't selected anymore. The dropdown isn't actually meant to be displayed anyway.

Do you plan on implementing the blocks "inline" like in the repeater field or will you stick with the ASM select?

I have no plans to do so. 

I used the ASM select for now as it provides some simple setup and allows for an edit link to the selected items. I found it has some issues using it that way as I'm bound to what it can do or how it does it. I think the ideal way will be to create a new page field widget (like autocomplete does too) so we have full control over the functionality, and are free to create the list item as it would fit. Also to distinct them from ASM and other page field selects.

The modal when creating (custom by module?) is different from the one when editing (default by PW)

Actually there's now 3 different modals/lightboxes. ASM select edit feature has jquery ui modal, creating blocks has a fancybox modal, frontend uses Fredi modal. Again this is meant to get it working quickly and I think it comes down to what I said above to use one and the same for all, but not sure yet as PW will soon drop fancybox as it's stoneage (1.2.6) and also won't work with jquery > 1.8.

Had an error on a different fresh install. Haven't dug deeper into it, since I got it working on another install. May be some faulty setup.
It comes up on page edit when pages have that pwbc_blocks_select assigned:

I think I know where that error comes from (page select field custom code) but it doesn't show for me.

Can you change the custom php code in pwbc_blocks_select to following and see if it solves it?

$parent = $page->blocks_parent;
if(!$parent->numChildren()) return;
return $parent->children('include=all');

Why prefixing the blocks with block_ when they reside in a directory called blocks already?

I'm not sure I understand. The prefix is the most simple way for the module to recognize the block templates. It has nothing to do with where the template file is located. The module needs to know them so it can change the template filename on runtime so we it can simply call render on the block pages.

BTW by "helping out", I actually meant "coding" not testing But testing is also appreciated and needed.

Thanks

[Soma]

I'm currently looking into Field dependencies and Repeaters.

I made it work with using dependencies inside repeaters modifiying the showIf data attribute added to fieldsets to inject the repeater page suffix _repeater[PID].

This means we could use repeaters to simulate different kind of blocks using fieldsets inside repeaters along with a select where you can choose the type of fieldset you want to enter.

I made a short test and it works great.

Example:

Repeater:

   Select Type (page field single select) 1203, 1204

   Image-Text (fieldset with text, image field) only show if Select Type = 1203

   Video-Block (fieldset with text and video url) only show if Select Type = 1204

   

Now I can set the fieldset visibility to show only if the select has a certain value, means you can swop the fieldsets.

I'm not sure about scaleability, since the repeater has it's limits. But I think if you keep it tight with fieldsets and fields and only use a couple (maybe 5-10 types) this could be used to have blocks you can add and edit inline.

What you guys think? 

[titanium]

Soma, I tried the Blocks module from github - it will be a great value to ProcessWire once it is ready for prime time! Thank you so much for taking your time for this. I'm sure it will be greatly appreciated.

I think that the editor normally likes to see what he/she gets, therefore the repeater inline approach makes sense to me. This Blocks module can be of great use in cases in which we would normally use a rich text editor with all it's shortcomings. We as developers will gain better control of what can be entered: no more unpredictable image placing in TinyMce or ckEditor - great!

I fear my programming skills are not good enough to be of any coding help, but I'm glad if I can help out with testing.

[Soma]

Thanks for the feedback.

Yes I get that users like to see what they get, but you get it when viewing/editing the blocks (click on asm list label name) and on front-end when go preview the page (unpublished pages are viewable by editors). I think it would a small price to pay for blocks in a scalable manner, easy to deal with and sort them. And as said front-end editing is something that should be considered a lot since PW makes it so easy and clients usually like it.

I have also mixed feelings and am somehow aware of drawbacks and issues to could lead to. Also misuse of this, either by the developer or by the user. At the end it all comes down to what do you need to solve with this? And does this lead to bad websites/Use of it (I think most of times yes!)

Currently I see it like this:

My module

pros 

- minimal easy setup

- scaleability

- reuse fields and blocks (would requires some complex config setup but possible)

- blocks are pages

- can use repeaters

...

cons

- no direct inline editing (if a concern at all)

- don't see a way to search via simple API selectors (would require special workarounds, a lot of work)

- not easy to limit and reuse things, a lot of work would need to be put in module (grows complexity)

...

Using repeaters with conditionals (if supported by PW at some point)

pros

- easily create different repeaters with different types

- inline editing

- able to use in simple search API selectors (repeater.field)

- repeaters are pages

...

cons

- doesn't scale as good

- some larger setup required

- not able to reuse fields and sets created in a repeater

- dependency on repeaters

- can't use repeaters (inside repeaters)

...

and not to leave out already possible approach

Using child pages

pros

- straight forward adding them, almost no setup

- preview and editing easy possible on front-end

- no dependency

- reuse fields, template, and content

- they are pages

...

cons

- no inline editing, different approach (but clients usually get this easily)

- could interfere with other child pages (although this can be solved if you put them in a global branch and append them using page selects)

- needs workaround for searches using API (but easier as they're direct childs)

... somehow

After all I'm looking also further and question things like: what about future major features PW maybe introduce and support in future? Import-Export, versioning, drafts etc. Ever thought of that?

Currently I don't know where all this leads us. As said this current module only shows a proof of concept and it maybe one possible to further develop. But first I want to make sure it would be the way to go. I think to use pages in some or other way is a good way to go as you benefit from all features a page can have with all it's API, without relying on a new proprietary system.

So this is maybe more what's behind it and more technical, but I think I would love to hear other developers to look and think about this.

[apeisa]

I think cleanest solution would be different kind of RTE. Something that all the big newsletter softwares are doing (mad mimi, mailchimp etc). Pity that there ain't any of those open sourced. I also think it could produce straight HTML and be somewhat drop-in replacement for current editors, keeping the metadata inside data-attributes or classes.

But I have had less and less need for this kind of stuff, and I believe in future even less. PW and future is more and more about content management for multiple platforms (mobile web & applications, computers, television, consoles...) and there "layout building" is something that each medium does, not the CMS.

[owzim]

Had an error on a different fresh install. Haven't dug deeper into it, since I got it working on another install. May be some faulty setup.

It comes up on page edit when pages have that pwbc_blocks_select assigned:

I think I know where that error comes from (page select field custom code) but it doesn't show for me.

Can you change the custom php code in pwbc_blocks_select to following and see if it solves it?

$parent = $page->blocks_parent;
if(!$parent->numChildren()) return;
return $parent->children('include=all');

That fixed it!

[owzim]

Fiddled around a bit more.

1.

When not logged in the blocks don't get rendered, this small hack fixed it:

foreach ($this->blocks as $b) {
    // if($b->viewable()) $out .= $b->render();
    $out .= $b->render();
}

So the blocks seem not to be viewable.

I checked, they are neither hidden nor unpublished.

2.

When deleting a block from the ASM list via the trashcan icon, it goes back into the input-select (expected behaviour).

But when saving or leaving the page edit, it also disappears from the input-select, where does it go?

3.

When creating a new page with the pwbc_blocks_select, after hitting save, this comes up:

Error: Call to a member function children() on a non-object (line 78 of /pwtesting/site/modules/BlocksContent/BlocksContent.module) 

[apeisa]

But I have had less and less need for this kind of stuff, and I believe in future even less. PW and future is more and more about content management for multiple platforms (mobile web & applications, computers, television, consoles...) and there "layout building" is something that each medium does, not the CMS.

Here is very well articulated article about this very same issue. Recommended reading for everyone: http://www.markboulton.co.uk/journal/wysiwtfftwomg (WYSIWTFFTWOMG! - Mark Boulton).

[uliverse]

Here is very well articulated article about this very same issue. Recommended reading for everyone: http://www.markboulton.co.uk/journal/wysiwtfftwomg (WYSIWTFFTWOMG! - Mark Boulton).

Interesting read, I think that is well expressed. That's why it is even more important to "force" the non-technical users to build semantic content rather than only "nice to look at" content. That could be achieved by providing blocks (or whatever) that produce clean markup in the background.

So far I have never seen a CMS that has really gone all the length in that respect. For text heavy sites/pages styling via template might work well, but it does not work for campaign websites. Those tend to not only consist of a bunch of <p>'s <h1>'s and a few <ul>'s – because they DO have to look good and not just convey information that can be automatically styled. So you are left with either a lot of manual coding work or terrible markup.

I agree with the author – it's time to re-think how CMSs work with content layout. Even though the web has dramatically changed over the past 10 years, the way content is put into most CMS (at least the ones I know) basically has not changed at all and is still inspired by word processors. Maybe a CMS is just not the right tool to build a certain kind of website – but we just use them for lack of better options and try to force something in there that shouldn't be there at all. The more creative and individual the design the less automatic processing is possible (because you need the human factor for creativity). That's where animals like Mailchimp and Weebly and other web builders fit in. But I am not aware of any serious open source CMS that takes such a drag and drop approach.

But we are actually mixing two discussions here. Maybe this threat should be split into the extension that Soma is working on and the fundamental discussion about content layout and styling in the CMS of the future...

[Soma]

Fiddled around a bit more.

1.

When not logged in the blocks don't get rendered, this small hack fixed it:

foreach ($this->blocks as $b) {
    // if($b->viewable()) $out .= $b->render();
    $out .= $b->render();
}

So the blocks seem not to be viewable.

I checked, they are neither hidden nor unpublished.

2.

When deleting a block from the ASM list via the trashcan icon, it goes back into the input-select (expected behaviour).

But when saving or leaving the page edit, it also disappears from the input-select, where does it go?

3.

When creating a new page with the pwbc_blocks_select, after hitting save, this comes up:

Error: Call to a member function children() on a non-object (line 78 of /pwtesting/site/modules/BlocksContent/BlocksContent.module) 

1. The blocks are saved in admin branch. I had it in the root a while and that's why you get the behavior as it's not viewable if they're in the admin.

2. As said in the readme, the blocks get deleted when you delete them

3. There's possibly a check missing (As with the page field php code.), I think I've already taken care in my version. 

[owzim]

Here is very well articulated article about this very same issue. Recommended reading for everyone: http://www.markboulton.co.uk/journal/wysiwtfftwomg (WYSIWTFFTWOMG! - Mark Boulton).

I did not read the article but I guess it states how horribly wysiwyg editors screw up page designs, by code and in a visual way (because clients get too "creative").

That's exactly why this thread was created and there is some interest in it. To give the client a guide, within specific constraints (created by the designer/dev) to layout the page. If this goes well, a wysiwyg is not even necessary anymore. So it actually solves the problem you might see.

[Soma]

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

[diogo]

Soma, I was also going to post about this

It looks interesting although creating content still doesn't feel very smooth. There is one thing though that I've been thinking for some time, why do people think that Json and Markdown are more semantic than HTML? To me it doesn't make any sense... Is ** more semantic than <strong>? Is Json more semantic than XML? Isn't HTML an XML way of organizing written content? HTML has come such a long way that I tend to think that it is the most efficient and semantic way of storing written content, I even wish that books would be written with it, and word processors and DTP tools would use it by default, an I would love to see better and more efficient HTML parsers coming up. Well, just a thought...