selfthinker

As the first part of the discussion that followed (which was moved to the Pub subforum) is still relevant to this thread, I post it again:

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. That's not what I meant at all. But to keep this discussion short, I won't try to explain further. 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... 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.

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: 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. 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. 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. 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. ;-) 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.

Thanks for that equally extensive reply, Apeisa. 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. 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). 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). 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. 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. 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.) 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.

Thanks for the extensive reply, Ryan. 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? 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. 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: 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. 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. 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.

You actually can do something about that: You can add all third-party code to the files to ignore here => https://www.ohloh.net/p/processwire/enlistments/463503/edit (You can get there over "Development > Enlistments > Choose files to ignore") I don't think many projects use it, though. Which is a pity, because that would make their statistics much more accurate. And yes, their scanner has some problems. I've seen some issues in many other projects as well. But it's still interesting if you are aware of it and take it with a pinch of salt.

Just to let you know... I found that most CMS are represented on Ohloh, but ProcessWire was one of the very few which wasn't. So, I went ahead and added the project: http://www.ohloh.net/p/processwire

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/