horst

Wouldn't it be better using g**gle search for that? searching forum: site:processwire.com/talk api (https://www.google.com/search?q=site%3Aprocesswire.com%2Ftalk+api) searching whole site: site:processwire.com/ api (https://www.google.com/search?q=site%3Aprocesswire.com%2F+api)

One last try: You may try to (re)save an original image in Photoshop as 24bit PNG with transparency, just to make sure it definetly get handled by the imagick engine. (There is a small chance that, for example, 8bit PMGs with transparency (or different types of transparency) get not handled by imagick, also if you selected it as first engine. PW does an image inspection and if the current prefered engine is marked not to be able to handle that format combination correct, it will be passed to the next engine in the chain. 24bit PNG with transparency definetly will be handled by imagick. (The last one in the chain always is GD, as fallback).

Yep. I bet that this are 99.9% transparent pixels from the originals cutout pictures. I mean the originals were photographed on a more or less white background, then it get cropped not by a hard pixel path but by some tool that uses cropping by transparency mask. After that, a shadow drop was added. In the original images the cropped out area is visually not seen, but there are some pixels with a special setting: color white & transparency 100%. It would have been better, if the cutout had be done by hard cropping, 1-2px into the object. If this currently is resized by GD-lib (PWs default or fallback engine), you may try to switch to ImageMagick engine if the server allows this.

image example? (original AND issue variation)

..., yep, ooor, you should not use ../ this in your dest path. 🙂 This is for security reasons. If you give real $dest pathes without up-traversal segments into your createDuplicateImage() function, then you don't need realpath() there. Or you use it one step earlier: public static function createDuplicateImage($src, $dest) { if (file_exists($src) === false) { return false; } // NOTE new line $dest = realpath($dest); // Duplicate the file \ProcessWire\wire('files')->copy($src, $dest); return new \ProcessWire\ImageSizer($dest); } But anyway. I'm glad you figured it out and finally it is working for you! 😉

This must have to do with the access rights set in your server setup. Normally they get set via wirechmod($filename) automatically. ?

You can do with using the imagesizer directly: $is = new ImageSizer("path/to/your/image/filename.jpg", [OPTIONS-ARRAY--OPTIONAL]); // $is->setOptions([OPTIONS-ARRAY--OPTIONAL]); // or set it later here, or ommit setting individual options and use the defaults ! $is->resize($width, $height); // width or height can be 0 ! This resizes and overwrites the image you pass to it. So if you do this with a PW pageimage, you would overwrite the original image if you pass it the originals name!!

@ryan Thanks for clarification. I somehow mixed it up with the core page paths module in my mind:

Hi @ryan, many thanks for the additions, especially the status one will be used by me! 🙂 I want to ask if the support for matching children paths also works with multi language names, e.g. (/path/to/page/) resolves the same as the de path of the same page (/de/pfad/zur/seite/) ?

On page /en/meineseite/?param=value first save the param into a session var, then do the redirect and in the target page read out the session var $value = $input->get('param'); $value = $sanitizer->text($value); // or any other appropriate sanitizer method for your usecase, and or any other custom validation $session->set('param', "$value"); $session->redirect($YOUR_TARGET_URL); $value = $session->get('param');

Nothing of your posted content looks like a PW installation. Are you sure you are in the right place here?

A short description of what you have done or want to do and what is not functional would be more helpful I believe. Also was there any error given instead of your expected action? I'm on mobile currently and my accu said low memory. So if I'm going offline because of this, I hope someone else can scheme in and help, when we are able to understand your issue. 🙂

@mervin Please post your errors or logs here in text. Do not drop (suspicious) ZIP files here without any description and references to your problem. Otherwise your posts may be judged as spam. 🙂

@markus_blue_tomato One solution could be to store an extra key containing the last modified timestamp from the image together with the blurhash string, and then every time before output, compare the (current) images last modified timestamp with the stored one. If the stored one is older, regenerate the blurhash string.

If you do not have limitations for outgoing (SMTP) E-Mails per/Day or per/Month and if whether your company nor any other user on the same shared hosting is blacklisted in spam protection services, it should be pretty fine to send them on your own.