Pete

@ryan ProcessWireUpgrade can't seem to see 3.0.206:

I'd 100% love to see the snapshots feature make a comeback eventually - clients can do... "funny" things sometimes (and I've been guilty of it too ?), though I appreciate it's a hard one to crack.

Hi Adrian, it's been a while since I needed this functionality and didn't realise I'd left my own module still up - I'll likely take it down soon and direct people to yours if you think that makes sense? I'm going to use yours for a project, but can I suggest an option to hide the login form? For normal maintenance I wouldn't let any roles log in and as superuser I'd just go to the right URL instead is my thinking. It may also be worth changing the title of your module in the directory to "Protected/Development/Maintenance Mode" so those keywords are found during search as currently only mine comes up for "maintenance".

@bernhard I can't quite work out what the code would look like there, because if I bd() the inputfields on the page, it only shows the "outer" combo field name, not the subfields. Something else to note using my code is that if you output the field DATA (not the inputfield markup) on the frontend (which in my case is a country) using code like this: echo $user->billing_details->country; it won't show the data as it doesn't know what the key/value pairs are supposed to be when formatting the data. So I got around that by doing: echo $user->getUnformatted('billing_details')->country; Which simply outputs whatever you had stored in the DB. I'm sure there's some way of covering all this in 2 hooks or less using your method bernhard but not sure what it would look like for a combo field. For now my 2 hooks and outputting the unformatted value gets me where I need to be. I just wish I'd remembered about getUnformatted 90 minutes ago ?

Ah thanks @bernhard that does make sense, I'll check it out!

I encountered an odd error today and I cannot for the life of me work out what caused it: However I added !is_null($fieldObject) before the count on the line in question (and the other 2 places that same piece of code crops up) and that sorted it. For whatever reason the field object was null. EDIT: Ah - I think this is a PHP8 thing actually which explains why it was working last week and not this week - that's probably it ?

If anyone's wondering how to get the data to save, you need to set the options again prior to processing the input. So here's my example - first hook adds my options to the field so they render, second hook makes the options available when processing the input: wire->addHookBefore('InputfieldSelect::render', function($event) { if($event->object->name == 'my_select_field_name') { $countries = [1 => 'UK', 2 => 'USA', 3 => 'Etc etc']; $event->object->setOptions($countries); } }); $wire->addHookBefore('InputfieldSelect::processInput', function(HookEvent $event) { // Get the object the event occurred on, if needed $InputfieldSelect = $event->object; if ($InputfieldSelect->name == 'my_select_field_name') { $countries = [1 => 'UK', 2 => 'USA', 3 => 'Etc etc']; $event->object->setOptions($countries); } }); Using this in a complicated project where I've got custom tables for some data and it works nicely. Possibly also worth noting this works for checkboxes and radios I think as they are all extended from InputfieldSelect

Thank you - I had Covid last week so haven't had time to look at this yet but looking forward to testing it out this week.

This module is great - thank you. I'd love to see the addition you mentioned above though as there are some forms where I only want to display hCaptcha to guest users since logged-in users on the site I'm working on are already validated by this point. I guess the permission should just hide/not render the form and skip it during form validation but not sure how easy that is. I guess the way to do that in the meantime would be via hooks, so using your example below from the docs, but only target visitors who aren't logged in and render it for just those visitors: <?php // site/init.php wire()->addHookAfter('ProcessPageEdit::buildForm', function (HookEvent $event) { $form = $event->return; $submitButton = $form->getChildByName('submit_save'); if ($submitButton) { $hCaptcha = $event->wire('modules')->get('InputfieldHCaptcha'); $hCaptcha->set('label', __('Spam Protection')); // ... configuration goes here $form->insertBefore($hCaptcha, $submitButton); } $event->return = $form; }); I'll give that a go and see how I go.

Oh nice - wish I'd looked harder before doing it my own way as that sounds ideal ?

I've also been using this great module on another WP conversion project to do the same thing: https://processwire.com/modules/custom-paths/ I'm not 100% sure if it checks for uniqueness (probably) but since everything's being imported by a script I wrote I know they are unique for now.

Haha just got caught out by it again 3 months later and end up here only to find my own comment on it ?

I've got a scenario where I use ProcessWire as a CRM for a client and they have several companies using this now, so it's important to be able to update things easily across all installations. A tricky one recently was working out how to manage translations via API to avoid going into several installations, enabling language support and translating the file manually (in this case they wanted to tweak a message in LRP's confirmation routine). On your master installation, do your translation as normal Export to CSV Upload the CSV file somewhere where your updater code can reference it - I created a folder in site/assets called "uploads" for some CRM-specific stuff, so I added another folder under there for ' Use code similar to the below in your updater script on other installations to first create the JSON file to be translated (it may not already exist) and then import your CSV file and tidy up afterwards - something like the below: <?php $this->modules->refresh(); // I've found this helps first, mostly for modules that have just been pushed to the Git repo but doesn't hurt to do it every time $this->modules->install('LanguageSupport'); // This wasn't yet installed $languages = $this->wire()->languages; $default = $languages->get('default'); // We only use the default language as it's only for the UK market $default->of(false); // It will complain without outputformatting switched off under some scenarios $translator = new LanguageTranslator($default); $translator->addFileToTranslate('site/modules/LoginRegisterPro/LoginRegisterProConfirm.php'); // This generates the JSON file that you would see in PW on the translations page $languages->importTranslationsFile($default, $this->config->paths->assets . 'uploads/imports/default-site.csv'); // This imports the CSV we exported from our master installation unlink($this->config->paths->assets . 'uploads/imports/default-site.csv'); // And we don't need the file afterwards I appreciate it's not a particularly in-depth tutorial, but may help someone out there with a similar need. Our CRM installations are all on an Amazon EC2 instance under separate subdomains, so separate databases too and there's a shell script I use to iterate all the installation folders, get the latest updates from the Github repo and then run an updater script that will do more complex updates like the above code or perhaps alter tables etc. This may get trickier in future if we shift to using something like Docker, or that may make life easier, but at the moment this is all nicely manageable the way it is.

Go for it - just be aware that you don't have the originals afterwards of course. You've reminded me I also have a Craft site I can run this on, although the client does usually manually resize their own images it would be good to check.

It turned 25GB into 11GB by the way. There's still a lot of photos in there ?

One other thing - I am also keeping a copy of the original uploads folder just in case. I've set max resolutions in various CMS' since 2001 and in later years you wonder why you ever set it as low as 800x800 for example ? This way I have the originals if I ever need them again, but I think for the content in question, 1600px max width/height should be absolutely fine. There will also likely be a write-up for this project - it's going to be a while longer though before it's ready.

Hey folks, so in a project I'm working on there are 750+ news articles in WP that are image-heavy in recent years. WP has a habit of storing the original images full-size - well, ProcessWire does too but I always set max dimensions on the image fields to resize during upload to prevent 2mb+ images on my disk. This had resulted in an uploads folder some 25GB in size from 2003-2022. Disk space is, fortunately, cheap nowadays, however I soon realized after mulling it over with Ryan that the easiest and most sane option for importing all those articles was to scrape in the post content HTML into a PW CKEditor field (thanks SimpleHTMLDOM for making this so simple!) but leave the images alone - WP had already done resizes for various lightboxes and galleries so it was just the original, huge images I had to contend with. The solution - on my own copy of the WP uploads dir - was to run this command and watch it go: find ./ -type f \( -iname \*.jpg -o -iname \*.jpeg -o -iname \*.png \) -exec mogrify -quality 90 -verbose -resize 1600x1600\> {} \; It's basically searching all files and subfolders for .jpg, .jpeg and .png files and resizing to no more than 1600px landscape/portrait whilst preserving aspect ratio (no cropping) and 90% image quality. I chose those sizes as the various links in galleries and lightboxes were loading the original file, not one of the WP resized ones, so now we can be fairly sure that we're loading <500kb of image maximum instead of sometimes 10mb+ (some folks have really nice cameras ? ). I'm sure @horst can probably tell me if that command could be better. I think mogrify is usually for a batch of files for example, whereas the find command is serving them up individually so convert might be more appropriate than mogrify, but this command iterates through the files quickly and only resizes which ones it needs to and is happily chugging away right now so I'm happy with it. One thing to note is that any resizing can be a bit CPU-heavy, so if you have the chance to do this on a local server first or out of "normal" hours for site visitors then that's recommended as the server may slow down for the duration.

It's on a CRON job so not a form, but also it's only happening occasionally, not for every email generated by that function. 100% it's since my new code so it's some weird combination of CRON and something else.

Had a bit of time to look into my issue and it's only started since I changed some code, plus that code is run via a Cron job as the guest user so too many variables to check at the moment, but the fault doesn't seem to be in the system or any module at least so that's good.

Experiencing the same lately, but not with every email sent from the same block of code which is all the more curious as it's the same email, just sometimes it'll send once, sometimes twice. I'm using WireMailSMTP with Postmark but will check it with the WireMailPostmark module when I get a chance to see if it's something in WireMailSMTP (unlikely I'm sure, just ruling things out).

Thank you - I think when I last tried it both selects were in a combo field (Pro module) so may not work there but might with this update - I'll check.

Can you remind me how dependent select fields work?

Thanks guys will take a look at these ?

Hi all, I've got a custom backend page add/edit modal and can hide the tabs I don't want on the page that opens in the modal easily enough, but is there an easy way to hide the "Save and Keep Unpublished" button and perhaps rename "Publish" as "Save"? I'm pretty sure I'll need a hook but not sure where to look.

For anyone who comes across this topic, I'd done a Wordpress import and was storing the original filename in an extra field in my photos field, so my code to rename after I botched the names up the first time was: foreach ($page->photos as $photo) { $photo->rename($photo->wordpress_filename); } $page->save('photos'); I suspect that you can do this too if you have a separate array of old and new names - not tested but it is the same idea as above done a different way by getting the file by current name first, then renaming it: foreach ($renameArr as $old => $new) { $page->photos->getFile($old)->rename($new); } $page->save('photos'); The act of simply saving the relevant field after the renaming updates the database nicely whereas looking at the previous comments this wasn't always the case.