I'm nearing the release of my first Piwigo plugin, and I want to provide an accurate caveat for anyone interesting in trying/using the plugin.

I'm using the provided hooks (events, triggers) for almost the entire plugin code base, except for one instance, a work-around, to get one key feature in place.

The plugin attempts to patch a core file (and fails gracefully; even if the dependent feature doesn't work, the rest of the plugin operates normally).

The patching adds only one statement, a copy() call to make a temporary copy of the an image upload before Piwigo resizes (samples down) the upload (if configured to do so, and the image exceeds the max size chosen). The full-size original temporary copy is then used by the plugin and removed shortly after it's created.

The patching proceeds as cautiously as possible. If the md5 hash of the core file contents doesn't match exactly as it should based on the current (2.5.0) release of the file, then no patching is attempted.

Also, when the plugin is deactivated, un-patching takes place (reversing the patch) back to the original state.

Okay, so here is my understanding Piwigo is implemented and used:

Scenarios:
1) Self-hosted Piwigo install
2) Piwigo.com customer
3) 3rd-party (not piwigo.com) Piwigo service provider customer


I presume for Scenario #1 that patching is reasonable. Even the (I'm guessing minority of) self-hosted users who may have customized their own core file will not be affected because of the hashing check.

In Scenario #2, I'd presume patching is *not acceptable* because of the single code base, multi-site implementation.

In Scenario #3, I'd guess it depends how the provider implements the install. If there's an independent codebase for each customer (e.g. like a virtual machine setup) then there may or may not be any issues.

So, if you've read this far (congrats) any corrections or my assumptions, questions, or suggestions?