Re: Thoughts on CMS packages

[selfthinker]

The original link now leads to a 404 error page. It has been moved here: http://www.friendlyskies.net/notebook/thoughts-on-cms-packages-july-2011

I have also written a blog post about 3 weeks ago about trying to find my way through the CMS jungle. And ProcessWire is one of my seven winners.

See http://blog.selfthinker.org/2011/10/21/in-search-of-a-good-cms/

[ryan]

Thanks for including ProcessWire in your review Selfthinker. I'm glad that it made your top 7!  I was confused a couple points though:

Its templating and editing concept is similar to Drupal’s: Templates are populated with the help of fields. And the values of those fields are used in the templates.

I appreciate the comparison to Drupal, as I have a lot of respect for Drupal. I want to mention that, at least from my perspective, ProcessWire's template concept is the opposite of Drupal's. Drupal is a markup generator with predefined template files that act as containers for markup generated by numerous other modules. You can think of Drupal's template approach as more of a theme system where you are directing where things should go, rather than actually creating them. And those things aren't necessarily fields, but markup from other modules. You don't have full markup control in any straightforward fashion. This is a plus or a minus, depending on your philosophy and needs. It's a plus in that one can make a lot of presumptions about the output and thus make it themeable. It's a minus in that you have far less control over your output.

ProcessWire is built to take the opposite approach. It has no predefined templates and you can take your templates in whatever direction you want. Templates can output markup, but they can also be controllers, web services, connections to other applications and more. The template system uses an API approach where your template file is given API objects that you then decide how to use. One of the API objects ($page) contains information for the page that generated the request. This is the opposite of a theme system because there isn't any predefined markup to theme (except a helper module like MarkupPagerNav). Likewise, your template isn't given fields per se, but it's given objects that you can pull data from. What data you decide to pull is up to you. But you have full responsibility for the output in ProcessWire. Of the CMSs I've used, PW's template system has the most in common with Expression Engine's in a big picture sense, but it's still quite different when it gets down to actually coding templates.

What I don’t like about this is that it means each template is fixed and less flexible (the same goes for Drupal).

Can you elaborate on this? I absolutely agree regarding Drupal (though know a Drupal expert would not). But there is nothing fixed about ProcessWire's template files, and I absolutely think ProcessWire's template system is the most flexible system out there. In PW, your template files have the entire ProcessWire API and all of PHP's environment and function library available. A template file can pull and manipulate data from anywhere in your site. A template file can be a controller, can bootstrap other applications, can act as web services or pull from other web services, can render any other page in the site, can handle URL segments and page numbers... and that's just scratching the surface. ProcessWire's template system is specifically designed for flexibility at it's core. I don't believe there is more flexible system available on any CMS in the world. But if there is something more flexible, I want to know about it.

And unfortunately it hasn’t got any concept of themes yet.

To be themeable, a platform must be a markup generator. ProcessWire is specifically designed to not be a markup generator. Themes are the opposite of what ProcessWire is all about. That's not to say that someone couldn't build some reusable site profiles and make them themeable (PW's admin is an example). Or even call site profiles themes as one might in EE. But I want to clarify that one should never expect ProcessWire to have a concept of themes because that is the territory ProcesWire has no crossover with. ProcessWire is a precise tool like a needle, whereas markup generating CMSs with a theme system are more like an ax. Different tools for different audiences and needs.

It’s promising, but it somehow seems to me it’s not quite done yet

ProcessWire is very minimal in it's presentation from the admin side, and I think this makes some think that there is more space to fill or that it is somehow unfinished. The reality is that PW is designed for large scale use on sites with thousands of pages. When working on sites of this scale, things like dashboards, sidebars, icons, lines and other graphic flourishes become visual clutter. So ProcessWire's default admin theme is really built around minimalism for scalability sake. That approach might seem barren (or refreshing, depending on your point of view) relative to something like WordPress. But I think it's also something that differentiates ProcessWire in a positive way. And one can expect the same simplicity and ease of use regardless of scale. When you are working on a site with 5k+ pages, you don't want anything else getting in your way. ProcessWire is a tool focused on the job and nothing else. Not because it's unfinished, but because that's the intention. Though PW's admin is actually themeable, and you are not alone in your visual preferences so I think others are doing a good job of giving PW a different look and feel for those that desire it.

(e.g. you cannot edit anything without JavaScript) and things might still change.

We are talking about PW's admin interface and not ProcessWire itself (which is defined by it's API). There is nothing about ProcessWire that requires javascript to use other than the admin interface. The admin interface requires javascript for the same reasons that tools like TinyMCE and Google Maps do. PW's admin is a PHP application, but it's also a javascript one... a mostly javascript app according to Ohoh. I think it's appropriate in an application environment to require javascript. Where I think it's inappropriate to require javascript on a web site designed to be accessible (and all sites I build are designed to be accessible). If there were any demand for non-JS support, it would certainly be easy to accomplish (minus TinyMCE), but I don't believe there will ever be enough demand for this to be practical.

[Soma]

While I appreciate people doing such writing. I'm kinda dissapointed by that little PW review, stating wrong facts.

One should at least know/understand the CMS, before writing something about it and state false things.... Or at least let it proof read by someone know the system well enough, if not sure about it.

[apeisa]

Soma: I don't think there are any false facts, mostly opinions. I found article very interesting and honest - it made clear statements about background. It was very clear from the beginning that author isn't pro on all those systems, but was writing about something based on his impressions after little use. Very valuable feedback for us.

Flexibility: I think what selfthinker meant with template flexibility is things like possibility for clients to change layout for page. While there isn't any built-in tools for that (for very same reasons that there aren't any themes) it is very easy to build few settings where editor can modify the layout.

[selfthinker]

Thanks for the extensive reply, Ryan.

I want to mention that, at least from my perspective, ProcessWire's template concept is the opposite of Drupal's. Drupal is a markup generator with predefined template files that act as containers for markup generated by numerous other modules. [...]

ProcessWire is built to take the opposite approach. It has no predefined templates and you can take your templates in whatever direction you want. Templates can output markup, but they can also be controllers, web services, connections to other applications and more.

What makes you say that ProcessWire is not "a markup generator with predefined template files that act as containers for markup generated by numerous other modules"? From what I understand that's exactly what it is. I just had a look at some of the code again to understand where my misunderstanding might be, but couldn't find anything.

• ProcessWire is a markup generator. If I understand "markup generator" correctly, it means, "it generates markup". It can do more than just generating markup, yes. But that doesn't make the point of a "markup generator" invalid. I can imagine that the misunderstanding here is that your definition of "markup generator" is something else?
  
• ProcessWire operates with predefined templates. Not sure what I might misunderstand here, but there are templates and they predefine what can go into them. PW cannot work without templates, can it?
  
• ProcessWire's templates act as containers for markup generated by either code in the templates themselves or by modules. Can the markup come from anything else?
  

This is the opposite of a theme system because there isn't any predefined markup to theme (except a helper module like MarkupPagerNav). Likewise, your template isn't given fields per se, but it's given objects that you can pull data from.

I think I understand what you mean. A theme is just part of the site itself, as it's so closely coupled with all the different data types, etc. So, the only "theme" which could make sense is a whole site (together with its dummy data), similar to the default site which comes with the standard PW installation. I guess that's what you call "site profile".

I now realise for the first time that Redaxo (the only of my 7 winners I have used before) works in a very similar way. But somehow I never missed themes there. I just had a look, and, sure enough, it doesn't have any themes either! (That's because of basically the same reasons as for PW.)

But what I don't understand is how that is different from Drupal? Drupal also doesn't have real "themes", but more "projects". Although it seems to be a bit of a hybrid.

What I don’t like about this is that it means each template is fixed and less flexible (the same goes for Drupal).

Can you elaborate on this? [...] But there is nothing fixed about ProcessWire's template files, and I absolutely think ProcessWire's template system is the most flexible system out there. In PW, your template files have the entire ProcessWire API and all of PHP's environment and function library available. A template file can pull and manipulate data from anywhere in your site.

Isn't that true for most CMS?

I tried to explain what I meant with PW templates being "less flexible" in a comment on the original blog post:

I guess there are two ways of seeing the flexibility of templates. The one you mean is from a developer’s perspective, and the one I mean is from the editor’s perspective.

With ProcessWire, the developer can build whatever he/she wants into the template, but the editor has not a lot of control over anything.

That is not necessarily a bad thing. On the contrary, it is often bad to let the editor have too much freedom. So, you have to find a good balance between those two extremes.

You cannot build any system in which a template is flexible for both the developer and the editor. So, I think for every CMS it's a matter of finding that balance.

I still think the one CMS with the best solution for that is Redaxo: The developer has all the flexibility over the output of a module (and whatever else is using its data), but the editor has control over which module to use on which page. But you can restrict which module can be used in which template.

It’s promising, but it somehow seems to me it’s not quite done yet

ProcessWire is very minimal in it's presentation from the admin side, and I think this makes some think that there is more space to fill or that it is somehow unfinished.

With that I meant something else than you assumed. I definitely agree that the minimalism of the the admin interface is a big plus.

What I meant with "not quite done yet" are mainly the two highlighted things on the roadmap and the inaccessible admin interface (see below). Regarding the roadmap, in my opinion something like multi language support is essential for a full-grown CMS. It is not essential for a good CMS, but to be competitive, there are certain features it needs to have. That is not to say you shouldn't use it. But if you happen to need multi language support, you cannot use it. But it's good to know that that restriction will be removed soon, and it's lack is only due to ProcessWire's young age.

(e.g. you cannot edit anything without JavaScript) and things might still change.

We are talking about PW's admin interface and not ProcessWire itself (which is defined by it's API). There is nothing about ProcessWire that requires javascript to use other than the admin interface. The admin interface requires javascript for the same reasons that tools like TinyMCE and Google Maps do. PW's admin is a PHP application, but it's also a javascript one... a mostly javascript app according to Ohoh. I think it's appropriate in an application environment to require javascript. Where I think it's inappropriate to require javascript on a web site designed to be accessible (and all sites I build are designed to be accessible). If there were any demand for non-JS support, it would certainly be easy to accomplish (minus TinyMCE), but I don't believe there will ever be enough demand for this to be practical.

Fair point that you can change the admin interface easily.

But I whole-heartedly disagree with the rest. ;-)

If you think in absolute amounts of users, the need for an accessible website is much greater than the need for an accessible admin interface to control that website. But if you think in percentages, the need for each is roughly the same.

Just imagine one of your clients has a disabled editor who would like to keep on doing his/her job. By choosing ProcessWire, they either need to tell that editor to let someone else constantly help him/her or to stop doing it altogether or they need to choose a different CMS.

Yes, from a commercial point of view that won't hurt anyone. You will just lose one client among many. But is it the right thing to do?

By the way, TinyMCE and Google Maps both do work without JavaScript! TinyMCE falls back to a simple textarea with which you can still edit the text. And Google Maps provide a static simpler version. (So, they are bad examples for you, but good examples for me. ;-) )

As to the difference between PW itself and its admin interface, that's the difference between a framework and a CMS. And in my review I only cared about the CMS side of it (of which the admin interface is a big part).

What I've learned today is that ProcessWire is probably not so much a CMS with a framework behind it, but much more a framework with a CMS on top.

[WillyC]

Self thinker have you developed site in processwire or drupal? You are one of my top 7, but it seem to me like you are trying to make some statement about some systems you haven't developed in and bridge trolling. There are some users like me that come from drupal and it seem like you have not yet used drupal, or processwire. Why write or rate systems you dont know about properly? Start here: Drupal create and output markup. Processwire don't - you do. Totally different to the roots. It is fun to write but you might spend more time using the system and less writing about them - I say this as your cheerful man friend that wants to be close and show love. We all need it. I can help you learn, send me your phone if you like. Google maps did not work without JavaScript for me and neither did tiny mce, but we talk.

[apeisa]

ProcessWire is a markup generator. If I understand "markup generator" correctly, it means, "it generates markup". It can do more than just generating markup, yes. But that doesn't make the point of a "markup generator" invalid. I can imagine that the misunderstanding here is that your definition of "markup generator" is something else?

Wrong. PW does not generate markup, you do. In most cms systems you add "news module" or "blog" which automatically generates news lists and article views and their markup - not in PW.

ProcessWire operates with predefined templates. Not sure what I might misunderstand here, but there are templates and they predefine what can go into them. PW cannot work without templates, can it?

Wrong. There are no predefined templates (other than examples that are bundled in demo site - easy to remove if you don't need those), but in PW you create your templates (data models, like database tables in sql). These templates can have template file, which is not required. You can just use pw as a storage engine if you want to, and even include it from another php-program and use its API from there. So PW can work without template files, but not without templates (data models) - it would be same thing than database without data (well, you could use it classes like $sanitizer etc, but not much value alone).

ProcessWire's templates act as containers for markup generated by either code in the templates themselves or by modules. Can the markup come from anything else?

Wrong. Templates are not containers for markup generated by either code in the templates themselves or by modules. Markup can come from anywhere suits your needs. Template file is just a regular php file that gets few PW variables as given. Most important of those is $page which pulls data from the current page. It doesn't generate any markup at all. You write the markup into the template file (like in demo site) or in separate file (like I do) and include that file and use your actual template file as a controller, where you manipulate and pull more data from other pages etc. You can also write modules or just regular functions that generate your markup if that suits your workflow better.

I think I understand what you mean. A theme is just part of the site itself, as it's so closely coupled with all the different data types, etc. So, the only "theme" which could make sense is a whole site (together with its dummy data), similar to the default site which comes with the standard PW installation. I guess that's what you call "site profile".

True. To have themes as "skins" then your markup should follow a common scenario. You cannot install site theme on top of JSON API for example...

Just imagine one of your clients has a disabled editor who would like to keep on doing his/her job. By choosing ProcessWire, they either need to tell that editor to let someone else constantly help him/her or to stop doing it altogether or they need to choose a different CMS.

I think accessibility is very important thing and there is no excuses for this. As far as I know there aren't very many "fully accessible" admin UI:s out there. Drupal and Perch are the ones I know. But I don't think PW admin application should try to go without JS.. that is because in PW it is very easy to create simplified admin views for your editors.

So in your example, I would build custom views for disabled editor to help him/her to work even easier than ever before. Rough time estimate for this would be something from 30min, but it depends how much and what kind of content he/she needs to edit and produce. Out of the box and without basic php knowledge this is not possible.

I don't think that you can fully manage whole site if you cannot use normal web browser, but you definitely can produce and edit content. But things like managing site tree, assets management etc... it's just isn't possible (or very hard) if you are in example blind. As we all know our industry is still fighting to get "reading usability" right on websites and I am very happy that PW let's do this as well as you know. I might be totally wrong here, and I am by no means accessibility expert, these are just my assumptions.

By the way, TinyMCE and Google Maps both do work without JavaScript! TinyMCE falls back to a simple textarea with which you can still edit the text. And Google Maps provide a static simpler version. (So, they are bad examples for you, but good examples for me. ;-) )

Google Maps doesn't, at least not for me. I don't know why it should, since if you are blind, you cannot read maps. If you are computer, you cannot read maps (as images anyway). I know there are many other Impairments than blindness, but I use it as most common example here.

What I've learned today is that ProcessWire is probably not so much a CMS with a framework behind it, but much more a framework with a CMS on top.

PW is a framework with an admin application build on top of it, which uses PW API (no shortcuts here, which is very important!). Something what oldies (Drupal, Joomla) are trying to achieve afterwards (separating cms and framework) - and I don't think that path can be very successful.

If you test PW as a software that you install and play without diving into coding (at least html&css and some very basic php) you cannot get much value from it. At least not before we have site-profiles. You really need to start building something unique for you needs before you realize what makes PW different (and better) from most cms out there.

[selfthinker]

Thanks for that equally extensive reply, Apeisa.

PW does not generate markup, you do. In most cms systems you add "news module" or "blog" which automatically generates news lists and article views and their markup - not in PW.

Oh, I see where the misunderstanding might come from: All my life I've mainly used CMS with which you can control 100% of the markup, whereas you probably have had the misfortune to work with those with which you cannot do that. Is that assumption correct?

I would never choose a CMS with which you don't have full control over the markup (which is also the reason why I nearly excluded Drupal from my reviews).

But it is weird to call that concept "markup generator". When you say "PW does not generate markup, you do.", that obviously cannot be true, unless your definition of "generating markup" is a different one than mine. That seems to be the case.

Just because you define which markup should be generated, doesn't mean PW doesn't generate it (if I use my definition of the term). Even frameworks generate markup. If something doesn't generate any markup, it's unusable for the web. ;-)

I'm not 100% sure what your definition of "markup generator" is. Quickly googling it, didn't produce results which might indicate that it's a fixed term. From what I think you mean, I would rather call it "markup dictator"!?

And I can definitely see how PW is not a markup dictator. But many other CMS are neither.

There are no predefined templates (other than examples that are bundled in demo site - easy to remove if you don't need those), but in PW you create your templates (data models, like database tables in sql). These templates can have template file, which is not required. You can just use pw as a storage engine if you want to

I think this is a misunderstanding again, depending on the definition of "predefined template".

I guess what you mean is a certain set of templates which is the same across all installations?

As most CMS can create different templates, I don't know what is supposed to be different in ProcessWire. Most CMS function as a "data storing" application, as well (i.e. they are just a way to store certain data in a database).

What I meant with "predefined template" is: You have a template "example.php" and you "predefine" (probably the wrong word) in it (or in a function which gets called by it or whatever) what kind of data it takes or what kind of data it is using to do something with it (whatever it is, it doesn't need to be markup).

Templates are not containers for markup generated by either code in the templates themselves or by modules. Markup can come from anywhere suits your needs. Template file is just a regular php file that gets few PW variables as given. Most important of those is $page which pulls data from the current page. It doesn't generate any markup at all. You write the markup into the template file (like in demo site) or in separate file (like I do) and include that file and use your actual template file as a controller, where you manipulate and pull more data from other pages etc. You can also write modules or just regular functions that generate your markup if that suits your workflow better.

A template doesn't generate markup? The one's in the default site do, and the ones in the skyskraper site do, as well. Are those bad examples?

You are contradicting yourself: You say "templates are not containers for markup", but you also say "you write the markup into the template".

Can you give me a list of places where markup can come from? Templates and modules, obviously. And from where else?

The way ProcessWire works in terms of templating is not unique. A lot of CMS work that way.

I am also used to work with frameworks (mainly CodeIgniter and symfony), so I also know how templating works in that environment. And yes, ProcessWire's approach is similar (or even the same) to that, but so are other CMS' approaches (probably not the majority, but they are plenty).

I think accessibility is very important thing and there is no excuses for this. As far as I know there aren't very many "fully accessible" admin UI:s out there.

Thanks for generally agreeing.

I haven't checked many accessibility features for my reviews (that's actually a good idea for a later post), I only checked if admin interfaces work without JavaScript. And from my 7 winners there are only 2 which don't work without JavaScript: ProcessWire and concrete5. I admit, that's not very representative, though.

I don't think that you can fully manage whole site if you cannot use normal web browser

Why not?

I think you will find there are already a lot of disabled people managing whole websites. And they are usually using a "normal" web browser, but just with certain add-ons or other software (or even hardware) on top of it.

By the way, TinyMCE and Google Maps both do work without JavaScript! TinyMCE falls back to a simple textarea with which you can still edit the text. And Google Maps provide a static simpler version. (So, they are bad examples for you, but good examples for me. ;-) )

Google Maps doesn't, at least not for me. I don't know why it should, since if you are blind, you cannot read maps. If you are computer, you cannot read maps (as images anyway). I know there are many other Impairments than blindness, but I use it as most common example here.

I currently use the static Google Maps quite often, because I don't have a proper internet connection at home at the moment. As my connection can be quite slow, I am very thankful for Google providing it! (And that's just one example among many.)

If you test PW as a software that you install and play without diving into coding (at least html&css and some very basic php) you cannot get much value from it. At least not before we have site-profiles. You really need to start building something unique for you needs before you realize what makes PW different (and better) from most cms out there.

I would love to properly use ProcessWire, but unfortunately won't have any opportunity any time soon.

I agree to a point that you cannot properly judge a system until you've worked with it. But I disagree that "you cannot get much value from" playing around with an example installation. I think you might underestimate me here (especially since I know a lot of its concepts from other systems). ;-)

I think most of our misunderstandings stem from either differing definitions of terms or different previous experiences (which makes it difficult to reduce things to a common denominator).

I really think I understood how most of ProcessWire works. As I don't understand much of Drupal, it's very possible that I have made a few mistakes in any comparison between those two CMS, though.

[ryan]

Selfthinker--I'm catching up here. I welcome the conversation and I think you are trying to listen, but also think you are on the defense first. Forgive me if I'm wrong, but you are saying things that are unusual for long time CMS users and I'm not sure you are understanding. I want to give you the benefit of the doubt but also want us to be respectful of our members here that are taking their time to politely reply (WillyC excluded). I understand you are here to defend your review. I can appreciate that and that is totally okay. I am happy anytime somebody wants to write about ProcessWire, and especially when they want to include it in their top choices. However, I think I'm at fault for correcting points from your review in the forum and putting you on the defense. Ultimately I am glad that you took the time to include ProcessWire in your review and thank you for doing so.

If you are interested in developing a site in ProcessWire and gaining the experience of using it on a site, then I think you are in the right place. In such a case, it's great to pose questions to our team, and this conversation should move forward. But if you don't have an intention of learning and using ProcessWire, then I would suggest you put your time and energy towards the open source CMS project that does fit your needs. I believe that ProcessWire is a good solution for many, but not for all. However I also believe that open source is the right solution for all, so those of us participating in it need to focus our time and energy towards the systems that best meet our needs.

[selfthinker]

Your reply makes me assume that you have misunderstood most of what I was trying to say.

You are implying that I was impolite. I was not aware of that, sorry if I was.

Your reaction also shows that you think I have a negative view of ProcessWire, which I have not. In contrary, I really like it.

Especially regarding my last post, what do you think I got wrong? The main reason for my replies here is trying to learn.

To go back to my initial statements in the review which caused trouble:

Its templating and editing concept is similar to Drupal’s

As I said before, the error here is half on my side, because I don't know much about Drupal. I probably should rather have said "editing concept" and left "templating" out of the game, as there's usually much more to it. But both their concepts regarding how they are using fields is definitely much more similar than between, say, PW and Joomla or most other CMS. I've never said (and never meant) that they are the same.

What I don’t like about this is that it means each template is fixed and less flexible

That's just undeniably true, isn't it. As I explained I meant that from the editor's perspective. And I also said that that's not necessarily a negative point, as giving the editor too much freedom can be negative, too.

And unfortunately it hasn’t got any concept of themes yet.

That's where I already admitted my error. That's the one point which I am also going to adjust in my review, pointing out that it's true, but rather a good thing and that it's part of PW's concept to not have any themes in the usual sense.

It’s promising, but it somehow seems to me it’s not quite done yet

That's also just true, but nothing bad at all, if you think about PW's young age. There's no reason to get upset about it. ;-)

(e.g. you cannot edit anything without JavaScript) and things might still change.

That's also undeniably true, but obviously people are allowed to have different opinions about how important that is.

Regarding the markup generator discussion, I really think this is only a matter of misunderstanding and using different words for the same concept, or rather the same words for a different concept. We are all using words which we assume are clear to everyone else, but they're not.

[apeisa]

I think you misunderstood Ryan's reply here:

However, I think I'm at fault for correcting points from your review in the forum and putting you on the defense. Ultimately I am glad that you took the time to include ProcessWire in your review and thank you for doing so.

No one is saying you were impolite, but conversion where we discuss about yes-no-yes-no-yes doesn't do any good for ProcessWire (or any other os-project out there). For that reason I keep my answer short:

Drupal: system provides default markup, and then there are several places where you can overwrite that markup. Totally different method than in pw, and that is what we think as "markup generator" here. If you look source codes from sites build with "markup generator cms" and one without (like pw or Expression Engine) you see that latter is almost always cleaner (it is as good as the front end developer and that is one of the main reasons EE is so popular among talented front-end developers). Of course you can re-write everything on most markup generator cms also, but that is usually slow and tedious process (and also fights against the ideology).

Template flexibility: you could have template where you have one field, let's call it "html". Then user writes whole site markup on that field. If that is the kind of flexibility you need, there you have it. Then your actual "template file" would be this:

<?php
echo $page->html;

[diogo]

Selfthinker, I don't think Ryan said you where impolite. He only stated that there's no point on taking this conversation further if you are not going to go deeper in the system. You are getting very extensive explanations from people that spent already lots of hours knowing and working with this system. Misunderstandings and lexical discussions apart, the truth is that at this point you are just ignoring most part of what people are saying and defending your initial thoughts without even trying to confirm if they are true (making your hands a little dirty in the system). The same way that you put these tools at test and give your opinions about them, you should also let other people give you their opinions about what you do, in these case your review (you linked to it here yourself, remember?). I understand that you don't have time to try all the products extensively, but the time it already took you to defend your review here, would be enough to at least work a bit on it and clarify some of your doubts, and, who knows, even help on some of the problems you have pointed out (build a non javascript admin theme, help with the multilanguage module, whatever...)

[selfthinker]

No one is saying you were impolite, but conversion where we discuss about yes-no-yes-no-yes doesn't do any good for ProcessWire (or any other os-project out there). For that reason I keep my answer short:

Drupal: system provides default markup, and then there are several places where you can overwrite that markup. Totally different method than in pw, and that is what we think as "markup generator" here.

Thanks, this answer shows that it's not (or at least not completely) a "yes-no-yes-no-yes" situation:

Ryan wrote something which I misunderstood, to which I replied something that Apeisa misunderstood, to which I replied what I assumed was the misunderstanding, to which Apeisa replied that that assumption was correct. So, all is good and we're finally getting somewhere.

But I agree that a discussion in which the participants don't "speak the same language" is tedious and fruitless, especially in internet forums where people have less possibilities to express themselves than in real-life situations.

Template flexibility: you could have template where you have one field, let's call it "html". Then user writes whole site markup on that field. If that is the kind of flexibility you need, there you have it. Then your actual "template file" would be this:

<?php
echo $page->html;

That's not what I meant at all.

But to keep this discussion short, I won't try to explain further.

the truth is that at this point you are just ignoring most part of what people are saying and defending your initial thoughts without even trying to confirm if they are true (making your hands a little dirty in the system).

Well, I feel basically the same, that some people don't really listen to me and therefore jump to conclusions which are not true.

For example, most of your assumptions in that single paragraph are incorrect...

The same way that you put these tools at test and give your opinions about them, you should also let other people give you their opinions about what you do, in these case your review

I have no problem at all with anyone's opinion (of those to which I replied). What makes you say that?

Some people seem to have problems with some things I said. But I don't understand what those problems are exactly. I'm just trying to understand and make myself understood.

[apeisa]

That's not what I meant at all.

But to keep this discussion short, I won't try to explain further.

I think I understand what you meant. In your article you write:

REDAXO was my favourite CMS for a long time. Its module concept and editing flexibility is something I haven’t come across in any other CMS before. It might sound strange, but there are very few other CMS with which you can freely add any kind of content in any kind of order. But now concrete5 (see above) is a contender for that.

Our current in-house cms works this way. Meaning editor can add different "blocks" to the predefined places and in any order he/she wants. I don't use term "module" here, since it is very different thing in ProcessWire. So editor can easily build pages like this:

MAIN COLUMN:

Text and images

News block

Form

Image gallery

Text and images

SIDEBAR:

Read our newsletter -block

Banners-block

Text and images

etc... you got the idea.

Sometimes it is desired, but many times it just leads to very messy pages. But in good hands, yes, very powerful way to create individual pages. (BTW: You might be very interested in this: http://blog.squarespace.com/blog/2011/10/21/squarespace-6.html)

But that way of managing content has one very major drawback: you are not actually managing content anymore, but "just" creating website, page by page. You tie your content and presentation very closely together. The smaller the site and needs, the better it works. On large scale sites: it leads to a mess. Things like redesigns (both: visual or structural), multichannel publishing, content re-usage and building API:s on top of CMS like that is more difficult. Of course there are structural content also (like news, events, form submissions etc) which are easily reusable. And probably the CMS you have used (REDAXO) is better in keeping content and presentation separate than the system I am familiar with. But in any way: if each page is "custom tailored" it always makes things I mentioned earlier harder.

[diogo]

For example, most of your assumptions in that single paragraph are incorrect

If you say so, I believe it. But this was the feeling I got from your replies and review.

I have no problem at all with anyone's opinion (of those to which I replied). What makes you say that?

The challenging tone of your writing did. I don't see your face or hear your voice tone, so, I might be also wrong here.

I don't know if your enjoying this discussion or hating it. But I hope it will, at least, make you curious about PW and it's evolution. If you won't start using it, just come check it from time to time.

[WillyC]

Self thinker, you.are still in my top 7 member but Arrive here you did and challenge  on every point but no reputation. Time it takes to build trust. You will.get there so hope you stay I will. Open your mind you will and trust follow. We help you gmanet.there. cal and we talk. I know you will.be happy with drupal and processwire and share the happiness with all