Requiring "Other" Mods for new Plugin

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

[g2ktcf]

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?

[mc12345678]

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.