Jonathan Lahijani

A while ago, probably in 2017, maybe even earlier, I setup an automation in Zapier that would automatically send me an email for every commit on the dev branch (it reads the .atom file GitHub provides for each branch). Each email contains the details of the commit. I don't use Zapier for anything else so I'm on the free plan which has a limit of 100 executions. I don't even think about it. This month is the first time in 10 years where the automation went over the execution limit, and it's only 1/3 of the way through. So many updates. I had DeepSeek rewrite the automation in Bash so that doesn't happen again; running the script every 15 mins via cronjob.

Hey @ryan. I'm loving the new pace at which things are moving... lot's of new features (like the InputfieldJson I saw) and bug fixes galore. It's a new chapter. In this forum post, you described how you used multiple AI models for generating API.md files. Could you perhaps do a blog post about how you're using it for new features and bug fixes? Is it as simple as "Claude, fix bug #1234" for a bug and "make a new inputfield called InputfieldJson powered by JsonEditor" for a new feature and iterating on the results, or is it fancier than that? Would love to know as I think your level of productivity with AI is just simply amazing.

Much of the updates I mentioned have been made and it's now on GitHub. Any questions about this module should be posted on the official thread:

InputfieldPageModalSelect is a ProcessWire inputfield for multi-page reference fields. It provides a modal-based page picker for advanced page selection workflows where a normal select, asmSelect, or PageListSelectMultiple interface is not enough. Modules Directory Link https://processwire.com/modules/inputfield-page-modal-select/ GitHub Repo https://github.com/jlahijani/InputfieldPageModalSelect

For what it's worth, AgentTools has an an autoscanner too: https://github.com/ryancramerdesign/AgentTools/blob/main/tasks/accessibility-review.php

@DrQuincy Awesome. Glad to hear it's working well for you. I tested it further and it seems to be working well. I'd say you can use the module I posted here on the forum without issues. I will put it on GitHub and the PW Modules directory perhaps this week but there are a few other features I want to add which include: lazy loading images pagination on the list of selected items (right now only the search results on the search tab is paginated) not loading the modal contents until it's been clicked initially (right now it loads it behind the scenes when you load a page editor) maybe some sort of filtering capability (other than just search) for both tabs; for example in my screenshot, I have "Product Category" which is a reference field; it would be nice to filter based on that. further testing for when the field is loaded via ajax or within a repeater confirmation alert when using the Remove all functionality advancements to auto-thumbnailing (right now it's cutting my images off) maybe table column sorting (and building the table with PW AdminTable APIs directly?) some additional UI updates and improvements

When checking a checkbox for field, can the table row get highlighted? It makes it easier to track visually. Note: this would be similar to when selecting a row in ListerPro, it highlights the row.

I just gave this a quick spin. For context, I've developed a couple complex ecommerce sites with ProcessWire, going back to 2014. I've also experimented with Padloper. I suppose what I find interesting is how data is stored (ie what fields are used). My approach has been to use repeaters for things like the line items, even addresses. With Padloper, I believe Kongondo used entirely custom fieldtypes/inputfields. I see that with Mercato it's using textarea with JSON in it for things like the billing address and cart items. Were there specific reasons for that approach?

Revisiting this topic again... I want to use vanilla CSS as much as possible moving forward, but I'm trying to find a "base" from which to start. This base would come with an opinionated way of organizing files, a reset, breakpoints and perhaps stub-out certain components and use all the latest CSS features. I can't seem to find anything like that and that's also pretty recent. Any suggestions?

I must say, I really like this field. Wow... I'm impressed with GPT 5.5 and Codex CLI.

I made a few LOT more updates and I think it's ready to share for testing. I'm attaching it here as a zip for now (v88), but will publish to GitHub when I think it's ready. Edit: I have not really tested this as far as the configuration options go. My focus was mainly on functionality and UX. Obviously, don't use this on a production site, only test sites for now. Edit: it now works well in both Konkat (aka Default) and Core (aka Original) admin theme. Edit: file has been removed; see forum post / GitHub / PW modules

Another verge large update with all the UX stuff: https://youtu.be/Xu6O84oUQKU

@DrQuincy Here's a video of a concept field I made called InputfieldPageModalSelect. Let me know your thoughts and suggestions!

I agree with this. A new type of multi-select inputfield for page references for advanced use cases would definitely help. I know Shopify has some unique, purpose-built multi-select fields (like when choosing products/variations). But it doesn't let you search options that have been specifically selected. I didn't see anything generic from CMSes like Payload, Statamic, CraftCMS, Kirby or Laravel Filament. Have you seen anything in any other systems that solves this well?

My print-on-demand webapp is very complex. It has: hundreds of fields tens of thousands of pages (let's focus on orders) listers (again, let's focus on my "Orders" lister) many filters on listers (my Orders lister has about 20 filters) When you load a ListerPro lister page, it technically does 2 requests: first request is to build the interface second request (ajax) loads the results based on the filters, etc. I noticed it became very slow over time, but I didn't look into it deeply until now. Even though I have thousands of order pages, that's actually not the issue. First, part of the issue is what type of page reference fields you are using, which I wrote a tutorial about, so make sure to view that as well. (also keep in mind TracyDebugger slows things down a lot here as well) But even with that, it's still slow on the first request. It would take 8-14 seconds to load a ListerPro page on the first request! The issue? Having too many filters (20 for example) combined with the fact my site has hundreds of fields means that generating that filters list is incredibly intensive. That filters list is powered by the InputfieldSelector field. I worked with DeepSeek and it came up with a simple solution: when rendering the field list (ie, the first dropdown in InputfieldSelector), don't show every single field as an option... instead only grab the fields that I have actually used. This keeps the InputfieldSelector field working correctly, but eliminates a bunch of fields I wouldn't have wanted to use in my filters anyway. So, we're sacrificing a little (unneeded) flexibility for extreme performance gain. Now my ListerPro page loads in less than a second! Use this hook in ready.php: if(wire('page')->process == 'ProcessPageListerPro' && !wire('config')->ajax && wire('input')->urlSegment1 !== 'config') { wire()->addHookBefore('InputfieldSelector::render', function($event) { $is = $event->object; // Don't interfere if limitFields was already explicitly configured $existing = $is->limitFields; if(!empty($existing)) return; // Parse field names from the current selector value $value = (string) $is->attr('value'); if(!strlen($value)) return; $fieldNames = []; try { $selectors = wire(new \ProcessWire\Selectors($value)); foreach($selectors as $s) { foreach($s->fields as $field) { if(strpos($field, '.') !== false) { list($field,) = explode('.', $field, 2); } $fieldNames[$field] = $field; } } } catch(\Exception $e) { return; } // Always include system fields (needed for the template row) foreach(['id','name','title','template','parent','status', 'created','modified','published','path','has_parent', 'created_users_id','modified_users_id','num_children', 'count','include','limit','sort','_custom'] as $f) { $fieldNames[$f] = $f; } if(count($fieldNames)) { $is->set('limitFields', array_values($fieldNames)); } }); }