Module Page Image Manipulator 2

[horst]

Hi, I have uploaded a new version to Github that fully supports PW 2.6+ with its new naming scheme.

The package now ships with two Pim versions, the older one, called Pim, that can be used until PW 2.5 stable, and the new one, Pim2 that should be used with PW 2.6+

So, if you start a new site with PW 2.6+, simply install Pim2 only!

If you have upgraded PW to 2.6 on an existing site with lots of image variations, you

1. should install Pim2 additionally to the older one, (do not uninstall it yet!)
    
2. then you should start to change your API calls in your templates like the following explanation

.

here is a code line from the older Pim:

$image = $image->pimLoad($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave();

.

To start with smooth change from Pim to Pim2, you can change it to this:

// use the old Pim to remove the PimVariations with old naming scheme:
$image->pimLoad($prefix)->removePimVariations();

// in the copied original code line, only change pimLoad to pim2Load, note the number 2 ! in the new start method !
$image = $image->pim2Load($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave();

.

This way you have some control on which parts the new creation may take effect, e.g. on a small site you can change all API calls at once and drop caches if exists. On bigger sites you may start at one template / page first, and add more changes later.

.

Regardless of this, you can safely let the call to the older removePimVariations() method stay in your code for a while, as they do not interact with the newer one. After a while, when you do not see any of those old filenames in your assets/files folders, you can remove those lines from your code and also uninstall the older Pim.

All other methods than pimLoad / pim2Load are completly identical and can be seen here in the API

Edited May 17, 2015 by horst

[Ivan Gretsky]

Hello! How is going?
I am confused how to update pim2 from PW (or really anywhere). Currently I got both pim1 and pim2 installed, but only pim1 is shown in ProcessWireUpgrade with the version 2.1 while pim2 is 2.7. Is there a proper way to handle this?

[horst]

Hi.

There are no plans to update Pim2. And if it will be updated, the version number from Pim1 will be bumped up, so that it shows up in the update modules list. (Pim2 is handled as submodule of Pim, Pim1)

[Ivan Gretsky]

Ok, so I just install pim1 and write pim2Load().

[horst]

To be correct:

Install pim, what installs pim1, go to modules / site, install pim2 and use pim2load().

It needs a rewrite someday for recent PW versions (2.8+ & 3.0+)

[Robin S]

Hi @horst, I tried out this module today and it's nice, thanks.

But the installation process and the PIM1/PIM2 thing was clear as mud to me - I got it worked out in the end but I don't understand why the module is set up that way.

I get the need for different module versions according to which PW version you are running, but couldn't PIM1 and PIM2 be separate modules be in separate GitHub repos and you just install the one you want? Or better - could there just be a single module that checks the PW version number and uses the right code for that version? That way pimLoad() and pimSave() wouldn't have to be renamed and choosing/installing/using the module would be simpler for the user.

[horst]

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

[Robin S]

@horst, I can see how that upgrade would be difficult to do gracefully. Will post back if I have any ideas.

Regarding CroppableImage3 and the ProcessWireUpgrade module: I think the reason why the upgrades module doesn't see available updates for CI3 is due to the module class name that is showing in the modules directory. The class name shown is "CroppableImage3" but I'm not sure where that comes from because it isn't actually a class name that is used in the modules (correct me if I'm wrong). Did you enter that manually? Or maybe it comes from the name of the GitHub repo?

When the upgrades module queries the modules directory it is looking for the classnames...

• FieldtypeCroppableImage3
• InputfieldCroppableImage3
• ProcessCroppableImage3

...but it doesn't find a match for any of these, therefore they are left out of the table of upgradable modules.

Maybe it would be best to follow the example of several of the other fieldtype modules, where the primary name of the module would be FieldtypeCroppableImage3 even though it auto-installs two other modules.

 

[horst]

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.

[horst]

I had to fix the detection with 'is_resource()' into a combination with 'is_object()', to validate if an image load into memory with GD was successful. And just 15 minutes after I pushed my fixes to github, I thought: lets go into PWs online module section and update it too, - but it already was auto-updated! 🤩