horst

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/

@Roope: sorry for this with the image array(), but you already have found your way to get the informations before resize and how to alter them within imagesizer. If you need the pageimage as your final result, you can store it with your first hook. If I remeber right, you already hook into before pageimage:size, right? Store it then, and after you have your tinified file, create a variation pageimage like this: $tinifiedPageimage = clone $this->previouslyStoredOriginalPageimage; // from your first hook !! $tinifiedPageimage->setFilename($filenameOfTinifiedFile); $tinifiedPageimage->setOriginal($this->previouslyStoredOriginalPageimage); return $tinifiedPageimage;

Hi BitPoet, thanks for pointing me to the missing requirements param! (shame on me ) But Phil explicitly said he used PW 3.0.14. ??

here is reported an issue with a native PW3 module that complains not to find a core module: https://github.com/horst-n/ImageSizerEngineIMagickCLI/issues/1 does anybody know why this may behave this way?

do you see any notice / hint in the PW logs? site/assets/logs/errors.txt site/assets/logs/exceptions.txt site/assets/logs/warnings.txt

Sorry, I do not work much with CKEditor, but maybe a detailed google search uncovers a solutions: https://www.google.de/search?q=site:processwire.com/talk+-%22Viewing+Profile%22+%2Bckeditor+%2Bextra+%2Ballowed

Best solution would be, to be able to only remove all unused image variations. Also, the deletion isn't the part what can do much harm to a site or server, I believe, but the recreation of the new variations, especially with (much) multiple requests for pages at the same time. If a page contains 100 images and each image need to rebuild 5 variations, ... hmm, ...

No, there is nothing built-in for this. You need to send apropriate HTTP-headers. About which one, you may read here: http://stackoverflow.com/questions/17968837/file-opens-instead-of-downloading-in-internet-explorer-in-a-href-link.

is_int() & is_null() if(is_null($page->cruise_spaces)) if(!is_int($page->cruise_spaces)) if($page->cruise_spaces === NULL) if($page->cruise_spaces !== NULL)

+1 for ProCache +1 for AIOM+ But ALL imageVariations?? Ugh! For imagevariations, I believe, a per-page solution would be much better.

What is with (Pro)-cached pages? I believe, a JS solution is needed there, as serverside PHP execution is ommitted.

@eutervogel: $pages->get() always returns the first page, if any or multiple are found. But, unlike the $pages->find() method, it assumes that you, when using ->get(), you definetly want get this page and it has disabled access checking and uses include=all. To understand what include=all and no access checking means, please try the following code to compare: $page_exsists = $pages->find("title=$searchtitle")->first(); This will give you only pages that are not hidden and not locked and that are also be accessible, (no admin (sub)pages like repeater items). But both, ->get() and find()->first(), will give you back a page object that has an ID! (find gives back a PageArray, = multiple page objects). And in cases where no matching page can be found, it contains a NullPage. NullPages ever have an ID of 0 (zero). So, if you want store a boolean, you can do it like this $page_exsists = $pages->find("title=$searchtitle")->first()->id > 0; But you also can check for NullPage, or if count() of the pageArray is greater than 0, or if it matches exactly 1, or if it contains multiple pages. Hope this helps a bit.

Hi Gazley, I'm not sure if I fully get what you are after, but I try to answer. You can access an Imagesizer instance like this: $ImageSizer = new ImageSizer(); // or, maybe better, with an image-filename $filename = $page->images->first()->filename; $ImageSizer = new ImageSizer($filename); Now you can query everything you want: https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire/core/ImageSizer.php#L312-L321 https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire%2Fcore%2FImageSizerEngine.php#L1110-L1131 https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire%2Fcore%2FImageSizerEngine.php#L205-L216 $quality = $ImageSizer->quality; // returns the calculated value from: engine-default-setting => wire/config.php => site/config.php EDIT: Or do you mean the new modules configurable default settings of the ImagesizerEngines? If yes, you can use the $modules method getModuleConfigData() $configdata = wire('modules')->getModuleConfigData('ImageSizerEngineIMagic'); $defaultQuality = $configdata['quality'];

You need to be able to make the ImageMagick executable in your system. If they are installed correctly, one can call them via php function exec(). You need to add the full featured directory path of the executable in the module. If PW cannot find it or PHP isn't able to execute it, PW automatically passes the image rendering to the GD-lib. 1) So, first you need to check if your ImageMgick executable is registered / installed correctly in your system. 2) can php call and use it? 3) is the right path defined in PW? (in ImageSizerEngineIMagickCLI module) If all would be true, the ImageSizerEngineGD would not be invoked.

The image craetion / rotation belongs to the creation of an AdminThumnail, I believe. It has nothing to do with the upload itself. Or do you have defined any max-dimension with the imagesfield? But if you are on PW3, why don't you use another image engine than GD? If you can go with IMagick or NetpbmCLI or ImageMagickCLI, yo will not run into those problems. The GD-lib is the only one engine that always need to load the full uncompressed image into memory as one block. The other engines are able to process images in lines or chunks.