Jump to content

MarkE

Members
  • Posts

    1,047
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by MarkE

  1. 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.
  2. 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....
  3. 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.
  4. ... 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?
  5. Thanks @Robin S. That seems to do the trick - I can do away with the extra save().
  6. I seem to have encountered another problem with repeaters. I am creating repeater matrix items in the API. Different types of such items have different fields which are linked using ConnectPageFields to fields other templates. On creating some matrix types, I am encountering the error "Call to a member function find() on null" for line 132 of ConnectPageFields (v0.3.3), which is $added = $new_value->find("id!=$old_value"); This error seems to be triggered by $new_value being null. $new_value is set on line 127 as $new_value = $page->getUnformatted($this_fname); With a bit of debugging, it is clear that the module is trying to establish a link for a $this_fname which does not exist for the particular matrix type being added in the API. I think I have resolved this by saving the new matrix item before setting its type (so that all fields are present) and then saving again after setting its type. However, I wonder if it would be better to fix it by a module update. I think that changing line 130 to if($this_is_multi && $new_value && $old_value) { has the desired effect, but have not completely tested it. Thoughts?
  7. v0.1.4 is now on GitHub. As well as bug fixes, this includes a 'hook suppression' option (not yet documented in the help) to enable superuser use without the module operating fully (for performance reasons) - i.e. if you need superuser but are not using the module.
  8. @formulate: per @ryan (see https://github.com/processwire/processwire-issues/issues/1502), "It's okay to change it to a double directly in the DB schema if you want to. I have done this on the rare occasion when it was helpful and it works just fine." i.e. you can copy and hack the float fieldtype and make it type 'double' - if decimal doesn't fit your need . I'm still not sure why 'double' isn't provided out of the box.
  9. Thanks @Robin S. I guess I mis-read 'allows selectize' - meaning 'stops selectize messing with'. Anyway, I can confirm that the module works nicely with my hook. (Maybe I also thought, given what a clever person you are, that you had bundled server-side select options, via AJAX, but clearly I was over-reading it).
  10. I'm obviously being a bit dim, but I'm not sure how this is supposed to be implemented. I already have a hook on getSelectablePages, using this code. Are you suggesting something different, or if not, how does this play with your module?
  11. Just came across this thread - very useful: Not sure why it is not documented, unless there are risks using it. It really should be documented IMHO. @OLSA's solution for repeaters was particularly helpful and was (almost) what I needed for my use case. My case was complicated by the successive pages not being children of the previous selection - the last page reference was a repeater matrix item, not a child. In my case, however, the 'blendFrom' page reference is a repeater stage in the Cider/Juice page, not a child of it, so parent=page.cider{suffix} does not work. My solution was to add (via a before save hook) a field 'parent_page_id' to the repeater matrix item, which is the id of its getForPage, and use the selector "template=repeater_stage, parent_page_id=page.cider" where 'cider' is the field in the previous page selector. Ideally, I would have liked to have used 'parent.name$=page.cider', as that would avoid the use of an extra field, but although that seems to work fine normally (in Tracy console, for example), it does not seem to work in this context.
  12. @Pete - the module has been working trouble-free for the last 2 years. I’ve pretty much forgotten the details, but will look into it when I have a mo. Funnily enough, I may have another app when I might want to use it - but I’ll look at @adrian’s solution as well. Mailgun would be good for the first app also, but not the second, so that’s a useful lead too, thanks.
  13. I'm definitely meaning to 'weigh in'. I think this is a really important topic - possibly the most important one for the future development of PW, maybe alongside the pagebuilder. However I'm really buried in a complex app at the moment and don't have time to fully consider all the issues. First off, regardless of the merits of my particular module, I do think that the help file explains some of the functionality that I think is important. In particular, the approach is completely declarative and UI-based - it neither requires coding nor a clean start (it can be installed in an existing system). I encountered a number of issues in building the module this way that others should be aware of - for example that ids can vary between the development and target environments - but I think any other approach reduces the scope of application. As regards the status of ProcessDbMigrate, I have been using it quite successfully in a moderately complex live app (there are some bug fixes and improvements pending for the released version) but really wanted to try it out in the app referred to earlier, which has complex fieldtypes (e.g. my FieldtypeMeasurement) and many pro fields. I hit a snag with nested repeaters which needs attention once I have finished the app. I don't see ProcessDbMigrate as the solution however, but I do think it demonstrates a lot of the required functionality (it creates json not yaml files, but that's not a big difference). I see it as a partial prototype. Aside for any snags like that mentioned, I do not like the profusion of templates and fields which clutter up the admin. As to a way forward, I think a collaborative development of requirements and spec would help and then some agreement on who and how to build it. I also really think that a contribution to this discussion from @ryan before proceeding would be most helpful. I'll try and return with some more detailed thoughts once I get this app done!
  14. Just came across this - @evan's solution works, but I can't believe there is no 'label' method or property.
  15. Further info (in what seems to be a monologue so far ? ) What is actually happening is that PW is opening TWO modals when I double click the item. The HTML looks perfectly OK - e.g. (from developer tools after PW has applied its classes etc.) <div id="pw-edit-modal-1017-100-104-107-113" class="pw-modal pw-modal-dblclick pw-edit-modal" data-href="/processwire/page/edit/?id=1017&amp;fields=weight,volume,gravity,acidity&amp;modal=1" data-fields="weight,volume,gravity,acidity" data-buttons="button.ui-button[type=submit]" data-autoclose=""> <p><span style="font-weight: bold">Default units: </span> Weight: pound , Volume: litre , Gravity: SG , Acidity: ppt malic</p> </div> The work-round is just to close one modal and then work in the other one, but why is it happening ....? SOLVED (sort of) Something was wrong in my front-end template - possibly mis-matching div tags. Code double checked and all ok now
  16. A bit more info. In fact the first save is OK, but returns to the modal with the original value. If I just close the modal (i.e do not change and re-save) then the change has been made. I have no idea why it returns to the (unchanged) modal rather than the FE page - poking around in FEE but no light yet. I also notice that if I click the close x immeditelay after loading the modal, the background lightens and then any changes (followed by clicking 'save') are taken and the modal closes. Seems like something to do the the js, but still in the dark
  17. I suggest you try the simple thing first: Replace <a><?php echo __("Ver detalle"); ?></a> by <a><?php echo \ProcessWire\__("Ver detalle"); ?></a> Let me know if that works - then I know we have the same namesapce issue as I have already reported
  18. MarkE

    Hanna Code

    The namespace issue still seems to be unresolved. I think that is also related to this. I would be grateful for any comments on the GitHub issue I raised and whether I should just raise a PR to get @ryan’s attention?
  19. The hack in the quoted post is quite simple @Krlos - you may wish to try it and see if it fixes your problem. If not, you can revert. Or you could just try \ProcessWire\_(“….”)
  20. Github issue opened at https://github.com/processwire/processwire-issues/issues/1502 Suggested fix is to amend the regexes in $sanitizer->float() to not remove 'E-', 'E+', 'e-' or 'e+', but I have (yet?) to devise a suitable regex. If anyone is a regex whizz then please save me some head-scratching ? EDIT: I have also suggested, in the GIthub, a simple fix to deal with the internally-generated scientific notation that causes the InputfieldFloat problem. That's what I'm using for now, otherwise I consider InputfieldFloat is unsafe for live use! (I appreciate that may sound a bit dramatic, but I cannot risk major calculation errors).
  21. Will do @Jan Romero. I'm pretty sure that the problem is with $sanitizer->float() since hacking that to just return (float)$value fixes the problem with float fields.
  22. This might possibly be connected with an issue that I raised here https://github.com/ryancramerdesign/ProcessHannaCode/issues/26 and here but I haven’t received any response
  23. If I have a float or double field in the Admin with a value such as -0.00001253 then saving initially shows this as -1.253E-5, which is fine, but saving again changes it to -1.2535 (v3.0.184 and 3.0.190) In my FieldtypeMeasurement module I have fixed this (in a not yet released version) by using a text field and using (float)$value in the wakeupValue rather than $sanitizer because $sanitizer->float($value) returns -1.2535 from -1.253E-5. Is this a bug or is there something subtle that I don't understand here? It seems to me that InputfieldFloat may be using $sanitizer->float() which does not convert the scientific notation.
  24. For some reason, in the new site I am building, every time I use the front-end editor on a field, I have to save the changes twice - the first time just reloads the module with the previous value. I've not come across this before. I disabled hooks and auto-save but it still happens. Any ideas?
  25. https://processwire.com/modules/inputfield-runtime-only/ ?
×
×
  • Create New...