The only BIG issue is that there is no useful (if any) working upgrade-script.
Is this on purpose and intentionally done to keep us from using 2.0?
How do "we" think that OC 2.0 will be widely adapted without such a script?
Or am I missing something?
I am available for such compromise, but alone I can't respond properly, and in fact it would be a great incentive to migrate and test the new OC 2.0.x, more users, easier to debug it.
DB issues can be handled by a common script, but the extension part have virtually infinite possibilities.
We can work in a default-to-default migration, but at the end of the day, users will miss the functionalities of their extensions and themes.
So this work also need that extensions devs update their work.
Anyway, put a new section on github for this, and let's go ahead.
The Majority of 'Contributors' has probably better THINGS to do, than 'commonly' writing a FREE Software to put themselfs OUT OF BUSINESS, because their former v.1.5.x Seller-'Mods' are not yet ready for an OC-2.x Version, actually not yet 'v.final.1.0' ready to 'serve' as a 'decent' test-platform to 'foolproof' test their own Mod's.yodapt wrote:Anyone else?
Sorry, but your'e out of your Mind, expecting such, at such a time.
And, as I see, the OC v.2 Developers are probably rather busy to get their THING to work. But as long as our BOSS closes 'matters' on github on a daily scale, I somehow 'feel', there are still 'things', waiting to be 'found'...
My 'very personal' opinion. No offense!
Please do NOT send me Personal Mails, they will no longer be replied to.
My Github OC Site: https://github.com/IP-CAM
2'800+ FREE OC Extensions on the World's largest Github OC Repository Archive Site.
http://www.opencart.com/index.php?route ... n_id=19572
When you update your database, you can then use that database with a clean install of 2.X and add any 2.X modules that are custom to the new store. However, expecting old extensions to work with 2.X is foolish - the same with vQmods. All custom work pretty much needs upgrading due to the changes to the core
Most extensions are based on VQMod so they will all just "abort" and error out if you try to update the code. I haven't had any issues with my clients being hacked on 1.5.x, (not sure if this is an issue for anyone else) and the extensions are all built for 1.5.x so I don't see much benefit to upgrading an old site yet.
Unless you're building a new site I'd stay stick with 1.5.x for a good 6 months until all the extensions catch up.
I could be wrong but thats just my 2 cents.
The problem I have is that for a regular guy like me, and my knowledge is more then other more common users of OC, it is almost impossible to upgrade me current db to use with 2.0.
What I find unbelievable is that the current 2.0 download comes with an "upgrade script" that makes people believe that they can upgrade.
We can only dream for a magical script which will be able to upgrade 1.5 customized installation with custom theme and a lot of extensions to 2.0 with 1 click and to get everything working.i2Paq wrote: The problem I have is that for a regular guy like me, and my knowledge is more then other more common users of OC, it is almost impossible to upgrade me current db to use with 2.0.
Unfortunately it isn't possible even if 100 top developers work together on such script.
In such cases, if you don't have enough knowledge and experience, it's better to hire a professional developer to do the job for you.
There are free scripts to handle DB transition and everyone can try to do the upgrade by himself but if the extensions are not working or something else goes wrong - you will need some experienced guy to fix it. It's just not possible to automate that.
Where the problem is the job? Just would be nice to know .... can I guess? The current trade you have a lot of good ("awesome") extensions that are not available in the version 2.x?i2Paq wrote: The problem I have is that for a regular guy like me, and my knowledge is more then other more common users of OC, it is almost impossible to upgrade me current db to use with 2.0.
"What I find unbelievable is that the current 2.0 download comes with an "upgrade script" that makes people believe that they can upgrade."
Why would the "upgrade script" be available if it does NOT do the correct job? or does it?
Love open cart but nowadays just feel
When dealing with any web platform that has a database, there are always 2 parts to upgrade...
the Filesystem and the Database.
The filesystem is always the easiest. Upload the new files on top of the old files and Bob's your uncle... done and done... mostly. One thing to keep note of with files is that new files will overlay old files, but some old files are no longer needed or have been replaced by a different file in the upgrade. But that leaves that old file there which can get confusing. One example is the "Welcome" module... it was replaced by the more generic "HTML Content" module.. but often the welcome module still sits there and people try to install it and get a bunch of errors.
The database is the trickiest part. A database can be exported to a file, but in that form it is very limited in its ability to be differentiated against. Most database tools for checking and acting on need to be done in place on the database. That is what the current opencart upgrade script does. It does some general purpose comparisons from the sql file that comes with it to your existing database that it looks up from the config.php file. It then attempts to make your database structure match the file. It only changes the table structures and none of the data. This works for 90% of the db changes but there are some changes that are so different that it can't just be handled with sql.
Sometimes data itself can cause issues. One major issue with updates to 184.108.40.206 is the way that modules are saved now. If you leave modules like "latest" installed before the upgrade, it leaves orphaned settings in the database. These orphaned values are no longer altered by the admin edit/save process but they can still override the expected data and cause chaos until they are deleted manually which is why so many people have problems upgrading from older versions to 2.x. These orphaned settings are not covered by the current upgrade script... and the real problem is that 3rd party modules leave n number of possible custom options that could be out there.
The question then becomes, How can we mitigate these extra steps. The issue is that they are too specific, and there has always been things like this hanging over each update. I tried keeping a running log of changes from OpenCart 1.2 through 1.5 and now 2.x and it's hell.. It isn't sustainable without manually keeping a file of steps that has to be generic enough to fail gracefully when those variations are not found. For example, someone who has upgraded from 1.4.x to 1.5.x to 2.0.x will have different files, different tables, different encoding, different data entries than someone who only went from 220.127.116.11 to 18.104.22.168. So we need a one-size-fits-all approach to upgrade. But when coding, coders do not want to add specific hard coded options. It gets messy and again unsustainable. So we try to find these more generic programmatic approaches to auto-determine and correct the state.
I used to maintain the upgrade script for 1.5.x and I would add these extra steps. But I couldn't keep up with them all and it was a major pain trying to keep up with the changes in the cart. So instead I've focus my energy on steps to follow to do the upgrades. They are tedious and have to be followed exactly and they work, but there are gotchas and many people have trouble following all steps which leads to the pages of questions on my "Beta 14x to 15x upgrade" thread. But I've mastered the process and I've successfully upgraded over 300 shops from as far back as OpenCart v1.1 all the way through 22.214.171.124. It can be done, but it isn't easy to have a script handle it unless you tailor the script exactly for the build and all the possible variations of upgrade state.
I'm not saying it can't be done, but it really requires a dedicated person to handle just that, and it is still difficult to get it all perfect across all permutations and especially across all servers. Web hosts all seem to have their own opinion on how to setup their servers and almost of all of them are clueless. This leads to shortened server execution timeouts on large databases, causing the upgrade script to timeout and now you are left with some frankenstein monster of a database. A lot of this comes down to experience and being able to get it back on course. All in all there are a lot of factors that can affect the upgrade process and none of it is easy.
Referring to the much used by the update, that is:Qphoria wrote: The database is the trickiest part. A database can be exported to a file, but in that form it is very limited in its ability to be differentiated against. Most database tools for checking and acting on need to be done in place on the database. That is what the current opencart upgrade script does. It does some general purpose comparisons from the sql file that comes with it to your existing database that it looks up from the config.php file.
http://www.opencart.com/index.php?route ... n_id=19572
At that script I have added vqMod feature.
I have developed the add-on, which may apply checked tables from the trade master database:
http://www.opencart.com/index.php?route ... n_id=20918
The program is uploaded to trade config.php file.
Thansk your comments.syntaxerror wrote:Hello Pekka,
Sorry, but it's kind of hard to understand the short writings in your Finnish-English. Both here on the site/forum, and in your readme.
What exactly is your script doing, and what are the steps required?
Does it really download latest OpenCart file system, and overwrite the one from 1.5, or does it just update/convert the database? If the latest, you really should update the instructions... and if A method is supposed to update the file system too, it doesn't work very well.
Instructions are not exactly the best, sorry my english
Everyone understand that I have made this program a large job.
It would be nice if there was a volunteer who would like to do less work: write clear English instructions.
Is that the point B more difficult to understand?
It is a relocation of trade to another directory and images "automatic" copying to the path where the new store is located.
Code is there:syntaxerror wrote:Yes, I fully understand the English issue. It's harder for the Finnish (Uralic) speaking people to learn English, than it's for the Indo-European - Germanic speaking. I have it the other way around, slowly trying to learn Finnish.
I probably could help out with the docs, but first I have to understand the converter. What it's meant to do, as it didn't do what I expected when I tested it after uploading it to the root of a 1.5 site (it's what the docs says I should). Think I have to dig into the code to try to figure out of this.
Both option A and B is equally unclear. And for your other tool, the Webmaster thing I really have no idea about what it is.
Would that name almost too much ... not suitable to these:syntaxerror wrote: Also I would recommend renaming it to "OpenCart 1.x to 2.x migration tool" or something like that.
OpenCart migration tool
OpenCart Converter tool
Ps. This upgrade also version 126.96.36.199 to version 188.8.131.52.
So this is vqMod.
Someone skilled can do this a add-on (to it suitable price), which handles all the customer's unique modules and convert those the database structure to fit the version 2.0.1.x
This could be a good name.syntaxerror wrote: So what about: OpenCart Migration & Upgrade Tool - that would cover the most used namings for the tasks.
However, the version 184.108.40.206 is required to use a "migration", when in the database was introduced in table `module` in version 220.127.116.11.
Thanks. All tips will be received.syntaxerror wrote: For the rest, docs and some bugs I've discovered I will use GitHub and your mail for my input on it.
Users browsing this forum: No registered users and 27 guests