BrendonKoz

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. ?

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).

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(); });

(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.

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. ?

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?

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. ?

I was honestly expecting a facepalm (missing $, semi-colon, or maybe typehint). Thank you so, so, so, so much!

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

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.

The purpose of the module is to provide a way to display Leaflet Maps. Leaflet =/= OpenStreetMap. Leaflet is a map display library whereas OpenStreetMaps is the actual map layer data source. OSM can be displayed using Leaflet (popular), OpenLayers, or even Google's map library, so I don't know (for sure) if the purpose of the module was specifically to avoid using Google's technology behind the scenes (which it does anyway as is evidenced from previous discussions of the code). I prefer OpenStreetMaps' imagery and ToS, but prefer Google's geocoder. Like I said though, your fork of the code is your own -- it did not have to follow my personal ideas.

I took a look at it. This is not the same thing that I was trying to accomplish (not that it has to be). These alterations don't use the Google geocoder's returned JSON data, it uses OpenStreetMap. I don't remember how, but I do remember I was able to get the JSON results of the OpenStreetMap geocoded data without any modifications to the module. What I was unable to get was the same values (100% of the time) from Google's geocoder, which contains more information (and often, I've found, more properly formatted and correct) than the OpenStreetMaps version. Because the found addresses for PLACES don't always match ("NYS Public Library" might not list a street address on OpenStreetMap, but Google will include everything), doing a manual lookup with Google's geocoder after-the-fact won't work 100% of the time. (Those were some of my reasons anyway.) As for code: When changing a version number that has companion modules you'd probably want them all to match. Just a suggestion for any future possible patches. LeafletMapMarker.php around line 62: } else if($key == 'raw') { $value = $value; } At first I did that too in my version (I think I removed it in my repo, maybe not) but that's just unnecessary. Still looking through the rest as like I said, I don't fully grasp FieldtypeModule code.

Congratulations on your success. If you're going to make a pull request I'd make it to the original Fieldtype module as that was the only reason I had forked the original module's code to begin with - to have workable code to store the raw return data, and offer a possible pull request.

If the only JSON+LD to be displayed will be event type, I'm personally planning to just hardcode it into the template rather than run another module. I did install that module originally with that intention but it mostly just attempts to simplify the creation of the template code. My `raw` field was used so that the rest of the module's code would be untouched and would continue to run as-is. If I could get it working I'd then add a module config option to offer to always save the raw data (or leave unchecked to not save it; default behavior). That way if the module author wanted to merge changes it wouldn't have any breaking changes. The schema upgrade method would have to be updated though. I didn't notice the other variables that may have worked before -- or maybe I did; if I did, they might've been a carry-over from the fork of Ryan Cramer's GoogleMaps implementation (some code is still the same). I didn't get time to look at this today so the code is no longer fresh in my memory.

I hadn't. I had previously installed TracyDebugger and couldn't figure out how to use it -- I think my problem was as simple as having installed it in the wrong PW instance (it's working now). I'll see if I can find any additional info from that, thank you for the tip! I had not, unfortunately. I was pulled from that task to work on an Omeka (archival CMS of sorts) theme and subsequent issues, and an application form using GIS shapefiles. I hope to be finishing the Omeka thing up today. If I have time later in the day I'll take another look into this. I too don't have much experience working with PW Fieldset modules; I've been trying to figure them out here and there though.

I realize my question is now outside the scope of this module, so I apologize in advance, and also have no expectation of a response -- just hopeful! By looking through this though I think I might be picking up some things with Fieldtype development that I couldn't quite grasp beforehand, so it's still useful (to me). Thank you for the response, @gebeer that was awesome! I made those, and some additional changes, but I've still been unable to get the data to save to the database (I'm instead saving an empty string value). I believe I might need some additional code somewhere, possibly in InputfieldLeafletMapMarker.module's ___processInput method? I tried commenting out the if/else block for whether a JS geocode had been done so that it would (should?) always perform a Google geocode, but that still didn't save to the DB. Any thoughts from anyone on what I might be missing here? I manually altered the database table to include the "raw" column in my field_{$name} field values. Changes (on Github repo removed) : LeafletMapMarker.php [line 38] + $this->set('raw', ''); [line 96] + $this->raw = $json['results'][0]; InputfieldLeafletMapMarker.module [line 310] - "\$page->{$this->name}->zoom" . + "\$page->{$this->name}->zoom\n" . + "\$page->{$this->name}->raw" . FieldtypeLeafletMapMarker.module [line 106] + $marker->raw = $value['raw']; [line 136] - 'zoom' => $marker->zoom/*, + 'zoom' => $marker->zoom, + 'raw' => $marker->raw/*, [line 157] + $schema['raw'] = "TEXT"; // raw google geocode data

Does this module use Google's API at some point in the geocoding process? I noticed that there are calls to: http://maps.googleapis.com/maps/api/geocode/json?sensor=false&address= ...in LeafletMapMarker.php, and calls to... http://nominatim.openstreetmap.org ...in Control.Geocoder.js. I am using this Fieldtype on individual Events pages - it works well and made sense. I'm now trying to go back and add JSON+LD to all of those Events pages which requires a "Place" value (Example: https://developers.google.com/search/docs/data-types/events). Unfortunately the auto-corrected address field from the geocoder ($this->address in Leaflet) is not always something I can easily split into meaningful entities for the JSON+LD Event type's @Place type values. That said, the raw results originally returned from either geocoder (Google's being nicer in this regard, but OSM works too) can be used towards building this out. Based on how this module handles all of its data, is it feasible to extend it somehow to allow saving of the raw geocode data? If so, any ideas on where I might begin to look?

I'd have never looked there. In fact, I know I didn't since I searched for the text string of "permi" in my *.php/*.module files. Dang. Thank you so much! Now I can fix all the other errors and continue on. Thank you!!!!

I must obviously be doing something wrong in my hackish attempts to develop a Fieldtype. The inputfield and fieldtype are installed successfully, but as soon as I attempt to create a field using the fieldtype, I immediately (upon submit of the field creation form) receive a 500 error. It took me awhile to realize that ProcessWire was snatching the error message away from the server though! Error found in: /site/assets/logs/error.txt: This was a completely clean install of PW v3.0.78 running the classic theme. Immediately after setup I installed my "under development" fieldtype module and the above occurred. I'm uncertain where to look since this seems to be referencing hasPermission in a core file, but as far as I'm aware I wasn't referencing permissions in my (inputfield and fieldtype) modules. I've attached my files if anyone wants to take a quick look, but I'm still confused why a core file might be rendering the error. Someone else had this issue with their site during a module update, so perhaps it's a versioning issue (I very well may be mixing old PW module code with new)... https://processwire.com/talk/topic/16358-error-call-to-a-member-function-haspermission-on-null/ FieldtypeBook.info.json FieldtypeBook.module InputfieldBook.module OpenLibraryBook.php

Although this topic is nearly 6 years old, I wish I had seen it sooner. It took me about a week just to realize what the difference between Fieldtype and FieldtypeMulti was, and exactly (in my situation) which class (FieldtypeMulti) I wanted to extend for the Fieldtype I am trying to build, such as Fieldtype, FieldtypeMulti, or WireArray. I still don't entirely know exactly which methods are required, or why, though the code documentation in the base classes is quite awesome! I can copy and edit from what others have done, but I'm just hacking scripts together at this point, really. It may work in the end, but it also may not be the right way about doing things. If there's still any interest (and/or time!) in expanding upon this, Ryan, I know that I'd absolutely love it!

but i would love to see how others do I believe Ryan is using PHPStorm during development of ProcessWire, otherwise he wouldn't have added (and maintained) the .phpstorm.meta.php file to the GitHub repo that helps with its intellisense abilities. There's a 30-day trial of PHPStorm so if it's not better to you than VScode then you won't need to pay. I think PHPStorm's integrated debugger would likely work better though. (I'd still like to give VScode its fair chance, so will be testing that first.)

Yes, I think I might have to. I'm using Atom right now and although there are Intellisense packages, it's already seeming sluggish. I'll give VS.code a try (also built on electron), but will likely need to buy a license to PHPStorm. Thanks again!

It seems that, when developing a Fieldtype that requires user input (Inputfield, in this case), both modules must be developed in tandem? In other words, it's not something that could easily be tested against during development to create just the Fieldtype, or just an Inputfield (again, for something like this)? I didn't see your Edit before, but that was very helpful, as well as the mention of extending FieldtypeMulti (instead of just Fieldtype) -- thank you!! ...just saw the Module.php file in core -- so THAT's where all of the documentation is!

Hi all, hopefully this is the correct (sub)forum to ask. I'm trying to undertake my first real (worthy?) module. I understand Textformatters, Markup, and Process modules, but I'm now looking to, I believe, create a module that behaves similarly to the Map Marker module(s); in my case I'm looking to add book information from an external service (insert ISBN or title into a text field and the service returns data that can then fill in other various fields). I'm confused for a few reasons...it seems I was not the only one. 1. Inputfield vs Fieldtype: I compared Ryan's FieldtypeMapMarker module and noticed that it also contained an Inputfield module. From the documentation's description between Fieldtypes and Inputfields I had a hard time discerning where my particular module would be categorized -- is this because I would also need two modules? Fieldtype: "Fieldtypes are modules that define a data type and field used to hold content for pages", and Inputfield: " One to gather input, and the other that handles the additional data (ex: author, publication date, cover art URL, etc.), that would otherwise be non-core? 2. For examples, I was trying to compare a few different FieldType modules, I looked at FieldtypeMapMarker by Ryan, FieldtypeDimension by soma, and InputfieldFlickr by apeisa (not a Fieldtype, but does something similar to MapMarker). They each seem to handle things differently (or perhaps I was looking too closely at comparing Flickr to MapMarker). When comparing any of these to the newer markup for module code I think I was just looking at too much all at once, but...are there actually multiple ways to go about doing the same thing that is fully supported by the CMF? 3. In what instances would a Fieldtype not also have an Inputfield (or some other form of input)? If not, is a Fieldtype simply a glue module? I'm also trying to determine if there are any other specific methods that are used/required solely for Fieldtypes by ProcessWire... Hopefully someone can help me clarify all of this. Thank you if you can!

That is a perfect response! Funny too! I definitely wasn't thinking along those lines when I saw the permission, but it makes much more sense now. Haha. Thank you Robin S!