Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

40 Excellent

About BrendonKoz

  • Rank
    Full Member
  • Birthday 12/12/1980

Profile Information

  • Gender
  • Location
    Saratoga Springs, NY, USA

Recent Profile Visitors

2,841 profile views
  1. Although slow and impractical to show all 100 images on a single page in a gallery, would it be as slow and impractical if you used the JS-based lazy-loading for images (don't forget to force container size on the image so there's no re-flow issues during rendering -- ex: https://css-tricks.com/preventing-content-reflow-from-lazy-loaded-images/). It's not necessarily a better solution, just an alternative.
  2. The ProcessWire modules directory link for Fieldtype Leaflet Map Marker is pointing to the master branch's ZIP archive which is the 2.8.1 version. I'm assuming that needs to be updated to point to the proper Github location.
  3. It appears that the issue I'm having with the CSS layout is because I wasn't using AJAX to load a pre-existing template/form, there is no wrapping form field. Even if your module uses InputfieldForm to wrap/render your module's inputs, the form itself is stripped in the page edit admin so that the page template only contains a single form. So...I either need to dynamically wrap my content in a form (with class "InputfieldForm"), or create a template and use AJAX load with the panel. I'm not sure which is simpler. Probably the AJAX for less future maintenance...in which case, I now need to figure out how to have an external template with my module as I can't think of any public modules that do that to study from.
  4. That second bit with the hook is extremely useful - just not in this instance: if the field is included, it's going to be used on the page, and therefore the JS will be required no matter what. However, I'm going to save that bit away for later!!! Thank you! Your function format (and find() call) apparently was what I needed. Using that worked. jQuery(document).on('pw-panel-opened', function (eventData, panelNode) { The iframe, in my case, was not going to work since the form actually exists on the current page. (A semi-unknown/unused aspect of the panel is that you can load content that already exists on the current page using data-panel-id: $button->attr('data-panel-id', 'module-fieldtype-container'); ... when using this method, however, there's no iframe.) Thank you!!!!!!
  5. I think my issue with the columns may be because I'm using the panel to load a form that exists (but is hidden via CSS) on the page-edit screen. Essentially my custom Fieldtype is large enough that it made sense to load the add/edit form somewhere else (modal/panel). It's likely that I'm not wrapping the form that I've created on the page (and grabbing via JS using $button->attr('data-panel-id', 'fieldtype-form');) in a particular class, though I've not yet figured out what that class is. I believe most people that use the panel are targeting an AJAX load to another file/form external from the currently edited page. As for the JS, I'm still trying to figure out how to target only the panel that I just opened and not any panel on the page (i.e.: Page Edit screen's "View" -> "Panel"). I thought I had figured it out with the following, but it only ever runs the ELSE loop. From the panels.js code, it looks like the classes should exist before the custom event trigger is registered, so I'm not sure what's going on. $(document).ready(function() { $(document).on("pw-panel-opened", function(e) { if ($('*[data-panel-id="fieldtype-form"]').hasClass('pw-panel-container-open')) { console.log('book add opened'); } else { console.log('panel opened'); } }); }); Running that test ([data-panel-id="fieldtype-form"]) from the browser's console while open or closed manually gives me the result I expect.
  6. Hi @Zeka, yes I'm developing (or trying to anyway πŸ˜†) a Fieldtype/Inputtype. I'll have to do some more testing with the columns to see what might be the issue I'm having (thanks for showing me your example). I'm also going to upgrade from Master to Dev to see if it makes a difference. I tried your version of the jQuery call and it worked - the first time the panel opened. Successive opens were not getting logged. So it seems I'm targetting the wrong element in my call (as your code example will run any time any panel is activated), but why it doesn't seem to run on all of the actual events is strange. (Edit: Firefox was kindly aggregating similar console.log results for me and I didn't notice.) Hopefully the Dev version will show further success. πŸ˜‰
  7. I tried taking advantage of the panel.js in the "dev" branch and using an "on" method for "pw-panel-opened" in my module but it also failed. $(document).ready(function() { $(document).on("pw-panel-opened", ".InputfieldBooksAddPanel", function(e) { alert('It is open!'); // This never shows up $('#isbn').focus(); // This never receives focus }); }); Also, unrelated, but can panels take advantage of the admin theme's columnWidth for rendering core elements? It doesn't seem to behave the way I'd expect (ex: I can get 50% width for the inputs within the panel, but there is never more than a single column).
  8. Hello all! Has anyone with more JavaScript abilities been able to hook into ProcessWire's jQueryUI Panel functionality in order to handle onload events of the panel itself? I'm trying to simply set focus to the first input element of the form after clicking the button that activates the panel, but my click event does not run (I think due to the return false; in the panel.js as shown below). .../wire/modules/Jquery/JqueryUI/panel.js: // delegate events from toggler to pw-panel-button $toggler.click(function() { $btn.click(); return false; }).on('mouseover', function() { $btn.mouseover(); }).on('mouseout', function() { $btn.mouseout(); });
  9. (Assuming the suggestion is for a normalized way of handling versioning in changelogs for all modules moving forward.) As much as I like the idea of using some dynamic method to keep a version number in check, I'm not sure that a changelog (or markdown file) is the best way to handle that - at least not by simply pulling the first line and expecting that it will contain the updated version number. There are many suggested ways of creating changelogs. (There's even a discussion about best practices mentioning some of those links.) Since there are so many ways to handle changelogs (sometimes organization-specific standards) I'm not sure this could work for everyone in practice (esp. those that are using info.json files for this module data). I definitely think it looks like a terrific idea for your own use case though, and until I thought about it further I got all excited by the prospect! πŸ˜„ I do think it's OK to have a fieldtype/inputtype combo that share the same name also share the same version number.
  10. So, food for thought in terms of REGEX vs DOMDocument: Benefits of using REGEX: Essentially faster/more efficient for processing of the data Doesn't care about valid source structure as it's parsing straight text, not XML nodes Implementation is unlikely to change Detriments of REGEX: Writing a perfect implementation of a REGEX when dealing with HTML to handle all use-cases without experiencing any edge-cases is difficult (might "greedily" match more than intended) It definitely works, but the developer argument is: is it the best (most appropriate) tool for the job? Without a good knowledge of REGEX, harder to understand the underlying code if changes/updates are required Benefits of using DOMDocument: Written specifically for the purposes of this type of task (searching/modifying the DOM) DOMDocument shouldn't ever be "greedy" over what it matches, like REGEX unintentionally tends to do Detriments of DOMDocument: May require valid HTML, but with iterations of HTML, what exactly is considered valid? Would different versions of PHP handle the DOM differently with version differences? Potential of implementation changes. loadHTML() may modify your source - what goes in might not be what comes out Character encodings may cause unforeseen issues (don't they always!) Without a good knowledge of PHP's approach to using DOMDocument, the code process can get rather difficult to understand if changes/updates are required Some further reading from someone else with more thorough testing: https://blog.futtta.be/2014/05/01/php-html-parsing-performance-shootout-regex-vs-dom/ https://blog.futtta.be/2014/04/17/some-html-dom-parsing-gotchas-in-phps-domdocument/ Realistically it's a judgment call. Speed and server efficiency versus (one would hope) better valid modifications/detections. I don't think there's really a right or wrong solution. Some shared hosting servers don't install the DOMDocument PHP extension by default though, so you'd want to check for the existence of the function during your module's install method. P.S. - Thanks for asking the question -- I knew DOMDocument was slower, but haven't compared in awhile. The articles I saw above were an interesting read. πŸ™‚
  11. Is there any established or suggested way of how to handle providing modules that offer functionality from different providers? Example: Let's say the Google Maps and Leaflet Maps modules didn't already exist. Someone thought to create a module, but realized future clients may want one provider over another. Because they're so functionally similar, created a base module that then offers classes (GoogleMap / LeafletMap) to extend the base (Map) class - which can be chosen either in the module configuration or in the field configuration. I've seen a few different modules that offer this functionality over the years - most recently Ryan's Tfa (Two-Factor Authentication) class. Ryan's WireMail and Tfa base classes have a distinct benefit of being part of the core and therefore don't need to be installed or initialized - only the modules that extend them do, so I'm not entirely sure if custom modules requiring the installation of a base module, and then offering extension modules is the best solution. Other solutions are to add folders (or classes) containing required module extensions that will be discoverable by the main module. I think I saw one that used a JSON configuration at one point in my research too. Any thoughts from others who might've handled this for their own custom modules - or have been thinking about this recently?
  12. I appreciate the further glance - though it's most definitely in an unfinished state. When I couldn't get a database save to work I panicked a bit and rewrote some areas (not necessarily finishing them). That said, it's good to make me think about it again - I might've forgotten to go back and fix it up. I still want to provide a few data provider options (manual entry, OpenLibrary, Polaris ILS, etc) through module configuration; need to fix up the interface and figure out accessibility/internationalization concerns, then do some further testing. There's still quite a bit to do yet (I'm primarily stumped at the UI, have a few possible directions I can go), but at least now I can happily move forward! EDIT: Confused myself. Sanitization is currently being done in OpenLibraryBook::set() -- though it'll be a little different once I add various data providers for the book information. I tried checking your website for an Amazon Wishlist or Paypal link (i.e.: "Did I help you? Consider buying me a coffee."). If you want some coffee money, PM me a wishlist or Paypal email. πŸ˜‰
  13. I was honestly expecting a facepalm (missing $, semi-colon, or maybe typehint). Thank you so, so, so, so much!
  14. I began writing this module from scratch, basing it off simple examples of modules, trying to learn the necessary methods required to create a fieldtype. I was WAY off, but learned a lot. Eventually I moved towards examining the FieldtypeEvents example from Ryan and, in many areas, copy/pasting and then adjusting the code (and then trying to determine what it all was doing) method by method, file by file (from his example to my module). I've gotten to the point where I was ready to test the code - I haven't fully fleshed out my visual interface, nor integrated any of the 3rd party API tools this will (can) take advantage of. I also haven't implemented any JS or CSS for the interface. Right now I'm just trying to get it to save and then display any of the data that has been entered into the form fields of a template from the admin. When I save the page, the field is reset to defaults and no feedback message (for the field) is shown at the top of the page upon reload. When using Tracy Debugger from within the processInput method (immediately attempting to debug the $input variable), Tracy caught no data to be shown. If anyone has some time to take a quick look and see what I might've done wrong I'd be super grateful. I've had no forward progress in about 3 days (and like many others was unable to get Xdebug breakpoints working in PHPStorm). 😞 https://github.com/BrendonKoz/FieldtypeBooks
  15. Is it dynamically creating a custom template on-the-fly? Just quickly thinking how it works, though it doesn't really matter. Quite slick indeed.
  • Create New...