horst

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.

Yes, this is correct, and there should be no need to hook into other parts, I think.

Hi @Roope, before we go into detail, I have one question about what PW version you want support: PW 2 or PW 3? If you are not rely on PW 2, there will be lot more possibilities. But there are ways for both versions. What I suggest for both versions is, not to hook into Pageimage or that like, you only need and should hook into Imagesizer::resize. You can add any option to the options array of Pageimages. You can do this with individual API calls, or you can do this as a sitewide setting in the site/config.php under $config->imageSizerOptions. $config->imageSizerOptions = array( 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 90, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => 2.2, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) 'tinify' => true, // your option for all imageformats here // or your options for specific formats 'tinifypng' => true, 'tinifyjpg' => true, 'tinifygif' => false, // or whatever you like ... ); Regardless if you use sitewide or individual options, they will make their way into the ImageSizer. Using sitewide options and overwriting them with an individual value passed as $options array in the API works too. This is all supported in PW since version 2.5.11. The only thing what I would hook in, (if you need to support PW2 too), is the Imagesizer::resize method: before: check if tinify is requested and if true, adjust quality for jpegs to 100%, (and, maybe, add "tiny" to the suffixes array ??) after: pick up the resized image variation and transfer it to your tinify service If you can go with a PW 3 version only, I have some thoughts to standardize optimizations like yours: they should be able to register themself into the ImageRenderingChain as optimization / compression tools. This way, the PW ImageEngines would take care for most of the above stuff and simply call (at last step) your provided service. ---- // example for PW 2.5.11+ public function init() { $this->pages->addHookBefore('ImageSizer::resize', $this, 'hookEventBeforeResize'); $this->pages->addHookAfter('ImageSizer::resize', $this, 'hookEventAfterResize'); } public function hookEventBeforeResize($event) { $this->image = $image = $event->object->image; // first do a check if tinify is requested if(!$image->tinify) { // or do we need to look into $image->options['tinify'] ?? for user options ?? $this->tinify = false; $event->replace = false; return; } // tinify is requested, set a flag for the hookafter and adjust quality $this->tinify = true; $this->image->quality = 100; } public function hookEventAfterResize($event) { // was tinify requested or not if(!$this->tinify) $event->replace = false; return; } // pick up the variation file and pass it to the tinify service ... }