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

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.

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.

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.

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?

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:

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

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

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

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

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.

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.

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.

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

lat9:

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

lat9:

Folder Per Zen Cart Version.

Not sure how this would work?

lat9:

Files edited to support multiple Zen Cart versions.

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

lat9:

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

lat9:

**
2. Folder Per Zen Cart Version**.

RodG:

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_By_Attributes_Combined. Have seen it elsewhere, but none come to mind at the moment.

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.

mc12345678:

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

RixStix:

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

I always have mixed feelings about this. On the surface it seems like the 'right' thing to do, BUT in practice it will often cause unnecessary problems. What often happens is that when people uninstall a module (especially one that has modified the core files) they'll often not do a very good job at restoring back to the pre-install state, so what happens is that if the SQL changes have been 'un done' the files themselves could still be referencing the no longer existent DB fields/tables - Causing the site to crash. This can be avoided if the SQL changes were left as they were - and if all the files were correctly restored, it isn't going to matter if the DB changes were undone or not. If not it'll just be 'unused' data, and that isn't going to cause a problem for anything.

Just my opinion.

Cheers
Rod.

ps. I'll never run an SQL uninstall script until/unless I've 'vetted' it first so that I can be sure that it isn't going to have an unexpected/negative repercussion. Most uninstall scripts I've seen (and created) tend to have very little done in the way of testing. They tend to be pretty 'crude'.

Everything in this thread is all the more reason to try and create hook system that allows modules to insert code when an action is called instead of overwriting the core files. updating Zen-Cart and the modules would also be easier for both developers and shop owners. The over-ride system goes along way to avoiding editing core files, but it falls short of the goal. And it can be confusing where all those files are for any particular mod. Imagine a scenario where you skipped an update because it was such a pain, I'm pretty sure it happens all the time.

Despite what someone said earlier about users needing to get their hands dirty, I don't think that people who haven't got the skill should be changing the core files.

I also think that users should be able to trust the plugins available on this site, that they are not a security risk or have vulnerabilities. If they can't rely on Zen-Cart plugins, they might as well be downloading from a null site or theme forrest.

And don't get me wrong, I literally love Zen-Cart - I recommend it to clients all the time because I know I can get their store to do the stuff they want it to do fairly easily without a huge overhead. Unfortunately, its not as popular with them as it should be.
Jus' Sayin'

Everything in this thread is all the more reason to try and create hook system that allows modules to insert code when an action is called instead of overwriting the core files.

I don't think this fact is lost on the devs.
ASAIK the reason things are not like that now is because it is simply not possible with the legacy procedural code that Zen Cart 1.x is based on. Hence 2.x.
Many basic plugins could be improved to use observers but some things will always require core changes.
In the end making major changes to the 1.x code to allow 100% overrides is wasted time that is better spent on 2.x.

torvista:

I don't think this fact is lost on the devs.
ASAIK the reason things are not like that now is because it is simply not possible with the legacy procedural code that Zen Cart 1.x is based on. Hence 2.x.
Many basic plugins could be improved to use observers but some things will always require core changes.
In the end making major changes to the 1.x code to allow 100% overrides is wasted time that is better spent on 2.x.

I cannot find any info on 2.x? 1.6 I have read some about, and am getting ready to set up a test site to see what it looks like, and I wouldn't mind having a peek at 2x as well.

katdidit:

I cannot find any info on 2.x? 1.6 I have read some about, and am getting ready to set up a test site to see what it looks like, and I wouldn't mind having a peek at 2x as well.
Bugs can be identified in this forum or as an issue on GitHub.

I cannot find any info on 2.x

Don't hold your breath....
https://www.zen-cart.com/showthread.php?116018-Update-On-Zen-Cart-v2-0-0

...there is a possibility that this information is not quite current....who knows...!!