Client's request which Processwire can't fullfill currently

[titanium]

Processwire a very efficient CRUD tool with a strong API, but there is the "one" thing which my clients are requesting: They would like to build pages which don't fit in the somewhat rigid grid the developer defines: They would like to build pages which are made of an collection of building blocks (some examples: a Google map; a picture gallery; a pic with lightbox functionality on the left with text floating on the right and so on).

The blocks can (and should) be defined by the developer in advance, but the clients/editors would like to combine them as they wish. The nearest close answer Processwire delivers to this request is the "Page" field. The pages can be build with that, but it's not very user-friendly: The editor has first to set up each of the child pages, and after that he returns to the page with the page field (I call it "master page") and adds the child pages one by one to the page field. If the master page is viewed, it renders the child blocks quite nicely - but the whole process of content editing takes just too long and it doesn't feel comfortable.

I have watched out here in the forum for similar requests (there are a few), but unfortunately, no concrete solutions yet. Is there anything in the pipeline to fullfill these kind of needs?

[adamspruijt]

I think it would definitely be doable, a "flexible" content fieldtype of sorts. It's something I've wanted to have pretty badly since switching from WordPress (using Advanced Custom Fields plugin w/ the Flexible Content Field addon) to processwire.

[yellowled]

Although I know and sort of understand the wish of clients to be able to do so, from a designer's/developer's point of view, these “free form” content types are not necessarily a good choice. (Disclaimer: This might be a very subjective point of view, and yes, I admit to being kind of a control freak.)

I don't know what kinds of clients you guys have, but a lot of my projects are websites for people who don't really know much about building web sites. Those clients can actually benefit from a “rigid” approach because it does not only limit their possibilities, it also limits their margin for error, bad layout choices and basically anything which makes designers pull out their hair, as arrogant as that may sound.

Then again, as long as this is implemented as a module or an option, keeping the flexibility we all love about PW, this probably is a “why not?” feature.  (Just my 2 cents.)

[arjen]

Why do "the clients/editors would like to combine them as they wish"? In my experience this is mostly a type of "I need to control" things. There are some exceptions but usually this doesn't benefit the reality (or goal) of a page. Offcourse, regular content like bodytext or images need to be controlled, but in my opinion every type of page has a goal. A designer (UI, UX or visual) determines (offcourse in cooperation with the client) what that goal is. Most of those goals I can be held accountable for since I'm designing or proposing a design to a client. When you give an editor options to create pages as they wish I've seen two scenarios happen:

1. They hardly ever use it (The client is not to blame since they are focussed on other things like running their business)

2. They overuse it (The client is not to blame since they want it "all" and we need to decide what is really important - the goal)

It's both a maintance (from client perspective) and a user (the visitor of the site) issue. I always try to make this as clear as I can. That said I realize some content blocks can come in handy but I hardly ever see a proper use of using content blocks/widgets (like WordPress). As always you should test this in reallife scenarios/use cases, but from my experience I've learned that this is hardly ever really needed. I think you should talk about using content dynamically — where ProcessWire is really awesome.

[teppo]

The blocks can (and should) be defined by the developer in advance, but the clients/editors would like to combine them as they wish. The nearest close answer Processwire delivers to this request is the "Page" field. The pages can be build with that, but it's not very user-friendly: The editor has first to set up each of the child pages, and after that he returns to the page with the page field (I call it "master page") and adds the child pages one by one to the page field. If the master page is viewed, it renders the child blocks quite nicely - but the whole process of content editing takes just too long and it doesn't feel comfortable.

You could achieve pretty interesting results by taking this idea a bit further:

• Define areas on front-end where new elements (widgets, nodes, blocks, whatever) can be dropped and create new page fields for each of them,
• set up a collection of pre-defined blocks (templates, including proper template files for this purpose) you want users to be able to drop in,
• create a clean way to add new pages / edit existing ones via front-end (edit/add button, something like Fredi),
• store newly created pages somewhere and attach them to page field on current page automatically.

Preferably you would also let the client re-arrange these blocks by dragging on the front-end side, to make it all function properly. Perhaps even drag blocks from one area / column (page field) to another?

That's all very much doable, though I would imagine that it could take quite some time to work all the details out (such as where to store those pages to keep things smooth and stuff like that.)

I'm definitely not advocating anything like this, based on similar reasons others have stated above (such as the fact that pages created this way usually end up unbelievably messy in the long run and no longer serve any real purpose, other than perhaps making some content editor very proud of herself) -- just saying that ProcessWire can be used for it if it's what makes you happy.

If you're into it, why don't you give it a try yourself? See where it takes you and ask if you need any advice

1. They hardly ever use it (The client is not to blame since they are focussed on other things like running their business)

2. They overuse it (The client is not to blame since they want it "all" and we need to decide what is really important - the goal)

Been there, seen both of those happen more than I'd like to remember.

For a very long time I believed this to be "the best way" (partly because it worked for us and made our clients very happy), but after listening and seeing all those problems it caused for our clients at the same time, I've come to one conclusion: this model is in reality one of the worst enemies of properly structured, usable and logical web content.

It requires serious mental fortitude to keep things in order when you've got all the tools you could ever ask for right within your grasp. This is true especially in the long run.. and especially when there are multitude of editors to deal with. Ever been asked to re-organize a ten year old site for a client, one that's seen hordes of editors, various shifts in content strategy etc.? Not a trivial task and each and every page having a very different structure doesn't really help.

It's rare for there to be someone who could keep it all under control either -- that kind of thing is too often limited to huge organizations only and even then resources tend to be scarce.

From my point of view the most obvious (even if still only partial) solution for this is a clearly defined structure that editors must stick with, even if it doesn't please them at all times -- which is exactly what ProcessWire provides tools for. Clients may not "get it" at first, but that's why we as designers, developers and professionals should explain and teach them why this is a good thing.

I rest my case.

[SiNNuT]

One simple approach could be to code up some Shortcodes for them to use inside a textarea. This way the developer can control the functionality and the client can insert and position stuff with relative ease. The developer should write some clear instructions to go along. Of course, this has it's limitations but if done correctly this can be pretty powerful.

<fieldbodytext>

  <p>some text>

  [myGallery] // it could use pics attached to a page image field

  <p>some more text</p>

  

// embed a video using mods.pw/D <p>some more text</p>

[myLatestNewsListing] <p>etc.</p> </fieldbodytext>

[titanium]

Thanks to all who participate in this discussion and your point of views. I do clearly understand the good arguments of getting in control of how content is structured and presented - we are definitely of the same opinion! For example, using TinyMce is a nightmare for me (and in the long run) for editors too, because it's results are often unpredictable and not maintainable. I want to get rid of such an RTE concept, because that's not what structured HTML is for in principle.

On the other hand, take a look at content heavy websites like a newspaper website, for instance. The content areas of these sites are mostly build up of a headline, an introductory text, an image (or an image gallery), a voting, some links... These block elements are limited (good to control, just a hand full of structured code, read: some templates), but it's up to the editor where the voting part or the image gallery is placed. It's part of _his_ creative process. It's not up to me to say: "wait, image galleries always belong to the bottom of the page!". No - it belongs where it best fits, mostly at that place where the according (con)text is placed. An editor may have good reasons why he might use two votings instead of one, followed by an image gallery and some text in between. I can't predict all these nearly infinite combinations and make a template for each of these. Think of "Lego" (oh god, I loved that stuff so much as a child - the elements are limited and easy to control (counted/changed/updated/deleted whatever Processwire does best), but the possibilities are unlimited!

What I'm voting for is basically nothing more than a page field, which has the possibility not only to select an existing page, but to create a new page also. This function already exists, but it does only work if the parent template of the "new-to-create" child page is firmly set. That would shorten the process of creating these child pages, the editor wouldn't have to leave the page he is currently working on.

Another approach would be a repeater, which has the possibility to select a different template for each row.

All in all, please don't understand me wrong - I don't want to turn Processwire into a messy pile. I would like to optimize the backend usefulness at some corners. Some of you said "it's doable" and you have great conceptual ideas, I would wish that I have the coding skills to bring them to life.

[arjen]

Thanks for responding titanium. I know you don't want to turn ProcessWire into a messy pile - you wouldn't be here otherwise I agree that an editor should have an option to place certain stuff like galleries and I think the approach of SiNNuT is really fine. It keeps most logic out of the editors reach. In my opinion the line is really thin and often pandoras box is opened. That's why I think newspaper sites are really difficult to design. But I've seen cases where this type of content will work for an editor. It comes down to the project and the client.

[onjegolders]

I agree with what others have.

You could certainly combine repeater boxes with shortcodes and that way you'd have the ability to drag and drop them to reorder on the page.

Alternatively you could create different templates which the client could select for each page.

news1.php (links at top)

news2.php (links at bottom)

news3.php (no links)

I'm sure someone could come up with a clean way to incorporate this into PW but I have doubts as to if anyone will due to their reservations about the idea. I'd love to see Nico's shortcodes module more extensively as I think it has huge potential (probably the best thing about WP).

If not perhaps look at something like Concrete5 which uses this way of thinking though I'm sure you can achieve what you want with PW.

[bfncs]

Hi there, very interesting discussion with good arguments going on here.

I think while all the possible solutions pointed out already will work, what this kind of content editing really needs to be user-friendly is be a nice editor. I imagine something like the usual WYSIWYG editors that has an added area with predefined drag-and-drop content blocks. You can then drag each one at a place in your existing content where it's content (and look) is editable. Probably this is done most easily with a grid-based approach. The hard part of this would be building the editor then, integrating it into Processwire should be quite easy.

I would be really glad if this kind of thing exists, because it might come in handy at some point, i.e. for custom marketing landing pages.