MarkE

I'm wondering if this could be achieved with a module...?

But he did mention that he would be releasing a module shortly.....

Have you read this @Greg Lumley?

This has attractions. But it would require PW to update the file path every time the page was moved or renamed - there would be other complications too - e.g. including an image in a RTE field in another page would mean that the html would need to be updated when the host page is moved/renamed. It might be possible to test out the idea using hooks, but my guess is that it would cause more problems than it solves. The method I use in DbMigrate is to do all the referencing in the generation of the migration using the path/name rather than the id and then using that to get the corrrect id for the files. For RTE fields, an id map is maintained $idMapArray[$page->meta('origId')] = $page->id; so that the html can be changed. This only needs to be done for a migration, not every time a page gets moved. So I think, on balance, my vote is to keep the id-based naming.

I'm not sure how this would be implemented. "Universal" implies it would be independent of the environment, but if a new page (and associated files) is created in the dev env, how can you create a universal id that you know will be unique in the production environment (unless the dev environment has knowledge of the production environment which, in PW, it does not). I came across this problem in developing ProcessDbMigrate. If you use that to migrate pages, rather than the standard export/import, then hopefully it will resolve the ids correctly. See https://metatunes.github.io/DbMigrate/help.html#field-types. NB: If you do use my module, please take care to take backups of both environments before installation and before any migrations - it is still very much 'alpha'!

Very good advice. You might also like to try my ProcessDbMigrate if you don't want to go the RockMigrations route. However it does struggle with some fields - like nested repeaters. I have temporarily paused developing it while I review the best way forward, but you are welcome to try it and I will try and provide support for any problems. See the support thread here and the github here.

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.