gornycreative

Yeah custom page classes are absolutely essential to everything I put together. It's really nice to be able to populate interfaces for different page types this way - e.g. I have a jsonld method I attach to various page classes that allow me to segregate the structured data and custom tailor it for each class - but in various templates I can simple $page->jsonld() and not think about the schema more than once for each page class. I already know the right fields for a given page type will go in the right spots in the schema output.

I will take a look this weekend. Thanks!

Cool yeah I agree re: cast vs loose comparison. I'm not entirely sure why it is getting stored/pulled as a string in my install, but it is. In terms of PageField vs field, this comes up if you have a braoder library of RepeaterMatrix types and need to iterate over the fieldgroup for the RepeaterMatrix - that field list gets a bit unwieldy (since it includes all fields for all matrix types for the given matrix). If I have an operation that iterates through the fields list, I've found it useful to test certain operations where Page content is being used to test for instanceof PageField - but that is probably a niche case limited to page builder assemblies... I don't think under normal circumstances it makes much of a difference.

Nice to see it in the modules area! Thanks for putting it together! I have two notes from working with it. In my install it looks like the form id is stored in the field data as a string, not an integer, so the strict comparison on line 102 fails and I never get a selection for the dropdown from ___getFormOptions. Dropping the === to a == fixes this for me, I suppose you could recast the stored value also. There is no initial class set up for the inputfield - i.e. I'm using Admin themes and the UIKit class is not getting pulled into the initial load for the inputfield attributes. Something like this could be used to get whatever admin theme classes exist: /** * {@inheritdoc} */ public function ___render() { $attrs = $this->getAttributes(); //ADD $adminTheme = $this->adminTheme; if($adminTheme && method_exists($adminTheme, 'getClass')) { $attrs['class'] = $adminTheme->getClass('select'); } $value = $attrs['value']; unset($attrs['value']); return <<<EOT <select {$this->getAttributesString($attrs)}> {$this->___renderOptions($value)} </select> EOT; } The only other thing I was thinking about - and I haven't done a ton of dev with FormBuilder so there might be a good reason for this - but I was wondering why you built this using a select instead of storing it as a PageField? I like having the ability to display the form using other formats besides the raw name - maybe that's easier with this method? Anyways, thanks again!

Although they have been bought by Canva, once I got used to how Affinity does things their Photo/Designer/Publisher trinity is my daily driver - particularly with the improvements finally brought to Publisher to make it feature complete with Serif's prior publisher (proper endnotes/footnotes support). And they do run on Linux with Wine and a bit of massaging: https://codeberg.org/Wanesty/affinity-wine-docs

So I started playing around with Supermaven's free tier. If you are looking for a code assistant for VSCode I would recommend giving it a try. I started using it after Theo covered it in one of his tool videos, and I can say it probably shaves about 15 minutes of work per hour for me. It does a reasonably good job of anticipating structures you are building based on a quick overview of the codebase for your project. I haven't extended the codebase to include the entire source for processwire in my projects, but even with just the minimum core wire folder modules and a few site module source code bits it is more than enough to cover the bases. I am using the free tier which has a smaller token context limitation, but the code suggestions are fast, they don't feel inappropriately intrusive and don't write-ahead too far until the engine has high confidence in the direction you are trying to go. When it has high certainty, it opts to give you large code blocks - even entire functions with appropriate substitutions. It has sped up my RockMigration script writing considerably - beyond the macros, because it sees other migration functions I have defined and does a very good job of anticipating not only the class structures for custom page classes, etc, but also replacing names for new classes with proper singular/plural forms, etc. I'd say it provides the correct code without modification 85% of the time. https://supermaven.com/

Yeah and I've been debating rolling my own styles and template also since I tend to try to use update UIKit or TW or whatever I am using and I have only started messing with FormBuilder, but I figure it may still be worth covering? Not sure.

I was playing around with this today. A few things I noticed. ->styles and ->scripts return null, but I could pull the original form output and use the extractions from there. I get an AJAX response and the submission works, but the parsing of the whole page object returned didn't seem to work (the whole page replaced the original form on the page). I don't have any PR yet, just going to tinker now, but thought I'd report my findings. I should comment - I am using latte templates for output. I may need to hook into output markup somehow.

It may depend on how you define your LESS variables, and whether you use CSS variables or not. This is something that the Wikimedia LESS and other frameworks run into from time to time - it's not unique to UIkit. Usually the strict math option resolves it because parenthesis are required to indicate math operators that LESS should evaluate - so I was surprised this was still choking, and it wasn't stopping on my custom mod LESS (partly because I had already quote escaped the math I needed to protect from LESS) - it was choking on stock UIKit source. The issue started for me with UIKit 3.18 I looked into whether the math setting changes may have an impact because of what others found on unrelated frameworks. In my particular case, I allow for dynamic type scaling in theme options based on variables, and I use dynamic font scaling to maintain line line lengths also. In my case when you allow LESS to do the math on its own it sometimes the parser is too greedy. I do wonder if using the up-to-date LESS.php package (I think it is 4.4.1 when I dug into it yesterday) would help, but I found it wasn't necessarily a direct drop-in for some reason. I ended up reverting to the default module.

This is more just a reminder post than a problem post. If you have been having issues building UIKit from more recent repos it may be because the math setting in the currently used LESS.php wikimedia version is a bit greedy. Even after setting the 'math' => 'strict' option in the $less object it still gave an 'Operation in invalid type error'. I forgot that I needed to modify two files in order to get this to compile. base.less and article.less have two variable calculations that need to be quote escaped. Basically you need to turn this: @base-h1-font-size-m * 0.85; into this: ~'calc(' @base-h1-font-size-m ~'* 0.85)'; No matter how many times I write this someplace I forget that it needs to happen. So I am saving it here for the next time I desperately search for it.

Okay... Doublechecking it was in RepeaterMatrix items only. Nested maybe 3 deep. I will play around with it later this week if it doesn't affect you and I'll let you know if I find anything related to the module. I need to dig into how I can alter the pwimage selector in front-end editing to grab the imagefield from the item in a repeater field and not from the page where the repeater field is anyway so I will dig into that as well.

Just Repeater and RepeaterMatrix - like I said the value is still in the database so it doesn't break anything. Could be a fieldgroup context issue I just haven't had a chance to look at the code to see.

For some reason this doesn't recall selections in repeaters for me. I see valid forms in the dropdown, select one and save, but the setting doesn't return to the form - the select element is stuck at the blank default. On the backend, however, the selection is saved to the database.

That makes sense. I'll look for more hookable stuff - I always forget to do that for mods.

My reason for looking into this is for things like a style block selection or a font selection - it would be great to be able to show an image below the selection instead of text. I'm not sure how well it would work for tooltips.