horst

@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 ... }

I assume, the Samsong mic is for singing only.

@Roope: this is good news. I have only one suggestion: I would avoid the uncontrolled automated mode! (for every size() request!) Instead I would bind it to a defined suffix option (tinify). Or you do it the opposite, check for a suffix (notinify) and compress all others. This is the only way to be able to also produce intermediate images wich resulting pageimages will be passed to another image->size() request. Also, if the image is marked to get compressed, you need to check the setting for quality (if it can compress jpegs) and adjust it to 100%. If you compress images with quality settings lower than 100 and afterwards pass them to the compress service, you will get results with higher filesize! and with lower visual quality! If you have any questions to my suggestion, I'll be glad to give more info and / or point to some. https://processwire.com/talk/topic/6667-jpegoptimimage/#entry65531 (the first part) http://images.pw.nogajski.de/jpegoptim/ (compared different imagesizer quality filesizes)

Thanks! I will try this on a site where it behaves a bit same like you described.

What does this exactly do? Can you give a short example how the search phrase has to passed to PW?

Ah, here is a very valuable post from within the case studio of the National Geographic Site: https://processwire.com/talk/topic/7494-case-study-the-triumph-of-national-geographic-traveller-india-in-processwire/page-2#entry72498 And, also it is that mainly new users ask here the community, I want ask one question too: What are the alternatives to PW?

Hi @delueg, I'm short in time ATM, but can answer a little part. The first only in addition of what @kiennguyen1101 already said. The primary part is to figure out and define the best data structure in PW for that project, so that the app can run fast and you can map / import the old data. There were case studies here in the forums and published sites in the site directory (or in the forums too) that were sites / apps on very large scales. Maybe to read a bit of that may give you valuable impressions. (National Geographic Case Study, CMSCritic Development Case Study, Villas-Rental, ... maybe other users can add some more links, - I remember threads and posts talking about 1 million pages in one PW installation and others, but have no bookmarks at hand) The second You are coming to Processwire at a point where the first PW 3 stable version will released not that far away. Also, that upgrade is the first one in the last 5 years or longer, that bring in a major change from no namespace to use namespace(s) in PHP. That normally would break existing code of templates and third party modules, but Ryan has built a rocksolid FileCompiler to handle both, (upgrading from 2.x to 3.x and the use of third party modules (developed for PW 2.x) in PW 3.x), automatically behind the scenes, without any manually interaction. But I personally have changed to start with PW 3 on every new site now. Upgrade guarantee for all ProModules is in. For third party modules, PW cannot guarantee, (but see: FileCompiler!). Also, for all third party modules that are used by many people, there ever was found a new maintainer here in the community, if the original owner / creator could not do it anymore. "Upgrade to a core change not fast enough" is a very vague formulation. I think, if you have a project like yours once online and running, you never will change from a (then stable PW3) version to a first PW4-alpha version. So, as the development cycle of such an major upgrade will take six (?) month or more, there is enough time for modules developer to upgrade too. (But once more: it isn't really necessary, seeFileCompiler) Also, core upgrades in PW are not necessary if you do not need newly introduced features. This is different here than with W*rdPr*ss or others. I have running sites on PW 2.3, 2.4, 2.5, 2.6, 2.7, 3.0 and don't need or want to change them. I only have updated sites core when I want to use a new feature there.

hhm, yes, but may be also: no.!? - At least, then you will need the php user to have filesystem write access, or not?

If the filesystem is not writeable, no one and nothing can do anything. I suggest the same as @Kongondo. Grab you a ZIP of your desired branch (devns I assume), copy it to your server (local or online), make sure, at least your site/assets/{ALL_SUBFOLDERS} are writeable by the php-user. Then run the installer. If you later on want to install a newer devns version, you have nothing more to do then to change the complete wire folder. For example, if you have PW 3.0.15 now, rename your wire folder to wire.3015, copy/upload the wire folder of PW version 3.0.17 to your installation and login into the admin. That's it. Easy. And yes: - Welcome to the forums.

what Jan said, you can define sitewide $config options. Have a look into wire/config.php and copy the part of $config->imageSizerOptions into site/config.php if you want to change something. For example, if you want to have the "upscaling" disabled sitewide, just set it to false in your site/config.php. If you want to have a different value for an option then set in config.php, you can pass a options array with the image resize functions: $options = array("upscaling" => false, "sharpening" => "medium"); $image->width( $width, $options ); $image->height( $height, $options ); $image->size( $width, $height, $options );