horst

I don't think that you will get measurable performance diferences if one single module is autoloaded or not. You need to do early checks and returns, if it is (not) responsible for a request, so. If you want start it on demand, you can send the forms to a single page that is responsible for its processing. In the template you can invoke it on demand. But I think it isn't worth it.

Another way could be to build and use an independent module and hook into after ImageSizer::resize instead building a (redundant) copy of a imagesizer engine module. Advantages: it will work with every (different) invoked imagesizer engine/s, and not only with the custom modified one! <?php namespace ProcessWire; class ImagesizerWithNginx extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Imagesizer with Nginx-Cluster', 'version' => 1, 'summary' => "", 'author' => "", 'autoload' => true, 'singular' => true ); } public function init() { $this->pages->addHookAfter('ImageSizer::resize', $this, 'uploadToNginx'); // Fired when a new or updated variation is created $this->addHookAfter('Pagefiles::delete', $this, 'deleteNginxfile'); // Fired when a file is deleted from a page } public function uploadToNginx($event) { $image = $event->object->image; $pageID = $image->page->id; $filename = $event->object->filename; $extension = $event->object->extension; // optionally optimize the image bfore upload, and then ... upload image to target } public function deleteNginxfile($event) { // see the S3 module } }

Given the following: you never show original images to the visitors, (what I highly recommend, as of the original should be in 100% quality, what would be much to high filesizes) every image variation is created through pageimage (= is a (new) imagesizer engine) it is possible to define a .htaccess directive for redirecting to the /site/assets/files/{ID}/{IMAGES} It should be possible to clone and modify one of the new Imagesizer Engines in that way, that you transport a copy of each created variation to the nginx cluster here in the image engine. Then the only other thing you need is a hook into Pagefiles::delete! So, you would need a module like this <?php namespace ProcessWire; class ImageSizerEngineIMagickNginx extends ImageSizerEngineIMagick { public static function getModuleInfo() { return array( 'title' => 'IMagick Image Sizer with nginx-Cluster', 'version' => 1, 'summary' => "Upgrades image manipulations to use PHP's ImageMagick library when possible.", 'author' => '', 'autoload' => false, 'singular' => false, ); } public function init() { $this->addHookAfter('Pagefiles::delete', $this, 'deleteNginxfile'); // Fired when a file is deleted from a page } // a complete copy of the original method, with addition of a call to the upload method as shown above, (line 342) protected function processResize($srcFilename, $dstFilename, $fullWidth, $fullHeight, $finalWidth, $finalHeight) { ... uploadToNginx($dstFilename); ... } public function uploadToNginx($imagefile) { // get the page id for the assets subfolder and get the basename of the $imagefile to build the target ... upload $imagefile to target } public function deleteNginxfile() { // see the S3 module } } PS: I would process the variations with 100% quality and pass the variations through an image optimizer like jpegoptim, just before you have to upload it. But I think that this is on your todo already.

Hi Dave, there is a module that handles files and image storage in S3-cloud. If there is no other / better alternative, I would fork this and change it to work with the nginx cluster (upload via FTP?) instead of the S3-cloud. At least, it can show you what hooks are needed: https://github.com/nmendes/AmazonS3Cloudfront/blob/master/AmazonS3Cloudfront.module#L52 An extra look needs to be to the filename variation creation for images. There was a change between PW 2.4 and 2.5.10. The module states compatibility to PW 2.4 only. But that can be due to no further maintenance through the author. If the filename variation creation is handled through PWs API (pageimage, pagefile, etc) I think it will be on the safe side and possibly working with recent PW versions too. EDIT: If the nginx and the main site have access to each filesystem, you simply may use symlinks for it. But as I first understand, the nginx is on a different machine, or not?

Thank you for the good news! (and the fix)

If I understand right, you use: <a href="<?php echo $config->urls->root; ?>"> but you should use: <a href="<?php echo $pages->get('/')->url; ?>">

In permissions, I see: user-admin-all, user-admin-staff, user-admin-customer, user-admin-administrator. Have you tried to only give the administrator role permissions for user-admin-staff and user-admin-customer. I think you have, or not? If so, they will see in a user edit page the role of administrator too, but they cannot select/change them, like with the guest role. If one try to select / change the role, it is displayed a red warning: (You may not change this role). Or do you ask how to hide those roles?

I'm using symlinks too, but I use it for the /site/... folders only, because I do not work on the wire/... folders: /www/public_html/wire/ == is physically in the htdocsdirectory of apache /www/public_html/site/ == symlinked to e.g. /Users/me/myproject/site/ /www/public_html/index.php == is physically in the htdocs directory of apache

Yes you can read and write modules config data via PWs API for all modules. Please refer to the docs, or search the forum via google for something like $modules->get("WireMailSMTP")-> getConfigData(), or readConfigData() ? and ->writeConfigData($data). Sorry, I'm on mobile and cannot provide links or exact code snippets ATM. ---- EDIT: you can use this: $data = wire('modules')->getModuleConfigData("WireMailSmtp"); // or, regarding on scope, $data = $modules->getModuleConfigData("WireMailSmtp"); after modifying, you can write it back: wire('modules')->saveModuleConfigData("WireMailSmtp", $data); // or $modules->saveModuleConfigData("WireMailSmtp", $data);

Do you want use image functions or do want not? If you want use image functions, I suggest to use an images field, that's what they are built for.

size() is bound to images, not files you need to get the page then get the imagesfield then select the desired image (not: file!) do the resize

you need to get the page then get the imagesfield then select the desired image do the resize Will say, it is done as always. Where is your page that holds the imagesfield? Do you have a path, a name or a id of it? // within a modules method you will do something like 1) $p = $this->pages->get(YOURPAGESELECTOR); 2) $images = $p->yourImagesField; 3) $image = $images->first(); // or whatever you like 4) $image->size(x, y); PS: Please do not send me PMs with something like: "how can I do xy, please help its urgent." Use the forums support thread or the job section!

@OllieMackJames: Are you able to use PW 3.0.10 for your site, or do you need to stick with PW 2.7 ? If you can use PW 3, you simply may copy one of the ImageSizerEngines into your site modules directory, change the classname, and add the optimization functionality. To add the functionality, I highly would suggest to use an API image option, e.g. array("optimize" => true). This way you are able to control which variation should be passed to the optimisation service and which one not. At the end of the image manipulation, you can ask if optimize is set: if($this->optimize) { $optimus = new Optimus('<your_license_key>'); $result = $optimus->optimize($dstFilename); file_put_contents($dstFilename, $result); } That's all you need. You also may set the optimize default to true in site/config.php $config->imageSizerOptions = array(..., ..., ..., "optimize" => true)); and then explicitly disable it via individual API option settings in your template files. Just choose what fits best for your site.

Yes, it prevent memory errors. The sizer is invoked in here in Pageimage. If it returns false, for what ever reason, but also for a memorcheck, the error is handled here in Pageimage starting from line 434. It writes a text line into the variation file: "This is intentionally invalid image data.\n"; And it logs that error. But it will not interrupt your page render / page load. It will proceed further content, just the image what would exceed your available memory isn't created, is missing. But this only belongs to the GD-lib, not to IMagick. IMagick can process image manipulation by lines or by chunks, what let it successful work with less memory too.

The GD now has complete memory checking before loading images into memory. It has had memory checking since some time already, but I have overseen two points in the code for this, what is now fixed with PW 3.0.10 too. In regard of the IMagick bug with PNG8 with transparency, we only can and will change this if we are able to detect if IMagick can handle this correct. Otherwise it will be handed over to GD.

Fieldname BaseStyle has Uppercase letters. Try to rename / use only lowercase letters. Check the fieldname in DB, (field_BaseStyle or field_basestyle)

Here is a better comparision, including all 4 sharpening modes and with 280px images output. I only post the link of an PNG screenshot here, because it is 8MB: http://images.pw.nogajski.de/assets/screen_255.png Here are the values, without the thumbnail images:

A first comparision in filesize & processing time among the first 4 engines with different qualities. Sharpening is set to soft here. Without sharpening, the Netpbm is much faster, but also more blurry than IMagick without sharpening. In regard of filesize and visual quality, Netpbm is better than IMagick. For the overall usage, IMagick as PHP extension is best optimized for speed with a very good visual quality. It is also faster than the IMagick-CLI engine in most cases.

Recent Netpbm binaries for Windows are compiled and served by Terry Ron Vantreese. They can be found here: https://onedrive.live.com/?id=9E7DB242359A93F0!28283&cid=9E7DB242359A93F0 To use them, unpack them and put them into a subfolder. Enter the path to that directory into the designated inputfield in the modules config page. Save it, done!

Ah, sorry, don't got this fully. With the everywhere available GD lib it is not possible to do any sort of colorspace detection / prevention / conversion. With ImageMagick, as CLI or PHP-Extension, it is only possible with compiled-in lcms to proceed colorspace operations. And only then, it would make sense to keep an ICC profile. To clarify my understanding of a colorspace workflow: detect the colorspace (ICC profile) of the incoming image transform it into a workflow colorspace (e.g. AdobeRGB or ECI-RGB) do all manipulations transform it into sRGB colorspace just before output optionally embedd sRGB profile I never would use the incoming profile as the output-profile, I ever would transform into sRGB. (Browsers and CMS's are not Photoshop, ;-)) Embedding an output profile into an imagevariation requires lcms. Processing it in the above workflow will increase the processing time up to 4 times for every variation. We have tested a lot on this two years ago.

The first thing is, if you do not have the PHP-IMagick Extension available on a server, but are able to use the PHP exec() function for CLI operations. Than this and the NETPBM module are useful. A quick and short comparision of the current state of all currently available modules is: The core implemented PHP-Extension Imagick module lacks of support / detection of PNG 8bit transparency files and correct GIF support. Therefor it only processes JPEG and PNG24 images. GIF and PNG8 images are handed over to the GD engine. If the ImageMagick-CLI can handle PNG8 bit images with transparency is not inspected before image processing. It may or may not, but with a recent, and fully functional ImageMagick installation it should be able to process all sort of image formats and subformats. The NETPBM-CLI is currently work in progress. With Version 0.1.0, It supports JPEG only. But the other formats will be added as soon as I get time for it. There are no known downsides, I just need time to test and implement this. The difference in quality is minimal between those three modules. They are all better than the GD lib. To choose one before the other ATM only depends on what is supported on a webserver, or may be on personal preferences. When the modules are finished, so that they support all kind of formats and subformats, I will publsh a comparision table of the most useful aspects. Until then, it will be helpful if people can test one or more of them and report back how it goes.

NOt an easy one, but maybe easier for you now: https://processwire.com/talk/topic/6096-imagick-resizer-need-to-be-tested-2/#entry59711

@jugibur: just to clarify: PW doesn't alter the original image per default. There is only one situation where the original image will be altered: If you have settings for max-image-width or height set with an imagefield and an uploaded image exeed those limits, then PW creates a resized variation and stores that as the original! Otherwise, the original image will not get touched in any way! So, in short, ;-) The common denomination for colorspaces is sRGB! Browsers (and all other PC devices in a colorspace chain) per default do assume the sRGB profile, at least, if a profile is missing. Therefore, no ICC profile is needed. If you want to use more advanced features, should this be done automated by a webbrowser? We all know that different webbrowsers has done and do interpret features in different implementations, regardless of W3C standards. This is for different reasons: product- / company- political, simply missunderstood things or bugs, or what ever. If you want to publish images, do you really want to go that far, that you want use/try browser- or feature-sniffing, and than serve different imagevariations (with and without ICC) on assumed browsertypes? Using sRGB is the fastest (and a painless) way to serve homogenious results to different browsers. But what I meant with homogenious, was not how the images will look like in browsers of different vendors. I meant, that the way how PW handles the manipulations should be nearly independend of the used or available engine(s). So, per default, we use the lowest denominator, what is GD or everything else without ICC conversion possibilties. Also, for the average user and in most cases ( > 99% ?), the images will be in sRGB colorspace. Hopefully, most people who uses other colorspaces, also have a bit knowledge about imagehandling and therefor will know what they do. So, for those people, it may be an optional comfort feature to have ICC, but I'm not 100% sure, if this is really a comfort, despite all downside aspects. Long story / short saying: The default and core in PW only will have features that are used and or available for more than 30% of (assumed) PW installations. All other things belong into third party tools / modules.

You also may setup a more comfortable own template only for the options, using a slider for quality, select or radio or asm for sharpening, etc. And then embedd this template via a pagetable, limited to only one item, into your gallery template. (and reuse it on other templates too.) This way you give your user a comfortable UI and also minimize wrong values, typos, etc. For example, you can setup a slider for medium quality with a range only from 50-70, a slider for high quality with a range from 60 - 90, etc. ---- checking if you need drop / recreate variations can be done by hooking into after page save: check if it is a page with your gallery template, check if the field with options has changed, if true, A) removeVariations() of the images field, or B) recreate specified images by onetime passing an additional option "forceNew" => true to the API call.

what do you get if you echo out or var_dump() $p->viewable() // and / or $p->url // and / or $p->id right after $p->save() ?