horst

I would use the hook that is called on adding the image to the images field. This is called everytime you add a new image, regardless if you do it via API or via Inputfield. An up to date code example for this hook is here: In this example you can check for a $p->template->name to match as condition to run different code parts, etc. To resize the original image itself, you may want to invoke the imagesizer manually. ---------- Instead of the hook, (for your case above), you only may use the manually invoked ImageSizer for each uploaded file *before* you add it to the image field: // set the max dimensions $targetWidth = 800; $targetHeight = 600; foreach($upload->execute() as $file) { // first get the filename of the *original image* (in case when hooking into file add !!) $filenameOrig = $file; // set options to not upscale, and set quality to 100%, if this image is a source for variations!! $options = array('upscaling' => false, 'quality' => 100, 'sharpening' => 'soft'); // call the imagesizer $imageSizer = new ImageSizer($filenameOrig, $options); $success = $imageSizer->resize($targetWidth, $targetHeight); // resize to max dimensions if($success) $lesson->video_image->add($filenameOrig); } ---------- If you first need to inspect an image, (for conditional processing), you may use the ImageInspector : $imageInspector = new ImageInspector(); foreach($imageFiles as $filename) { $result = $imageInspector->inspect($filename); // to check if we have a valid result, it must be an array if(!is_array($result)) continue; // $result['info'] has all relevant data, like width, height, imageType, mime, orientation, rotate, flip, channels, bits, ... $width = $result['info']['width']; $height = $result['info']['height']; // ... }

You should try to uninstall WireMailSMTP and try sending with native WireMail. This should work, as it uses the PHP mail() function. If WireMail works, and WireMailSMTP don't, it might be firewall restricted by your hosters settings. Native PHP mail function is controlled and allowed by your hoster, other (foreign) connections (other IPs or only Ports) maybe blocked by firewall settings of your hoster. (?)

@ryan thanks a lot! I had a little use case where I couldn't resist to use the new feature. It was only for pages with text fieldtypes. I used two little bootstrap scripts to export & import some pages. export.php import.php

Hi @Dennis Spohr, most things can be done with hooks. Hooks are class methods that have 3 preceding underscores, so you may find them in the php and module files in the wire folder. (Using a "search-in-files" function of your Editor / IDE: "function ___"). Or go to Captain-Hook. Unfortunately or Fortunately, the part with sending emails on exceptions / errors seems to be completly different. It uses the native PHP register_shutdown_function, done in WireShutdown.php and therefore is not hookable through the PW system. But the PHP docs say that it is possible to register more than one shutdown-function, and that all functions get called on shutdown. So you can register your own one. If you want to have the ability to optionally bypass processwires shutdown function, you must register yours before PWs one. (I don't know how, but would try it in site/config.php first). Than, in cases where you don't want PWs function get called, you can exit yours with exit();. Otherwise other registered functions get called and executed too. Have a read in the WireShutdown::shutdown() function. There you see how to check if there were an error, how to get it and how to inspect it, etc. ----- Also there is the site/finished.php file, that gets executed at the end. But this one I haven't used til now and don't know if it get called on exceptions too. ----- If you test and further questions apear, come back and ask.

@jploch checking the image type: $image = $page->images->first(); $imageSizer = new ImageSizer($image->filename); $imageInfo = $imageSizer->getImageInfo(false); This will return strings like: jpg gif gif-trans gif-anim gif-trans-anim png24 png24-trans png24-alpha png8 png8-trans In your case, when gif-trans-anim is detected, you want to switch to css-workaround.

I moved some posts not related to MarkupSrcSet to the ImageAnimatedGif thread.

@jploch The crux is with the transparency of the background. The original image is recognized as a transparent, animated GIF. But the stored transparency color index validates to 0,0,0 (black !) I have opened your image in photoshop and added 1 layer filled with white to the base of the other 60 layers. The animated resulting GIF is same size as yours with transparency but works with the anim module: To sum up: the anim gif module doesn't work in any case with this sort of images. The culprit is the transparency background. If you are able to add a filled background layer to those images, it will work good with resizing. (test the image above) If you also need the transparent background, you cannot use any sort of variation creation. Workaround could be to determine in template file if it is a GIF (or only if it is an animated GIF) and then use markup with a special css class for displaying those in different sizes, according to media query max-width, for example.

@jploch I have tested this and created a new Rendering Engine, but for me, every created variation has the same (wrong) result as your example. It is something in that image that doesn't work right with the lib. I think it is a false transparency for every slide in the animation. Are there other images that behave the same? In your "working example" that result in correct variation, I belive it is the original image or simply copy of it. You use ->width(300) and the original is 300px. For me, every downscaled variation doesn't work correct.

maybe you can store it in $session and check this before sending the emails? if(true !== $session->emailsAlreadySent) { // or: wire('session')->emailsAlreadySent // code to sent emails here ... $session->emailsAlreadySent = true; }

I want to port the animated gif module to the new image rendering engine module type. With this it will automatically handle the animated gifs correct. Maybe I can do it this week / weekend.

Image rendering engines are always used together / in parallel. Or, in other words, the GD engine cannot be disabled, it is always on as a fallback or last standing man. The image rendering procedure in short: image inspector extract all relevant infos about image type, subtypes, optional layers, etc, and give back a descripting paramvalue according to the return of image inspector, all available rendering engines get "asked" in hirarchical order if they can handle this type of fileformat / subformat the first that matches will get the job and as an additional fallback, if it somehow made a false promise and failed with the rendering, the image will be handed over to GD engine (or the next in hirarchy) Lots of stuff under the hood! ----- To your question: I think it is fine to keep the default values in site/config (together with the missing param for what overrides what). But when enabling an additional rendering engine, you are already in the configscreen and can set the "optional" default settings there.

@Robin S: As a workaround, until this is fixed, you dynamicaly/temporary may set the 10% to all engines? A codesnippet in an init (or ready.php) file, where you set / change one param from 0 to 100 instead of changing the site/config.php Startingpoint: https://github.com/horst-n/CroppableImage3/blob/0946fdce7b1c9859f94adf764df80d73c201bbbc/FieldtypeCroppableImage3/FieldtypeCroppableImage3ConfAdaptor.php#L91-L97

I think it is some sort of bug. But not that way you would think first, I believe: It is a feature that is/should be configurable, but the User-Interface is missing. Explanation: With multiple, different render engines, we need different quality settings for them. Per default, the module settings overwrite the configsetting, but it should be configurable to disable this. For example in CroppableImage it is configurable: But for regular (GD) image rendering there is no module config screen. Maybe we need to add a new param for this to the $config->imageSizerOptions like "useEngineQualitysettings", per default = true. Let's ping @ryan!

Oh, sorry, your are right. This one is old stuff. It is superseeded by: https://github.com/horst-n/CroppableImage3/blob/0946fdce7b1c9859f94adf764df80d73c201bbbc/FieldtypeCroppableImage3/FieldtypeCroppableImage3.module#L364-L365 And this one cleans out every obsolete variation on setting changes.

It isn't unused, it is called everytime the settings get changed. And it do the dishes.

Not really sure about it, but your cropnames uses - chars, what may conflict with the pageimage suffixes. Suffixes are concatenated with the - char. Maybe you can try to change your names from 3-zu-1 to 3zu1?

Here are the latest "official" notes ------------------------------------------------------------------------- Updating from prior versions: Updating from Croppable Image 3 with versions prior to 1.1.7, please do this as a one time step: In the PW Admin, go to side -> modules -> new, use "install via ClassName" and use CroppableImage3 for the Module Class Name. This will update your existing CroppableImage3 module sub directory, even if it is called a new install. After that, the module will be recogniced by the PW updater module, what makes it a lot easier on further updates. ------------------------------------------------------------------------- Sticking with a PW legacy 2.8.20+ Version (none namespaced)? - I have created a CroppableImage2 snapshot, which you can get from the github repo branch: CroppableImage2 -------------------------------------------------------------------------

@Robin S, please can you test an update from an installed version prior to 1.1.0? I have updated the github repo to 1.1.7. The first "update" has to be done by installing via ClassName in side -> modules -> new: Module Class Name = CroppableImage3 It has worked for me this way. Existing directory was changed / updated with all new files, old unused files were removed. And now, after that, it is recognized by the updater module! Yeah!

I will test that again later on, thanks Robin!

Due to less time, I will wait until the UIKit Admin is official / stable, before trying to locate and fix incompatibilities. But any pull request is welcomed.

That's what I made in Version 1.1.0: https://github.com/horst-n/CroppableImage3/commit/6a52e7726170bf3d81981c1d0da9cc247bbaa1b0 ------- Ok, your test was on a first install of the module, and not as an upgrade, yes? How does it work out for those who have installed a version prior to 1.0.0? Thats the most common and important situation! You have installed the 3 modules, each in its subfolder or not, but Fieldtype... is the main module, than you use the update module button, (you will need an existing wrapperclass CroppableImage3.module in the github repo for this to work!). <= Thats what I have tried already and it hasn't worked for me. Always left one dependency uninstalled. But I will try this once more, as 1.1.6, - just to check if my test with 1.1.0 / 1.1.1 wasn't interfered with another issue that made it broken. Many thanks for your support @Robin S !

Was allready done. It resulted in not correctly installing all needed dependencies (with a wrapper class: three). It only installed two out of three, then complaining about the missing one. System broken!

Hey, this is a follow up from here: So, now I have tested every possible combination from ClassNames, filenames and the ModuleName. Every thing will break something when used from an allready installed module with an upgrade through PW. When I define the main classname in the modules directory as FieldtypeCroppableImage3, the update process fetches the repo, but installs it under site/modules/FieldtypeCroppableImage3, whereas the existing repo stay under site/modules/CroppableImage3! This breaks the whole site, front and backend. The updater doesn't rename the origin repo with a leading dot. Other solutions tested also broked things. So, can you please tell me which way to go to bring the module into recognition of the update process?

How did you install / update it? Update a previous version or first install? manually or via backend or ...?