horst

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

Hey, you impatient PW users, here is a intermediate version for the current PW 3.0.17 devns branch. It is only available in the Github PW3-Tree. (you need to upload and install manually) Attention: Please first install the InputfieldRangeSlider module. It is required for the new version! The module now sits upon the new core Imagefield and provide a few more configsettings as the PW 2 version: disable enable the core image editor (default: disabled) should Imagenames be displayed by default (default: off) should Thumbnails be displayed complete, not a cropped square (default: off) style settings (color and transparency) for Thumbbackgrounds max char number for Imagebasenames (please adjust according to the length of your GridSize) (default: 15) globally disable the individual selection for Quality and Sharpening, instaed use the ImageSizerEngines defaults or define globally static defaults In the Inputfield itself, you are able to toggle displaying the Imagenames and how the Thumbnails are displayed: cover or contain. There is also a textinput for filtering by basenames. Screens:

In addition to @teppo and @szabesz, there are more usecases what are currently seems not to be covered well. I must admit that I first also have thought that we need the list view too. But now, after playing around a few times in the last two or three weeks (with an unofficial beta, thanks to @Lostkobrakai) I'm not even torn. I have learned to live without the listview. Usecases that are not well covered atm, for example are image rows with 20 motives that all look the same, where you need the filename, and I mean the filename of all files at once. What I come up and tested (in context of the croppableimages extension) for this are two things: one can toggle visibility of filenames over the thumbs using a little textbox for filtering by filename This is even faster than looking through an endless list of filenames. Another usecase sometimes may be to directly see the aspect ratios of all images at once, not a nice looking centered cropped square. But you will not get that WOW-effect with a visually cluttered grid, also covered with filenames all over. So IMO it depends on the usecases and the user preferences: As you also can see in the second screen, media queries are respected. This isn't what I have done, this is already in the new core imagesfield! (@szabesz: there must be a glitch somehow with your device / version) I simply have extended the new core image field and was able to use comfortable supported hooks from the core field. Here seems to be all usecases already covered on the developers side! Conclusion: with every newly introduced thing, first part is a confrontation with no more able to behave the same as before (we, the users / developers) (sorry for maybe long and bad describing words, but I think you get it) Phase two should be to find some time, play around and try out that new thing, and if you find a usecase that isn't covered well now, don't simply say we need to implement the old way here for that. I personally think I'm oldschooled in many things and also not a friend of often changing things, but I'm so happy that I have had the chance to get my hands that early to the new imagesfield and in addition also found the time to play around with it! As one result, now I have improved my own behave / workflow in some usecases and are also able to give my clients a very well looking edit page, so that they can see and say: WOW! EDIT: and sorry if it looks that I shamelessly promote the croppable extension here. The new core imagesfield from @Renobird and @Lostkobrakai allone is responsible for all the ongoing new things. I wouldn't have done anything without it and also simply wouldn't be able to do things like I now could do. This all depends on the core imagefield. Most things what I have done to adapt the croppablefield with it, was to strip out great parts from the PW2 version so that all the design and magical stuff is delegated / handled from the core imagefield.

If you are able to do, I would suggest to create a simple testsite with latest PW 3.0.16 and enable the IMagick ImageSizerExtension. Would be interesting to compare the time on the exact same server.

Ouch!

We already check for correct filetypes (imageformats) before processing images. We use PHPs function getimagesize(), what internally uses this magic-byte-check for format detection, I assume. But will check this further. EDIT: Yes they do: https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/image.c#L41 https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/image.c#L1246

Good news! (ProCache and AIOM) In regard of the image variations, maybe you can provide a hook, so that others are able to add a functionality?

I would use $input->get->s, and not the PHP superglobal $_GET['s']. Also you need to check if it is a valid ID: <?php $pageId = (int) $input->get->s; // also typecast to integer // get a page $editpage = $pages->get("id=$pageId"); // now check if you have get a page if($editpage->id > 0) { // if it could not find a page with that id, it returns a NullPage with id = 0 // it also may be good to add some more to the get selector, like template=XXXXXX, //as if one simply can send you only an ID, someone may try to open Adminpages or others!

@teppo: we definetly need two versions. I think, to clear all at once is the more common one and should have priority. A per/page solution may come later. @tpr: that's the question. I don't have experiences with RTE's and images. I know that Ryan has done something to be able to recreate variations in RTE's. But I don't know when and in what extend. Think of these use cases: variation from an imagefield of the same page variation from an imagefield of another page The first one can be covered, if I remember right on what I have read from Ryan (don't know where I have read it) The latter one I don't know. We need to test thouroughly, I think, or ask Ryan what is currently covered and what not. There are three different types: original images image variations orphaned imagefiles Only the variations belong to the Cache.

On Github you can pull three newest versions: PW 2.7 stable PW 2.7 dev PW 3.0 devns (= namespace) Maybe you haven't selected the right branch, or it got deselected before you clicked the download button ==> https://processwire.com/download/