Leaderboard

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 ? 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: 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 -- 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.

A few weeks ago I told you about a new module I was working on that automatically saves front-end form submissions and can send email reminders for the user to finish their form. The module is called FormAutoSaver. This week I finished up that module and have released it both in the ProDevTools board and the FormBuilder board, and it's available for download now. Note that it is first release/beta test version right now. This module can be used with or without FormBuilder. Though when used with FormBuilder it is more of a turn-key setup that can be done in the admin. I've put together a dedicated FormAutoSaver documentation and information page on the site, so rather than repeating a lot of information here I'll point you to that, if you are interested in it. I also wanted to mention that a new version of FormBuilder has also been released this week (v52). There aren't any major feature additions to write about here, but there are several small improvements and bug fixes. By the way, I've added FormAutoSaver to one FormBuilder form on this site: the site submission form. There's not much to see, since it silently works in the background. But if you want to try it out, fill-in some or all of the form (making sure to fill in your email address), but don't submit the form. Feel free to leave the form or even switch devices. You should get a reminder email in 5-10 minutes with a link to finish your form. While you are there, please submit recent sites you've built in ProcessWire, we love seeing your work! My kids are starting spring break from school next week, so I'll be mostly offline and likely won't have any updates next week, but will be back to core updates after that and hopefully getting ready for a release candidate of our next master version shortly after. Thanks for reading and have a great weekend!

The problem: how to refresh a page's frontend content in real time without a page refresh when the page has been edited in the backend. This is an alternative approach to the one discussed in the topic below. The above topic attempts to solve the problem using SSE. The solution in this topic instead relies on Local Storage and htmx. There is no ajax polling. Please note that auto-refresh here refers to a page refresh during the same session and in the same domain. It is not cross-site. The solution can be summarised as follows: Use a hook in ready.php to inject custom JavaScript to the ProcessWire backend admin, specifically in ProcessPageEdit. This can be a JavaScript file or inline script. The purpose of this file is to update a given Local Storage key after a page has been edited. Instead of listening to the Save Button click, the script just checks on load if a certain hidden input whose value matches the page currently being edited is present. This hidden input is placed inside ProcessPageEdit form using a hook as detailed below. The hook in this step #1 can be: $this->addHookAfter('AdminTheme::getExtraMarkup', null, 'hookAddCustomScriptsToAdmin'); In ready.php, add a hook to listen to saveReady(), e.g. $this->addHookAfter('Pages::saveReady', null, 'hookNotifyFrontendOfBackendPageSave');. When the page is saved, the handler method hookNotifyFrontendOfBackendPageSave will check if there are changed fields. It will then write to a temporary session variable for the current page with the names of the fields that have changed. On page load/reload, there is a hook in ready.php that monitors ProcessPageEdit, i.e. $this->addHookAfter('ProcessPageEdit::execute', null, 'hookAddMarkupToNotifyFrontendOfBackendPageSave'); The handler hookAddMarkupToNotifyFrontendOfBackendPageSave will check if there is a session variable set in #2 indicating that the page has had recent changes in the fields names set to that session variable. If this is true (that there have been changes), this hook will simply append the hidden input in #1 to the ProcessPageEdit form. The JavaScript in #1 will detect the presence of the hidden input. It will then amend the Local Storage value in #1. It cannot simply set the value to the ID of the page being edited as that will not be construed as a change. It will instead append a timestamp to the id of the page as well and set that as the value. This will enable a listener in the frontend, described in the following steps, to detect that change. In the frontend, we have a simple JavaScript file that listens to changes to the Local Storage storage Event. The frontend also has a simple hidden input in the template file whose pages we want to refresh. This hidden input has htmx attributes. Its trigger is a custom event 'autorefreshpage'. It will listen for this event before firing a message to the server. This hidden input also has hx-swap=none as nothing will be swapped to it. Instead, the server will send back results of changed fields in various markup with hx-swap-oob=true. That will enable swapping markup in any parts of the frontend html in one go. When the Script at #4 detects that a given Local Storage value has changed, it first checks if the page ID for that Local Storage value matches the page ID of the page currently being viewed in the frontend. If the answer is yes, it will fire the custom event autorefreshpage. This will make htmx fire a message to the server whose only value is the page ID it has been passed. On the server, in home.php, we have code that is listening to ajax requests. If it detects an ajax request, it checks if the page ID that htmx sent matches an available session that was recently updated. This would be the temporary session detailed in #2 above. If a match is found, it calls a function in _func.php that will set variables for fields for that page. These use partial templates (optional). These partial templates are for different outputs of the page, e.g. images, headline, etc and all their markup have hx-swap-oob='true' in appropriate places. All these content is sent back as one output back to htmx. It will read the hx-swap-oob and find the markup to replace in the DOM using the html IDs of the markup with the hx-swap-oob. This approach allows the developer to have maximum control over what to send back to htmx and over the markup. In this step, we also delete the temporary session, ready for the next updates. The result is as demonstrated below. A simple and effective DOM swap that places very little strain on the server. I'll clean up the code for this and upload to GitHub. This approach will not work with Save + Exit and similar :-).

Totally agree. ProcessWire is so amazing I wish I could grow with it in larger scale projects. Totally disagree. At work we are 3 devs at the moment working on the same projects all the time and we have fully automated deployments both to staging and production. And it is easy to review and merge pull requests. And I've shared all that is necessary with the community. For free. And so has @LostKobrakai @MoritzLost Please stop stating your points in a manner that discredits the work of others or the way how others are working. Thank you. We have wire shell. Why don't you take up this project? You are obviously in need of such tools. Why do you keep bashing around and do not help improving the tools that we already have or help to make new tools being created and - also important - being shared with the community? I like that you bring up all those points, but I really don't like the way you are doing this. Imagine someone evaluating ProcessWire and somehow finding your thread or reading it by coincidence. Even if that person will likely not read it with the same emotions that I do he/she will still get an - in my opinion - wrong picture. I think it is in the interest of all of us to promote the things we have and to encourage everybody to take part.

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: 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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". 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

@horst Your assumptions were all right. Argh, it happened quite more than once that i simply forgot about that. Thank you very much for your brief and clear explanation. @bernhard @Robin S Big thanks also for your advice and details.

It's not different between frontend and admin - I just used that in my screenshot to show the as-yet-unsaved image. So you do have to watch out for it in template code too. Suppose you have a busy site and you're using getUnformatted() in your template code. If a website editor accidentally uploads the wrong image (you can imagine some worst-case scenarios here!) but then notices before they save the page, that temporary image might have already been displayed and viewed on the frontend via getUnformatted().

True, but just want to point out there can be occasional "gotchas" when doing this because PW sometimes returns things that may be unexpected in the unformatted value. For example, the unformatted value of a Page Reference field will include unpublished pages and the unformatted value of a Repeater field can include "ready" items that are not populated in Page Edit. And in the case being discussed here the unformatted value of an images field can include "temporary" images that have been uploaded in Page Edit but the page has not yet been saved. So in the example below the frog image is saved but the fish image has just been uploaded but not yet saved, and might yet be abandoned before saving because of being a mistake or unwanted. Yet it appears in the unformatted value:

Hey @Ivan Gretsky Good question, and sorry for taking a while to respond ? In this case the first example was, simply put, a mistake — it didn't work at all. Thanks for spotting that, it's fixed now in the docs ?? As for a best practice of sorts, in my opinion in Controller context one should preferably refer to view as $this->view. Referring to it as $this->wire('view') or $this->wire()->view etc. will work as well, but there's a slight chance that it's a different view. To be honest the "different view" situation is a bit of a border case, and something you're unlikely to run into, so usually this won't really matter. It could, though, happen if a) someone has intentionally provided a new View object to a Controller or overridden the $view API variable (in site/template level code or a module), or b) while using ProcessWire's multi-instance support and rendering content from two instances simultaneously. Personally I also prefer $this->view because it makes sense to me and is (IMHO) syntax wise cleaner than the alternatives. Components are indeed a bit different. First a little dive into the technical background: The Component base class extends ProcessWire's WireData class, and thus when we set $this->title in the example above, what actually happens is that the value gets stored in a local data array, so that $this->data['title'] now contains the value we set for title. When the component is rendered (Component::render() is called), everything stored in that local data array is passed to an instance of the ComponentView class, which makes it available in the view file. In other words the View object doesn't come into play at all. ComponentView has certain similar qualities to View, but it's more limited (in both features and scope). And when I say scope, what I mostly mean is that components are intended to be their own "sandbox", so that what happens in them doesn't directly affect the "outside context", i.e. Page specific view(s), or the layout. What happens in your last example is that you are storing a value in the "global view" instead of the local context of the component in question. This does make it available in the component, since ComponentView extends ProcessWire's TemplateFile which in turn makes it work, but I would say that this working (in some situations) is more a side effect than an intended result ? The reason it won't work when rendering components outside of templates fully handled by Wireframe is, as far as I can tell, that in this situation only the necessary parts of Wireframe are initialized. Global View API variable is not one of these. (Honestly this is somewhat fuzzy area for me, and I would've expected $this->view->headline to throw some sort of notice/error.) Reading your post does make me wonder if components should actually provide a "fake view" to make passing variables to their own view layer more in line with controllers, but at this time I'm unsure if this is a good idea. Technically speaking it would be a backwards compatibility break, since someone might currently rely on having access to the "real view". Anyway, this is probably a bit off-topic; the long story short is that "yes, data is passed from components to their views in a slightly different way" ?

@bernhard At one time a module was written to manage customer orders. In 2013, Apeisa published Shop for Processwire version of DEV. There were a lot of interesting points there that we used. Payment gates with our bank were gradually added. Most importantly, it's all written for the kind of commerce our store uses. Usually CMS for trading offer their own trading algorithm. And this is not always convenient.

@clsource Nice article. All in all, very true. However, I disagree with one point. At one time, I went through a lot of CMS in search of a basis for the development of the store. In the case of complexly organized product hierarchy, all other CMS do not allow to implement an effective solution. And only ProcessWire makes it easy to implement the most complex hierarchy. At the same time, it can handle the load of a million requests. Moreover, I started my work in 2013. Now ProcessWire has many more features and capabilities.

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.

@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. 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. 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: 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. 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. 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. 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. 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. I meant typing in translations in the code editor, see the point above. 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. 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.

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?

Padloper 2 has been released I will write a better post later. Need to know for now: Get it from here. We will be transitioning to a new website and/or shop in due course. For now, please get it from that old site. For now, and to allow it to bow out gracefully, initial purchases will be powered by Padloper 1. All hail Padloper 1 :-). Due to #2, and #3 and due to non-SCA compliance on that particular site, there might be Stripe issues. Apologies. Please contact me for help. Support for Padloper 1 has ceased. Security fixes will continue. Things I have promised to look at will be looked at :-). Support subscription period for beta testers' purchases commences today - 30 March 2022. It is a special day...in more than one way... Update 3 April 2022 Frequently Asked Questions A few questions are coming up with respect to this release. For now, I'll answer them here but might start a new threaded dedicated to FAQs. Q: Will beta testers have to purchase a new licence for this release? A: No. Your licence and download link are still valid. The only difference is the countdown of your VIP support commences on 30 March 2022. Subscriptions and updates are valid for one year. This download link was emailed to you when you purchased Padloper 2. Please contact me if you do not have a download link. Q: I have shops built in Padloper 1 that I'd like to migrate to Padloper 2. I don't have the expertise and/or time to do the migration myself. Is there paid support for this? A: Yes, paid support is available. We can migrate your Padloper 1 shop to Padloper 2 per your specifications. This includes both backend and frontend migration. You can purchase either or both backend and frontend migration. Please contact me to discuss. We will soon add this custom work information to our website. Q: Is there a backend/admin demo of Padloper 2 that I can test pre-purchase? A: Yes. We are currently putting final touches to it. An announcement will be made here once this is ready. Q: Which is now the official Padloper support forum? A: This forum will eventually become the official Padloper support forum Although it is a public forum, we will still be able to offer VIP support. The only difference is downloads will be not be available in the forums, since it is open. Support via email will still be available as well. Q: I am getting a called to undefined function bcmul() after install. What does this mean? A: Please see the minimum requirements for Padloper 2. You will need to install the PHP extension bcmath on your server. This is in order to get accurate rounding off of currencies.

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.

Hello I wrote this small article https://dev.to/clsource/processwires-pros-and-cons-2o8n I would love to know if there any other considerations or ideas regarding that article. Thanks ?

I think a couple of ways are possible. One is similar to what @horst suggested, but you can use the special created timestamp of 10 to more exactly identify temporary images: $page->getUnformatted('images')->find('created!=10') There are also the public Pagefile::isTemp() and Pagefiles::isTemp() methods that can be used to check if a particular Pagefile/Pageimage is temporary or not. Another way would be to set the outputFormat property of the images field to array before you get the field value so that the value is standardised for single and multiple image fields. $page->getField('image')->outputFormat = FieldtypeFile::outputFormatArray; // Now use $page->image

Thanks for the detailed explanation. @3fingers, I have come up with an alternative solution to your original question. It does not use SSE but uses htmx and Local Storage. It is detailed and demonstrated in the topic below:

@kixe No. That's not how it works now. // Single select example $page->of(false); $page->multy_select_field = PageArray( wire('pages')->get(1111) ); $page->save(); $page->of(true); // Multyple select example use construction $a = PageArray([ $page1, $page2, $page3 ]); $page->of(false); $page->multy_select_field = PageArray([ wire('pages')->get(1111), wire('pages')->get(2222) ]); $page->save(); $page->of(true);

No doubt. But how do you manage all the e-commerce stuff that has to be done besides managing your products?

It looks like there's a compatibility issue between modules TemplateEngineFactory and TemplateEngineTwig in current PW master and dev versions. I use the "Add Module From Directory" form: * With TemplateEngineFactory and it installs version 1.1.3 (no update available) * With TemplateEngineTwig, it chooses version 1.1.0 and reports a compatibility issue: So I can't install it. I'll try to install it from the sources but I did want to report that issue.

@bernhard At first glance this can work, but I need to do some thorough tests against different cases/situations/states a page and images can have. It's just the first shot that came to my mind: $page->getUnformatted('images')->find("created<{$page->modified}")

Just a guess, but could this be a namespace issue? Have all the files involved got namespace declarations? (Including AIOM?)

Ok, I see. But I also every time use ProCache(d) sites and the authors do know that they can edit a page without changes on the front end as long as they do not save it. But I see, it isn't that "bullet-proof" I thought it is, (in the front end too). Thanks for pointing that out!

And if you want to make things a little more obvious to anybody reading your code (or simply to yourself) you can use getUnformatted() to return the array version of the field no matter what the current outputformatting is: <?php $images = $page->getUnformatted('imagesfield'); if($images->count()) { $img = $images->first(); ... }

I believe you are using a single images field, means the allowed amount of stored image is set to 1. If that is true, the scope where you calling it is important. Behind the scenes a single image field and a multiple images field are the same, they only behave different in template scope, where output formatting is set to true by default. For single image fields this reduces the code a bit so that you already act with a single image right after the field name. So in a function or method scope, this is not (cannot be) auto set to true, and your image field returns a collection from which you have to select the first item: $page->image_contact->first() So a working code then can be: if(0 < count($page->image_contact)) { $vcard->addPhoto($page->image_contact->first()->filename); }

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.

@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. ?

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.

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.

@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. 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! 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. 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 ? @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 ^^ @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. @roderigo I'm not affiliated with Craft or Pixel & Tonic, I've added a disclaimer above.

Good comparison and and I can agree to almost all of your statements, except: 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.

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.

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.

Awesome, this worked like a charm! I'm posting the code in case someone else needs it. Thank you very much @horst for taking the time to write the detailed solution (and for letting me know about the Fetch Web-API). I realize that that I'm diving head-first in some unexplored waters (AJAX and stuff) and I'll try to read some more documentation so that I won't try again an outdated solution! This is the ajax.php file: While this is the JS file with the solution provided by @horst with some slight edits (variable names):

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.

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

Who needs Craft when there is Processwire ?

ProcessWire 3.0.197 resolves 9 issue reports and adds 3 feature requests. For details in resolved issues and feature requests, be sure to see the commit log. I'll cover a couple of my favorite feature requests that have been added this week: New $files->getCSV() method This comes by way of feature request #400 via @bernhard to add something to abstract away the redundant details of reading a CSV file into one simple method call. This simplifies the reading of a CSV file by abstracting file-open, get-header, get-rows and file-close operations into a single method call, where all those operations are handled internally. All you have to do is keep calling the $files->getCSV($filename) method until it returns false. This method will also skip over blank rows by default, unlike PHP’s fgetcsv() which will return a 1-column row with null value. Here's how you use it: Let's say we have this CSV file (first row is the header): Food,Type,Color Apple,Fruit,Red Banana,Fruit,Yellow Spinach,Vegetable,Green Here's how you'd use the new method: while($row = $files->getCSV('/path/to/foods.csv')) { echo "Food: $row[Food] "; echo "Type: $row[Type] "; echo "Color: $row[Color] "; } There are also several $options supported, see the $files->getCSV() documentation page for more. There's also a new $files->getAllCSV() method that does the same thing but returns all the rows in the CSV file in one call. Improvement to InputfieldPageListSelectMultiple Next was feature request #339 that requested adding the enhancement developed by @Robin S (via the PageListSelectMultipleQuickly module) into the core. This enhancement keeps the selectable page list open for multiple selections rather than closing it for each selection. It also better indicates when an item is selected. While I ended up writing it in a different way than Robin S.'s module, the end result is nearly identical to Robin S.'s short GIF screencast below: Also added this week is a new "visibility" option for Inputfields: Open + Locked (not editable), along with some small hook documentation improvements in the Pages class. Thanks for reading and have a great weekend!

Ok sorry about that. I try to explain it in other words. What I meant was that if your system is blocked and does not respond to new requests it is likely that you have a process that is still running. This can happen quickly while testing SSE because you can quickly get into an endless loop and the process will run and run and run and block your system until the process is killed because it reaches max_execution_time for example. That's why I suggested to add a hard break while testing so that you exit after 30 iterations and the system will get ready for the next request. Hope that makes sense now? I'm not sure I understand. My usecase was simply trashing multiple pages or updating multiple pages via RockGrid (bulk editing). The user selects multiple rows and then clicks on an action (trash, update, ...). The user is then asked to confirm the action, which triggers the process of updating/trashing pages on the server. Now the only difference to a traditional approach is that this request is kept open using SSE and it keeps waiting for the server to receive the progress (eg trashing page 1 of 10, 2 of 10, 3 of 10... etc). Until this action is finished the system will be blocked for other requests of the same user (I don't understand how that works technically, but I think that other users can still request data from the server in the meantime?!). When the server is done with updating/trashing all pages it will send "DONE" to the client and the connection will be closed which makes the server ready for the next request. So it's a very special use case but it's also a quite common need! The example you are describing can not be solved using SSE as far as I understand. I think one would need sockets here. But I don't have any knowledge about them so I can't say anything here but I am happy to hear how that would work even if that is not really on topic any more ?

Hi @Zeka, many thanks for your hint! Helped me to get going. My first guess was right,- missed something obvious ?. Too avoid the mistake i made, this might help other forum members eventually: As long as an file (which is used by a javascript ajax call) is not accessible to the processwire core (e.g. is a dedicated page derived from a template at least), such things as core translation etc. are not available in those files. My approach here was to create a template, create a page from this template (with the code of my former `contacts-flatproducts.php`, s. OP) and took this page as my reference within the form action attribute.

If anyone is still interested about this topic I've gracefully solved sse implementation both with alpine.js and vue.js (just for fun). Let me know if you want some code examples and I'll post them here.