Greetings from the world of Concrete5

[jordanlev]

Hello,

My name is Jordan Lev, and I've primarily been using Concrete5 for the past 5 years to build websites for clients. I just came across ProcessWire the other day (not sure how I missed it for so long), and it is very impressive and really jibes with the way I think about building sites. I actually have created several Concrete5 plugins that offer functionality similar in spirit to the way one constructs fields and templates in PW, so it was pretty incredible to discover an entire CMS that embodies those principles!

I have been playing around with ProcessWire a little bit, and reading through some forum threads. I'm hoping a project comes my way soon that PW would be a good fit for, so I can actually use it for a real-world website.

For those of you who have never built a site with Concrete5 before, I encourage you to check it out (if for no other reason than to get some ideas on a slightly different model of how a site can be put together). I think what C5 is most well-known for is its front-end editing, but I would say that there is a deeper reason C5 is so well-loved by people like me: it really allows you to "design the editing experience". I think PW is somewhat similar in this regard, although it seems that PW is more about "designing the content structure" (which often overlaps, but not entirely).

I've read some posts by Ryan that indicate he is concerned with separating the definition of the data from the display of it (for example, https://processwire.com/talk/topic/4189-flexibility-in-page-design/#entry41205 ), and that is a fantastic way to think about things (and very refreshing if you've every worked with less modern systems like Wordpress)! But I also think that philosophy is more well-suited to larger sites that have a lot of structured content. The places where I think PW could be made even better than it already is are for the smaller-scale marketing/informational sites, where tying the content and the display more closely together actually makes sense (especially for the non-technical users who have to manage the content as time goes on). For example, I think the much-discussed "file manager"/"media manager" feature is pretty critical to an easy-to-use workflow, and I feel like there are ways it could be done that honor the underlying spirit and simplicity of PW. Also, I think front-end editing is a HUGE win in terms of ease-of-use, and the "Fredi" module seems to offer that functionality (and there are a few minor tweaks I'd love to make that would allow the site editing experience to be even more "designable").

I have seen comments in the forums that are both "pro" and "con" on the things like file manager and front-end editing, and I think the difference in opinion stems from the difference in the kinds of sites people are building (larger, more structured sites that are served better by PW's existing dashboard versus smaller, less-structured sites I think are better-served by a tighter integration with the pages themselves).

What I would love to know is how interested the ProcessWire community is in even attempting to make PW a better fit for these smaller-scale websites. Are people interested in discussing these ideas, and possibly even working towards making them happen? Or is the community primarily concerned with the larger / more structured sites and not interested in rehashing this line of discussion? Or perhaps I'm making some assumptions and generalizations here that aren't true?

I just want to share with you all that some of the things Concrete5 has are incredible (pretty much every client has been blown away at how easy and intuitive things are with Concrete5 when I first show them the sites I've built), and I am interested in understanding more about how to make this happen with ProcessWire, and also sharing my experiences and insights with you all in the hopes that ProcessWire can be more appealing to a wider set of users without sacrificing its underlying simplicity and design philosophy.

So I'll leave it at that, and am looking forward to hearing what people have to say!

Thanks,

Jordan

[owzim]

What I would love to know is how interested the ProcessWire community is in even attempting to make PW a better fit for these smaller-scale websites. Are people interested in discussing these ideas, and possibly even working towards making them happen? Or is the community primarily concerned with the larger / more structured sites and not interested in rehashing this line of discussion? Or perhaps I'm making some assumptions and generalizations here that aren't true?

 

Welcome!

 

You are right, PW is more aimed at complex content structures but by no means limited to that. AFAIK most of Ryan's client sites are huge data behemoths (not meant in a negative way), so the core will never ship with built-in features you're talking about, and nor should they (keeps the core lean and fast), but that's not a disadvantage in any way. PW provides an amazingly flexible and powerful foundation, and that's where modules come in (in fact many of the core features are packed into modules themselves, core modules).

 

Many of the PW users/devs here also use it for small sites, so I think there will always be an interest to serve those well too.

 

There are couple of modules, that focus on small sites. Some that come to mind are those which provide dashboard like UIs, the Blog Profile, or the Blog Module and as you mentioned, Fredi. Also there is a very new InputfieldType, called InputfieldPageTable which essentially gives you huge amount of flexibility when constructing sites with content blocks, like for campaign sites or landing pages.

 

Of course you are welcome to dig into Module development and enhance ProcessWire with those or contribute to existing modules. The API is incredible and you can hook into almost any functionality or process.

 

Cheers!

[apeisa]

Jordan, in a bit hurry, but just wanted to quickly comment: very well said about in what position PW is regarding "heavy content" vs "easy editing". I think the best route will indeed be on building simpler tools to provide different tools on top of core, just like owzim said. I am happy to hear what kind of ideas you have regarding Fredi and making simple sites even easier for editor? Before I build Fredi, I played a lot with "real" live editing. That is easy for text and textareas, but falls short when trying to support all the different field types that PW has - and that is definitely one of the key selling points for PW.

[kongondo]

Welcome to ProcessWire Jordan!

[Pete]

Having had simple sites in other systems, a lot of my clients are actually finding it easy to use Processwire without an interface that holds their hand the whole way.

Aside from making more modules like the blog module to really make it more like other systems (every page type with its own menu item and not navigating the page tree) I'm not sure what could make it much simpler for clients. Once you explain the tree structure to them and give them some simple training they get it.

I think there's a balance to be struck between making things easy to use and dumbing things down too much.

I understand where the blog module fits in though in that it's a more complex beast and there are some killer features in there, bit for the majority of small sites I've not needed anything other than normal templates to get clients up and running with news pages, galleries and event calendars - they're all simple templates to set up.

I've also never needed the image manager type of module. I've not yet come across a project where I've needed to re-sent an image - I suspect when I do it will only be the odd one here and there anyway

I'm not meaning to argue with everything you guys have said above, but point out that I've got by without most of it

I do look forward to each new module that comes out though as unlike certain really huge platforms (WP) they tend to do different things (not a dozen photo galleries for example) and I make a note in my head of one's I think will be useful on certain sites, but for the small sites mentioned in the first post I dint tend to use many modules at all for general stuff like portfolios, galleries, news etc.

[Pete]

Forgot to say hi - Hi Jordan

[Martijn Geerts]

Thanks for the time writing your background Jordan and using ProcessWire.

Welcome Jordan.

[mr-fan]

Hi Jordan,

i've tested out C5, too

but it is not really easy to translate...very hard i thought...

and it's heavy for a shared host to take....even if you use the cache on some hosts the pages are slower...and much more stuff i didn't like.

I used a long time a real simple CMS (same basics like PW Pagetree driven and instead of fieldtypes and templates there where blocks ->like in C5 // but different structur and no more long time devellopment)

A Pagetree is a thing that clients check really fast! And the PageContent could be really created to fit the needs for different aproaches on a page f.e. with fieldsettabs and so on!

i've only small sites running (biggest is 500 pages in g00gle) mostly between 5 and 50 - but i've until now no usecase in my portfolio that i'm not said to meet here and see PW so late

Only thing i didn't checked out/tested is it easy to build frontendforms from PW read a lot in the forum but there is no "out of the box" solution (for bigger forms Formbuilder seems to be the thing)

I'll be very excited to build my first site with PW.

Best Regards mr-fan

[jordanlev]

Hi everyone,

Thank you so much for your comments and your warm welcome to the community!

@apeisa, I think you are referring to the difference between "front-end editing" versus "inline editing" (I read a forum thread about this here for ProcessWire but I cannot find the link now) -- and I agree that true inline editing is very difficult to do, but the way Fredi works now I think is very good (pop up the editing interface in a dialog box). I think it would be nice if there were more options on the $fredi object. One example is if you could set the width and height of the dialog box. Another thing is if you could utilize more complex markup (almost like providing a small template for the fredi "edit" link itself, instead of only being able to customize its text) because then you could do things like put a border around the editable area and make the whole thing "clickable" (which is how Concrete5 does it, and I think it very intuitive because people do not have to search the page for a small "edit" link, and also because it requires less tweaking of the page layout becaue it is just adding a 1- or 2px border as opposed to a new link which could push elements down or sideways on the page). Also, it would be nice if there were a way to change a page from "view mode" to "edit mode" (although I think this is possible if you write your own javascript to show/hide the ".fredi" classes, but would be nice if it were more built-in).

One question I have is about "draft" or "preview" mode on pages. I know that you can create a new page and keep it in a "draft mode" (so it does not yet appear on the live site), but when you make more changes to a page that is already live, is there a way to keep a separate "draft" version of it so that the logged-in user can make some changes and save the page but without publishing those changes to the live site?

Overall I see that the correct way to do things in ProcessWire is by writing modules (as oppoed to adding a lot of features to the core). I think this makes a lot of sense and when I start using PW for real projects I will keep this in mind.

About the "file manager", are there hooks in the PW system that would allow me to add to the Rich Text Editor's "Image Insertion" feature so that instead of listing images on the page, it could list images in a custom "file manager" object I could create in my own module? I really dislike the 2-step process of adding images to another field on the page before you can insert them into a rich text area (but I understand that some people like this, so I am not saying it is bad -- but it is not what I prefer).

Thank you all again, I look forward to discovering more about how ProcessWire works!

   -Jordan

[jordanlev]

And one more question: Can someone explain to me the reasons why fields are created separate from templates? When I create a template, I would think that I could just add any kinds of fields to that template, but that does not seem to be possible -- instead I must go to the "Fields" page and create the fields, which are then available to *all* templates. It seems to me that it might be better to just create fields for a specific template -- because it would be fewer steps and also because it seems "messy" to me that I would have fields that are created for one special template available to all templates. But since PW is such a well-thought-out system I am thinking there must be good reasons behind this decision so I am curious what those are.

Thanks!

[kongondo]

And one more question: Can someone explain to me the reasons why fields are created separate from templates? When I create a template, I would think that I could just add any kinds of fields to that template, but that does not seem to be possible -- instead I must go to the "Fields" page and create the fields, which are then available to *all* templates. It seems to me that it might be better to just create fields for a specific template -- because it would be fewer steps and also because it seems "messy" to me that I would have fields that are created for one special template available to all templates. But since PW is such a well-thought-out system I am thinking there must be good reasons behind this decision so I am curious what those are.

Thanks!

Yes..it is a very well thought-out system ...If fields were only available for a particular template, then they wouldn't be reusable. That would mean creating, e.g. a textfield for template A and a different textfield for template B, etc....a waste of resources . And yes, you can add any sorts of fields to any template as long as you create those fields first. Fields will not automatically be added to any template unless you specify the field as 'Global'

Edited June 4, 2014 by kongondo

[Christophe]

Hello,

Concrete5 and ImpressPages CMS are a bit similar in some aspects.

Processwire is so customizable (html/css frameworks, backend organization/page input fields...). It is nice to developers and nice to users, as far as I know.

[Macrura]

And one more question: Can someone explain to me the reasons why fields are created separate from templates? When I create a template, I would think that I could just add any kinds of fields to that template, but that does not seem to be possible -- instead I must go to the "Fields" page and create the fields, which are then available to *all* templates. It seems to me that it might be better to just create fields for a specific template -- because it would be fewer steps and also because it seems "messy" to me that I would have fields that are created for one special template available to all templates. But since PW is such a well-thought-out system I am thinking there must be good reasons behind this decision so I am curious what those are.

Thanks!

hi jordanlev and welcome.

processwire is so flexible that you could probably emulate all of your favorite features of Concrete5 very simply and quickly, using some custom modules...

I started with Joomla way back in '06 and i probably still retain a couple of concepts that i liked about that system (they might have had 1-2 good ideas); for example i tend to favor building my own navigation system like Joomla does, since i always tend to need a ton of flexibility with menus and i can't deal with being tied to the page tree. likewise there are plenty of wireites who defected from modx but still retain some of the logic of how that system worked, and apply it to their PW workflow;

Recently kongondo released a blog module that is sure to close the argument for any remote reason to mention wordprass*...

I started helping a couple of clients build shopify sites, and after using that system, looking at their templating language and seeing the backend management, i was surprised because i thought it would be more advanced; a simple example is with PW's image handling, which in itself saves huge amounts of time; with most other systems you have to resize the images prior to loading them into the cms.. but of course the thought immediately occurred to me about how easy it would be to 'build' a clone of shopify with PW, maybe using the shop module and a custom admin theme...

so i really appreciate you explaining the pros/cons of Concrete5, and what innovations, workflow benefits etc that it uses... and i think some people here on the forum will probably come up with suggestions for how to implement those things with PW;

i think you'll discover that because the way PW is structured, you can typically accomplish the same thing in PW in about 1/10 to 1/20 the code. (I know this for a fact as i have converted a couple of really complex wordpress themes to PW and the code trash was quite significant)..

*spelling attributed to willyC

[jordanlev]

...If fields were only available for a particular template, then they wouldn't be reusable. That would mean creating, e.g. a textfield for template A and a different textfield for template B, etc....a waste of resources

Is it really that big of a waste, since you're only re-using the *definition* of the field across templates (which I can't imagine takes up a lot of space in the database)? The data that goes into the fields is on a per-page basis, so I guess I don't really see why it's better to create the fields and then add them to the template as 2 separate steps, as opposed to just saying "this template should have a field of type X". Is there some other feature of the system that benefits from sharing field definitions across templates?

Thank you.

[Martijn Geerts]

$pages->find("title=yes");

Can return multiple pages with different templates.

---

vehicles
   |
   +-- honda cr-v (template:cars, fields: • color:yellow/amount_wheels:4)
   |
   +-- honda gold wing (template:moters, fields: • color:yellow/amount_wheels:2)
   

Here you can search all vehicles with the color yellow for example

For every found page you know what vehicle it is from the template

$pages->find(parent.name=vehicles, amount_wheels=2);

will return 'honda gold wing' page with the motors template

Edited June 5, 2014 by Martijn Geerts

[jordanlev]

$pages->find("title=yes");

Can return multiple pages with different templates.

---

vehicles
   |
   +-- honda cr-v (cars template, fields: yellow/amount wheels)
   |
   +-- honda gold wing (moters template, fields: yellow/amount wheels)
   

Here you can search all vehicles with the color yellow for eaxample

For every found page you know what vehicle it is from the template

Ahh, I see... that does make some sense. I think this kind of feature is related to "content structuring", which seems to be ProcessWire's strength, as opposed to "loose content areas primarily intended for display" which is how I think of things coming from the Concrete5 world

Thanks,

Jordan

[Martijn Geerts]

ProcessWire is highly structural. 

here's a Pagelist, with accessories

accessories template:accessories
  |
  +- wheel ( template:part )
  |
  +- chair ( template:part  )

If the accessories templates only allows children with the template of part, you can show all parts by looping all children of accessories.

[thetuningspoon]

Is it really that big of a waste, since you're only re-using the *definition* of the field across templates (which I can't imagine takes up a lot of space in the database)? The data that goes into the fields is on a per-page basis, so I guess I don't really see why it's better to create the fields and then add them to the template as 2 separate steps, as opposed to just saying "this template should have a field of type X". Is there some other feature of the system that benefits from sharing field definitions across templates?

Thank you.

Each field actually has its own table in the database, so when you create a field, it is unique. Which is important because each field can be customized significantly with various options. As was mentioned, this also allows us to use the same field on multiple templates and query based on the content or existence of that field.

I do sometimes wish that I could create multiple copies of any given field on a template and just modify the name without having to create a whole new field for it, but there might be trade-offs to something like that.

In terms of the UI, you can now create a new field from within the template editor screen, though.

[qtguru]

@Jordan am surprised how i never came across Concrete5 it has something I have been looking for the concept of MVC and frontend editing. I would probably look more into this and try it out for a Project. This really appeals to Developer namescapes,Form Object and all.

Am gonna give it a spin we are evaluating something in our office, all our developers love using MVC-ish (anything related to MVC) to code. 

Thanks also

[triples]

Hi,

I'm still learning about PW but I have had a little experience of Concrete5. Whilst I liked C5's editability and readiness of templates/themes, I found many Concrete5 sites were invariably slow (and sometimes very slow) to load....  something which Google doesn't like, so it was fairwell C5. 

I now have to figure out front end development to get a PW site up and running as I am not a developer (Joss has been my inspiration here), but the example PW sites all load quickly.

Regards.

[qtguru]

Hi,

I'm still learning about PW but I have had a little experience of Concrete5. Whilst I liked C5's editability and readiness of templates/themes, I found many Concrete5 sites were invariably slow (and sometimes very slow) to load....  something which Google doesn't like, so it was fairwell C5. 

I now have to figure out front end development to get a PW site up and running as I am not a developer (Joss has been my inspiration here), but the example PW sites all load quickly.

Regards.

am not a C5 user but it depends where the sites slow due to heavy resources e.g images,css,assets or slow as a result of bottleneck from C5, I intend to pitch CS to my company to manage the website for the organization because the Frontend Editing is a good option for us, and also PW for our documentation page, we don't want to be called to manage contents its very depressing and boring for us. 

Did you explore any Caching Solution for C5 ? 

[triples]

Hi Sephiroth,

Did you explore any Caching Solution for C5 ? 

No, but I noticed it across many of the live site examples that C5 posters had shared (nb, this was a while ago).

I have just revisited the C5 website and found the 'site showcase' link (it's in the footer). To be fair, sites are loading faster than when I was looking. What was odd about the site showcase as the lastest new entries were from early/mid 2013.

I'm still not convinced by C5 but it's still there and it has some big names using it.

Cheers

[jordanlev]

@triples, I run a lot of C5 sites, and have no problems with speed on version 5.6.x. I believe that version 5.5.x had some issues with caching, but they seem to have been resolved with the 5.6. release. I haven't yet tried the newest version (5.7) because it has some usability issues that need to be worked out, and I've also heard reports that the speed isn't there yet.

So, I'd say the 5.6 version of C5 is just as fast as any CMS I've used.

Of course, any system can be made to run faster or slower depending on how you use it. For example, I built an eCommerce site with ProcessWire a few months ago, and I went along with the common advice here that everything should be treated as a "page"... each customer is a "page", each order is a "page", each product is a "page", each invoice line item is a "page" (none of these pages are displayed on the front-end, but in terms of data architecture that is how I have it set up). This turned out to be a very bad decision because of the fact that every field is actually its own table in the database, it makes reporting abysmal. I had to deconstruct the PW query builder and come up with my own SQL query to get any kind of reasonable performance on the "order reports" page... and it is like 20 JOINs in one query. The code is now not very easy to understand which is going to make maintenance more challenging then if I had built out a normal schema with normal database tables/records (instead of trying to shoehorn my data model into PW's "everything is fields+templates+pages" system).

I don't mean to bash ProcessWire... but my point is that any system can be made to run faster or slower depending on if you're using it for the things it was designed for or not (and if you do things efficiently or not). Comparing one system's demo site to another system's real-world buildout is not a fair comparison.

All in all, I'd say that ProcessWire's strong points are definitely its consistent and well-thought-out API, and its incredibly clean templating. But the editing interface is very clunky (although I know this is a matter of subjective opinion) and if you don't want "everything to be a page" then all the built-in field functionality isn't very easy to use in other contexts.

Best,

Jordan

[qtguru]

It's why i asked what caching solution was implemented even a good system can be bottle-necked by bad code. Am really liking Concrete 5 its a proper MVC system which is something i'd like. Also as much as i love Processwire I don't think I would ever use it as a replacement for eCommerce but for anything else Hell yeah there's systems like Prestashop.

Thanks Jordan 

[Beluga]

It's why i asked what caching solution was implemented even a good system can be bottle-necked by bad code. Am really liking Concrete 5 its a proper MVC system which is something i'd like. Also as much as i love Processwire I don't think I would ever use it as a replacement for eCommerce but for anything else Hell yeah there's systems like Prestashop.

Prestashop will soon even have a secure password hashing method: https://github.com/PrestaShop/PrestaShop/pull/1957#issuecomment-93427902

It only took them 8 years. Actually that PR was even from a community member..