Opinions wanted: Plugin "Packaging" for multiple Zen Cart versions

[lat9]

As we get close to the Zen Cart 1.5.5 release, I'd like to gather opinions from both developers and users regarding how plugins supporting multiple Zen Cart versions get "packaged".

I've seen a couple of different approaches and, as in life, there are pros and cons associated with each approach:

1. User edits. The plugin identifies (in its readme) the change blocks required for any core/template changes. The person performing the plugin installation is responsible for merging that change into their store's files.
   
   • Pro: Simple distribution
   • Pro: Code re-use. No change needed to the plugin if no change to the core/template files in a new Zen Cart version.
   • Con: When was the last time you read a readme?
   
   
2. Folder Per Zen Cart Version. The plugin pre-installs its required changes into multiple Zen Cart versions of the file, one per Zen Cart version supported by the plugin. The person performing the installation is responsible for choosing the file version associated with their store's current Zen Cart version and then merging those changes into their store's files.
   
   • Pro: Changes for a given Zen Cart version are pre-integrated.
   • Con: Plugin change is required for every supported Zen Cart version.
   • Con: Complexity of the installation.
   
   
3. Files edited to support multiple Zen Cart versions. The plugin pre-includes its required changes into a single version of the file, with conditional statements to enable that version of the file to be used on multiple Zen Cart versions. The person performing the installation is responsible for merging those changes into their store's files.
   
   • Pro: Changes for a given Zen Cart version are pre-integrated.
   • Pro: Code re-use. No change needed to the plugin if no change to the core/template files in a new Zen Cart version.
   • Con: Potentially changes the underlying processing for older Zen Cart installations.
   
   
4. Use a Plugin Manager. The plugin includes installation code (like Image Handler 4) that automagically provides the required file updates. The person performing the plugin installation "simply" copies the plugin's files.
   
   • Pro: Easy for the person installing the plugin; no files to merge.
   • Pro: Simple installation instructions.
   • Con: Installations using "popular" core/template files (think /YOUR_ADMIN/orders.php) can be complicated to the point of failure.

The changes coming in Zen Cart 1.5.5 are revolutionary, with the inclusion of a pre-enabled responsive template on the store-front and significant look-and-feel changes to the admin-console. How do you think that plugins should be packaged going forward? With your response, please indicate whether you're wearing a "developer" or "user" hat.

[mesnitu]

Responding as a user: Sounds good the plugin manager.
Actually I never use it, I've always merge ( witch is very boring ), and after a couple of plugins or modules, those merge gets more complicated and in the end, it's very hard to keep track of those changes.
From a Developer point of view, I think this can be good, because probably one gets some work when zencart is upgraded.
I'm was upgrading from 151 to 154, then realize 155 is coming, an I prefer to wait that to be merging modules.
In fact I dont' even call it a upgrade, I starting all over, because I feel that it's simpler.

I'm very fun of Drupal (7), and now BackdropCMS, a fork of 7 version, and I've always like that I'd never even went to see the core files, despite the fact that I've installed dozens of modules.
To update, one safely uploads the files, or even better , using drush : drush pm-update projects drupal, and for modules drush update whatever-module-version.
Eh voilá, Zen vibrations.

[torvista]

1. NO QUESTION
Why
a) ZC is a DIY solution. People have to learn and get their hands dirty.
b) Plugins are rarely plugins and people need to get that very clear in their heads before they trust anything in the downloads section.
c) People providing extra/missing functionality need to be able feel they can offer the code easily, as no-one ever offers to pay them in thanks.
Wasting their time supplying multiple versions is a big obstacle/time-waster and the more you spoon-feed users the more basic the questions asked become and the more uninterested becomes the person providing the free support.
d) People need to not only read the readme but read the support forum before they should consider adding third-party code of dubious quality to their money-making non-buggy Zen Cart.
e) I dislike the Image Handler approach. I go through every file in everything I consider using as invariably it is wrongly-structured or I simply disagree! I want to know what is living in my shop, where it came from, when etc. I add comments everywhere for upgrading help.
I know a great job has been done on Image Handler but that is the exception.

There has been discussion elsewhere of making some rules for plugins but I think it is counter productive. People like me hack stuff together as best as we can, and offer it up trying to give something back. Trying to be super professional and making it foolproof for everyone would simply stop me from bothering (I have a business to run) and others would lose out on that contribution. Developers should ensure it works when dropped into a vanilla, current ZC and stop there.
The rest is caveat emptor. If the community wants to improve it, go ahead, that's the idea.

Users should have very clearly in their heads that they should take great care in what they download and be forced to merge it and so learn something about how their site works. "Foolproof" does not exist and trying to make it so is on a hiding to nothing apart from getting asked "Proven Fool" questions.

• Con: When was the last time you read a readme?

Not a con, common sense. The pros make up for it.

</rant>

[rbarbour]

Community Contributed Plugins should be required to:

1 - State in "plain" English what it's purpose is.
2 - Include the Zen Cart Version(s) it was tested on.
3 - Provide a "list" of Core edits.
4 - Basic Installation Instructions.
5 - A License.

If it was tested on and requires separate installation for different Zen Cart Versions(s), then provide separate version folders.

No plugin that alters "Core" files should include a plugin manager that overrides the "Core" files. These files should be merged for they will always have to be for every Zen Cart version.

Just MO, but I think how Community Contributed Plugins are packaged should be at the discretion of the contributor and the "risk" of the community. If a plugin's support thread hasn't had activity or the plugin itself hasn't been updated, investigate and ask. Common Sense?

As we get close to the Zen Cart 1.5.5 release, I'd like to gather opinions from both developers and users regarding how plugins supporting multiple Zen Cart versions get "packaged".

I've seen a couple of different approaches and, as in life, there are pros and cons associated with each approach:

1. User edits. The plugin identifies (in its readme) the change blocks required for any core/template changes. The person performing the plugin installation is responsible for merging that change into their store's files.
   
   • Pro: Simple distribution
   • Pro: Code re-use. No change needed to the plugin if no change to the core/template files in a new Zen Cart version.
   • Con: When was the last time you read a readme?
   
   
2. Folder Per Zen Cart Version. The plugin pre-installs its required changes into multiple Zen Cart versions of the file, one per Zen Cart version supported by the plugin. The person performing the installation is responsible for choosing the file version associated with their store's current Zen Cart version and then merging those changes into their store's files.
   
   • Pro: Changes for a given Zen Cart version are pre-integrated.
   • Con: Plugin change is required for every supported Zen Cart version.
   • Con: Complexity of the installation.
   
   
3. Files edited to support multiple Zen Cart versions. The plugin pre-includes its required changes into a single version of the file, with conditional statements to enable that version of the file to be used on multiple Zen Cart versions. The person performing the installation is responsible for merging those changes into their store's files.
   
   • Pro: Changes for a given Zen Cart version are pre-integrated.
   • Pro: Code re-use. No change needed to the plugin if no change to the core/template files in a new Zen Cart version.
   • Con: Potentially changes the underlying processing for older Zen Cart installations.
   
   
4. Use a Plugin Manager. The plugin includes installation code (like Image Handler 4) that automagically provides the required file updates. The person performing the plugin installation "simply" copies the plugin's files.
   
   • Pro: Easy for the person installing the plugin; no files to merge.
   • Pro: Simple installation instructions.
   • Con: Installations using "popular" core/template files (think /YOUR_ADMIN/orders.php) can be complicated to the point of failure.

The changes coming in Zen Cart 1.5.5 are revolutionary, with the inclusion of a pre-enabled responsive template on the store-front and significant look-and-feel changes to the admin-console. How do you think that plugins should be packaged going forward? With your response, please indicate whether you're wearing a "developer" or "user" hat.

[carlwhat]

1. NO QUESTION
Why
a) ZC is a DIY solution. People have to learn and get their hands dirty.
b) Plugins are rarely plugins and people need to get that very clear in their heads before they trust anything in the downloads section.

i agree with steve. his comments always seem to make the most sense to me.

i think the more one idiot proofs.... i mean automates everything, the more problems tend to come up....

when i install a plugin, i always look at the readme. i always do a diff and check out what is going on. i love it when plugins rarely touch core files.... they so rarely do that though.

quick story: i recently implemented image handler for a client. i have little experience with IH. i read the docs. do the docs mention PROPORTIONAL_IMAGES_STATUS? i could not find it in the docs. and yet if this value is set to 0 (which his was); no images. in addition, i suppose i like the auto-installation; however for my environment, it is perhaps not ideal. i installed it on my development server, got it working, committed the changes to my version control system, and then pulled them to my client's live site. but when i did it this way, the install did not add the new configuration records. so i had to do that manually. i knew that was a possibility, but frankly i prefer my own version control system, rather than the plugins auto-installer and renaming conventions.

best.

[RixStix]

Community Contributed Plugins should be required to:

1 - State in "plain" English what it's purpose is.
2 - Include the Zen Cart Version(s) it was tested on.
3 - Provide a "list" of Core edits.
4 - Basic Installation Instructions.
5 - A License.

6. UnInstall SQL to undo database changes that were made by an Install SQL

[RodG]

User edits.

Always prone to error - not 'user friendly'. I moved away from this method pretty quick due to the number of problems and questions that this method generates (generated).

Folder Per Zen Cart Version.

Not sure how this would work?

Files edited to support multiple Zen Cart versions.

Yup. This is my approach - Keep the code moving forward whilst maintaining backwards compatibility.

Use a Plugin Manager. .

This is a good idea and seems to work quite well for the systems that use it, BUT, in order to work and function in a *reliable* manner it would probably require a complete restructure of both the ZenCart core code as well as the modules themselves. I can't see this happening - it'll be a bit like creating a whole new eCommerce system.

Just my $100 worth :-)

Cheers
RodG

[mc12345678]

2. Folder Per Zen Cart Version.

Not sure how this would work?

Take a look at one of your less preferred plugins like CEON URI mappings.. In that package, where a "core" file is modified, a directory has been created to reflect all of the files modified for that applicable ZC version maintaining the applicable folder structure and the changes needed for that version incorporated into the file(s). Effectively offering the ability to use the "latest" version, but also to show the specific modification(s) for the files of the version being used for comparison. Another example that comes to mind would be the currently in github version of Stock By Attributes: https://github.com/mc12345678/Stock_...butes_Combined. Have seen it elsewhere, but none come to mind at the moment.

[lat9]

Thanks to all for the responses so far! I, like @RodG, take approach #3 in the majority of the plugins with which I'm associated but the upcoming changes in Zen Cart 1.5.5 caused me to pause and come up for air.

I'm leaning towards an approach #5 which is a combination of #1 and #3:

5. Have a pre-merged version of the plugin's core/template modifications that are based on the associated files in the latest Zen Cart version supported by the plugin and provide step-by-step instructions for the hand-edits required for other (earlier and potentially later) Zen Cart versions.

It'll be a little more work from the development side for a plugin's initial release using that installation method, but will reusable for future updates.

[RodG]

Take a look at one of your less preferred plugins

Aha. Now I see.

I have also used this method myself - Not for Zencart though, but for other eCommerce systems - BUT, I've only taken this approach where it has been difficult/impossible to maintain backwards compatibility.

It is my second choice of the options that were given.

In short, my philosophy is to take as much out of the hands of the end user as possible (excluding required configuration options of course). Essentially this means avoiding all need for manual edits, and also removing the *possibility* of the end user trying to install an incompatible version. The reason being is that it never ceases to amaze me at how many people simply don't have a clue about what version(s) of any given software they are actually using anyway. :-(

Cheers
RodG