BrendonKoz

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!

Just curious if anyone has any idea as to why there's any reason to deny such a permission (page-lister) from users that would have edit (or greater) access? Is it optional because it's a (potentially) slower query and therefore may cause unnecessary strain on the system? (That's the only possible conclusion I could come up with.)

Here's a fairly easy question: With regard to the invoice GIF you shared, I hadn't ever seen auto-suggest/auto-fill links used before ... Is that a component built into core, an existing module, or something you customized? Everything else shown is enormously impressive. I'd like to think that PW is still running blazingly fast, but I'll ask anyway: is PW still running efficiently for the client (and during your mockdata testing)?

I remember (now) reading about this. I had completely forgotten about it. Thanks for sharing it again!

Thanks all - was mostly curious if anyone had yet done it, and their decision over how it was implemented. Very much appreciating the discussion!

I've just been thinking recently about "live" style guides and how, if it would be used on a live site, doesn't it make sense to implement it into the system (CMF/CMS) that would be maintaining the content, as well? I'm curious if anyone's yet done this? Either had invisible sections of their site devoted to a style guide for showcasing various components, modules, elements, etc., or even configuring a multi-site implementation of PW for this purpose? I haven't thought through the technical side of how one might implement this, only had the thought itself. Gantry is a framework, built in to some other CMF/CMSs, for something similar to this purpose (with additional features included) - which I originally had thought would be awesome to bring to PW, but realized it was out of my skillset. However, just a "simple" Pattern Library or Style Guide? That just might be possible.

Is modifying the recurring tabular list below the RRule definition currently the only way to exclude dates in the exclusion? We pay for a (rather poorly implemented) calendar that has a GUI mini-calendar selection to create a list of dates to exclude. Love this calendar, but I'd be fearful of removing/changing something that our staff (not highly computer literate) is used to - so just curious. Thanks for providing this! RRule is a confusing thing to implement in a database!

I can't compete with BitPoet's knowledge, but I'm just going to add here that, if you haven't yet already, you'd want to read over the documentation on ProcessWire's selectors. It'll help you understand the different ways you can retrieve Page objects from the system (using $pages->get() or $pages->find()). Selectors: http://processwire.com/api/selectors/ Obviously I'd recommend to read through the entirety of the documentation, but Selectors are probably (in my opinion) the most important thing to understand.

No apologies necessary; I appreciate even just the initial response! There's no expectation of a response, but thanks again for the reply!

Brilliant! I need to check the module configuration options more often. Never think to look there after initial install. Thanks, BitPoet!!

Hey 3fingers - thanks for the reply! Unfortunately those are not helpful in this instance. I've gotten the default CKEditor to comply just fine the way I was hoping. The problem is specifically with the PWimage add-on for embedding images in to CKEditor. Thanks, tpr! These are kind of what I was thinking I could do, but was thinking/hoping there might be a PW way of fixing it that I just didn't find. Once this project's done I have a few things that I'll want to tackle to see if I might be able to fix. Looks like this might be added to the list.

Hmm... I could disable the core pwimage plugin (from the field settings), copy/paste that plugin from wire and move to site, rename it, and just maintain a diff from the official repo version... Just not sure if this is the best or only method available. Thoughts?

Hi all, I'm wondering if anyone's come across this problem and/or solved it. I'm using Bootstrap for my front-end CSS in the current project. Bootstrap's image alignment classes are pull-left, center-block, and pull-right (as opposed to PW default of align_left, align_center, align_right). I could rebuild the Bootstrap CSS to accomodate (by adding) PW's chosen class names, but I'm currently instead trying to accomodate PW to use Bootstrap's names. I've found the information about using Custom Editor JS Styles within the field's settings in the ProcessWire admin. What I haven't found is... ... How can I allow and enable custom class names from the PWimage CKE plugin? I'm aware that I could modify the JS source of pwimage, but since that's a core module if I were to update ProcessWire I'd overwrite my modifications. Is there an alternate, best-practice way to handle this? Thanks!

Thank you for the response, AndZyk! Do you happen to know what any of the "internal uses" of the published field are? That was mostly my concern, as I think in this case the easiest solution would be for me to manually update that field's data, and is currently what I'm leaning towards as a quick solution. In the future, with this project, access to a published field will be unnecessary.

I am currently running the Processwire 3.x branch (specifically 3.0.36 at the moment) and am back-porting data from a previous website that was created back in 2010. In trying to provide seemingly accurate publication dates to the older articles that I'm manually porting, I was thinking of adding a `published` field to the pages. Upon closer inspection I found that all pages do indeed have a `published` field already (in this version of ProcessWire anyhow). I suspect it was added to core back when ProDrafts was created. I see that there's a module to handle the ability of providing this field to all pages. http://modules.processwire.com/modules/publish-date/ I'm not sure if this is necessary now though if all pages already have an associated `published` date field? Would a module need to be created to expose this database field to the admin side, or is there another way to do this? Would modifying this field cause any detrimental side-effects (I do own a ProDrafts dev license, though am not currently using it in this project).

No, I actually side with @cstevensjr in not wanting to remove the added security. I do have some additional fixes that have nothing to do with the security certificate issues though, so at some point I'll probably offer those fixes as a patch to the plugin without introducing the reduced security. They primarily have to deal with fixing the way various mail clients and how they handle (or don't correctly handle) attachments and/or inline images.