Jump to content

MarkE

Members
  • Posts

    596
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by MarkE

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 🤞
  6. 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/
  7. 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.
  8. 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?
  9. 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 🧐
  10. That looks like the case. How do you suggest re-triggering the hx- attributes?
  11. Correct Ta. I'll look at it again this evening and post more info then if I can't fix it.
  12. 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 😞
  13. 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
  14. 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.
  15. 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'
  16. 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!
  17. 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
  18. 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).
  19. 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.
  20. Moving on.. I managed to get htmx loading. I can now get @kongondo's simple <a> example working (modified to be a <button> as per my previous post). But I can't get InputfieldSelect fields to fire with hx-trigger="change" although they will fire with hx-trigger="mouseover" (or 'focus', 'mouseout' etc., but not 'change' or 'click'). Of course, 'change' is what I want. Nothing works inside a repeater.
  21. Thanks for your helpful suggestions @kongondo. However, my problem is that the hx-... attributes do not seem to be recognised at all - whether or not I have constructed them correctly. I used your example: modified as follows: $adminEditURL = $this->wire('config')->urls->admin . "page/edit/"; $adminEdit = "{$adminEditURL}?id={$this->page->id}&field={$name}"; $button = "<a href='#' hx-get='{$adminEdit}' hx-trigger='click' hx-swap='outerHTML' hx-confirm='OK'>Click Me!</a>"; but still nothing happens (except that the href takes the browser to the top of the page) - the chrome dev tools show all the attributes present but no network activity. Your comment is spot on. If I do it in the front end, then the network monitor shows a 403 error which is what you would expect. However, in the back-end there is no network activity and therefore no error. At this stage, I am just trying to get htmx to fire - once I do then your suggestions will be very useful 😉 I short, the problem seems to be that the htmx script is not active, so I am wondering if it is something to do with the sequence in which scripts are being loaded. As an example, the complete set of loaded scripts in the <head> per the html source is (excluding pw config) <script type="text/javascript" src="/wire/modules/Jquery/JqueryCore/jquery.cookie.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryUI/JqueryUI.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryUI/panel.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryUI/selectize/js/standalone/selectize.js"></script> <script type="text/javascript" src="/site/modules/SelectizeAll/SelectizeCustomChange.js?v=0.1.1"></script> <script type="text/javascript" src="/site/modules/SelectizeAll/SelectizeAll.js?v=0.1.1"></script> <script type="text/javascript" src="/site/templates/scripts/admin.js?v=2"></script> <script type="text/javascript" src="/site/modules/PageAutosave/PageAutosave.js?v=6"></script> <script type="text/javascript" src="/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.js?v=111-1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryUI/modal.js?v=1641685970"></script> <script type="text/javascript" src="https://unpkg.com/htmx.org@1.7.0"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryTableSorter/JqueryTableSorter.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.js?v=107-1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryUI/vex/scripts/vex.combined.min.js"></script> <script type="text/javascript" src="/wire/modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.js?v=111-1638562531"></script> <script type="text/javascript" src="/site/modules/FieldtypeRepeaterMatrix/InputfieldRepeaterMatrix.js?v=8-1640343319"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js?v=102-1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldPage/InputfieldPage.js?v=107-1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.js?v=106-1638562531"></script> <script type="text/javascript" src="/wire/modules/Process/ProcessPageList/ProcessPageList.js?v=123-1638562531"></script> <script type="text/javascript" src="/wire/modules/Jquery/JqueryCore/jquery.longclick.min.js?v=1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.js?v=101-1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.js?v=108-1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldAsmSelect/asmselect/jquery.asmselect.js?v=202"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.js?v=202-1638562531"></script> <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldSubmit/dropdown.js"></script> <script type="text/javascript" src="/wire/templates-admin/scripts/inputfields.js?v=33g"></script> <script type="text/javascript" src="/wire/templates-admin/scripts/main.js?v=33g"></script> <script type="text/javascript" src="/wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/js/uikit.min.js?v=33g"></script> <script type="text/javascript" src="/wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/js/uikit-icons.min.js?v=33g"></script> <script type="text/javascript" src="/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.js?v=33g"></script><script>vex.defaultOptions.className='vex-theme-default';vex.dialog.buttons.YES.text='Ok';vex.dialog.buttons.NO.text='Cancel';</script> So we can see that htmx.org is loaded (and it is shown as a source in the dev tools also). Any observations or suggestions for further debugging actions? EDIT: I tested whether the htmx global variable is available, to which the answer is 'yes' in the front end, but 'no' in the back-end, underlining that it seems to be a problem with loading....
  22. Thanks @kongondo. Exactly, yes. Also I can see nothing happening in the 'Network' monitor in the dev tools. This, in my InputfieldMeasurement::render() $f = $this->modules->get("InputfieldSelect"); $f->label = $this->_("Unit"); $f->attr('name', "{$name}_unit"); $f->attr('value', $value->get('unit')); ...... ...... $moduleName = basename(__DIR__); $f->attr('hx-get', $this->config->paths->$moduleName . 'test.php'); $f->attr('hx-target', ".InputfieldMeasurement_magnitude" ); $f->attr('hx-swap', 'outerHtml'); $f->attr('hx-trigger', 'change'); $f->attr('hx-confirm', 'Do you want to convert the magnitude?'); $inputfields->add($f); Nothing gets triggered, but the dev tools show that the attributes are there. The htmx script is added in init() as per my OP. I can see in the dev tools that it is loaded (and the html source shows the relevant <script> tag). I used the exact same script in the front end and it works fine.
  23. ... I hope! I can get htmx working fine in the front end but I would like to use it in the back-end also. In particular, I want to incorporate it into my FieldtypeMeasurement module. I am loading it using wire()->config->scripts->append("https://unpkg.com/htmx.org@1.7.0"); in the init() and the Chrome dev tools show that it is loaded OK. I have then added the 'hx-...' attributes in the inputfields and again the dev tools show that they are present. But no 'hx-...' triggers work. I'm probably just being a bit dim, but does anyone have any suggestions?
×
×
  • Create New...