It's not a secret that the current architecture of CS-Cart is a bit outdated against the background of modern PHP frameworks like Laravel, Symfony and so on.
Talking about core internals - caring of the backward compatibility ties our hands when we think of refactoring.
However, it's possible to implement the ability to develop add-ons in an object-oriented way without tons of spaghetti code. The object-oriented way provides much more intuitive and clean way of code structuring. Also, it would be a lot of easier to cover your code with unit tests.
I've attached the poll, please feel free to share your opinion by voting or by writing your detailed thoughts on this topic.
Awesome for new development but non one wants to spend time rewriting code that works and has an established user base (I.e. maintain compatibility).
Addon sales for cs-cart are way down from what they used to be. So my interest in investing in rewrites f existing addons is near zero.
Just because it uses a class does NOT make it OO. I.e. many of your Tygh area are simply class instantiations of procedural practices.
To become really OO, you'd have to redefine all the core objects in cs-cart like customers, products, orders so they were truly objects.
Please keep in mind the cost of these type of changes to developers and the value to merchants. Usually developer cost is high and merchant value is low which is not a winning combination. Historically the value is only to cs-cart developers for things like moving to Merchium and/or keeping developers interested in playing with new toys.
Awesome for new development but non one wants to spend time rewriting code that works and has an established user base (I.e. maintain compatibility).
Addon sales for cs-cart are way down from what they used to be. So my interest in investing in rewrites f existing addons is near zero.
I'm not talking about dropping compatibility with the current way of how it is done. I talk about the possibility of writing add-ons in an OO-way - so yes, I meant the new development.
I can't comment the sales of CS-Cart add-ons because I don't have any relevant information.
Just because it uses a class does NOT make it OO. I.e. many of your Tygh area are simply class instantiations of procedural practices.
I fully understand that. I don't mean the same procedural logic onto the static methods - this gonna have really convenient OO architecture since I have lots of experience with modern OO practices. I'm currently developing a prototype so I will share it with you later.
To become really OO, you'd have to redefine all the core objects in cs-cart like customers, products, orders so they were truly objects.
We understand it. But, as you described above, "noone wants to spend time rewriting code that works and has an established user base". We always choose spending time on developing new requested features and improving performance and stability, rather than spending it on the refactoring that will break all existing add-ons.
I'm currently developing a prototype so I will share it with you later.
A sample addon that is updated to reflect current feature/functionality would be awesome.
Several years ago (maybe 2009-2010) I did a 6-part tutorial on how to write an addon using movie products as the example (with sample code and instructions). It was geared toward developers and also served as a tutorial on using hooks. Seems those tutorials have been flushed from the forums but seeing examples of things like how to do the cs-cart-blessed way to upgrade addons, etc. would be a big plus or even how to setup configure to use the language files.
Right now, I don't know of a way to be able to upgrade an addon with new settings (or new language variables) without uninstall/install which can blast all the merchants addon data related to the addon (if an uninstall is to be a full removal).
There are several of these quirks that mean I've had to "roll my own" along the way to enable updates in functionality/lang_vals to my addons when newer versions are released.
Right now, I don't know of a way to be able to upgrade an addon with new settings (or new language variables) without uninstall/install which can blast all the merchants addon data related to the addon (if an uninstall is to be a full removal).
There are several of these quirks that mean I've had to "roll my own" along the way to enable updates in functionality/lang_vals to my addons when newer versions are released.
I'm currently writing an article for "Developers guide" section about i18n in CS-Cart. The article will cover the way the language variables are being upgraded.
That would be one improvement but still doesn't address addon settings or other things that currently require uninstall/install. Cs-cart has it sweet because you roll your addons with your releases and don't update addon settings (or any other extensions) during the process.
Be happy to provide you feedback on your article before you publish if you'd like to send it along. Important that new ones be added but existing be unchanged (unless a force option is specified).
Right now, I don't know of a way to be able to upgrade an addon with new settings (or new language variables) without uninstall/install which can blast all the merchants addon data related to the addon (if an uninstall is to be a full removal).
There are several of these quirks that mean I've had to "roll my own" along the way to enable updates in functionality/lang_vals to my addons when newer versions are released.
I've reported this issue in the black hole2 years ago:
http://forum.cs-cart.com/tracker/issue-5217-lack-of-addon-upgrade-function-results-in-data-loss/
The bug seems to have been forgotten.
We've implemented the functionality of add-on upgrades at CS-Cart 4.3.1.
Please take a look at the documentation: http://docs.cs-cart.com/4.3.x/upgrade/upgrade_addon.html
Would have been much more helpful if you simply listened to addon developers and supported their needs rather than asking us to completely redo our build/distribution environments. This methodology is not workable by me and if you used it yourself, you'd understand the overhead and maintenance costs involved. I currently generate a single archive for both new installs and upgrades.
The vast majority of issues would be addressed by simply reading the addon.xml in real-time and resolving the new settings and executing the sections. For languages, if it's already in the ?:lang_values table, then ignore it but if it's new, create it. In addition to 'for=install/uninstall' you could have simply added a for=upgrade version=1.1. (1.1 would indicate the version being upgraded FROM). So if the xyz addon was at version 1.0 then that 'for' would not apply. And if it's at 1.5 it also would not apply. You could even have a section called 'upgrade' and if then perform the actions in that section if the current version is 1.1.
This would also serve as a history of sorts. It's also not complicated, is self documenting and does NOT require any changes to a developer's build process.
Need to separate the "check for upgrade" and the "upgrade data".
I already embed my own license checks and upgrade checks within all my addons (since this critical means of support was never there before). So what was needed was to be able to deploy a new addon and have the addons settings and language variables updated from addon.xml. I already do all my own language variable management and db adjustments in one of several types of 'post' install scripts.
So again, what was a fairly simple original request turns into a complicated solution that requires someone to completely revamp their build environment and will also cause duplication of effort for upgrades versus new installs.
What was provided was not what was requested by addon developers though it may have been what was requested by merchants because they deal with many addon developers who do not provide automatic upgrades to their products. But even in those cases, the addon developer could then provide a single archive that can be used to install or upgrade a product using the current '+' icon or even adding a 'upgrade' selection to 'disabled/uninstall' dropdown. In that case, an addon developer would only need to provide a service that checked a version request and if your of date, provide the latest addon archive via the protocol.
So the test of whether you have met the customer/addon developer needs is to identify how many addon developers are using your new method?
Doesn't this method also require the merchant go download/install each version between where they are and current? The above would enable and addon developer to skip all that and go from 1.1 to 1.5 in one step.
I already embed my own license checks and upgrade checks within all my addons (since this critical means of support was never there before).
Do you declare what callbacks exactly are used and what data is transferred between the clients server and your server?
And also what happens when your server becomes unresponsive. Will the clients website go down or specific functionality?
Do you have a statement on your website somewhere?
A license check is done whenever an admin logs in. Just like cs-cart. If the license is not valid (wrong domain or incorrect number of stores) then the addon is disabled.
If the admin is an is_root admin and a check has not been done in the last 24 hours, a version check is performed to see if an upgrade is available (frequency to check versions is an addon setting in all addons - default is once a day). If so, then it downloads the new version and upgrades the addon. A (sticky) notification is then displayed indicating the addon that was updated. If a new version is not needed, a (non-sticky) notification is generated saying the addon is "up to date". A version check (install) can also be done via URL parameters. Contact us if you want to force a version check.
If when the license is being checked or the version, the connect timeout has been reduced to 15 seconds. So if my servers don't respond within that time, the checks are skipped that time and everything remains as is (and no other of my addons are checked in that cycle so there's only 1 possible 15 second delay).
Statements are in the license agreements but the actual steps involved (above) are not really published, mostly for security purposes. Though some of the process is outlined in our FAQ.
In the 7 years I've been doing cs-cart addons, I've only had 2 occurrences where my servers have not been available. The first time impacted clients because the timeout was not in place (it was the default TCP timeout of 60 seconds and did not account for multiple requests). After that, the timeout and number-of-attempts restrictions were put in place and I've not received a complaint since (even when my access to my site went down for a full day due to an attack on the data center).
For obvious reasons, I don't reveal the exact methodology used since all the addons are open source, I don't want the license checks to be defeated though that would be a license violation but it's pretty much unenforceable and my licensing is based more on trust that enforcement.
I have done business with many reliable trustworthy software vendors who had a stable site for years. Then after quite a few years they disappeared, license checks failed and my site went down or the functionality I paid for became unavailable.
I have also done business with a software developer who fetched customer data through callbacks, without declaring this.
Both experiences offered hard lessons.
I have a lot of trust in you and know the problems that piracy pose, but the above illustrates why I am extremely reluctant to run addon software with callbacks on my servers.
Talking about add-on release and upgrade process - we're preparing a totally revamped way of doing this. I mean you'll be able to release add-ons directly at our marketplace and any upgrades will be built and delivered automatically along with license checks and so on. So please stay tuned - it'll be released in a couple of months.
I think there's already enough off-topic discussions here.
Talking about add-on release and upgrade process - we're preparing a totally revamped way of doing this. I mean you'll be able to release add-ons directly at our marketplace and any upgrades will be built and delivered automatically along with license checks and so on. So please stay tuned - it'll be released in a couple of months.
I think there's already enough off-topic discussions here.
Hoping you will query developers to identify their needs (some of which are described above) before you go off and implement something that
1) you won't use internally for all your addons because there's too much overhead (show us through your own use the value)
2) doesn't meet the needs of 3rd party developers
3) doesn't provide real value to the merchant
The worst thing you can do is go off and develop something new without the above and find that no one will use it because it isn't practical to be used. You really can't do this in a vacuum.
I have a lot of trust in you and know the problems that piracy pose, but the above illustrates why I am extremely reluctant to run addon software with callbacks on my servers.
And we too have trusted merchants that we work with where we disable license checks due to established relationships and business constraints. But our general model is to verify licenses.