Requiring "Other" Mods for new Plugin

I want to create a new plugin (actually a couple lol). I need to add certain fields to the database as I have previously mentioned. Numinix Product Fields will give me about 90% of what I need.

If you were doing this, would you just require this mod and add the other 10%?

Or

Just add everything you need ...?

Thanks!

I'd go down path #2 (just add everything you need) to make it easier on people that want to use your newly-minted plugin.

lat9:

I'd go down path #2 (just add everything you need) to make it easier on people that want to use your newly-minted plugin.

that is what I was learning towards. Then upgrades are easier in one package.

Thanks!

g2ktcf:

that is what I was learning towards. Then upgrades are easier in one package.

Thanks!
Exactly ... and then you're more in-control of your package!

Seconded. Unless absolutely necessary, I discourage people from submitting plugins that have preconditions for other plugins.

swguy:

Seconded. Unless absolutely necessary, I discourage people from submitting plugins that have preconditions for other plugins.

Do how would YOU handle "duplicates" from those other mods? I need product dimensions -> Length, Width and Height for example. If someone already has that additional mod installed then that would cause issues. If it was JUST the database, that is easy enough to look and test for. But changes for inputs on the Admin Products edit page would not be.

Thoughts?

PS I have been known to start an idea...and leave it there. I am actively coding this one...slowly, but a little more every day! :D

For this particular case, I would say:

• if you have Canada Post with dimensional pricing installed, skip this step
• if you have so-and-so plugin installed, skip this step.

otherwise, run this sql file ....

THEN later on you may need to say:

Note: if your product table already has dimensions, you may need to modify this plugin to reconcile the field names I used (length, width, height) with whatever you already have, if the names are different. Just change these files:

foo.php
bar.php
etc.

and change "length" to "name-of-your-length-field"
Something like that.

That makes total sense. I never considered offering options on how to get the field names into the DB! That is great input.

Thanks!
Chris

You could even make the field names defined constants and tell people to just update those.

swguy:

You could even make the field names defined constants and tell people to just update those.

exactly what I was thinking!

While there may be some known caveats about whether to run a section of the installation or not, it is also important that the sql be written to recognize that the field(s) may already exist. This cuts down on questions about the operation failing and how to figure out why.

mc12345678:

While there may be some known caveats about whether to run a section of the installation or not, it is also important that the sql be written to recognize that the field(s) may already exist. This cuts down on questions about the operation failing and how to figure out why.

for field names the exact same name, that would be an easy thing to do for the sql side. For some plugins, we can even check or a list of popular used ones like Numinix's.

But I am wondering about the forms that go into the Admin product pages for the input forms. I guess comment out the code and have the user uncomment what is needed IF they have certain plugins already installed?

g2ktcf:

for field names the exact same name, that would be an easy thing to do for the sql side. For some plugins, we can even check or a list of popular used ones like Numinix's.

But I am wondering about the forms that go into the Admin product pages for the input forms. I guess comment out the code and have the user uncomment what is needed IF they have certain plugins already installed?

The historical tenet of Zen Cart is to provide more allowing the user to edit/remove what is not needed or wanted. This is instead of providing some sort of "hidden" content to then uncomment. I saw above that seemed to be asking about how to address the form part, unfortunately because we almost all of the form data is captured by hard coding instead of some sort of array of information, the addsit I nal fields likely should be included with some sort of documentation about how to prevent that/those fields from being duplicated.

A long long time ago, data was put together using a sort of table class which could then be searched through to identify the existence of a type of data or in this case a specific field. To get away from the pure "table" structure, where table tags were used, all natural div tags have been used. In the admin this means a lot of code has to be touched to adapt to a new "template" instead of some few key logic or construct changes.

Also it's been a while since I've looked at or caused duplicate fields in a form, but I expect one of them to take priority over the other in some way. I'd have to do more research again to advise further on how to handle that possibility of two "plugins" offering the same field(s) in a single form.