MindFull

@adrian - Thanks for that. That's usually what we do for the primary DB instance when we aren't using GCP. For us, setting the DB instance flags in Google Cloud SQL accomplishes the same thing via their admin console. In case anyone needs it: this is Google's reference for Cloud SQL's flags. Do note, there's a known issue that there's no automatic daylight saving adjustment. I prefer to leave the UTC with no offset. I'll likely look at the module's source a little closer and modify the input/output timestamps from PW to match the client user's timezone.

Happy to report this module has been fairly robust in some of our clients PW instances. Thanks for all your work! One thing I noticed is that the revision timestamp is being generated by the database and not via PHP. So when the two services are on separate machines, with different timezone configurations, the timestamps don't match up with the activity on the web server. Just discovered this as one of our client's databases went down and a failover database in another zone took its place. Revisions were showing that the users had traveled to the future... 5 hours from now. ?

Are you referring to fields that have the Datetime type? If so, have you tried enabling the "Date Picker Year Range" field by selecting any radio under the "Date Picker" field other than the "No date/time picker" option? It allows you to specify the year range before and after the current year.

I went down this road for a couple months - tried it out but I wasn't making much headway with the learning curve (steep). Reluctantly, I decided to come back to PW... ?

################################################################################################# # START PROCESSWIRE HTACCESS DIRECTIVES # @version 2.3 ################################################################################################# ... # ----------------------------------------------------------------------------------------------- # Access Restrictions: Keep web users out of dirs that begin with a period # ----------------------------------------------------------------------------------------------- RewriteRule "(^|/)\." - [F] Eeek! - My PW 2.3 is showing lol! I have go to remove that from my Notepad++ cache

Absolutely loving this! The tables look great - way to to put PW to work!

I've seen the .well-known directory with hosting providers that offer cPanel accounts with the AutoSSL feature turned on. Both LetsEncrypt and Comodo cert renewals use the folder to install and replace soon-to-expire SSLs. Depending on your hosting provider's configurations, even self-signed SSLs may get updated. BTW: For those that chose to use AutoSSL, Processwire's .htaccess config prevents reading of .txt files and access to directories beginning with periods so those would need to be turned off temporarily to allow the cert to be installed. Otherwise, PW will issue a 403 each time AutoSSL attempts to access the directory/file. Then, the SSL will expire and piss everyone off until it's fixed. But that's no fault of Processwire - It's better to keep those things in check then to let hosting plugins silently do whatever they want.

Then don't save it No, really though, if you want you can just delete/clear the field before save.

That's great to hear! It makes me want to give it a go just to see how it compares with my vagrant/vb box config. More speed = more better lol.

Just an idea: use PageTable. Maybe use a template for artist that has Artist_firstname and Artist_lastname, etc. Then, a pageTable called Artist_pageTable that uses the artist template. Also, create a template called Artist_works with the associated work fields, including the Artist_works_inventory_no. Then create a pageTable called Artist_works_pageTable that uses the Artist_works template. Since everything's a page, you could do this: $pages->get("template=artist,Artist_firstname=$firstname,Artist_lastname=$lastname")->children("Artist_works_inventory_no=1")->count();

The repeaters are nested so you'll need to approach this differently. In your page tree, you'll see that the repeaters are not true pages of your Artist page. If you look at settings of the repeater fields you created, you'll see they have templates and parents that belong in then Admin/Repeaters area. If you must use repeaters like this (which I don't think you do) you'll need to target the repeater templates/parents. Since your attempt shows that Artist_works_inventory_no is not unique, you could try: // get ID of repeater with artist that matches the first/last name provided $artistRepeaterID = $pages->get("template=repeater_Artist,Artist_firstname={$firstname}, Artist_lastname={$lastname}")->id; // repeaters have names like for-page-someID, check your page tree to see what I mean $artistWorkParent = "for-page-".$artistRepeaterID; // Find the matching children that have the inventory id and count echo $pages->get("name={$artistWorkParent}")->children("Artist_works_inventory_no=1")->count(); Personally, I think this approach with nested repeaters could be reevaluated. Many you can explain what you're trying to accomplish?

I think so too. If the inventory number is unique for all art work, you could use: echo $pages->count("template=repeater_Artist_works,Artist_works_inventory_no=1"); The repeater before Artist_works comes from PW adding before storing the repeater field in Admin/Repeaters

Maybe you can show us what you've tried? I just copied/pasted Soma's example and the core of it stills offers a starting point for using PW core inputfields in custom forms. Here's how the result looks: This is with the code Soma gives for the form and the head.inc which he gives in the mentioned thread. You'll have to make it functional for your needs but it gives you a starting point.

Congratulations! It gets easier on each iteration (no pun intended)

Just curious, is there a particular reason to why you use opening and closing php tags for each line of code?