horst

@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?