Settings/db Not Changing When Existing Addon Is Updated (Addon.xml Has New Settings)

We are trying to install an updated addon in CS-Cart 4.3.4 (yes we need to upgrade soon). An older version of this addon is already installed. Upon uploading a zip file, the files are updated in server, however its not acting right in the admin addon settings, and its not applying things from addon.xml to the database.

How do we percolate CS to re-up the addon.xml without uninstalling then reinstalling? The addon.xml has DB column drops, and I'm leary to comment them out to try the update in case there is some kinda db cached record that will apply the drops anyways.

Things i have tried:

- Changing addon.xml to have a new version, priority, etc

- Opening the addon area in a browser that has never visited that page before (never cached)

- Clearing every CS-Cart cache i can find + storage + theme rebuild + redis + pagespeed + cloudflare + browser.

- Disabling Cloudflare completely on the domain (in case it was somehow caching the addon settings popup)

- Disabling the addon, uploading the update, enabling the addon

- Various other disable/enables in specific multistore views

- Renaming existing addon.xml to addon.xml.bak and trying an update

- Combinations of this rename with disable/enables

- Renaming and also removing the row in _addons DB table and reinstalling (new values were set, this is the closest i got, at least the new settings + DB stuff was saved -- but the settings popup wont change)

- Visiting the addon settings popup directly and trying these things again (https://www.example.com/my-admin-path.php?dispatch=addons.update&addon=some_addon)

I have noticed this behavior in all addons. Its extremely frustrating when developing too, as you can't just add more settings into addon.xml and do a reinstall. It takes manual DB deletions or an uninstall first to percolate the changes.

Is this an issue with our version of CS Cart, or CS Cart in general? I didn't see anything addressing this in the changelog. Related topic: http://forum.cs-cart.com/topic/47590-best-practice-uninstalling-and-removing-an-addon-cs-cart-v43x/#entry269838

Thanks

Ok i partially figured out why things don't work as intended with this: It has to do with the values of section_id section_tab_id in _settings_objects table.

If you end up deleting the addons row in _addons in order to force update, the following will happen: When an addon is updated that includes new settings, they use different section/tab id's. So if an addon was previously installed with 2 settings, they may have (for example) a section_id of 100 and a section_tab_id of 101.

After update, the _addons row is re-created, and the settings are re-saved (with the old ones still present). The 2 previous settings are re-entered into _settings_objects, along with the 2 new settings, all under new section_id's and new section_tab_id's. Then delete all the unused _section_id's and _settings_descriptions.

What needs to happen is this: delete the duplicate old settings that have new _id's, then change the new settings _ids to reflect the old settings that are still present. The 2 new settings will now have, for example, matching section_id of 100 and a section_tab_id of 101, and they should now appear in admin addons popup window.

This is a ton of hacking around just to update an addon meta/schema/settings without uninstalling. If anyone has a better way to force an update, please do share :)

Good luck.

You should save you settings from the addon (copy/past to a txt file), then uninstall/install the addon.

cs-cart does NOT re-read the addon.xml if the addon is already installed or at least it won't recognize any new fields.

I would NOT start hacking on the DB versus uninstall/install of the addon.

Ah wow just realized something that can make this exponentially more of a *****. CS def needs a re-up in regards to this IMO.

So lets say i have a dependency addon that is used by like 10 others. For example, the underscore library. Everything is going swell until one day i want to add a couple settings to the underscore addon.xml. Something like ability to pick either underscore or lodash, choose which CDN the lib is hosted on (or local), and ability to choose a from different versions.

Without messing in DB, one would be forced to check over those 10 addon.xml's, edit their uninstall queries/procedures to preserve data, reinstall the dependency underscore, reinstall the 10 addon xml's, and reinstate their uninstall goodies.

Yikes.

Smirking as I read.... Yes, you are correct and it's been a problem since the epoch.

It would be easy to simply have a for="upgrade" to the various tags like where they would be re-evaluated if the addon was being installed when it's already installed (I.e. an upgrade) or when it is being freshly installed. Then the queries and other things would retain their values because they would not have a for="uninstall" and they could have a for="upgrade" if schema/data changes are needed..

The "upgrade" would be either clicking the '+' icon and uploading an archive or possibly to have a 'reinstall' option on the addon selector. I.e. "Disable", "Reinstall", "Uninstall". where once could have extracted the archive already. Note that templates from themes_repository should be re-installed when doing an Reinstall/upgrade.

But they invested in this overly complex set of tools and development environment requirements that I'm not aware of any 3rd party developers that use them. It needs to work from an archive I create, not dictate how I need to package my products.

tbirnseth, I have a similar issue to the original poster. I'm relatively new to CS-Cart custom development and I'm currently building a custom add-on for my company's store. I expect that this add-on will significantly evolve over the next few months, with changes to the database schema at each iteration. Our current database isn't very big, so data migrations so far have been manageable whenever I need to reinstall the add-on. I'm worried about this becoming a real headache in the future because the add-on works intimately with the product tables, so there are a tonne of table dependencies.

What do you recommend for a deployment workflow when I need to change the database schema? Right now I backup the relevant DB tables, uninstall the addon, install the new addon code via the admin panel, and then restore the DB tables. This works fine if I'm adding a new DB column to the schema that I can default, but this process will break when I have more complex schema changes.

Any recommendations for how I can improve this deployment process?

If you have onsite development, then just alter the DB and do the same in the addon.xml. I woudln't bother with install/uninstall unless you change settings.

You can change settings via the settings_objects table. But if you can, uninstall/install as you're doing is much less complicated and has the side benefit of testing your installation.

tbirnseth, I have a similar issue to the original poster. I'm relatively new to CS-Cart custom development and I'm currently building a custom add-on for my company's store. I expect that this add-on will significantly evolve over the next few months, with changes to the database schema at each iteration. Our current database isn't very big, so data migrations so far have been manageable whenever I need to reinstall the add-on. I'm worried about this becoming a real headache in the future because the add-on works intimately with the product tables, so there are a tonne of table dependencies.

What do you recommend for a deployment workflow when I need to change the database schema? Right now I backup the relevant DB tables, uninstall the addon, install the new addon code via the admin panel, and then restore the DB tables. This works fine if I'm adding a new DB column to the schema that I can default, but this process will break when I have more complex schema changes.

Any recommendations for how I can improve this deployment process?

Hello!

You can comment the old code in addon.xml and leave only the new lines. Then you can uninstall/install the add-on, but please be careful and make back-ups.

Hmm. Ran into another thought: How do we preserve data on uninstall for addons that use normal CS-Cart settings? For addons that use for="uninstall" or custom tables/fields its pretty trivial. The standard settings are autopilot though when overriding at a storefront, putting values into objects at settings_vendor_values table which overrides global values in settings_objects.

There is an addon installed with like 20 fields set across 6 stores (120 fields to re-enter data) with a mix of store and global settings, and i really dont wanna manually mess with this one to get an update to work.

The best way to address this is to NOT uninstall but to overlay and then manually re-install the theme_repository templates.

While this won't get you the new settings, you could add those manually through tags that can check whether the settings are set and if not add them.