horst

@alan: I just updated the readme: https://github.com/horst-n/WireMailSmtp

On pages like the older images doc, there are links at the bottom (RELATED FORUMS THREADS) in the form of: .../index.php/topic,97.0.html Don't know if those were working before the switch, but now they don't. Also I know that we have the brand new Docs, what are very fast growing! Just wanted to mention.

Hi Jim, you are right, in the older documentation, there is only the older basic image handling described, but for most of it, you can switch to the new Docs, lately introduced with PW 3 branch, also if you use PW 2.6 / Pw 2.7 Here you go: https://processwire.com/api/ref/pageimage/ https://processwire.com/api/ref/pageimage/size/ https://processwire.com/api/ref/pageimage/suffix/ ...

I can see! You should read a bit about the images and our ImageSizer in the docs. What you are currently missing is, how to avoid the images caching. Add "forceNew" => true to your options array while developing. Otherwise you always will get the previously created and cached variation. If you want to compare different options in one go, you also should read a bit about the suffix property.

This post describes a bit where it comes from: https://processwire.com/talk/topic/12151-wire-queue-basic-implementation-of-simple-queues/#entry112809 @Sephiroth: if you find it useful in general, I can assist in extending / building a sqlite version that suites your needs. (define more finegrained sqlite table fields and fetching batches of a given number recipients at once, for example 100)

Well done!

@diogo: this is a really nice one. Many thanks for sharing!

I assume you are not able to upload and execute binarys on a shared host. I think it isn't allowed / is suppressed by the hoster. At least, that the GD-lib is invoked points to this. You also can force an image engine via API calls: $image = $image->width(500, array("forceEngine" => "ImageMagickCLI")); I think you need to ask the hoster where the IMagickCLI resides and take this path.

I suggest to use Pia. With Pia, you simply can define the (max) outerbox dimensions and it will return you an image with dimensions that fit into it. Means, if you define a 600x600 box you will get back an uncropped image variation where the larger side is 600, regardless if it is portrait or landscape. If you like to have larger landscapes than portraits, you can define width=800, height=600. It is simple. Examples with Pia: $thumbnail = $image->contain("width=800, height=600"); $thumbnail = $image->contain("square=600"); If you have many different aspect ratios with your images, you also should have a look to Pias option "weighten"!

If you have updated to 3.0.18 just before the error occures, you also may try to empty the modules cache 1-3 times.

Is not 100% to your request, but maybe of interest too. https://processwire.com/talk/topic/5796-session-handler-database-do-not-delete-old-sessions/

With PW 3.0.18 there were again major changes in the code of the core images field that renders the intermediate version invalid, (again). So, atm it doesn't make much sense and also I don't have the time to find a way how to implement the croppable images functionality into the new images field. At least, because there is no easy interface or hooking point supported to archive that. One possible solution could be to make the old core images field a third party module, so that the crop tools can extend this as it was before. Ryan mentioned this somewhere already. Another solution, what I would prefer is, what @Martijn suggested: https://processwire.com/talk/topic/13279-pw-3018-yet-more-images-field-upgrades/#entry120097

Is this already in, "crop sizes from presets"? If we could have that with the core images field, it would make the croppable images obsolete, what I think would make things much easier. We only would need one images fieldtype and optionally can define "presets" or not. Wouldn't it? +1

I believe those IDs are collected in a visited array in $session and he will pull it from there with implode("|", $visitedCollection).

Ah, glad that you found an easy way.

Hi impatient Pete, I have edit your post and added the link to the new AdminThumbOptions array on Github. The PW 2.5 is obsolete with PW 3.0.17, so this is important to know, and not to rely on the old settings! And just to clarify: I wrote "Hey you impatient PW users", not "Hey you impatient PW user".

I cannot follow for what you need all those arrays besides the images-array? In the images-array all informations are accessible, why do you need to populate additional arrays with redundant data? I clearly haven't checked what you want to do here. You get you a random image from a multiple images field (what is a wirearray). And now, where is the other data that you need to find, before you populate all those arrays? I'm also not sure if this is correct: $rand_nr = rand(0, $h_images->count()); or if it should be $rand_nr = rand(0, $h_images->count() -1); Images->count is 1-based and numeric array indexes are zero-based. ---- But back to the main question. Is it right that you have an images field and a list with links that is somehow paired one by one, but lives in different objects? What do you use to store the links in? Wouldn't it be possible to write the links directly into an images field (by default, you have descriptions and tags field, but with a module like images-extra, you can add as many fields to the images as you need).

This is wrong. Maybe it is not desired, but it is how it is designed and how it should behave. Read on here: https://processwire.com/talk/topic/8709-croppableimage/page-7#entry119837

Crops are variations, and they clearly should be removed! But they will be recreated automagically to the exact last selected crop-rectangle and with your used values for quality and sharpening. It can do that because we save every named crop with your last selected coordinates into the metadata of the original image. So, even if the crops are gone, if you recall it via API, it recreates a new one. (At least it is expected to do so)

Ok, if this has worked with PW 2, there is something broken / has changed. I put this on the bug list! But atm there is not much time I can spent on it.

Only thing I know is with ProCache, there you can globally toggle it with a single click.

If there are image variations present, you need to add a 'forceNew' => true to your options array. But this shouldn't stay always in your code. So, you need to find a way to manually or half-automated set a flag if the following derivatives should be recreated or not, I think.

You get back a random integer and how do you call the image from the array? Can you provide a line or two of your code? Does it look like this? $iRand = rand(0, $arrayTitle->count()); $image = $arrayTitle->eq($iRand); And why do you not use the getRandom() method? I do not understand what should be the advantage of using php rand here? If you select a random item from your multiple images field, you get the handle to a pageimage and all of its methods and properties. $image = $arrayTitle->getRandom(); But regardless how you do it, at least you should get a random pageimage object from which you can pull the title or name or whatever you need. echo $image->title; echo $image->url; echo $image->name; echo $image->filename; echo $image->description; ... ---- PS: Do you make sure that at least one image is provided with your field?

What kind of data is in your $arrayTitle? and have you compared the value of index 0 with the other items? Do they differ somehow or are they more or less equal?

I haven't tested it this way, but I think you will be on the save side with updateting an existing site when you follow this path: If missing, install the RangeSlider module delete the whole croppableimages directory under site/modules copy the new one into site/modules, (DO NOT SIMPLY COPY IT OVER THE OLD ONE, or AT LEAST MAKE SURE THAT THE FOLLOWING FILES ARE NOT PRESENT THERE **) clear caches for modules and the file compiler update your site/config.php with the settings for adminThumbOptions (it needs at least one setting for 'gridSize', I prefer 160 over the new default of 130) open the module config page and select your setup **) have a look into site/modules/CroppableImage/InputfieldCroppableImage and delete the InputfieldCroppableImage.js and InputfieldCroppableImage.css if they exists. The PW 3 intermediate Version doesn't use this files atm. It uses InputfieldImage.js/css and InputfieldCroppableImageMan.css/js