horst

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

The reason it wasn't detected was, that no module was in the root directory of the module, but all each of the three modules resides in its own subdirectory.

@Robin S it was due to an needed upgrade from Pim1 to Pim2 because of changes in the naming conventions for images in PW > 2.6.?. At this time Pim1 already was installed and used in many sites. When people upgraded their PW version in those sites, they could not / cannot simply change Pim1 with Pim2. There was a manually action in changing API calls in template files needed. This was / is the reason for this weird behave. For the simply case of first install of the module, I can use a PW version detection of course, but that wasn't the problem. The problem was / is, that in prior PW versions with use of Pim1: i must used the Pim1 as first / only module, to get the people informed about update changes via upgrade-module(s) must ommit an automated change from old naming convention to the new one, because sites possibly would break down if I would raise a need to recreate every image (!) So, yes, I was and I'am very unhappy with this situation. If someone has a better solution, please tell me. ------- BTW, with the CroppableImage3 I run into something similar: Croppable3 isn't recognized by the widely used upgrade-module from Ryan, so people don't get informed about updates of it. I believe, many sites are running a version prior to 0.9.17. Everytime someone updates an older PW version site to a newer version, they run into a bug that was already fixed a year ago in version 0.9.17. People than always report that they just upgraded from x to PW > 3.0.31* (or similar), and the module now wouldn't work anymore. But it is already fixed. They all need to do a manual update, but how can I inform them? The updater should do so, but doesn't do.

Have you disabled or refreshed browser caching? Have you checked the files in local and or FTP directory? or do you only noticed this "not changing" in the website by using the browser?

I used it at least here: https://nogajski.de http://joerg-hempel.com http://bella-italia-aachen.de/

@jploch: a question from me to clarify: You have installed ImageAnimatedGif module and it produces correct resized and animated variations with calls to pageimage methods (widt, height, size), but it doesn't produce the same result when you use it with MarkupSrcSet? The ImageAnimatedGif hooks into before pageimage resize, and MarkupSrcSet simply calls pageimage size, so I'm wondering what could be the difference here? What is the result of MarkupSrcSet? Images are scaled down and animated, but with artefacts? Can you provide an example? (a variation from direct call to pageimage and one result from MarkupSrcSet)

It seems to be wrong as you call wire() in the global namespace, but you must call it in ProcessWire namespace. What you do is calling \wire(), but it must be ProcessWire\wire(), what would be really weird to add it with every call to a PW function (in a PW programm). Best way would be to add the namespace on top of each *.php file in your template system, (template file, view files, snippet files, ...): <?php namespace ProcessWire; Than it should be valid and functional.

@rick: In your code that handles the form input, you simply can call the module or public module method: //if(<condition for form was posted>) { $myModule = $modules->get("MyModulesName"); // get a module handle $myModule->passNewDataIn($input->post->someData); // call the public method for data input // rest is done in modules method, ... // if you are not in template scope, you can use $myModule = wire("modules")->get("MyModulesName"); //}

I have found my better checkerbox background image again: in use as BG it looks like this:

To show our *.module files with the correct PHP syntax highlighter is now possible on Github. With new repos, you first need to add a .gitattributes file to it. After that you can view *.module files with the PHP syntax highlighter applied: MetadataExif.module So, this doesn't work with already created / comitted repos by simply adding the .gitattributes file. But it will find its way through different caching layers on github if you add it to your repos and further committs to them. (https://github.com/github/linguist/issues/1792#issuecomment-286379822)