MarkE

For some reason, this doesn't always work. However, I found that $object->addClass('no-selectize', 'wrapClass'); $object->removeClass('sa-selectize', 'wrapClass'); did the trick when just the first line did not. In fact, just the second line by itself was enough. Not sure if it's relevant, but this was on a field in a repeater matrix item.

This looks a nice idea and I was looking to implement something similar on a site of mine. However, many pages have repeater matrix fields. If these are changed directly, rather than through the host page edit, then the modified date for the host page is not changed (even though the updated results are shown). I guess there are two ways of fixing this: hook on saving the repeater item to set the new mod date for the host page check all mod dates - for host and repeater pages - rather than just the host page Any ideas which approach is more efficient? I guess I'm more inclined to option 1.

I look forward to that. I have one to do coming up, although much simpler than your’s sounds. Previously, I’ve just started from scratch, using the WP site as the spec, but maybe there are better ways.

Hmm. I can't see anything wrong with the code you quoted. Do you have Tracy Debug installed (if not then I really recommend it). If so, try your code in the console (when you are on the page in question).

When you create a repeater field, say 'fieldname', PW automatically creates a template called 'repeater_fieldname'. It looks like you are using this, not the actual field name. If you actually called your field 'repeater_agenda' then the template will be called 'repeater_repeater_agenda' (check your templates list with system templates filter turned on). I wanted to eliminate the possibility that you might be calling the template rather than the field.

@lenoir I would expect the field name to be 'agenda' and for 'repeater_agenda' to be the name of the (system) template it uses.

Is repeater_agenda your field name? It looks more like the template name.

I have updated the initial post to suggest how to provide full context flexibility, including for repeater matrix items. See also

v0.0.15 released. Various bug fixes and improved performance inside repeater matrix fields (see this post for technical details).

Personally I wouldn’t use a hook for this. I would use a custom page class called EventPage and put the method in that. See https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes

You should be able to to that with $event->object->getPage() Quite whether this is the right place to hook, however, is another matter...

I have now developed the code in my previous post a bit and incorporated it into my FieldtypeMeasurement module - see here

v0.0.12 now available. This fixes a few bugs and also introduces interactive dependent-selects in the config. Now that both the config and the pages have dependent selects, I thought it would be helpful to demo how it all works. Firstly, the config. On the details tab, you select the quantity you want to measure and then choose what units you want to be selectable within a page (you can also choose whether to convert automatically, not at all, or to 'ask'): New field.mp4 You will realise that we ended that demo just saving with no quantity selected. That's because we can use the same field in different template contexts to measure different quantities. So, next, we are going to add our field to a template and choose 'volume' as the quantity: volume template.mp4 Similarly, we can add our field to a different template to measure mass: mass template.mp4 Finally, we can create a page using one of these templates. In this case, it is 'volume' and we have chosen to convert automatically: volume page.mp4 If we had chosen to 'ask', we would have got a confirmation box before doing the conversion. All of this is accomplished by the magic of htmx (and of course ProcessWire). The principles behind it are discussed at The actual code has moved on a bit from that post. For instance, I have used css transitions in the config. These work really nicely with htmx: #Inputfield_unit_set { opacity: 1; transition: opacity 200ms ease-in; } #Inputfield_unit_set.htmx-swapping { opacity: 0.1; transition: opacity 100ms ease-out; } #Inputfield_unit_set.htmx-settling { opacity: 0.1; } Now I'm getting the hang of htmx, I really like it ?

Yeah, not the first time for me either. Anyway, I've found the problem now - I'd added a script using echo "<script src='{$js}'></script>"; . I changed that to $this->wire()->config->scripts->append($js); and all seems good now.

No. Also I looked at the event listeners for mouse events and there was nothing unusual there.

Upgraded to 3.0.198 and the problem persists... ?

The dropdown menus in the AdminUI on my dev machine have suddenly stopped working. Also the submit button is wrong - see below: Menu prob.mp4 As you can see, the drop-down disappears when I try and select from it. It all works OK on the live site and I have done the following: Compared the 'wire' files between the dev and live sites - no corruption or missing files Logged out and back in again Cleared the cache Stopped and restarted Laragon Obviously, I have some code on my dev site that is not yet in the live site, but I can't see that it should affect the Admin UI. Nevertheless, I have tried disabling any new js files and that doesn't fix it either. I am also using the exact same database on each site. Version is PW 3.0.190 on Windows 10 / Laragon. Any ideas?

All sorted now, I hope. I needed to insert the AsmSelect js (and also that for Toggle, at least on creation of new fields). Not exctly sure why, and I'm sure there is a better solution. Anyway, here is my code if it helps anyone else. (BTW I still need to get it working in modals ?) 1. In the module ___getConfigInputfields() method: public function ___getConfigInputfields(Field $field): InputfieldWrapper { /* @var $field \ProcessWire\FieldtypeMeasurement */ $inputfields = parent::___getConfigInputfields($field); $input = $this->wire('input'); if($input->post('quantity')) $field->set('quantity', $input->post('quantity')); $f = $this->modules->get("InputfieldSelect"); $quantities = Measurement::getQuantities(); $f->label = __("Quantity"); $f_name = 'quantity'; $f->name = $f_name; $f->columnWidth = 50; $f->description = __("Type of physical quantity to be measured."); $f->notes = __("Save after changing to see the options for units applicable to this quantity."); foreach($quantities as $quantity) { $f->addOption($quantity); } $f->value = $field->get('quantity'); #### add HTMX to change the units selection #### $adminEditURL = $this->wire('config')->urls->admin . "setup/field/edit/"; $adminEdit = "{$adminEditURL}?id={$field->id}&refresh=1"; $f->attr([ 'hx-get' => $adminEdit, // caught by HTMX AJAX LISTENER in hook 'hx-target' => "#Inputfield_unit_set", // our element to target with swap 'hx-swap' => 'innerHTML', // 'hx-trigger' => 'change', // 'hx-include' => "[name=quantity]", // the new quantity ]); ########## end of hx- attributes ######################## $f->addClass('no-selectize'); $inputfields->append($f); $f = $this->modules->get('InputfieldCheckbox'); $f->attr('name', 'hide_quantity'); $f->label = __('Hide quantity display in the input field.'); $f->attr('checked', $field->hide_quantity ? 'checked' : ''); $f->columnWidth = 50; $inputfields->append($f); $quantity = $field->get('quantity'); $fs = $this->unitSet($quantity, $field); $inputfields->append($fs); $f = $this->modules->get('InputfieldCheckbox'); $f->attr('name', 'show_remark'); $f->label = __('Show remark'); $f->notes = __("Show a remark entry box (default front-end rendering is as a tooltip)."); $f->attr('checked', $field->show_remark ? 'checked' : ''); $f->columnWidth = 100; $inputfields->append($f); return $inputfields; } In the ready() method: $this->wire()->addHookAfter('ProcessField::buildEditForm', function(HookEvent $event) { $object = $event->object; $field = $object->getField(); if(!$field || !$field->id) { $this->session()->set('newField', true); } ##################### HTMX LISTENER ############################# $input = wire('input'); $ajax = wire('config')->ajax; if($ajax && $input->get('refresh') == 1) { $quantity = $input->get('quantity'); $fs = $this->unitSet($quantity, $field); $inputfields = parent::___getConfigInputfields($field); $inputfields->append($fs); /* * In order to render AsmSelect and Toggle fields, we need to make sure the js and css is present */ // AsmSelect // $js1 = $this->config->urls->modules . "Inputfield/InputfieldAsmSelect/asmselect/jquery.asmselect.js"; $out = "<script src='{$js1}'></script>"; $js2 = $this->config->urls->modules . "Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.js"; $out .= "<script src='{$js2}'></script>"; $css1 = $this->config->urls->modules . "Inputfield/InputfieldAsmSelect/asmselect/jquery.asmselect.css"; $out .= "<link rel='stylesheet' href='{$css1}'/>"; $css2 = $this->config->urls->modules . "Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.css"; $out .= "<link rel='stylesheet' href='{$css2}'/>"; // Toggle // We only want to add this for new fields as it persists afterwards if($this->session()->get('newField')) { $js3 = $this->config->urls->modules . "Inputfield/InputfieldToggle/InputfieldToggle.js"; $out .= "<script src='{$js3}'></script>"; $css3 = $this->config->urls->modules . "Inputfield/InputfieldToggle/InputfieldToggle.css"; $out .= "<link rel='stylesheet' href='{$css3}'/>"; $this->session->remove('newField'); } // Finally we can render the html to be swapped into 'unit_set' $out .= $inputfields->render(); echo $out; die(); } }); In the module.js file: /* We need to tell htmx that ProcessWire expects Ajax calls to send "X-Requested-With" */ const FieldtypeMeasurement = { initHTMXXRequestedWithXMLHttpRequest: function () { console.log("initHTMXXRequestedWithXMLHttpRequest - configRequest") document.body.addEventListener("htmx:configRequest", (event) => { event.detail.headers["X-Requested-With"] = "XMLHttpRequest" }) }, listenToHTMXRequests: function () { // before send - Just an example to show you where to hook BEFORE SEND htmx request htmx.on("htmx:beforeSend", function (event) { console.log("FieldtypeMeasurement - listenToHTMXRequests - event", event); }) }, } /** * DOM ready * */ document.addEventListener("DOMContentLoaded", function (event) { if (typeof htmx !== "undefined") { // CHECK THAT htmx is available console.log("HTMX!") // init htmx with X-Requested-With FieldtypeMeasurement.initHTMXXRequestedWithXMLHttpRequest() // just for testing FieldtypeMeasurement.listenToHTMXRequests() } else { console.log("NO HTMX!") } }) You also need $this->wire()->config->scripts->append("https://unpkg.com/htmx.org@1.7.0"); in the module init() method

EDIT NOTE: If you read this comment earlier, I have deleted that content as it was all a red herring. I have now found the solution to the second problem: In order to populate the form correctly (as well as swapping in the html), we need to catch the new quantity when the field is saved. Saving the field calls getConfigInputFields again so we can simply add these lines in that method iin our module: $input = $this->wire('input'); if($input->post('quantity')) $field->set('quantity', $input->post('quantity')); The processInput method called from ProcessField as part of the save will then have the correct config fields to process the changes against. The problem with the display of AsmSelect fields remains however - as you can see from the image below: It is displaying like a multi select, not an AsmSelect. After saving, it displays correctly.

I looked into this further in the context of a Fieldtype module - specifically my FieldtypeMeasurement module. Unfortunately, it proved to be a bit too complex (at least for my tiny brain) to use @Robin S's idea. Instead, I attempted to use htmx (encouraged by my previous efforts with @kongondo's help) and made quite a lot of progress, but not quite enough.... I thought it would be helpful to share my efforts as a general solution for Fieldtype modules would be nice. The basic idea is to specify the hx- attributes in the config InputFields in the module as follows: public function ___getConfigInputfields(Field $field): InputfieldWrapper { /* @var $field \ProcessWire\FieldtypeMeasurement */ $inputfields = parent::___getConfigInputfields($field); $f = $this->modules->get("InputfieldSelect"); $quantities = Measurement::getQuantities(); $f->label = __("Quantity"); $f_name = 'quantity'; $f->name = $f_name; $f->columnWidth = 50; $f->description = __("Type of physical quantity to be measured."); foreach($quantities as $quantity) { $f->addOption($quantity); } $f->value = $field->get('quantity'); #### add HTMX to change the units selection #### $adminEditURL = $this->wire('config')->urls->admin . "setup/field/edit/"; $adminEdit = "{$adminEditURL}?id={$field->id}&refresh=1"; $f->attr([ 'hx-get' => $adminEdit, // caught by HTMX AJAX LISTENER in hook 'hx-target' => "#Inputfield_unit_set", // our element to target with swap 'hx-swap' => 'innerHTML', // 'hx-trigger' => 'change', // 'hx-include' => "[name=quantity]", // the new quantity ]); ########## end of hx- attributes ######################## $f->addClass('no-selectize'); bd($f, 'quantity field'); $inputfields->append($f); ... $quantity = $field->get('quantity'); $fs = $this->unitSet($quantity, $field); $inputfields->append($fs); ... return $inputfields; } Then in the module's ready() method, add a hook like this: $this->wire()->addHookAfter('ProcessField::buildEditForm', function(HookEvent $event) { ##################### HTMX LISTENER ############################# $input = wire('input'); $ajax = wire('config')->ajax; if($ajax && $input->get('refresh') == 1) { $quantity = $input->get('quantity'); $fieldId = $input->get('id'); $field = fields()->get("id=$fieldId"); $fs = $this->unitSet($quantity, $field); $inputfields = parent::___getConfigInputfields($field); $inputfields->append($fs); echo $inputfields->render(); die(); } }); I have omitted the code for unitSet() here, for simplicity, but can show it if needed. Basically, it adds the selector field for units plus a notes field, both of which are dependent on 'quantity'. An important point to note is that the same unitSet() method is called in getConfigInputfields and in the hook. What works: The dependent select field ('units') is updated by htmx on a change of quantity, as is the dependent 'notes' field. What doesn't work: If I use an AsmSelect field for the 'units' dependent select, selected items are not added as they should be. I have checked that all the required js appears to be loaded, but maybe it is not all available in context. If I switch to a plain Select field, the dependent select appears to operate correctly, but... Selected items (in the dependent 'units' field) are not retained after saving the field - i.e. the selection is emptied. Other dependent and changed fields are saved correctly. Re-selecting and saving a second time fixes both these issues, but that rather spoils the whole point of the exercise. I am not sure of the reason for these problems, but this is my analysis so far: In saving the field, PW uses the 'form' object built by ProcessField::buildEditForm(). This form is the original form, not taking into account the change of 'quantity'. The hook inserts the new HTML so that everything displays correctly (Asm excepted) but does not update the form. This may account for the second problem (at least) because the 'options' property in the form has the dependent options for the previous quantity, not the newly-selected quantity, so the newly-selected dependent 'units' item is not in the options list. I looked into modifying the form in the hook (after all, it is $event->return), but frankly struggled. I'm not sure whether it was the syntax or protected properties that was preventing me from updating 'form'; in any case, the updated form is not retained as the hook has to 'die' to prevent recursive loading - so setting $event->return has no effect. So I'm afraid I've hit a bit of a brick wall and have run out of ideas for now. The module works fine, as is, however - you just have to save after changing quantity and then select the units, but it would be nice to have an interactive solution. I'm hoping there are cleverer/more experienced people out there with better ideas ?

Please note that there is a bug in that the 'in-field' conversion feature is not working properly inside lazy-loaded repeaters. I am looking for a fix for this (any suggestions welcomed ?). EDIT - The problem can be avoided (for existing repeater items) by disabling dynamic loading, but new items will need to be saved before 'in-field' conversion is enabled. EDIT 2: Hopefully now all fixed in v0.0.11

I suspect that one of the other suggestions might fit your particular needs best @cst989, but FWIW, here is a very brief outline of my 'spreadsheet' solution: The whole 'sheet' is a page - rendered in the front end. Each column ('stage') can be of multiple types and is a repeater matrix item. Each row is a field. Not all stages have all the fields. The rendering template php loops though the 'stages' within the fields. Some row/column combinations are editable in the front end and may be complex fields in their own right (e.g. repeaters or my FiledtypeMeasurement), so the use of table or matrix did not fit my need. Users can add new columns as shown. To resequence columns (at the moment) they need to edit the page in the back end. The sheet is responsive and scrollable. So, in summary, it is a hand-built solution based on repeater matrix. If you do want to go this route, I can share code snippets.

Something like this? If you are interested I will post details later - no time now...

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.