Leaderboard

It might be a good idea to somehow persuade more PW devs to give more thumbs-ups this request: https://github.com/processwire/processwire-requests/issues/230 Anyone reading this and supporting the request, if you have not yet clicked the thumbs-up icon, please do it now :) Me too, of course. However, the most important reason why I have not yet looked at Bernhard's modules in details is that he keeps rewriting them every now and then (which is quite understandable but still...) and I certainly have no time to keep up with all the changes. Most importantly, I stick to ProcessWire and to some other (pro/non-pro) modules because I rarely have to deal with any breaking changes throughout the years. That is why I am dreaming of Ryan picking up this request one day in the future.

Thanks for all that @bernhard. I don't want to perpetuate a to-and-fro and would really welcome input from others too. I do want to say that I, for one, appreciate what you have done, even if I decided to go a different route. I will take another look in depth at RockMigrations, as it has clearly developed quite a bit since I first looked at it. However, the module info says that it has been archived and that you are working on a new version. Is it better if I wait for that? Also: Is there any documentation of best practices beyond the examples? For example, you mentioned putting migrations inside classes and, in particular, custom page classes, which sounds like a great idea, where it makes sense to do so. I use PhpStorm, which has many of the same features as your IDE. The snippets sound especially useful (Live Templates in PhpStorm). Are they available anywhere? (I note that there is what appears to be an old GitHub repository for some PW snippets, but I'm not sure anyone ported those to PhpStorm either). Maybe you can reflect on some of my comments about achieving broader appeal? I well understand that RockMigrations was developed for personal use and that there may be little motivation in meeting other needs (although your contributions to the PW community are already extensive...). Likewise my motivation was to develop something that met my needs. My reason for being concerned about the wider appeal and applicability of a migrations module is to sustain PW as a viable, well-supported and favoured solution, which is ultimately to the benefit of all its users, including me.

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

Hey all. I have read a bit through all the posts here, got inspired and have changed my personal little local tool for live reloading from using ajax polling to use SSE. If you like, I can share my experiences and thoughts to some of the (somewhere) above mentioned problems. My setup is manually enabling / disabling SSE via a button. The SSE-php file does NOT use PWs system. It is complet solely, means it does not use (and maybe block) a users PW session. It uses the basic examples from MDN, as the JS do too. No special buffering, string_padding or the like is needed! I use h2 (HTTP2) protocol, what also needs https to run. (I'm not sure, but I think h2 is needed for not early disconnecting (and then start polling)). My polling loop on the server is every second. I send one keep-alive ping around every 15 to 20 seconds. In the one-second-server-loop I check if something has changed in the GIT tree, in comparison to the previous run. If so, I do an ajax call to PW, where my styles and scripts pre- and post processors are hosted (in a module). (It is similar then included in ProCache, but was coded earlier then that in PC.) They do a in-depth check and do recompile necessary files on demand and return if refresh is needed or not, what, only if true, gets pushed through to the client browser. I can work in the admin, I can work in the client, also with concurrent fetch/ajax calls while SSE is listening, etc. My PHP file is: My JS in browser is: Here is a screen, showing the network tab and console:

Definitely yes ? At the moment no, but I plan to create a video that shows the most important parts. The ProcessWire snippets are available here: https://marketplace.visualstudio.com/items?itemName=baumrock.pwsnippets (also on github of course), but the RockMigration snippets are at the moment only locally available until I've used them a little more. Thx for that feedback. That's absolutely understandable and a valid point ? Update 2023: I've improved a lot here and try my best to not introduce any breaking changes. My modules follow semantic versioning, so a major version bump indicates a breaking change so that everybody is aware and can check if that is a problem in his/her specific situation. Also there is the rock-monthly newsletter now to communicate the most important news.

Check this:

Thanks for the comments @bernhard. I'll do my best to reply. If, along the way, I demonstrate a misunderstanding about RockMigrations, please accept my apologies and help me to understand better - I have tried to use it but it didn't do what I wanted and I found it very time-consuming to try and get it right (admittedly this was some time ago and it has no doubt developed quite a bit since then). Equally, I would be grateful if you could try out ProcessDbMigrate, or at least read through the help file, and comment on the various pros and cons in order to advance the whole subject. A fair request. At its simplest, you could say that it is a (complete or, at least, sufficient) specification of the current state of the entity(ies) in question. Arguably, RockMigrations fits this definition, if you completely specify the entity. However that is time-consuming and it is simpler to just specify the changes (which is not fully declarative as it assumes a certain prior state). With ProcessDbMigrate, I was attempting to produce a declarative definition automatically, rather than having to code it. That might not be enough 'detail' but we can discuss further. Related to the above: to implement it in a declarative way required me to specify every field and template in full in code, by hand (at least for the migration scope in question). I had already done this via the UI and just wanted to produce the spec automatically from the database. Again, related to the above. There is not much point using the Admin UI to specify the fields etc. if you are going to do it via the API anyway. Many people like the UI and are less proficient at coding (typing, remembering all the structures and formats etc., even if aided by the IDE). Allowing specification via the UI does not mean that 'mouseclicks' need to be recorded - just that the config files need to be generated from the resulting database automatically (or at least programmatically). I hope you were referring to the OP here, not my post, as I did research all the prior migrations tools (even using some of the working bits of the core tools) and put a lot of work into my own solution. I quite agree. That's why I was suggesting some way of agreeing requirements and then reviewing the best way forward, which may be by adaptation of an existing tool. As regards YAML vs JSON vs PHP, I agree that it is not such a huge thing. After all, the PHP is just an array specification. However, I plumped for JSON as it seemed easier when I was wanting to automatically generate specs from the database. FWIW, my original intention was to generate RockMigrations-style PHP from the database and leverage your existing work, but I struggled with that (I did say I'm not a great tech...). That might still be a good way to go ? In doing so, could you please also address the roll-back issue (added as an edit to my first post). Other requirements that ProcessDbMigrate meets which I think RockMigrations currently does not include database comparison, preview and audit trail. Please read the help file to get a full picture of what it does before commenting on pros and cons.

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.

@Val_0x42 Nice that it is working for you til that point. But your ajax processing lacks a bit of security. Actually you pass any submitted ID to get a page and add it to the page reference field. Best practice is to verify that it is a page with a correct template and parent page, etc, before you add it to the page reference field. Something like: <?php namespace ProcessWire; include( './index.php' ); $page_id = $input->get('pageid', 'int'); $status = $input->get('status', 'text'); $p = wire('pages')->get($page_id); // now check if it is a real page or a NullPage if(0 == $p->id) { return; // maybe early give up on none existing page? } else { // check for the right template if('your-sorceries-template-name' == $p->template->name) { // a check if it is located under the right parent page? If necessary then if('your-sorceries-parent-template-name' == $p->parent()->template->name) { // or check against a hard coded page ID of the parent page ? $method = $status == 'true' ? 'add' : 'remove'; $user->sorceries_checked->$method($p); } } }

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. 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!)

I stumbled across this post searching for the reason why my module won't create the process page under setup. I tried some suggestions from this threat, but eventually found another solution. I just wanted to share this in case someone needed it. I used the getModuleInfo() function to add a page. I did not prefix my modules name with "Process" but only extended it with the Progress class. The only thing I had to do was calling the parents install() method in my modules install() method. That`s it. Now the setup page is created automatically on install. <?php namespace ProcessWire; class MyModule extends Process implements ConfigurableModule { public static function getModuleInfo() { return [ 'title' => 'My Module', 'summary' => 'A module', 'version' => 1, 'page' => array( 'name' => 'mymodule', 'parent' => 'setup', 'title' => 'My Module', ) ]; } public function install() { parent::___install(); } public function uninstall() { parent::___uninstall(); } }

Ah! Right! I'll do some safety checks right away as you suggested, I'm also restructuring the site a little so my files will change, but this will still be the core method I'll use to update my fields. Thanks for the answer!

In general, a main domain and a sub domain would be in separate sibling folders in a webservers disc space. Also the domains are unrelated siblings, nearly. Only thing I would do is ensure that the main domain only is reachable via www.example.com and NOT via example.com (without www.), so that any cookies from the main domain always rever to www.example.com host.

Thanks guys! @bernhard That is quite nice, to add the second field by JS. I was thinking of adding it via PW's hook system and do the conversion in PHP. But I like your idea. Had to change some parts, because sometimes the field is inside a repeater field and the names are price_repeater1234. Perhaps it is just me, but I would have thought conditional hooks take this into account. I had to remove the Inputfield(name=price) and check from within the hook. BTW, there is a new str_starts_with() function in PHP 8 ? @MarkE Looks interesting! Like the idea a lot. This time I'll stick with the simpler help of JS.

Have done that and commented.

Yes! This is a very good point. And then I assume there would be an issue with Max Post Vars if there were too many variants too, depending on people's PHP settings. Hmm

Top of the evening, sorry for late reply @alexm ?. Yes I have. Plan was to release Padloper first then go through the list of planned and requested features. I have been thinking about it though. There's two things here. Lazy loading and pagination. The former is more important as without that, for a variant-heavy page, the product won't load at all, even though one might have to scroll a lot (if no pagination). But this is definitely on my list. Thanks.

Thx for your post @MarkE and sorry for not mentioning your module in the other thread ? Absolutely. 1) Could you (both) please explain what you mean by "declarative config". In detail. 2) Could you please explain what you mean by "RockMigrations is not really declarative". (Connected to 1) 3) Could you please explain why you think "RockMigrations is difficult to implement on existing sites". 4) Could you please explain why you think "it is fine if you want to code rather than use the PW Admin UI (*) and if you are doing everything the 'RockMigrations way' from scratch for a site, but I think it sits a little uncomfortably with the PW way of doing things." *) I can somewhat agree on that until here (though that's the whole point of the topic: Having the setup/config in files, not in mouseclicks...) but the rest could not be further from the truth. Sorry. That's why I think the discussion was not really helpful. It was full of opinionated assumptions and expectations without any noticable efforts in doing research in what we already have (and we have tools for that since 2016!), which concepts of the available tools work well, which don't, which could work differently (eg. having migration config in YAML rather than in PHP which seemed to be a huge thing for some whereas it absolutely means nothing to me. And: Which would be such an easy thing to implement into RockMigrations if need be...). I'll show why I think your statements are absolutely wrong in my opinion, but I'd be happy to hear your explanations first to get a better feeling of how RockMigrations is being seen by you or maybe also others, as I think that would be valuable feedback. Thank you ?

I realise that the original post here arose from the context of a comparison of Craft and PW. While it is sometimes helpful to look at other CMSs for inspiration, my fear is that, in this case it clouds the essential point: The 'lot of talk' refers to where, indeed, there was a lot of useful discussion of this topic but, unfortunately, not a lot of progress. As I suggested in that discussion: @MoritzLost's wishlist is definitely a contribution to such a collaborative development and I would agree with much of what is said. My chief concern is that it is very aspirational (and also reflective of personal preferences) such that: I think if the aspirations were more limited (at least initially), there might be a better chance of a result. Before reviewing the 'wish list', I would like to firstly consider the range of views then, finally, look at the current state and the way forward. Viewpoints Both @MoritzLost and I refer to @ryan's views on the topic of migrations and version control, but I do not recall seeing those expressed specifically anywhere. I also note that, in the other thread, @horst gave a "-10" to my suggestion that it was a really important topic. If they do not think it is important, I would really like to hear why. My viewpoint: I am not a tech wizard and my needs are quite simple; however, I have built a few sites in PW that make extensive use of its capability as a app-building framework rather than just a simple CMS. It is ideally suited to this purpose... ...except when you need to upgrade the live site. It is impossible to copy the live DB, change and test that then upload, without making it unavailable. Making anything but simple changes to fields and templates carries a high risk of human error. Wishlist As regards @MoritzLost's wishes: Absolutely. That would be helpful. The other wishes in the list are either 'nice to haves' or personal preferences (IMHO). I would add one other 'wish' at this point: "Ability to implement on an already-existing site." EDIT: And another 'Roll-back capability' Current state At the moment the core provides practically nothing. There are some export features but they are incomplete and buggy in places. @bernhard's RockMigrations module is a well-developed solution to the problem, but it is not really declarative and I think it is difficult to implement on existing sites. It is fine if you want to code rather than use the PW Admin UI and if you are doing everything the 'RockMigrations way' from scratch for a site, but I think it sits a little uncomfortably with the PW way of doing things. For these reasons, I developed 'ProcessDbMigrate' as a POC (This is extensively documented here). In fact it rather exceeded my expectations and achieves the following: To allow development to take place (in a separate environment on a copy of the live database, or on a test database with the same structure) using the Admin UI. When finished, to permit a declarative approach to defining the migration and implementing it (again in the UI). To allow testing of the migration in a test environment on a copy of the live database. To allow roll-back of a migration if installation causes problems (ideally while testing rather than after implementation!). To provide a record of changes applied. Optionally, if changes are made directly on the live system (presumably simple, low-risk mods – although not best practice), to allow reverse migration to the development system in a similar fashion. To provide a database comparison tool which can (if wished) be used to create a draft migration for the differences between the databases. I have no pride of authorship here (and I am sure some may think my coding is a bit hacky), but it is a fairly thorough attempt to address the wishes expressed above. It is declarative (using JSON rather than YAML). It deals with the content vs configuration issue by defining a 'scope' for every migration - in other words, it can be used when the distinction between content and configuration is a bit fluid (which is always a potential issue in any CMS). It can be simply implemented on any existing site by installing the module. However, ProcessDbMigrate does have some drawbacks. It introduces quite a few new templates, fields and admin pages which could confuse a user (although they are flagged as 'system'). It doesn't completely and accurately model all possible fields and templates so it does need to be tested on the chosen site before implementing. This is partly because it is 'POC' and partly because I couldn't find a definitive model. I know for certain that it does not cope with nested repeater fields. EDIT: plus if you use it to compare a whole database it will probably crash by exceeding memory limits - however, it is more reliable when scoped to genuine configuration matters. Way forward As I said earlier, I think the way forward should be collaborative. I also think that a module is more practicable, at least initially, than expecting a massive core upgrade; it is also more workable for a collaborative approach. I think that a specially moderated thread might be a good start, where the moderator is reasonably unpinionated but sufficiently experienced. Initially, views should be gathered (via a poll? - perhaps @teppo could facilitate this?) as to the need for a migration/version control solution. Then some ranking of the 'wish list' items followed by a selection of a 'doable' set of requirements. The existing solutions could then be compared with this list to assess whether any of them go some way towards meeting the requirements and might be adapted or incorporated (either as code or as a 'leg-up' on the specification). Alongside this, we need a complete and accurate published data model of fields, templates and pages. Futhermore, this would need to be kept up-to-date for core changes. Existing modules (particularly Fieldtypes) would need to be reviewed for compliance. @ryan's help with this would be essential. No doubt contributors to the thread will have their own views on how to progress things, but a willingness to make tangible contributions would be helpful! Conclusion Perhaps I have missed the point entirely, in which case, please explain, but my fear is that this discussion will just remain a discussion and it will be left to individuals with the motivation to provide their own solutions which inevitably will reflect their own personal preferences and needs.

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.

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

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?

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.

I am more excited about the recorder than about YAML. And I see your point. When using a PHP array for the migrate() method, you can do things that you can't do in YAML. But on the other hand, for recording changes locally and than migrating them to staging/live, YAML would be sufficient. Your use case, where you setup fields and templates for a RockMails module with RockMigrations is different. When installing that module, it needs to check whether it is being installed on a multilang site or not. But when recording and migrating changes, we already know the context for the migration since it has been recorded through YAML. My conclusion would be to store the recorded data in YAML or JSON. For other use cases, like you described, we can still use a PHP array.

Yes <?php $rm->migrate([ 'templates' => [ 'car' => [ 'fields' => [ 'title' => [ 'label' => 'Name of the Car', 'columnWidth'=>50, ], 'km' => ['columnWidth'=>50], ], ], ], ]); voila. fields "title" and "km" will be 50% width in the car template context. the title field will have a custom label on the car template. It's really that simple most of the time! Change some properties, commit, push, done! What are you missing? Depends. Both are possible. RockMigrations is really also great if you add it later on a project that did not handle migrations before. It really does not care. For example you could add this in your ready.php: <?php $rm = $modules->get('RockMigrations'); $rm->createField('test', [ 'type' => 'text', 'label' => 'Testing RockMigrations', ]); // add field test to home template after the title field $rm->addFieldToTemplate("test", "home", "title"); You'll have your test field right after the title field of the home template. You can do the same for everything you add to your site. Doing it like this, of course, the migration will run on every page request. The great thing about the migrations is that this will just work! It's not ideal of course, but I just want to show how it works. Add another field? Here we go: <?php $rm = $modules->get('RockMigrations'); $rm->createField('test', [ 'type' => 'text', 'label' => 'Testing RockMigrations', ]); $rm->createField('test2', [ 'type' => 'text', 'label' => 'Testing RockMigrations again', ]); $rm->addFieldToTemplate("test", "home", "title"); $rm->addFieldToTemplate("test2", "home", "test"); Now we got two fields. Ok, we want those fields in a row? Lets refactor this (it would be possible using the syntax from above as well, but I just prefer the array syntax as it has everything in place): <?php $rm = $modules->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'test' => [ 'type' => 'text', 'label' => 'Testing RockMigrations', ], 'test2' => [ 'type' => 'text', 'label' => 'Testing RockMigrations again', ], ], 'templates' => [ 'home' => [ 'fields' => [ 'title' => ['columnWidth'=>33], 'test' => ['columnWidth'=>33], 'test2' => ['columnWidth'=>33], ], ], ], ]); Commit, Push, Done. So do you really think manually creating those fields was quicker? Even if you create those fields remotely first and then pull a DB dump and you have at least semi-automated the process and a dump takes "only 15 seconds or so"... I bet migrations are quicker, more versatile, more powerful. Let's say you want to tidy up your project a little bit. Let's add tags for those two test fields: <?php $rm = $modules->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'test' => [ 'type' => 'text', 'label' => 'Testing RockMigrations', 'tags' => 'RockMigrationsTests', // <----- add this ], 'test2' => [ 'type' => 'text', 'label' => 'Testing RockMigrations again', 'tags' => 'RockMigrationsTests', // <----- add this ], ], 'templates' => [ 'home' => [ 'fields' => [ 'title' => ['columnWidth'=>33], 'test' => ['columnWidth'=>33], 'test2' => ['columnWidth'=>33], ], ], ], ]); Thats it! Both fields live under that new tag: Nice and clean! Ok, now let's remove those changes: The IDE will help you find the right method... So we can do: /** @var RockMigrations $rm */ $rm = $modules->get('RockMigrations'); $rm->deleteFields("tags=RockMigrationsTests"); $rm->setFieldData("title", ["columnWidth"=>100], "home"); How long would it take you to delete those two fields manually? Making sure that all checks are met ("you can't delete this field... it is used by XX templates..." *#*&!), going back to the templates editor, removing the field first, then deleting the field, then going back to the home template and setting the title field back to 100%... I don't know the exact workflow - I haven't done that for a long time now ? Yeah and we are not even talking about doing those changes in a team... Have fun ? Yeah, @adrian, I know Tracy can help. Just trying to show how quick you can get when doing things using RockMigrations. Of course there are some situations where you might not know the properties you need to set. But Tracy can help you. Or you inspect the inputfield and lookup the name in your devtools. The nice side effect: You learn a lot about PW and you will understand it a lot better and improve even more. Well... I don't know what more to say. I feel your pain, but I don't really understand why there are many here "complaining" about those missing features of ProcessWire but nobody seems to be using RockMigrations or seems to have given it an hour or two to simply try it out... ?‍♂️ PS: I know the example runs migrations on every page request, which is not ideal. You can come up with your own strategy to prevent that or you can simply use $rm->fireOnRefresh() so migrations will only fire on modules::refresh I'm maybe similar. There's not a single new project not using RockMigrations and custom PageClasses now. It might be overkill for some, but I think for people that are asking questions that you are asking RockMigrations is just the right tool and you are missing something. That would be a pity. We need more people like you here ? Sometimes life as a developer is hard. But we get paid for that ?? I agree on that. I'm working on it and I wished more were doing so ? Why not? I agree it's not perfect, but I've put hard work into making this possible over the last years. And I think I've come very far. I don't know much other systems though, so I might be on the wrong track. If you know any better systems I'm just as happy to hear about them as @adrian

This looks very interesting: https://cloudblogs.microsoft.com/opensource/2019/03/12/microsoft-open-sources-accessibility-insights/ You can find 2 tools: 1 chrome extension for Web, and 1 Windows App for WinProgs: https://accessibilityinsights.io/ And the GitHub Repo: https://github.com/Microsoft/accessibility-insights-web