MarkE

Have done that and commented.

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.

OK @bernhard, I have now re read https://processwire.com/talk/topic/26565-share-your-pw-dev-setups-tools/?do=findComment&comment=220484 and haven't got much to add to my previous comment. I think a lot boils down to the target 'market' for the migration tool. PW actually has a rather broad user base - from those who want something just a bit more flexible than WP at one end to those who would be equally happy with a plain PHP framework. I have used both WP and CodeIgniter in the past and find PW way better than both. I am not a full-time professional developer - very much a part-time amateur on a few projects. I also hack around in Python from time to time. Consequently I do not instantly remember all the structures, attribute names etc. - the UI helps with all of that. My view is that the migration tool (or tools) should cater for the full range of users and not just for the pro developer. My reason for this is (similarly to @MoritzLost) that PW without migrations is not a great solution for anything other than simple 'build and forget' websites which (forgive me ?) you may as well do in WP. Part-time or more amateur PW users need to maintain and upgrade sites just like full-time pros, but less frequently. You say in the post referenced above that it is much quicker to type the code than use the UI. I am sure that is true for you and your team, but most certainly not for everyone. For example, creating a new field, you enter 'type' => 'text' - well, that's easy, but what are all the other fieldtypes called? I would need to look up their names - the UI gives me a selection drop-down. Have I entered all the necesaary attributes for my new field? I would need some sort of checklist to consider; in the UI it is all presented to you. The IDE helps with methods, for sure, but not with strings, and not with completeness. I appreciate it must be difficult to put yourself in the shoes of those less capable and experienced than you, but I think that is required to understand the needs of the wider user group. (I must admit that I don't understand @MoritzLost's problems with RockMigrations as I would have placed him in the super-pro category with you). You can take the view that only the super-pro group is important, but I think that only serves to marginalise PW. In my view, all users (other than those building very simple websites, for which PW is arguably overkill) need a solution to the migration/version issue even if they don't know it yet.

Yes. I was very impressed, but I didn't really understand the context (was this just a demo or a real working tool) and I wasn't clear what your plans were for it (to incorporate in RockMigrations somehow?). Because? It does seem to be very interactive and maybe that causes problems. With ProcessDbMigrate I very much opted for batch creation of entity specs, which is easier to manage. Yes, I did, but I must confess to not having thought through all the comments made there. The intial part of the post clearly shows implementation on an existing site by just specifying the changes, not the whole description - hence my comment about 'not fully declarative as it assumes a prior state'. I will re-read it more thoroughly.

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

I wonder if FieldtypeMeasurement might help? Only in alpha at the moment so you would need to test well. Create a conversion php file with the calculations (see the help). Data entry would then be net or whatever gross you want, with interactive conversion as required. See the readme for more details. Happy to help if you want to go down this route. Note that both this and @bernhard’s suggestion require a field change, whereas a hook (if it works) might not, so you would need to handle data migration.

There may be some ideas here

$page->getForPage()->fieldname ?

Ooh that looks useful. I’m away from my Desktop at the moment, but that looks like it might be handy to make my FieldtypeMeasurement module (even ?) slicker. I.e no need to save the first config field before choosing the dependent one.

Thanks @kongondo. Just enhanced and fixed a few bugs in the new 'in field' conversion feature in v0.0.10. I tried to use hyperscript to do this, given its purported 'compatibility' with htmx, but I came across the same problem with lazy-loaded fields as we had with htmx - i.e. it didn't trigger when used in a field inside a repeater matrix item. However, there didn't seem to be a similar ready fix for this, so I resorted to good old fashioned jQuery which seems to work OK ?

New version 0.0.10 at https://github.com/MetaTunes/FieldtypeMeasurement Bug fixes and improved operation for the 'in-field' conversion feature. EDIT: Version 0.0.10 is now published to the modules library at https://processwire.com/modules/fieldtype-measurement/

New version 0.0.9 at https://github.com/MetaTunes/FieldtypeMeasurement This has lots of bug fixes, plus a much neater way of doing conversions 'in field' : You can choose to enable the magnitude value to be automatically updated when you change the unit selection in a field - the options are to 'Always' convert, to 'Never' convert or to 'Ask' whether or not to convert each time the unit selection is changed (note that, if conversion is chosen and the unit is changed to 'no selection' then the magnitude value will be blanked). Many thanks to @kongondoin getting this working via HTMX (and also to @Robin Sfor modifying SelectizeAll). This version has been tested quite extensively, but only in one environment. Different PW versions, modules and your own code may affect it differently. It is therefore not recommended for use in production sites unless you have fully tested it in context first.

All working fine now. Many thanks for your help @kongondo (and @Robin S). New version 0.0.9 of FieldtypeMeasurement is now on GitHub https://github.com/MetaTunes/FieldtypeMeasurement Do you think this is worth adding to the modules library?

I think this works @kongondo $(document).on('reloaded', '.InputfieldRepeater', function (event) { htmx.process(this); }) Now I have the (non-trivial) task of working out how to target the right repeater item and swap in the converted measurement ?

That looks like the case. How do you suggest re-triggering the hx- attributes?

Correct Ta. I'll look at it again this evening and post more info then if I can't fix it.

I tested htmx on a measurement field in a repeater and it worked OK. I then changed the repeater to a repeater matrix and it failed. So it looks like there is some js in RepeaterMatrix that is hijacking the event. Unfortunately the app which is acting as a test bed for the Measurement module relies heavily on repeater matrix fields ?

Hi @Robin S - I have run into a problem with this module as it seems to intefere with htmx (presumably by taking the change event hostage). See

I can do, but I don't think that is the issue as I installed the latest version of the module on my 3.0.184 site and htmx worked OK. So it must be another module or something else in my site that is causing the problem. As I mentioned earlier, htmx is working OK in the front-end. Plus I tested without all the hooks in ready.php (i.e. site-specific hooks) and that didn't fix anything. I also tried it with auto-save uninstalled without any luck. Aha - I think I've found it (at least partly). I disabled the SelectizeAll module by @Robin S. Now the change trigger works, although not inside a repeater matrix item (it did work inside a repeater [not repeater matrix] item on the 3.0.184 site, so I will try a dummy repeater on this site too). I really like SelectizeAll, so it would be great to get it working without interfering with htmx. EDIT: I have posted an item over on the SelectizeAll support thread.

I created a bare page with just title and measurement fields and the effect was exactly the same (except in this case, no GETs for data:image/svg+xml) - i.e. working with 'mouseover' and no errors or network activity with 'change'

Me too! Slightly curiously, when I tried it this morning, there was network activity, but just a whole load of GETs for data:image/svg+xml from pw.min.css - which appears to be the chevrons in the dropdown box. But no ajax activity and no errors. The console shows that HTMX is loaded OK. Mouseover (outside repeater) works. I disabled all hooks, but still no luck!

Could be something to do with auto save / live preview, but I haven't got auto save turned on for the page in question. EDIT .. but disabling the auto-save module does not fix it

Hmm. That's really odd. I implemented your code as described @kongondo, but the effect was as before. With hx-trigger="mouseover", all your tracy and console logging displays as expected. But with no hx-trigger or hx-trigger="change" there is no network activity and nothing is logged. Obviously there is something different between our setups. I am on a later version of the Measurement module (which I doubt is the reason) and on PW3.0.190. I therefore tried it in a site on PW3.0.184 and the exact same Measurement module and the change trigger works (although I haven't tested in a repeater yet). So, either it is something in 3.0.190 or something else in the setup of the site I am using it on. Which version of PW are you using? EDIT: It works inside a repeater on PW3.0.184 (haven't tried a repeater matrix), although only for the first such repeater item, which is not a surprise as there is a multiple element id issue with the demo code in a repeater (it fires on all repeater items, just doesn't update the demo target).

Thanks @kongondo. That's enormously helpful. I'll go through it in detail in my usual late-night coding session. My idea is to replace the present, rather clunky, method of doing conversion (checking a box then saving) with a prompt when the user changes units saying "Do you want to convert the measurement" (but which can be turned off in the config). I could, of course, have done this with straight Ajax, but was keen to try htmx as it looks like a really neat approach. BTW the current version of the module on Github still has some bugs. I have a much-debugged version that I have been using extensively and am really pleased with, but planned to incorporate this change before releasing it.