Jump to content

Craft CMS and ProcessWire – a comparison


MoritzLost
 Share

Recommended Posts

Last year I started working with Craft CMS, a CMS roughly similar to ProcessWire in scope and target audience (developers). Since I like Craft a lot and found it has some great solutions for problems I had with ProcessWire, I wanted to write up a comparison between the two systems, point out similarities and differences. This is also intended to introduce some ideas that ProcessWire could benefit from.

Admittedly, this comparison is a bit unfair – ProcessWire is completely free and open source, while Craft CMS requires a paid license for everything but very small projects. So while Pixel & Tonic, the developers behind Craft, can fund an entire team to work on Craft and developer support, ProcessWire is mostly maintained and developed by one person. Still, I think the comparison is worthwhile, since it could help focus development on the areas where ProcessWire (in my opinion) needs improvements the most.

Disclaimer: I'm not associated with either ProcessWire or Craft CMS (Pixel & Tonic), and I'm not being paid for any of this.

Pricing

A regular Craft license for a single site is 299 $ in the first year, then 59 $ / year for updates (this is optional). If you don't need multiple user accounts and some optional CMS features, there's a free version as well. There are also premium plugins which come with licensing fees. There's no bulk/agency pricing, so you have to include the license fees in the calculation for every project.

ProcessWire is completely free, though there are the commercial Pro modules. Some of those are required for almost every site, in particular ProFields (for the Repeater Matrix), so the average site probably won't be completely free. Those modules are available as agency licenses, so for agencies with lots of ProcessWire projects they are a pretty good deal.

Content modeling

Both systems are quite similar in this regard. You can create fields (chosing from a variety of field types) and create content types with any number of fields. ProcessWire calls content types templates, Craft sections – sections can further be divided into different entry types with different fieldsets.

ProcessWire puts everything into a single page tree / hierarchy. This is handy in some situations, but all in all detrimental. First, you have to fit everything into a page hierarchy, even pages and content that don't have a natural place in the tree. This makes it harder for clients to find what they're looking for. Also, you're heavily incentivized to generate your site navigation based on the tree hierarchy, which is bad in the long run.

Craft instead has top-level index views (in the backend) for every content type – entries, categories, users, etc. You can organize entries in a section in hierarchies or streams, depending on what makes sense for that content type. Craft also has a media library where you can upload assets independent of pages. ProcessWire doesn't allow you to do this. I'm actually fine with that, though many clients care about this for some reason.

Interface

Both ProcessWire and Craft have mostly nice, usable interfaces. The editing interface of Craft feels a bit cleaner and more modern due to being more restricted. ProcessWire opts to have lots of display options (and even replacable admin themes), which is handy in some situations. Craft is more streamlined, which makes it feel more coherent. Both approaches have their merit.

Craft is actively working on improving accessibility and has a stated goal to be accessible. Meanwhile, ProcessWire at the moment doesn't make any claims regarding accessibility, and ryan seems to be actively opposed to the idea.

Templates & Theming

Both ProcessWire and Craft are developer-centric in that you have full control over your HTML output. Both systems have starter projects in lieu of themes, allowing you to start with a project template and customize it as you go, or start from a completely clean slate.

A major advantage of Craft is the Twig integration which it provides by default. This is a contentious topic and I don't want this to turn into a debate of plain PHP templates vs. template systems. But Twig just has some advantages that plain PHP doesn't:

  • Block-based inheritance is impossible in plain PHP, and without that you can't have fully extendable base templates without those base templates having knowledge of ALL extending templates or being so granular that they stop being useful.
  • Twig forces you to separate logic and presentation, putting your business logic in services and/or controllers.
  • All the other benefits that are always brought up in discussions about Twig, like security by default, simpler templating syntax etc.

You can include Twig in ProcessWire, though it's a bit of extra work. And Craft's Twig integration goes much deeper, providing many useful functions to templates. For example, there's a cache tag that 'just works' (99% of the time) and allows you to cache parts of your template output. With ProcessWire, you have to use the $cache API manually and take care of cache keys, cache invalidation etc.

Developer API & data access

Both ProcessWire and Craft provide a strong API to query for content / data. They are actually quite similar in that you can query by content type or properties, search for field values, apply custom ordering etc, everything you would expect.

One downside of ProcessWire's API is that it's string-based (there's an array alternative, but that isn't super reliable and not well documented). This means that you have to take care of input sanitization to prevent query injection. Craft's element queries use method chaining instead, which means you have better separation between query and data. This way, the the field type classes are responsible for sanitizing their inputs before adding them to the query, so you mostly don't have to escape user input manually.

One downside of element queries in Craft is that they're quite hard to extend. Though that's to be expected because those queries support a lot more native features (multi-site support and expiration dates, for example).

Multisite support

Craft provides full multi-site support while ProcessWire doesn't. There is a third-party module for ProcessWire module, though that comes with zero guarantees that it will continue to work and is much less convenient than the built-in multi-site support. Not really an issue for sites that don't require multi-site capability, but a gamechanger for sites that do.

Internationalization & localization

Both systems support code I18N, and both support multi-language setups.

Interace translations in Craft can be included as simple PHP files, though there are modules that extend this to provide an editor interface for string translations. ProcessWire does provide an interface, but it's clunky and heavily developer-centric, requiring you to chose files from a list, so you can't really ask clients to use it. ProcessWire also uses file scanning to detect translatable strings, which means you can't use it with custom setups (in particular, it's impossible to use with Twig). Finally, you can't really bypass the interface since translations are stored in JSON files in, essentially, random locations, so adding translations directly in the code editor is impossible.

Field translations in Craft work with all built-in fields and all module fields and are well integrated into the developer API. ProcessWire's field translations suffer from the fact that they seem tacked on and not well thought out. For example, regular text fields can be translated inline. But if you want to translate an asset field, you need to add the second language's field manually, which feels weird and looks bad and unintuitive in the interface.

Custom development

Craft is built with Yii2, which most people will agree isn't the best PHP framework there is. But it does integrate nicely into Yii2, and you can also bypass them and build specific features using Yii2. The framework provides standard components for models and validation, controllers, views, etc.

With ProcessWire, everything is homegrown. This makes it easier to get started at first, but hinders you in the long run, because there just aren't as many utilities, best practices and components to use for custom development. Oftentimes, you're either completely on your own, or have to dig through old forum posts and blog articles to find details (sometimes unfinished) features. Building custom features into ProcessWire isn't really encouraged or supported as ryan confirms here.

Roadmap and feature policy

Craft has a limited feature set, but supports those features well. Things like multi-site support, translations and live preview are built into the system from the start, provide strong APIs and all of those features work with each other. They also provide a roadmap so you can see what new features are coming next. All in all, Craft development seems organized and focused on their target audience.

ProcessWire's feature approach is a bit … chaotic, to say the least. New feature seem to be added whenever ryan thinks of something cool to add. The problem is that most of those feature are never completely thought out and are quickly abandoned. There's hundreds of features that look cool but just aren't well supported – they lack documentation except for old blog posts, they have bugs that never get fixed, they don't work well with each other and so on. A much more limited feature set that can actually be supported with documentation, support, integration with other features would be preferable by a long shot.

Documentation

The Craft documentation is clear, well organized and provides a good overview of the system as a whole. It's It does lack a bit in depth, so for custom development you often have to look through the source code to find what you're looking for. There's also a generated and searchable class reference.

ProcessWire's docs are also helpful in general, though they lack a clear structure and hierarchy, making it hard to read it back to back or find specific pieces of content. Its also missing most of the features that get added on a weekly basis – see the point above. This means the only way to discover or find info on those features is to root through old blog posts.

Semantic versioning

Semantic versioning is crucial for peace of mind come update time, so developers know whether an update contains bugfixes, new feature and/or backwards compatibility breaks.

Craft, up until version 3, doesn't follow semver closely. The first digit (3) is reserved for marketing, while BC breaks are delegated to the second digit (e.g. Craft 3.6 -> 3.7). Bugfixes and compatible feature additions are lumped together into the third digit (though curiously, sometimes they add a fourth digit for urgent bug fixes). But starting with Craft 4, P&T will switch to full semantic versioning, so every BC break will bump the major version number.

ProcessWire uses the first digit for marketing as well (ProcessWire 3). Unfortunately, it doesn't use the second digit at all, so we're still at 3.0.X years after the first PW3 release. And the third digit is just incremented whenever there's a couple of commits that need releasing, so it doesn't have any significance beyond the ordinal scale. This makes it impossible to know if a given update will cause problems for you. Ryan has stated somewhere (can't find the link) that this is because there haven't been any BC breaks since version 3.0.0 so far, which is … not true. At some point, an update broke the ability to upload SVG files to asset fields if you don't have the FileValidatorSvgSanitizer module installed. If this isn't a BC break, what is?

Terminology

This is a minor point, but it bugs me. Both Craft and ProcessWire have terrible terminology. Without looking, what do you think a section is in Craft? ProcessWire meanwhile overloads the term template to refer both to content types and the PHP files for those content types, making it really hard to talk about those. Have fun if you're using Twig as well, now there's three distinct things that are all called templates.

------------

I wanted to talk about version control as well, but this post is already a mile long, so that's gonna be a topic for another day.

  • Like 15
Link to comment
Share on other sites

Thanks for this comparison, a lot useful informations. I remember how many years ago (around 2013–14) I was looking for a new CMS and for some time I played with Craft. Later I found also Bolt CMS (also with TWIG support) and Kirby interesting.  

  • Like 2
Link to comment
Share on other sites

This is great, thanks @MoritzLost for taking the time to write this up and share it with us. Although I don't agree with all the points (e.g. I think the PW emphasis on tree/hierarchy is a pro rather than a con) it's really interesting and useful to get an insight into how other CMSs solve problems and bring value to their users.

I'm not sure if Ryan feels the same, but speaking as a person who enjoys developing modules and tools: eventually the limiting factor becomes ideas. That is, the will is there to keep creating useful things but the challenge is knowing what will consititute a useful thing to the audience. So getting user requests and descriptions of pain points is what's needed to keep the wheels turning.

Regarding the Craft/PW comparison...

You did state this clearly at the outset but I want to really emphasise this because it's such a major factor: the difference in cost between Craft CMS and ProcessWire is massive. I did a conservative estimate of the net income I would have lost as a solo developer over the last 5 years if I had have built all of my projects with Craft/plugins rather than PW/modules. It's approximately USD $43,000. For someone in my position that is just huge. Maybe I could have successfully added those Craft costs into the quotes but then maybe I would have lost many bids if I had done that.

In general, if you think about the difference between something that's free and something that costs upwards of $299 it should be no surprise if there are some advantages to the thing that costs you $299. In fact it would be outrageous if you paid $299 for a thing and it was worse or no better than a free alternative. Suppose I would like a drink and I'm choosing between the free option (a bottle of tap water) and the $299 option (a bottle of Dom Pérignon champagne). The champagne should be a better experience than the tap water. That's why it costs $299. But when we bring this analogy back to PW/Craft, it's like ordering a bottle of tap water and then having the pleasant surprise that it's a very nice méthode traditionnelle. Maybe not quite as good as the Dom Pérignon, but at $0 that's extraodinary value and a lot of people would say it's the better choice for them. For the types of projects I use PW for, I have the occassional niggle but it's very minor stuff.

Although I'd love to see PW match all the features of all its commercial competitors I also think it's reasonable to take the position that a free product is not going to be all things to all people. I actually wish there was more clarity about the kind of developer and kind of projects PW is targetted towards. In my opinion, narrowing the focus of PW and clearly communicating this at processwire.com would be a step in the right direction. Even if this was somehow expressed in negative terms, e.g.

  • Don't know what a foreach loop is? Other tools will suit you better than PW.
  • Looking for themes? Other tools will suit you better than PW.
  • Looking for "a plugin for everything"? Other tools will suit you better than PW.
  • Part of a large development team? Other tools will suit you better than PW.
  • Building "enterprise" applications? Other tools will suit you better than PW.
  • Working on projects with budgets in the mid-five-figures and higher? Don't be such a cheapskate, get out your chequebook because other tools will suit you better than PW.

The way I see it, the person who will get most value and satisfaction from PW is a solo developer with at least intermediate experience (or a willingness to get there), working on projects that have demands that go beyond the basic but where the budget is somewhat limited. The main benefit that I get from PW is that I can build surprisingly powerful sites and build them fast so the hours/costs are kept down. This is the PW sweetspot and I think we should lean into it.

  • Like 23
Link to comment
Share on other sites

Great writeup, @MoritzLost!

You nailed many pain points of ProcessWire. And actually spotted the main reason of why they are not being prioritized. Which is @ryan being the only one conceptualizing and deciding upon the architecture, the feature list, the roadmap, marketing... and actually almost all things ProcessWire. And he probably does not see them as pain points, as he doesn't face them in his workflow.

I guess that the reason that Ryan stays almost the only PW core developer is his personal experience. His way of work determines this. not the lack of finance, which could be established. And that is something that we cannot change from the outside, but should try to convince him to consider changing.

I am really grateful to Ryan for his work and attitude. I will love and use ProcessWire either way. I perfectly understand how hard it is to move from being a solo developer to a head of a team, as I am in the process myself. I do love everything perfect and checked by myself. And actually because of all that I suggest we think about the way to have some collaboration on ProcessWire development. Maybe we could start with some kind of conversation about it, if @ryan will find this idea worth trying. A messenger chat, a video call... Thinking forward we could have roadmap discussions, GSoC events, paid feature development by either core or subsidized developers, community supported docs and translations, crowd funding/marketing and even foundation... But we need to start with a discussion.

I would love to be a part of this better organized community and take action towards collaborative PW future under Ryan's lead. But that is just an option to consider. ProcessWire is fine the way it is already. Maybe limitations laid out by @Robin S are the wireframe (sorry for the brand misuse, @teppo) that keeps PW sustainable and are to be taken as is.

  • Like 3
Link to comment
Share on other sites

Good comparison and and I can agree to almost all of your statements, except:

21 hours ago, MoritzLost said:

A major advantage of Craft is the Twig integration which it provides by default.

Personally I would count that as disadvantage because Craft is forcing you to use one special template engine.

I know you don't want to start a discussion about Twig vs. PHP, so I just want to say that I think it is better to be able to switch template engines like in ProcessWire instead of being forced to use one template engine. 😉

That and the expensive pricing were the reason why I never used Craft for a project yet. But I can understand why you like it so much.

  • Like 7
Link to comment
Share on other sites

@Robin S Absolutely, I agree with all of this! For the record, I've used ProcessWire for years and still am, and I like it for what it is. I've just noticed that after working with Craft for a while, PW falls flat in comparison in some regards. But yes, the point regarding pricing is a absolutely valid. We're also doing some PW projects that are small enough that the price tag on Craft is actually relevant and a deciding factor.

One caveat to the free vs. paid argument is that some of the suggestions here (and especially in the other thread regarding version control) could actually take less time to implement than the current solution. For example, how much time did it take to create a custom module installation process, module store API etc? This time could've been saved by just using Composer, and this would be an immediate improvement since it integrates well with VC and other tools. Though to be fair, I'm saying this with the advantage of hindsight, not sure if Composer was even around when PW got started. The same goes for the sheer breadth of features and the pace of new features being added. I would prefer seeing much fewer features and instead having that development time go towards upkeep, support, bug fixing and documentation of the core feature set. So we're still talking about the same amount of time going into PW development, just focused in a different way.

11 hours ago, Robin S said:

I think the PW emphasis on tree/hierarchy is a pro rather than a con

I thought so too until I started working with Craft. I think it comes down to the scale of the project – for small projects it's convenient, but for larger projects the downsides of this approach become more noticable. Decoupling content from navigation is healthy in the long run, the article I linked has some great points regarding this: https://cld.agency/blog/content-utopia Though it's also a matter of personal preference!

11 hours ago, Robin S said:

I did a conservative estimate of the net income I would have lost as a solo developer over the last 5 years if I had have built all of my projects with Craft/plugins rather than PW/modules. It's approximately USD $43,000

Wow, that's a lot of projects 😄 You're right, if you're doing many small projects, the licensing model for Craft isn't a good fit. Though if the project is small enough, you could also use the free lite version. The only important limitation is that you can't create additional user accounts beyond the admin account, but for projects with not a lot of content editing or changes after the site is live this might be fine.

11 hours ago, Robin S said:

The way I see it, the person who will get most value and satisfaction from PW is a solo developer with at least intermediate experience (or a willingness to get there), working on projects that have demands that go beyond the basic but where the budget is somewhat limited. The main benefit that I get from PW is that I can build surprisingly powerful sites and build them fast so the hours/costs are kept down.

That's a really good summary and sums up my points above and in the other thread really well! Somebody please put this on the PW homepage 🙂

50 minutes ago, Ivan Gretsky said:

I perfectly understand how hard it is to move from being a solo developer to a head of a team, as I am in the process myself. I do love everything perfect and checked by myself.

@Ivan Gretsky I'm in the same boat, the problem is that ProcessWire does't work well with version control, so it's difficult to establish a git workflow with pull requests. On my Craft projects, I have no problem letting my student trainee work on some feature, because I can review everything they've done and their work only makes it into the project if I explicity approve it. With ProcessWire, this is much more difficult. Though this discussion fits better into the other thread I wrote yesterday ^^

48 minutes ago, AndZyk said:

Personally I would count that as disadvantage because Craft is forcing you to use one special template engine.

@AndZyk Well from my point of view the jedi are evil it's a disadvantage to NOT have a template engine built into the CMS. A matter of personal preference to a certain degree. Though I've noticed a trend that the most valiant defenders of plain PHP templates are the the ones that have never given Twig a serious try 😗

Technically you can bypass Twig and write plain PHP templates with some adjustments to the routing and templating components, though admittedly, Craft isn't built for that. Unless we're talking about custom routes and controllers, those are supported and Twig is completely optional in this case. Still – having first-class support for a templating engine means the entire system works well with that templating system. Craft provides a lot of super convenient tags, functions and filters for Twig that just work out of the box. We also use Twig for our ProcessWire projects, but because it's not built into the system, it's much less convenient. And some PW features don't work with it at all, like the translation system.

17 hours ago, roderigo said:

Moritz Lost maybe you should add discount coupon code available for process wire users ? or free trial opportunity for product you are selling

@roderigo I'm not affiliated with Craft or Pixel & Tonic, I've added a disclaimer above.

  • Like 4
Link to comment
Share on other sites

56 minutes ago, MoritzLost said:

Though I've noticed a trend that the most valiant defenders of plain PHP templates are the the ones that have never given Twig a serious try 😗

Just wanted to add, that I have given Twig a serious try a few years ago and came to my conclusion that it took me more time to learn first how to do things in PHP and then translate it to Twig than just to do it in PHP. But if you are happy to learn two languages at the same time or are already experienced in PHP then I imagine Twig can be a time saver. 😉

I prefer a CMS that doesn't force me to learn a new template language.

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

Quote

Admittedly, this comparison is a bit unfair – ProcessWire is completely free and open source, while Craft CMS requires a paid license for everything but very small projects. 

I agree it is unfair to make comparisons like this. I also don't think it's very nice to come to an open source project's support board and try to convince people to use a commercial CMS. Maybe the fact that a comparison can be made at all is a compliment. But Craft is a big commercial project with a sizable team and lots of resources and money behind it. ProcessWire is the opposite of that and the comparison seems inappropriate. 

But since you've stated this is a comparison, I'm not sure where the comparison is — you've focused exclusively on what you think Craft does better (by your own preference), but haven't made efforts to point out the areas where PW does better. So it comes across a little bit as an advertorial for large commercial CMS at the expense of a small open source project.

Throughout you are stating a preference for something in Craft and claim a similar feature in ProcessWire is "not well thought out." This is wrong. A more honest statement would be that you and I clearly have different preferences, or maybe you don't fully understand something. But that does not mean that something that differs from your preferences or understanding is "not well thought out."  I would never commit something to the core that hasn't been really well thought out, that's something I take really seriously.

While much of Craft doesn't suit my own (and others) preferences, and may not be "well thought out" according to how I think things should work, I'm not going to join their forum and tell them it's not well thought out. That's because I respect them and trust that it's well thought out, according to their needs and preferences. So when you start telling someone that something they've put a lot of work into isn't well thought out, that's akin to saying that you do not respect them. 

I make no claims about being perfect at anything, and there is room for improvement in everything. What I take issue with here are the broad, subjective and largely false generalizations, and that's what I'm replying to. I'm also concerned that anywhere that you've quoted me, you've taken a statement by me out of context, extrapolating it as proof for an unrelated conclusion you've made. For example:

Quote

Meanwhile, ProcessWire at the moment doesn't make any claims regarding accessibility, and ryan seems to be actively opposed to the idea.

In that link we are not talking about ProcessWire at all, and instead are talking about the processwire.com website in development, NOT the CMS. Why would you say I'm "opposed to the idea" of accessible development? This is something I'm interested in and passionate about. I don't understand why you are quoting me on one thing and saying another. 

Quote

Building custom features into ProcessWire isn't really encouraged or supported as ryan confirms here.

In that link, I'm writing about a module called ProcessUser and something that is imposed upon it for a specific security purpose, unique to that particular module, and no other. But you have used my statement as proof that building custom features in ProcessWire isn't encouraged or supported. Nothing could be further from the truth. I have never had such a thought. My thoughts and intentions would be exactly the opposite. 

Quote

A major advantage of Craft is the Twig integration which it provides by default. 

What you consider an advantage, I consider a major disadvantage. PW puts nothing between you and PHP, by design, that's a major advantage. I certainly would not be happy with Twig integration being a default. Clearly you like using Twig, which is fine for you to have that opinion, and I think it's perfectly fine for Twig to be an option. But I definitely wouldn't want to standardize upon it. Maybe it doesn't suit your preference, but I hope you can appreciate why we don't do things like that in PW. 

Quote

With ProcessWire, you have to use the $cache API manually and take care of cache keys, cache invalidation etc.

You are comparing two different kinds of caches. You are talking about a template engine cache. In PW there is no template engine, so likewise no template engine cache. Most of the time you would never need such a cache in PW at all. The $cache variable is something different, and while it can also cache markup, it is much more simple than you imply. 

Quote

One downside of ProcessWire's API is that it's string-based (there's an array alternative, but that isn't super reliable and not well documented). This means that you have to take care of input sanitization to prevent query injection. 

PW's API is not string-based. You are writing about selectors (and specifically selector strings), not the "API". ProcessWire lets you specify selectors as strings or as arrays. Most prefer to use strings due to the simplicity of it. But this does not mean that arrays are not reliable. And if you use arrays, then there's no need to do value sanitization. 

But the majority of the time you are using selectors, you are not injecting user input into it either, so I would consider selector strings to be a major advantage for PW the vast majority of the time. And for times that it's not, you don't have to use it. 

Quote

Craft's element queries use method chaining instead, which means you have better separation between query and data. 

The problem with chaining methods for this is that they are live code, you can't store them. Perhaps it has benefits in Craft, but they would not be appropriate for PW. 

In PW selectors can be specified as arrays or strings, and in cases where you want to separate the query property from the query value, then that's why we have the array option in PW. And yes, they are reliable, despite your claim that they are not. 

Quote

This way, the the field type classes are responsible for sanitizing their inputs before adding them to the query

The same is true in PW. Fieldtypes build the query and sanitize/validate the value to be queried. The only thing PW asks you to do is IF you are using a selector "string" that ALSO happens to contain user input, then just sanitize that user input part with the selectorValue() method. If you are using an array, then such sanitization is already done for you. This has nothing to do with details of a fieldtype, which will do its own validation/sanitization.

Quote

ProcessWire does provide an interface, but it's clunky and heavily developer-centric, requiring you to chose files from a list...

Saying "clunky" is a subjective and hardly fair statement to make. What might be clunky to you is optimal to others. You are writing specifically about the file translation system, so the whole purpose is to provide an interface to translate your site php files (primarily template files). The interface is geared to focus on that task only, and that's the point of it. 

I understand you value more layers between things (like with Twig), but I always prefer fewer layers, a more direct approach, so you'll see that throughout PW. If I'm using a file translation system, I want to know what file I'm working with and I want to be able to tell the translator what file to work with. That my preference, and I understand you have a different one. 

Quote

 ...so you can't really ask clients to use it. 

Of course you can, that's who it is for. Yes they are grouped by file, and that's how I prefer it, and I have never had a client have a problem with that. If you have some preference to keep translators/clients out of the admin, you can also ask them to translate from a spreadsheet (exported from PW) and PW will happily read that in and use it. 

Quote

Finally, you can't really bypass the interface since translations are stored in JSON files in, essentially, random locations, so adding translations directly in the code editor is impossible.

None of those 3 statements is true. Translations may be stored in JSON files, but they can be exported/imported (all files at once) to/from CSV files. 

Translation files are not stored in "random" locations. They are stored with the language's files, which is a static location identified by its ID. 

Adding translations in the code editor is not impossible, because where else would you add new translations, if not in the code? If you need a new translation, go ahead and add your __('text') in your code, and it immediately becomes available as a translation. 

Quote

ProcessWire's field translations suffer from the fact that they seem tacked on and not well thought out. 

You are welcome to your opinion, but as someone that put a lot of thought and effort into field translations, it's hard for me to take your opinions seriously when you state things like this. Nothing about them is "tacked on" or "not well thought out", quite the opposite. So to me it seems like at worst, you don't understand what you are talking about, or at best (and most likely), you just have an alternate preference. This is fine, but I don't think that's obvious to everyone reading. So please don't make statements like "not well thought out" when you really mean that something doesn't suit your preference, or maybe you don't fully understand it.

Quote

For example, regular text fields can be translated inline. But if you want to translate an asset field, you need to add the second language's field manually, which feels weird and looks bad and unintuitive in the interface.

I appreciate examples but I'm not aware of any field where you need to "add the second language's field manually". This does not sound at all like PW multi-language fields. If you are talking about PW at all, perhaps you are talking about the "language alternate" fields option? If so, this is an option that is there to provide additional flexibility for specific cases, but it is almost never used in my experience. Please don't use it as a foundation for any comparison, as its borderline deprecated at this point and I don't expect many will ever use it.

Quote

With ProcessWire, everything is homegrown. This makes it easier to get started at first, but hinders you in the long run, because there just aren't as many utilities, best practices and components to use for custom development.

This conclusion is the opposite of the truth. The fact that PW doesn't impose a specific framework upon you means that all options are open. Anything is available to you. It is more open, not less open. It's you and PHP, and anything you can run in PHP you can run in PW. 

Quote

ProcessWire's feature approach is a bit … chaotic, to say the least. 

ProcessWire feature approach is built around constant improvement. It is driven by the community and the needs of clients. The development of PW has always followed this approach. I have a job working with clients just like most PW users and so I develop according to what's needed and when. Most of my income comes from client work. I work on the PW core for free, so development usually has to have some crossover with the other projects that I work on. Despite being open source and largely unfunded, the fact that PW and Craft can end up with apparently similar capabilities and feature sets—and the fact that they can be compared at all—I would consider to be a sign of efficiency and that we are doing something right. 

If you consider our approach "chaotic" then fine, but the accurate terms would be "flexible", "sustainable", "consistent" and "continuous". The approach been very successful for PW as a project. And PW is also one of the longest lasting projects in this area (open source or commercial), and will continue to be because it's not built around money. 

Quote

The problem is that most of those feature are never completely thought out and are quickly abandoned. 

I don't add features without completely thinking them out. That's silly, why would we do that? I would never commit something to the core that has not been well thought out. I don't understand why you would say this unless you just don't understand it.  

Nothing committed in the core has been abandoned. Elsewhere, I've abandoned a ton of code, but most of it has never been seen by anyone. When I commit something to the core, I've spent a lot of time working on it and I'm also committing to supporting it, long term, for as long as there is value in it. That's another reason why I take a lot of time to think through anything that gets added. You are welcome to say that you have a different preference, and you can I clearly have different preferences, but please do not suggest something is not well thought out because that is not true. 

Quote

There's hundreds of features that look cool but just aren't well supported 

Well, I'm glad you think there are "hundreds" of features that look cool... though not well supported? I don't know what we're talking about. 

Quote

...they have bugs that never get fixed, they don't work well with each other and so on.

False. The only bugs that don't get fixed are those where they cannot be duplicated, or that don't have a clear solution and seem to be isolated to one person. And I don't know what you mean about "don't work well with each other and so on". 

Quote

A much more limited feature set that can actually be supported with documentation, support, integration with other features would be preferable by a long shot.

ProcessWire's core focus is already a limited feature set, where much is left to modules. The aim is to have everything you might "need" and do it really well, but save things you might "want" for modules. 

Quote

ProcessWire's docs are also helpful in general, though they lack a clear structure and hierarchy, making it hard to read it back to back or find specific pieces of content. 

This is one area where it certainly does help to have a big commercial company behind it, with full time documentation writers and such. While they do have a structure and hierarchy, I understand it may not be exactly the way everyone might want it. The site search engine is actually quite powerful and searches the API and all documentation pages, so I recommend that when you want to find something specific. 

Quote

This means the only way to discover or find info on those features is to root through old blog posts.

This is fair, and it'll continue to be that way, the blog posts can do heavy lifting in between the time that features are added and documentation is updated (as does this forum). The blog posts do also end up as the linked documentation for features in some cases. I'm okay with it. I understand that if we were a big company it might be odd though.

I don't put efforts towards pretending that PW is a big company, I work within the resources we have, putting most of it towards where it counts and less of it towards pleasing critics.

Quote

ProcessWire uses the first digit for marketing as well (ProcessWire 3). Unfortunately, it doesn't use the second digit at all, so we're still at 3.0.X years after the first PW3 release.

The aim is that all versions are compatible, meaning you can safely upgrade from any older version to any newer version. I don't know of any other projects that do this as well as PW, so I would consider it a major benefit. If we get to the point where this is regularly not the case, then we likely would adopt semantic versioning. But the need isn't there at this point in time. 

Quote

And the third digit is just incremented whenever there's a couple of commits that need releasing, so it doesn't have any significance beyond the ordinal scale. 

Close, but not totally accurate. New versions are currently aimed at a group of new related features or a group of issue fixes. The version number goes into systems that prompt people to upgrade, at the time it is appropriate to do so. They are also for documentation purposes so that we can easily reference them in "since" statements. Lastly, it's useful to have version numbers to reference in blog and/or forum posts. Currently this system of version numbers is the most beneficial one for this project. 

Quote

This makes it impossible to know if a given update will cause problems for you. Ryan has stated somewhere (can't find the link) that this is because there haven't been any BC breaks since version 3.0.0 so far, which is … not true. At some point, an update broke the ability to upload SVG files to asset fields if you don't have the FileValidatorSvgSanitizer module installed. If this isn't a BC break, what is?

This isn't what I'd consider a breaking change. This is something where it just asks you to install a module as part of an upgrade to the version, it doesn't break the API or the site, just locks down a specific admin feature for security until you install the appropriate module. And security always comes first in PW. But I don't think there are any actual breaking changes in PW. Again, if it became commonplace like it is in other projects, then we'd likely adopt the same version number approach they do. So perhaps that's something that will come in the future, but we're not at that point. I'm open to it at the appropriate time. 

Quote

ProcessWire meanwhile overloads the term template to refer both to content types and the PHP files for those content types, making it really hard to talk about those. 

A "template file" is a "file" for a "template". I don't know how to be any more clear than that. But yes there are instances where we're talking about template files that I might use the term "template" rather than "template file" since the context is established. I agree that terms like "template" and "file" are fairly generic, and it would be nice if templates were like cars where we could refer to the "car" but also have a label like "wheels" and know we are still referring to the bigger "car" above it. But "file" is a generic enough term that while accurate, needs context. 

Quote

ProcessWire is completely free, though there are the commercial Pro modules. Some of those are required for almost every site, in particular ProFields (for the Repeater Matrix), so the average site probably won't be completely free. 

I'll take it as a compliment that you consider RepeaterMatrix to be so valuable. The Pro modules were never intended to be "required" for any site. They are meant to be a luxury or a time saver, but there's nothing you can do with any Pro module that you can't do yourself by some other means. Though Pro modules might save you time in doing it. I've built example modules that show you how to do do just about anything that Pro modules can do, they just might require more of your effort. The original intention for Fieldtypes and Inputfields was that everyone would build their own according to their needs, but I don't know many that do that other than me. Have a look at FieldtypeEvents sometime to see how simple it is to do.

Quote

ProcessWire puts everything into a single page tree / hierarchy. This is handy in some situations, but all in all detrimental. First, you have to fit everything into a page hierarchy, even pages and content that don't have a natural place in the tree. This makes it harder for clients to find what they're looking for. 

I don't share your opinion on this. If you are of the mindset that the page tree reflects the front-end site 1-to-1 then you are in the mindset of a different system. I consider the tree to be essential, a major benefit, as you know everything has a place and hierarchy and you don't have to have various different kinds of navigations or buckets to find them. If you know one thing you know everything in PW. I've never been a fan of different bucket systems and the ambiguity that they introduce. ProcessWire was designed from the beginning to get away from what you are talking about, what I subjectively feel is a mess in other systems (again, my preference). PW aims to be simpler and more flexible than that, though pages can still be browsed as a tree or as buckets, even if the tree is the source.

Quote

This makes it harder for clients to find what they're looking for. Also, you're heavily incentivized to generate your site navigation based on the tree hierarchy, which is bad in the long run.

I don't agree with your premise, or the linked post. Having a link to someone else's opinion does not make it right, maybe just right for you personally, that's fine. I would agree that there are benefits to letting the page tree influence your navigation, but there aren't drawbacks to not using it that way either. 

Quote

ProcessWire is mostly maintained and developed by one person.

It may have started that way. While I am currently the gatekeeper in terms of maintaining the core I consider ProcessWire to be a long term community developed project, and it becomes more that every year. Every open source project needs someone to start it, and someone to be a caretaker, ensuring the quality of it, and I see that as my role, which I take very seriously. But this is a team project and one that is much more sustainable long term than a commercial one. 
 

  • Like 26
  • Thanks 5
Link to comment
Share on other sites

Thanks @ryan for  answering detailed on all this.

I have read the initial post this morning and found it quite ok at first to compare different (equivalent) systems.

Since I had a very tight day today and still have, I have not read very carefully, but had to think again and again in between times to the post. And more and more I came to the conclusion that there must be some "slipped" something. Above all, a much too egocentric approach that has almost exclusively the needs of their own agency in mind and the like. 
I had planned this evening, when finished my day's work, to read again in more detail and to formulate my impression in a post. For example, I don't know the other CMS and especially didn't know about their licensing model. That's really a bummer not to mention that! 

During the day, I had thought that the OP had formulated something unfortunate insensitive. Now I could come rather to the impression, that consciously one tries to produce a pressure, which manipulates the development in a direction favorable for the own agency. So all personal preferences in the CMS available, but without "annoying license costs". Between buddies one would say "nice try", but that's not it at all.

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

I am a bit confused as I didn't see @MoritzLost's post to be insulting. Maybe it is my week English skills. But I am pretty sure he was not writing it neither to show any kind of disrespect, nor to promote another commercial CMS. He is not a native English speaker either. And a much younger person than me (as far as I can tell by the photo)) I wish we could see through wording and get to the points that he was trying to make. And I am sure he is making them in an attempt to make his beloved CMS better. I know he enjoys PW by his thoughtful posts here, his modules and his processwire.dev website.

It is so easy to misunderstand each other. And sometimes it is hard to see ways to improve in criticism that sounds unfair. But if we can't handle it here, in our friendly home community, then who can?

 

  • Like 13
  • Thanks 1
Link to comment
Share on other sites

@Ivan Gretsky you are surely 95%+ right in what you say and I agree!

Except I do not agree with that youth is a universal excuse. And I find it a little dissonant that someone can write such very carefully worded posts with tutorials on the one hand and not recognize some obviously insensitive statements on the other.

But 95% or more consensus. 🙂 

  • Like 5
Link to comment
Share on other sites

@ryan Hey Ryan, this thread has definitely not gone the way I intended. I didn't mean to disrespect you or your work or to offend you, but I obviously have, for that I'm sorry. Thanks for still taking the time to address my points in detail.

I agree that my tone was off and I was a bit too flippant, leaving the impression that I just want to advertise Craft and dunk on PW. I don't want to convince people to use Craft, I have nothing to gain from this. This is why I posted this in dev talk where I think most people reading this post will be long-time users of ProcessWire who won't jump ship at the first mention of another CMS. This is also why I didn't bother to write out a list of everything that's great about ProcessWire (for the record, that's a long list!), because I think most people reading this already use and like ProcessWire and don't need to be convinced that it's great. The fact that a free CMS developed mostly by one person can be compared to a commercial system developed by a team in this way and hold its own at all is actually impressive!

I like ProcessWire, I've used it for years and still am. And I think I have contributed to PW a fair bit; I've pitched PW to dozens of clients and made sure the agency I work for buys the bulk licenses for most Pro modules. I've been active in the forum, I've written multiple open-source modules and an entire website dedicated to telling people about PW and how to use it well. I thought all this afforded me a bit of good faith when I'm writing something critical. Obviously I was wrong.

I just wanted to talk about some things that I found lacking in ProcessWire and where I thought Craft has a good solution that PW could benefit from. Admittedly, calling this a comparison was a bad idea and gave the wrong impression. It's definitely not a full comparison in this sense, it's list of good ideas and approaches that I liked in Craft and would love to see in ProcessWire. At the very least it was supposed to.

I'll try to address a couple of specifics below. For most of the talking points, I think your objections are valid and you're either right or there's arguments for both sides. I will leave out the points where I feel there's nothing more to be said for either site, or it's solely a matter of preference.

Honestly, at this point I feel this discussion is way more heated than the topic warranted, probably due to me missing the correct tone or making some way too sweeping statements. If you feel this post is in bad taste or in bad faith, feel free to delete this thread altogether.

3 hours ago, ryan said:

While much of Craft doesn't suit my own (and others) preferences, and may not be "well thought out" according to how I think things should work, I'm not going to join their forum and tell them it's not well thought out. That's because I respect them and trust that it's well thought out, according to their needs and preferences. So when you start telling someone that something they've put a lot of work into isn't well thought out, that's akin to saying that you do not respect them. 

You're right and I'm sorry about that wording. I didn't mean to imply that you didn't put a lot of thought and hard work into those features. What I meant to say was that some features don't work in particular use-cases which were important to me and that I don't think are super unusual or niche. In those cases, this use case was either not intended or not considered. And in those cases, the comparison to other systems (like Craft) has merit, if a similar feature is build in a different way that does enable those use-cases or is generally more flexible.

This applies, for example, to the translation system. It's based on file scanning, so I can't use it at all since all my projects use Twig for templating and translations in Twig aren't picked up by it. So in this case, the translation system wasn't built to support any use-cases beyond the normal PHP templating. A different design for this feature, for example separating the file scanning from the translation API and allowing developers to call the API to add translations from their own code, would have solved this and enabled more use-cases beyond the one that the feature was built for.

3 hours ago, ryan said:

In that link we are not talking about ProcessWire at all, and instead are talking about the processwire.com website in development, NOT the CMS. Why would you say I'm "opposed to the idea" of accessible development? This is something I'm interested in and passionate about. I don't understand why you are quoting me on one thing and saying another. 

The relaunched processwire.com website, at the time this post was made, had major accessibility concerns. And at a very basic level at that, starting with the primary color used for backgrounds which doesn't provide enough contrast against the white text. I haven't checked everything, but as far as I can tell those haven't been fixed. This is a very basic accessibility issue, so relaunching a website like that signals that accessibility isn't important to this project. Of course it's only the website and not the CMS itself, but public perception matters to.

I was referring to this quote in particular:

Quote

Regarding accessibility stuff, I have implemented several of the suggestions here like some of the items Teppo mentioned. Though should clarify there isn’t a specific goal of tailoring the site for visually impaired people at this stage.

To me, this demonstrates a lack of understanding of accessibility issues and goals. So I don't think I'm wrong in saying that good accessibility isn't, right now, a strong focus of ProcessWire.

3 hours ago, ryan said:

In that link, I'm writing about a module called ProcessUser and something that is imposed upon it for a specific security purpose, unique to that particular module, and no other. But you have used my statement as proof that building custom features in ProcessWire isn't encouraged or supported. Nothing could be further from the truth. I have never had such a thought. My thoughts and intentions would be exactly the opposite. 

Agree, that was worded way to strongly. What I meant here is that the architecture imposes limits on the extensibility and in this case, you didn't seem willing to rethink the architecture to enable use-cases that go beyond the regular interface provided by ProcessWire. I still think this issue can be solved without compromising security or anything, by decoupling the logic for security checks from the CMS routes. I argued for that in the issue and haven't gotten a reply for over half a year now. To be, this signals that extending PW user accounts in this way is disouraged and shouldn't be done. Again, though, you're right that my statement here was way too sweeping.

3 hours ago, ryan said:

The problem with chaining methods for this is that they are live code, you can't store them. Perhaps it has benefits in Craft, but they would not be appropriate for PW. 

In PW selectors can be specified as arrays or strings, and in cases where you want to separate the query property from the query value, then that's why we have the array option in PW. And yes, they are reliable, despite your claim that they are not. 

I'm also addressing the next couple of points here. The problem is that it's very easy to shoot yourself in the foot. In fact it's trivial to create an injection vulnerabilty:

$category = $input->get('category');
$newsWithCategory = $pages->get("template=news, category=$category");

Of course I can sanitize the category input to make it safe-ish, but I have to remember to do that every time and it's easy to get wrong. This is why we use prepared statements instead of string concatenation for database queries with user input, to separate data from commands. So in this regard, the string-based selectors feel like a step back to me.

3 hours ago, ryan said:

Saying "clunky" is a subjective and hardly fair statement to make. What might be clunky to you is optimal to others. You are writing specifically about the file translation system, so the whole purpose is to provide an interface to translate your site php files (primarily template files). The interface is geared to focus on that task only, and that's the point of it. 

I understand you value more layers between things (like with Twig), but I always prefer fewer layers, a more direct approach, so you'll see that throughout PW. If I'm using a file translation system, I want to know what file I'm working with and I want to be able to tell the translator what file to work with. That my preference, and I understand you have a different one. 

That's fair. My point is that the interface is very close to implementation details, translations are grouped by the file they're located in. For clients who don't understand or care about those details - for example, that don't know anything about the template structure or indeed that there are templates at all - it's harder to use than it needs to be.

3 hours ago, ryan said:

Translation files are not stored in "random" locations. They are stored with the language's files, which is a static location identified by its ID. 

What I mean is that the German translations might be stored in something like site/assets/files/10942 and to find that number I have to go to the backend and check. I can't just hit CMD+P in my editor, type in 'german' and get the appropriately named translation file immediately.

3 hours ago, ryan said:

Adding translations in the code editor is not impossible, because where else would you add new translations, if not in the code? If you need a new translation, go ahead and add your __('text') in your code, and it immediately becomes available as a translation. 

I meant typing in translations in the code editor, see the point above.

3 hours ago, ryan said:

I appreciate examples but I'm not aware of any field where you need to "add the second language's field manually". This does not sound at all like PW multi-language fields. If you are talking about PW at all, perhaps you are talking about the "language alternate" fields option?

As far as I can tell, the language alternate fields are the only way to make fields translatable that don't come with a multi language variant. Like asset fields. If I want to allow an editor to provide a different image in the same asset field in multiple language, is this possible without language alternate fields? Last time I tried this I didn't find anything. Correct me if I'm wrong.

3 hours ago, ryan said:

Well, I'm glad you think there are "hundreds" of features that look cool... though not well supported? I don't know what we're talking about. 

The lack of documentation is a big thing. If I have to do some Google woodoo to find a blog post or forum thread from 2019 to figure out how something works, it's not well supported in my opinion.

 

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

Like it or not but when reading both posts, to me Ryan clears it objective and Moritz brings it subjective.
Processwire can hardly be labeled or compared with established cms systems out there because Processwire
gives almost unlimited -never seen before- freedom in how to use it. Only recognizing this unlimited freedom
to a certain level, because of habitual coding and thinking learned from other systems can bring up
such comparisons.

 

 

  • Like 1
Link to comment
Share on other sites

Not sure how it goes and if the whole thing gets deleted for the good))

But I can agree with some points laid out and wish we could talk them out and improve on them. Just today I was chatting with a client representative on a project she works at for more than 2 years. And she said that she still cannot imagine doing strings translations by herself as it is way to hard in her opinion. This is a 10+ langs multilang project, so it matters. I admit, she might not be very bright, but everybody else on the team is trying even less)) Maybe it is because we are using lots of included and rendered files and so on. But the case exists.

Managing multilang images is kind of not so easy too, but it can be done with something like image tags.

  • Like 4
Link to comment
Share on other sites

14 hours ago, MoritzLost said:

Though I've noticed a trend that the most valiant defenders of plain PHP templates are the the ones that have never given Twig a serious try 😗

Sarcasm (scnr):

I've noticed lately that the most valiant defenders of the opinion that PW lacks support for migrations are the ones that have never given https://processwire.com/modules/migrations/ (which dates back to 2016) and https://processwire.com/modules/rock-migrations/ (which has it's 3rd birthday next week 😎 ) a serious try 😗 😉 

Personal note:

While I did not read your posting as offending as Ryan seams to have read it I can totally understand his reaction. I have not put a fraction of the time into ProcessWire compared to Ryan but still I was confused about some statements you made. And I know how it feels if you talk about things in a way you did in this thread and in a similar way you did in this thread and in this thread. It might not have been your intention, but it seems you are a bit quick in stating "how things are" and how they have to be...

Back to topic (and I try to keep objective):

-- Selectors --

Ryan has already answered here. I just want to add that I'm using array syntax for selectors a lot and I really like it 😎  BTW: Just noticed that it's also a birthday for selector array syntax: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support Happy Birthday and thanks for being with us and being a reliable tool in my everyday work for the last 6 years 🥳

4 hours ago, MoritzLost said:

I'm also addressing the next couple of points here. The problem is that it's very easy to shoot yourself in the foot. In fact it's trivial to create an injection vulnerabilty:

$category = $input->get('category');
$newsWithCategory = $pages->get("template=news, category=$category");

Could you please explain the vulnerability here for others to learn from your example?

-- Features --

I just wanted to share that I've had quite the opposite experience with a lot of tools that I've tried over the last view years. At first sight there was a lot of bling bling and shiny cool things, but at second sight I found limitations here and other annoying parts there. Maybe I've just tried the wrong tools but with ProcessWire my experience was exactly the opposite: My first impression was that it is by far too simple for what I need. Several years later I feel like I'm just scratching the surface 😅

-- Twig --

I'm SO happy that we don't have such a layer by default in ProcessWire!! I've not worked much with template engines but I've used smarty back in 2004 so it's not that I don't know that such tools exist or what they are for. Though what I do a lot is keeping my template files as clean as possible. How I do that? I use custom page classes everywhere and if I need just a little bit of logic somewhere I put that logic into the page class to keep things simple on the frontend part.

What I really like here is one of the biggest benefits of PW of all: It keeps simple things simple and makes complex things possible (and fun). If you have just started (with PW or with web development in general) you can simply echo some page properties and see the result on the screen. No additional tools. No necessary build chain. No template engine. Just PHP and HTML. Great 🙂  In my opinion 😉 

I've recently had to try another open source CMS. That CMS has native support for migrations as everything goes into YAML files. It has fancy backend editing for everything. Fancy, yes. But that adds another layer of complexity to the whole thing as well. Imagine how long it took me to understand how I can create a single field and display the content of that field on the frontend? Long. Very long. I don't want to tell you how long. 😄  Because of all that fancyness that system uses a custom language for rendering all the fields. It was a terrible experience for me and I felt really bad that I as a quite experienced PHP developer was not able to achieve simple things in a PHP based content management system.

One user commented on one of their youtube tutorials that it's another perfect example of a german product developed by a few geniuses but impossible to use for the average dev. I agree with him and I'm happy that ProcessWire takes another route!

-- Documentation --

I agree that lots of information is scattered around somewhere (in the forum, in the docs or in code), BUT (and that's the part you didn't mention and which is just another example of why things might be taken personally): In my opinion ProcessWire (or Ryan) does a lot right in that regard and is way ahead compared to other tools I've used (maybe tried the wrong tools again).

For example the docs in code are absolutely great! Nearly every method that I need to inspect has some explanation directly in code so I can quickly jump to that place in my IDE or even get helpful pieces of the docs instantly as tooltip:

UIrVtjn.png

Next, the forum: WHAT A GREAT PLACE!! 

I've been on another system before I discovered PW. They had a forum as well... But I simply did not get help there. I posted a question and did not know if I'll get an answer in one week or two, if ever. That was such a pain and PW is so great in that regard! It might be a small community but the support is outstanding. I've also seen other products that have a discord channel or something similar. Maybe forums are old-school, but in my opinion they are still great and will be for a long time. You have an archive where everybody can find answers to their questions and learn from posted answers. And one other great thing is that 90% of those answers will likely still just work if you apply them today even if they are several years old.

-- Version numbers --

What I'd pick up from that point is that some of the strengths of PW might look like weaknesses for others on first sight. Just as the simple and clean backend for me looked like PW is not capable of complex things the used version numbers and the fact that the github master branch might not see any updates for several months can give the impression to others that the project is not actively developed. It's a matter of everybody's perceptions and expectations.

ProcessWire could to more in that regard. But on the other hand I really appreciate that it (or Ryan) does not care as much about that as other systems do. The downside of this is that it can be hard to sell to other devs and/or clients...

-- A word to Ryan --

8 hours ago, ryan said:

Have a look at FieldtypeEvents sometime to see how simple it is to do.

I don't agree with you here and I think that's a blind spot on your end. 😉  When I started developing my first custom Fieldtype it took me quite long to understand how things work. Learning from the events fieldtype was really hard! It is obvious and simple once you know how all the pieces play together (you basically just need an inputfield and a related fieldtype for sleep() and wakeup(), right?) but it was really not easy to start with a blank screen in my IDE without having this concept in my head and then put all those pieces together one by one trying to understand what they do and then making them do what I want. I guess we didn't even have TracyDebugger back then. 😳  (By the way - how great is Tracy?! Another invaluable tool in our Ecosystem that I don't want to miss!)

I think it's similar to what happened when I first discovered the PW backend. This was one of the most liked posts in the forum so I think it was and maybe still is not obvious to many how easy it actually is to work with and customize the PW backend. As a side note I think that might be one reason why PW is still underestimated in regards to being not only a wonderful tool to create websites but also a wonderful tool to create web applications.

And I have to do it again: I think RockMigrations is just another example of something in PW that looks more complex than it actually is. And an example of something that looks less powerful than it actually is. I've taken that learning from the other threads and already improved the module greatly. The next version will make it a lot easier to get started with. Maybe that will open some eyes.

And maybe Ryan will also revisit this thread one day and will recap and pick up some of the things that were mentioned. There were some good points in it and the amount of reactions shows that, I think. So thanks for bringing those topics up @MoritzLost and thanks for the insights as always @ryan.

  • Like 12
  • Thanks 3
Link to comment
Share on other sites

Another 2 cents for the "not an essentiall comment"-jar.


1) WHAT A GREAT PLACE!! (by @bernhard)
Indeed. This is one of the most friendly, most awesome and most advanced communities around.
Hands down. This is almost a bit like "family" - at least for me.
Thank you!


Therefore...

2) Discussions like this are needed. Really!
They are... hard to digest.
Unfair.
Emotional.
Yet worth it at the end.

I think ... first of all there are two people here that might want to "enjoy" a 1:1 discussion to clarify things. As both have very good and honest arguments here. This "clash" could and will be good. I personally think that there was only a slight offset in communication and perception - to be honest.
Both aren't far away from each other.

I personally hate/love those discussion in projects because they become super emotional right from the start and it takes way too long to calm each and everyone down to a common ground afterwards. Especially when there is a large team around that fires up the situation. Oh.
But most of the time the project benefits from it. Therefore my idea of a 1:1 here.

I personally enjoy giving harsh feedback.
While I hate receiving harsh feedback.
But that's life... I guess.
We grow with it.

It's sad that all comments "against" ProcessWire CMS/processwire.com end at one point aka @ryan.
I don't know Ryan in person but still a bit through various discussions in various boards, threads and messages and really enjoy all of his insights, feedbacks and even more for what he has built and builds here - with ProcessWire. 

Has anyone ever noticed that he dedicates his sundays for this community?
So much love for this!

That's why I fully understand and support Ryan's post and feedback.
Even though while Moritz has some good points as well.
I understand Moritz's points here in some kind.
I have my very own personal issues with ProcessWire CMS - some days more, some day less but most of the time I praise ProcessWire as the best solution ever. As it is for me and my projects.


3) Takeaways so far - for me (you are free to argue against my perception)

This thread was and is some kind of bumpy but as Ryan, ProcessWire, and this community are... this is just another challenge we will laugh about in 12 months and enjoy what happened in the meantime all together.

4) Future outlook

Maybe we as a community, devs, friends, however you want to call it should start outlining things WE could do.
Not only demanding things and asking for whatever.
Maybe we could offer solutions instead.

Designers could create a new visual look.
Marketers could offer USPs and target-group analysis.
SEOs could work with that and look up whats interesting compared to other CMSs.
AND. SO. ON.

I can offer the SEO aspect in this, maybe frontend templates for very fast loading and awesome Google Insight numbers. Count me in on this!

Ok. Ok. I put 2 dollars in the jar.

  • Like 7
  • Thanks 1
Link to comment
Share on other sites

I figure this is an off topic board among friends here (like our pub, or a real one) and it’s okay to write with honesty and engage in spirited or sometimes heated conversation. So just want to be clear that I like and respect @MoritzLost and value his opinions, even if I don’t agree with all of them. We will all have a diversity of views and everyone should feel free to share them, and likewise others should feel free to question those or state their own, which is what I’m trying to do. But I’m glad MoritzLost shares his opinions here. Plus, a little controversy also helps to engage the community, and drags me out of the code for a bit, so I can’t fault anyone for that. 

Once I can state my thoughts, I carry no concerns, but thought I should defend the things that deserved defending, as I always should. As a caretaker of this project, part of my responsibility to add my honest point of view to a conversation like this, especially when something is posted where I don’t fully agree. I think many in our community know the subjectivity of statements here (whether OP’s, mine, or another’s), but an equal number may not, as this is a public board. So some counterpoint or back-and-forth is not only clarifying to the larger audience, but also useful, as we explore different facets of it all, and lead to the most important takeaways. 

I appreciate that MoritzLost continues to defend his point of view on parts, despite my own defense or heated questioning of those parts. It helps me to better understand and know which are the parts that he thinks are most important and deserve the attention. We obviously don’t have the resources to pursue everything Craft does, so narrowing in on the most important parts—the meat of it—is helpful here. 

I’m traveling right now so can’t participate as much as I’d like to at the moment but just didn’t want MoritzLost or anyone else to think I was angry or something. Likewise I didn’t want anyone else to think they had to moderate themselves either. When I’m among friends I feel comfortable to express and be honest, and so should you. If you get a heated reply from me it’s because I care about it and value your opinion. I’ll spend more time reading everything when I get back, but I can see already it’s a good and helpful discussion. 

  • Like 20
  • Thanks 4
Link to comment
Share on other sites

Thanks everyone for the valuable comments! I think it's great that we can return to a good discussion here after the bumpy start (which I'm certainly not innocent of as mentioned above). Hopefully nobody needs to hold grudges now. Thanks to Ryan in particular for the good summary regarding those issues. I think everything has been said regarding the interpersonal stuff now so I'll leave it at that 😌

On 4/2/2022 at 1:26 AM, bernhard said:

Could you please explain the vulnerability here for others to learn from your example?

@bernhard Given the above code example, I can add everything I want to the selector in the query parameter: https://example.com/?category=5,%20include=all
This will result in the following selector: template=news, category=5, include=all. So now I can look at unpublished or hidden pages that the editors may not want me to see. This can be solved by sanitizing the query parameter, in this case with $sanitizer->int() or $sanitizer->selectorValue(). But this is something I have to do manually and remember everytime and everywhere it's used. And while it's simple for integers, it gets a bit more involved with strings. Finally, all of this relies on the implementation of $sanitizer->selectorValue() not having any vulnerabilities or implementation bugs, and no software is bug-free. You can solve all this, but reducing the surface area for issues like this is still really valuable.

This isn't unique to ProcessWire, the other day I read a blog post regarding a known vulnerability with filter_var that hasn't been fixed yet …

On 4/2/2022 at 1:26 AM, bernhard said:

I've recently had to try another open source CMS. That CMS has native support for migrations as everything goes into YAML files. It has fancy backend editing for everything. Fancy, yes. But that adds another layer of complexity to the whole thing as well. Imagine how long it took me to understand how I can create a single field and display the content of that field on the frontend? Long. Very long. I don't want to tell you how long. 😄  Because of all that fancyness that system uses a custom language for rendering all the fields. It was a terrible experience for me and I felt really bad that I as a quite experienced PHP developer was not able to achieve simple things in a PHP based content management system.

Sounded like Drupal up to the last two sentences 🙃 You're right, having native support for migrations and config schemas doesn't guarantee the system itself will be usable. But on the other hand, you can have the best of both worlds and have an easy to use system with support for all those features.

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

On 4/4/2022 at 12:48 PM, MoritzLost said:

@bernhard Given the above code example, I can add everything I want to the selector in the query parameter: https://example.com/?category=5, include=all
This will result in the following selector: template=news, category=5, include=all. So now I can look at unpublished or hidden pages that the editors may not want me to see. This can be solved by sanitizing the query parameter, in this case with $sanitizer->int() or $sanitizer->selectorValue(). But this is something I have to do manually and remember everytime and everywhere it's used. And while it's simple for integers, it gets a bit more involved with strings. Finally, all of this relies on the implementation of $sanitizer->selectorValue() not having any vulnerabilities or implementation bugs, and no software is bug-free. You can solve all this, but reducing the surface area for issues like this is still really valuable.

This isn't unique to ProcessWire, the other day I read a blog post regarding a known vulnerability with filter_var that hasn't been fixed yet …

You won't believe it but this is really a big issue in some kind. Not really in terms of ProcessWire but in terms of devs.
I recently got part of a team to manage existing ProcessWire websites and... yes... no $sanitizers were involved at all.
Can't and won't blame anyone for this. Ok... sure... I could but I won't.

On 4/4/2022 at 12:48 PM, MoritzLost said:

Thanks everyone for the valuable comments! I think it's great that we can return to a good discussion here after the bumpy start (which I'm certainly not innocent of as mentioned above). Hopefully nobody needs to hold grudges now. Thanks to Ryan in particular for the good summary regarding those issues. I think everything has been said regarding the interpersonal stuff now so I'll leave it at that 😌

My 2ct-opinion on this:
That's why I call this the most awesome community ever! (This is a USP, take a note!)
We could blame each other in some kind or lay open things that don't match/work at all, yet... after some rumbling everything most of the time turns to the better.

And to be fair... I have never ever encountered anyone assaulting anyone here.
Rough wordings, maybe. Yet... being direct is needed sometimes.

 

Thank you @MoritzLost for the insights and even for starting this discussion in some way here. (yes... that's my personal opinion!)

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Interesting discussion, and I'll add a rather ironic perspective.

I inherited a largely non-functional website project that someone else had built in Craft, about 3 years ago, and at the time I found the Craft documentation wasn't particularly clear, whereas I worked out how to use ProcessWire after about 20 minutes of reading the documentation.

I converted the whole project to ProcessWire, and actually got the project functional. I had to write several custom modules and deal with a lot of hooks and set up CRON jobs to interact with a third party API, and I found ProcessWire a pleasure to work with.

That said, I can understand that there are pain points for some people with ProcessWire, and it's always good to look at other systems to see how they do things in case there's something useful that could be incorporated into ProcessWire.

My personal preference other than ProcessWire is Umbraco, which is built on ASP.Net rather than PHP, but in many respects is similar, so I don't have a problem jumping between PHP for ProcessWire and Razor syntax and C# for Umbraco. It also is an open source project, but with commercial add-ons like a form builder (which makes ProcessWire FormBuilder look cheap). Now that .Net and SQL Server run on Linux, it's potentially even more appealing to me, although ProcessWire is still my first choice.

Currently I'm a solo developer, but as my workload grows, and also clients are starting to ask for an insurance policy in case something happens to me, the potential to be able to manage collaboration on projects is something that's increasingly on my mind, and out of the box, this isn't something that ProcessWire handles, although there are third party solutions like RockMigrations by@bernhard 

  • Like 8
Link to comment
Share on other sites

On 3/31/2022 at 2:01 PM, MoritzLost said:

Roadmap and feature policy

ProcessWire's feature approach is a bit … chaotic, to say the least. New feature seem to be added whenever ryan thinks of something cool to add.

I was thinking about this argument and this is something I also wish that could be improved.

There doesn't seem to be a roadmap anymore. The current roadmap is from 2019: https://processwire.com/about/roadmap/

I think it would be nice to revive the roadmap or at least make a poll for what the community is wishing for the most. The last poll was at the beginning of 2021.

The current approach that a feature will be added if @ryan has the need for it on a project is not bad, but that leads to many developer centric and less client centric features, which I personally often don't use, because there are already so many developer centric features. 😀

  • Like 8
Link to comment
Share on other sites

On 4/11/2022 at 2:54 AM, Kiwi Chris said:

whereas I worked out how to use ProcessWire after about 20 minutes of reading the documentation.

Super OT:

When I started using ProcessWire I only knew the templating syntax of Textpattern and was fine with it as it handled everything I ever needed. (I loved it! Really.)

All I was able to do in PHP was a Hello World!. Within a day or two I moved my personal site from TXP to PW, launched a side project within the first week, did a rebuild of other side projects in the first few weeks and a real-life-project shortly after that run for about 5 years. Best learning experience ever!

So yes... you can even learn the basics of PHP while using ProcessWire and go from there. Maybe PHP-Dev-Starters should use ProcessWire as a starting point - yes, that's my real and honest opinion. The tutorials and (later on) the docs can do that!

  • Like 8
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...