Jump to content

Page Image Manipulator 2


horst
 Share

Recommended Posts

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 by horst
  • Like 8
Link to comment
Share on other sites

  • 1 year later...

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?

Link to comment
Share on other sites

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)

  • Like 1
Link to comment
Share on other sites

  • 9 months later...

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

 

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...