gornycreative

Looks like that did the trick. Thanks! @Robin S

Thanks @Mats - that's enough tinkering for now! 😄 1.0.2

Ahhh so good. Date ranges would also be fun.

Something else I noticed recently, when a page has two unsplash inputfields on the same template they are linked, so perhaps the js needs more granular selectors for the interaction layer so that each inputfield can operate independently. This module otherwise still works very well. I think pulling the data-id value from the element and attaching it to the `splashAndGrab` id on the fieldset in the js and form output will fix it. If I can get something working I will sub a PR. This was simpler than I thought. I want to test a few more things but I believe I got this working in a way that allows for multiple separate instances. Once I test a little more I will sub a PR.

I started implementing this... and will incorporate some styling elements in the next AdminStyleChroma... One of the things I have run into - and this is a specific interaction with Pro modules so it may not be something you have encountered. If you use UserActivity and have the limit-save option set (which tries to only save changed fields) for some reason changes to EasyMDE fields are not always detected and do not always save. I haven't looked deeply into it, but I know that if I type content in manually the change is generally detected, but cutting and pasting content on its own usually does not register. If there is a timing swap between the control and the underlying form input, maybe make it shorter? I ran into something similar with the gradient module I did where, if User Activity is installed, I trigger a field change flag. I've tried typing manually, typing manually and then pasting content, pasting content alone, and pasting content and then typing and got inconsistent results. Turning off limit-save obviously removes the problem entirely. And it seems that waiting a certain amount of time also seems to give more consistent results. For the Grapick module I did a bit of a cheat where I add the class to the input that UserActivity looks for: //Will allow an inputfield to be picked up as changed when using the advanced features of UserActivity. pwStopsWrap.classList.add('InputfieldStateChanged'); This was set on the change function that gets called once a gradient color point on the UI is moved or the color is changed.

It usually is not... thus the need for scripts like this (which I used regularly on WP back in the day) https://interconnectit.com/search-and-replace-for-wordpress-databases/

Perfect. I will check it out.

I have been totally out of the loop working on a contract, but I saw the video release and now have read over this thread! Looks great, especially if you need to maintain public calendars. I was working around the code for FieldtypeRecurringDates but this looks like a full-featured alternative for appointments and other simpler event management. Something to think about, and it may already be on your roadmap but... For sites that include more extensive event descriptions, or reusable chunks of complex metadata or descriptions, it would be nice to be able to associate pages with an event - or perhaps an event rule? Is their an external page association you can set to an event/event rule in addition to the event title and description paragraph? Either from the calendar side via a page selector, or on the external page side from a multiselect dropdown field? It would be nice to be able to link an outside event information page - which describes everything - to an event on the calendar. I'll have to grab this later and see if there are some sync options to dev. Would be nice to be able to sync to a google calendar or acuity, bonsai, calendly, clickup, etc.

Cool. I should've check issues on github first. Thanks!

A minor issue, but if a site isn't running multiple languages, the $language api var is null. There needs to be a null check on line 322 in the .module file, such as: if ($this->wire('languages')->count()) { $lang_id = $this->wire('languages')->getLanguage()->id; } to: if ($this->wire('languages') && $this->wire('languages')->count()) { $lang_id = $this->wire('languages')->getLanguage()->id; }

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