Plugin sql, auto-installer, self-deletion

[torvista]

When a plugin requires additions to the database, these can be done by
a) a separate sql file to be run in the admin SQL patch tool or (when it fails), phpMyadmin.
b) an autoinstaller included as part of the admin files.

There are two issues I would like to raise.

1) What is the recommendation?
I prefer a), no question.
Why?
Zen Cart is DIY.
Users have to learn. Insulating them from the install process is dumbing-down and when it does not work (which has prompted this post), you have to start digging through files to find out why. Seeing the sql code fail is a pretty good heads-up that something needs attention.
I believe in banging on and on about not trusting any third party code in your site, they are all of wildly-varying quality and compatibility, and just letting it blindly alter your database is nuts.
The smoother the install process is, the more a false sense of security it generates.

2) I see auto installers that self-delete the install file.
I think this is wrong.
The first installation of any plugin should be in a DEVELOPMENT server and so only after checking/fixing/customising the fileset, it gets uploaded to the production shop...but is now missing the installer. I think the plugin fileset should be maintained complete.
I think the init that does the install should just check for the existence of some function or constant related to the plugin and then return if found.
The overhead is minimal.

[Website Rob]

Had the same chat with another senior developer earlier this year. We both agreed the auto-installer is the way to go.

Reason being is that an auto-installer (for everything, including the SQL part) is the way of Computers and the Web. As Zen Cart makes its way to becoming more automatic with modules this will be a requirement. We need to move past the point where Zen Cart is so brittle or module code is so bad, that one must test everything in a 'dev' section first.

For example, think back to Windows "Blue Screen of Death" and, if you are a Windows User, ask yourself how long has it been since you last saw that msg.

[lat9]

Steve, I'm in partial agreement with you.

For issue #1 (SQL patch vs auto-installer), my preference is the auto-installer because

• It allows a plugin to easily add, remove or change its configuration on subsequent releases.
• It keeps the plugin's configuration in-sync with the plugin's current processing

While each of those could be accomplished via a SQL Patch, separating the plugin's configuration from its processing can add complexity to a plugin since the plugin can no longer be sure that the configuration matches its current processing.

I'm a big fan of test sites for staging changes, with periodic database refreshes from the live site. When a SQL-patched plugin is being tested, then I've got to remember to re-run that SQL patch each time I do a database refresh on the test site ... I can't tell you how many hours I've lost trying to figure out why a plugin is no longer working after a refresh!

For issue #2 (install file self-deletion), I'm in violent agreement as that processing presents the same test-site issues as a SQL patch.

[Design75]

Had the same chat with another senior developer earlier this year. We both agreed the auto-installer is the way to go.

Reason being is that an auto-installer (for everything, including the SQL part) is the way of Computers and the Web. As Zen Cart makes its way to becoming more automatic with modules this will be a requirement. We need to move past the point where Zen Cart is so brittle or module code is so bad, that one must test everything in a 'dev' section first.

For example, think back to Windows "Blue Screen of Death" and, if you are a Windows User, ask yourself how long has it been since you last saw that msg.

I agree with Rob that the auto installer is the way to go. It is too often that users (but also "developers"), do not know what to do with a sql file, or how to merge files. Even with clear installation instructions, which most people will not read anyway.
The auto installer also means that people who write contributions need to test their contributions better, so no (obvious) errors occur.

[torvista]

Ok, I'm easily persuaded on the auto-installer in light of updating an existing installation.

On from this there really needs to be a plugin framework/example available so lay-people have something of quality to follow/copy and so encourage input from more contributors, not make it only for the pro developers who have their noses in these matters all the time.

[lat9]

Ok, I'm easily persuaded on the auto-installer in light of updating an existing installation.

On from this there really needs to be a plugin framework/example available so lay-people have something of quality to follow/copy and so encourage input from more contributors, not make it only for the pro developers who have their noses in these matters all the time.

I agree with you totally on that, torvista! Perhaps we could use this thread to identify the best-of-best requirements and then lay out a couple of examples.

Plugin File Naming

There are plugins that only require a couple of configuration settings and do all their business on the storefront, those that provide only an admin component and some that provide both storefront and admin elements. For new development, especially in the latter case, I'm a big fan of (where possible) every file having its own name.

I've seen (and inherited) plugins where every file is the same name, making it very difficult to ensure that the right bits got into the right directory! I mean, seriously, if the XYZ plugin includes files in its distribution named /includes/classes/xyz.php and /YOUR_ADMIN/includes/classes/xyz.php ... that's a recipe for disaster since it's so very easy to mistakenly drop files from a storefront /includes directory into the like-named admin one!

My preference in that case is to name those similar, but usually very different, files xyz.php and xyz_admin.php (respectively) to denote their expected home. It's not perfect, but it's better than everyone being named Bob! No offense meant to all the Bobs out there!

[Design75]

I tend to name the files according to their function. Like xyz_class.php, cuz_functions.php
For database entries, I use a unique prefix, like modulename_value-1, modulename_value-2.