Starting to Dislike OpenCart

I'm really starting to dislike OpenCart due to its intrusiveness when you need to upgrade.
I just updated this via Softaculous and voila...all my designs are gone and everything are back to the default style.
I hope that if this procedure is not advisable I hope you have some sort of warning.

After further browsing in your website, I found the patch, download and read.
It says on the PatchOnlyReadme.txt

MOST CHANGES IN THIS PATCH ARE DEEP IN THE CODE AND WILL NOT AFFECT ANY CUSTOM TEMPLATES
THERE MAY BE SOME EFFECT ON MODS THAT MODIFY THE CORE FILES.
BE SURE TO BACKUP ANY FILES LISTED IN THE DELTA.TXT FILE AND MERGE YOUR CUSTOM CHANGES OVER

Backup the files listed in delta.txt - you mean navigate my ftp and find this 40+ files and backup before I upload the new sets of file? Can't this be improve?

For custom themes, an upgrade should be no problem.
For changes to the core files (all files that are no custom theme members), you should use vQmod.

thanks ckonig. i hope you don't mind if i ask what is vQmod and where I can get this?
what i want is to update/upgrade all the necessary core files without changing the content or items on the store.

Yeah, I really hate backing up everything and then merging the files once finished with the upgrade.

I wish vQmod was mandatory for ALL addon's and extensions. At least then we would just have to update a simple XML file whenever we upgrade instead of having to go back in and modify the core code over again or merge it back to working order.

LOL, I say we make that a new requirement...all addons or extensions in the Extensions area must come with a vQmod file if they touch the core code at all. I'm sure Q will love that.

Jin wrote:I just updated this via Softaculous and voila...all my designs are gone and everything are back to the default style.

IF you modify the default theme that comes with OpenCart then it will be overwritten.

I agree that when it comes to a bug-release a document with all the changes, so a manual updated by adjusting or adding the changes to your files, would be a welcome change.

It is frustrating but there isn't really much we can do.

To make a template anyway near custom without just changing a few colours, you will need to modify the controller files (due to the MVC model making placement of items very restrictive with out changing these) which makes upgrading to the next x.x.x.x a real pain.

Shouldn't have problems backing-up though, its something I do at least once a week

I might just go with other CMS if OpenCart will just give me headaches for simple patch update.
Backup each files manually then upload then merge...what the...nevermind.

That is your choice, but good luck finding something that never breaks on upgrade. I've never seen any software package pull it off no mater how much they tout that ability.

I agree with opencartisalright,
vQmod should be mandatory as far as core files are concerned. Because it is possible!
I am working on a big set of extensions which will add a complete new field of functionalities to OpenCart (warehousing, purchasing, etc).
Until now it was always possible for me to NOT touch the core files, but make all changes to them via vQmod.
When I found an extension I found useful, I made a vQmod from it, also that was always possible.

When the update from 1.4.9.3 to 1.4.9.4 came, it took me about 3 hours to fix the vQmod XML files, and I was done.

Of course sometimes it is exhausting, because your IDE doesn't really support you. At night I dream of a program, where you put in the original php file and the modificated one, and the program creates you a vQmod XML file.
So if anybody is good at parsing and has too much time... please build such a program.

But until then I will continue to work with vQmod and I am still very thankful to Qphoria, because my project would be just a big mess without it.

twiggy wrote:To make a template anyway near custom without just changing a few colours, you will need to modify the controller files (due to the MVC model making placement of items very restrictive with out changing these)

Another option (and one I've used before to avoid exactly these upgrade problems) is to break the MVC model and place model and controller functions in the actual template files. Yes it's not ideal, but then the changes aren't overridden when updating. To me, this is worth it.

Of course, with vQmod now you don't even have to do that, which is great. But until vQmod is part of the core (which might never happen) this is at least another option.

A longer term solution would be a robust plugin / hooks system, of course.

Short of that, if you use a version control system for the mods you install or perform, then updating becomes much easier. Subversion, Git, and Mercurial will all assist with the merge process, doing automatic merges where possible and notifying you of any potential conflicts for assisted manual handling.

These two techniques, hook events and version control, are proven and widely used. The latter technique is available now to anyone willing to spend some time to learn how to use the tools.

Edit: A simpler tool than the version control systems is kdiff3, available on mac, windows, and linux. With kdiff3, you point to two directories and it will show all the differences in the files present, and differences inside these files, and then will assist in the merge if you wish.

Greg F wrote:A longer term solution would be a robust plugin / hooks system, of course.

yes that would be good and it is being looked at for a future version. probably 2.0 which will be a ways out, but many people seem to think that a robust plugin/hooks system will eliminate any problems with upgrades which is of course completely wrong. It helps, but things still break pretty badly with upgrades. I've seen sites pretty much completely destroyed on wordpress/magento/joomla etc which all claim to have robust plugin/hook systems so that upgrades don't break anything.

Johnathan wrote:

twiggy wrote:To make a template anyway near custom without just changing a few colours, you will need to modify the controller files (due to the MVC model making placement of items very restrictive with out changing these)

Another option (and one I've used before to avoid exactly these upgrade problems) is to break the MVC model and place model and controller functions in the actual template files. Yes it's not ideal, but then the changes aren't overridden when updating. To me, this is worth it.

Of course, with vQmod now you don't even have to do that, which is great. But until vQmod is part of the core (which might never happen) this is at least another option.

I too have crossed over the barriers of MVC to call things directly from the controller. I agree that while frowned upon and harder to work with, for a mod it allows you to keep it all in one place.

I'm not 100% sure how other carts do upgrades. I know ZenCarts upgrade process is just like OpenCart's, for better or worse... but they don't do patches. phpbb3 and SMF have a smoother upgrade process, but I'm not sure how it works exactly. I know they use a patching system like vQmod but that actually writes to the files, but I don't know what happens if the change affects a modification. There is no doubt that there needs to be improvements, but with the last few versions, if you are having problems then you are likely overthinking it.

You have 200 files on your server... the patch has like 40 of those files. You don't have to go backup each of those.. you simply need to know if a mod has changed one of those files. If so then you will need to merge the changes with kdiff on mac or winmerge on windows. It is up to you to keep a little txt file cheatsheet of the mods you have installed and ones that you know modify core files and write the list of changed files in that txt file so you know.

Even with hooks in place, you can't hook every single line of code that you may need to modify.

Another better method that we don't often use in OpenCart is to subclassing the controllers. This allows your version of the controller to automatically inherit changes from the parent controller, and as long as the parent controller hasn't removed anything, your changes should still work. That's something I will be working to better exercise understanding of for others to start using it when applicable. That is basically how a plugin system works. We just haven't promoted using it like that

Qphoria wrote: Another better method that we don't often use in OpenCart is to subclassing the controllers. This allows your version of the controller to automatically inherit changes from the parent controller, and as long as the parent controller hasn't removed anything, your changes should still work. That's something I will be working to better exercise understanding of for others to start using it when applicable. That is basically how a plugin system works. We just haven't promoted using it like that

yes this is everyones latest thing that is supposed to guarantee break free upgrades. It was one of the biggest things magento touted when they first came out. Mod all you like never break on upgrades. I haven't seen much of that claim after the first big upgrade when they realized everything was going to break anyways. Not that I'm saying opencart shouldn't implement some of these things to help the situation. I just get tired of hearing people say oh magento does it this way and it doesn't break anything on upgrade, but anyone who has ever tried to upgrade anything but a completely default magento store from 1.3 to 1.4 or 1.4 to 1.5 knows that is simply not true.

Interspire uses some good examples of subclassing, not so much from an upgrade safe point of view, but from the point of view that makes modding easier and reusable api calls easier. For example, they have a generic credit card controller that simply allows a payment class to extend it and use a common function for curl communication, form creation using another generic form tpl, and handling callbacks the same. This lets you simply subclass the functions you are using and enter only the meat and potatoes so that the rest of bits are handled in the parent. While not a guaranteed solution, as long as the main bits are not changed willy-nilly then it should be more upgrade resistant while still making the initial development easier. And technically any core changes for the other bits that are changed will be virtually transparent to the subclass so long as you don't break the parent-child bond.

It's not an exact science, but probably couldn't hurt. I'm looking at adding a generic credit card class as well for a starting point

I found the OP quite funny to be honest - The reason you lost all your changes isn't opencart's fault, it's because you used softaculous to upgrade. Softaculous is made to install a pre-made cart/application into the right folder, on the right domain that you choose, with the right settings. it doens't ever say it will upgrade your software without breaking it. Hell, the whole process softaculous uses is delete everything and write the new stuff, so what do you expect? I think you need to be careful when using these quick fix tools to read exactly how they operate, or face this kind of issue again

Jay is right.. I don't think softaculous can do upgrades. It is only meant for initial installs.

I know for a fact it doesn't

JAY6390 wrote:I found the OP quite funny to be honest - The reason you lost all your changes isn't opencart's fault, it's because you used softaculous to upgrade.

True.

But the point is that when there is a bug-fix release (full version release or just the adjusted files) it is still hard to upgrade/update.
Telling a user to use WinMerge to compare his files with the ones from the release is easy but what should be done is create a document in which you find what file is changed and what the changes are compared to the previous release.

I don't think any software goes to that length with their change log do they?