Jump to content

MarkE

Members
  • Posts

    596
  • Joined

  • Last visited

  • Days Won

    6

MarkE last won the day on October 17 2021

MarkE had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MarkE's Achievements

Hero Member

Hero Member (6/6)

288

Reputation

  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.
  2. 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).
  3. 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.
  4. @lenoir I would expect the field name to be 'agenda' and for 'repeater_agenda' to be the name of the (system) template it uses.
  5. Is repeater_agenda your field name? It looks more like the template name.
  6. I have updated the initial post to suggest how to provide full context flexibility, including for repeater matrix items. See also
  7. v0.0.15 released. Various bug fixes and improved performance inside repeater matrix fields (see this post for technical details).
  8. 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
  9. You should be able to to that with $event->object->getPage() Quite whether this is the right place to hook, however, is another matter...
  10. I have now developed the code in my previous post a bit and incorporated it into my FieldtypeMeasurement module - see here
  11. 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 😃
  12. 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.
  13. No. Also I looked at the event listeners for mouse events and there was nothing unusual there.
  14. Upgraded to 3.0.198 and the problem persists... 😕
  15. 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?
×
×
  • Create New...