Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Addon Development - Best Practices


Recommended Posts

@@kymation more than a real need it is an useful feature that exists in most of them. If you uninstall a module you usually loose all config values; if you just disable it the values are still there and you don't need a full install. I use it very often when testing them.

Link to comment
Share on other sites

  • Replies 130
  • Created
  • Last Reply

I agree that the installer's Enable/Disable is useful. I just don't see the need for an additional method or two to do the same thing.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

@@kymation I found it when trying to add an enable button in content_modules admin to do it in one click, very handy when testing a page. But It might be useful for example, if you have a multi-addon, to enable or disable other sub-addons when the main one is disabled, or when you add a content module that replaces or need a stock one to be enabled/disabled...

 

One example: Imagine you have an addon for product page that replaces the stock product images or product description. You can read width and position of the old addon from install routine, and the new addon will be installed in the same place, same width as the older one, and automatically disable the older one instead of uninstalling it (of course after informing the user the old content module is disabled and the new one replaces it).

 

It may be also convenient in the future (combined with a well implemented version control system) to disable outdated addons uncompatible with the new oscommerce version. Imagine oscommerce, say version 5.9 changes completely the way to handle shipping modules; if the modules have a supported core version the upgrade routine can automatically disable all modules that support versions lower than 5.9.

Well too much imagination maybe... o:)

Link to comment
Share on other sites

I'm trying to think how that might be implemented. The code in the installer changes the value of a constant that is stored in the database. Your enable/disable code would have to change that same database value. That means duplicating code.

 

I would be more interested in this if it were easier to do. What am I missing?

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

My preference is for a module to report that it thinks there's a clash with another installed module. I don't like the idea of it disabling the other module automatically.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

I'm trying to think how that might be implemented. The code in the installer changes the value of a constant that is stored in the database. Your enable/disable code would have to change that same database value. That means duplicating code.

 

I would be more interested in this if it were easier to do. What am I missing?

 

Regards

Jim

 

It's just an example. In the example I mean:

 

You install module B that is meant to replace module A.

- Module B reads values from module A:

  module_b -> content_width = module_a-> content_width;

  module_b -> sort_order = module_a -> sort_order;

Then, if wanted, module B outputs:

  "Module B is meant to replace module A. Do you want to disable module A?"

and then call module_a->disable method if the user agrees.

Or:

  "Module B is meant to work module A that is currently disabled. Do you want to enable module A?"

and then call module_a->enable method if the user agrees.

 

That implies each module has their own standard methods for enable or disable, or just rely them on a core function thas does the job. Of course this example can be done now without those methods, but it implies guessing the database value from module A class name and the width of the module.

 

or as @@BrockleyJohn says, just add messagestack with a warning and let the user disable the module.

 

I don't know if enabling module is really useful, just got surprised when I realized when I tried there is no standard or straight method to do that as there is for install/uninstall, being a common property for all modules. At least most of them has the isEnabled() method.

 

If it just exposed the database keys where it stores the common values (size, position, enabled) values it would be sufficient.

 

But I'm sure setting module size and position is a must for future use in admin. This will allow, for instance, seeing a graphical preview of the whole page, or allow newly installed modules to fit the empty space.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...