Migrate VM 1.1X to VM 2.X

[chrisbti]

Is there a Joomla 1.5 and 1.6 migration tool to migrate VM 1.1x to the new VM 2.x
Pleaase advise

Thanks
Chris

[jjk]

Not yet - and I suppose you would have to wait a few months until the migration tools become available. But you can already use MySQL database tools like phpMyAdmin to import/export the data from older VM versions into VM2. Might take a few hours to get it right, but it works. I've done this already a few times for testing VM2.

[chrisbti]

I thought of migrating it manually, I guess you would just compare columns etc right?...but then again if they have a migration tool you save alot of time.

[jjk]

Yes, once you figured out which tables (aproximately 10) and columns you need, it takes just a few minutes. However, on my first attempt it took me a whole day.

Personally I prefer to use a free MySQL GUI tool named "HeidiSQL" to do this.

[Milbo]

The migration tool will be started within the next 4 weeks. there will be one.

[svcitius]

Milbo, you inform at a forum when will be accessible migration tool?




~Google Translater~

[Milbo]

There will be a news and a forum entry

[Milbo]

Atm I am working really hard on the migration tool.

We implemented the idea of jjk, which means that you can just upload your media to the correct directories, then you can synchronise the directories with the virtuemart database. So integrating pictures to vm2 is very easy now.

The migrator is already working for shoppergroups, shoppers, categories, manufacturers, mf categories, products, orderstats, and partly the orders.

Atm I am working on it so that it works robust, that means it does not hurt, when the process is stopped by max_execution time. Then I will see for the orders. Maybe we find an idea to synchronise the old imagepaths for products in vm1 with the new vm2 system.

Porting discounts and taxes is possible, but would lead to an horrible configured vm2 store. To have the advantage of vm2, it is important to redo them. We also may find a solution for this with more ideas by users.

[franzpeter]

@ Milbo,
I am fighting with your so called easy upload for media. I use a cron script to directly import my products from a distri to VM database. I do not use any Joomla or VM Api, just the direct way. You say that it is sufficient to upload media and synchronise the directory. But how should VM know which picture belongs to what product? Before (VM 1.1.xx) it was easy. It was only necessary to upload the pictures and put the correct path (i.e. file name) into the vm_product table. Now, the vm_products does not contain any row to do so. Instead, we use a table called jos_virtuemart_medias, where we put the path inside a row called file_url. So after doing so, you cannot simply click on synchronise. How should the database know which image belongs to what product. Instead we use another table called  jos_virtuemart_product_medias, where the connection occurs. In case of database product batch import it is a step back and reminds me on a shop solution called prestashop, where simple tasks are implemented in a complicate way.
I like VM 2 but the media handling is more complicate than necessary. Before, such a media table was only used for additional images, not for the main product images.

[Milbo]

@ Milbo,
I am fighting with your so called easy upload for media. I use a cron script

a cron script? I am quite sure that does not exist. You are using a normal shell script or simular started by cron! Why you do that via cron? I dont have any clue. Is not a problem, but we should try to use the right language/words/termina.

to directly import my products from a distri to VM database. I do not use any Joomla or VM Api, just the direct way. You say that it is sufficient to upload media and synchronise the directory. But how should VM know which picture belongs to what product? Before (VM 1.1.xx) it was easy. It was only necessary to upload the pictures and put the correct path (i.e. file name) into the vm_product table.

Where is the big difference? The normal way in VM2 is to create product and to choose a media, when the media is not there you can directly upload it in the product edit view. When you do a migration,  then the script needs to know which media should be related to the product. Before you had almost the same problem, the script has to know wich path you want to relate to the product, now it is the id. So when you compare your sentence: "It was only necessary to upload the pictures and put the correct path", so you can say now it is also easy. "Just upload the picture, execute synchronise media and choose the right media from the dropdown menue."

Instead, we use a table called jos_virtuemart_medias, where we put the path inside a row called file_url. So after doing so, you cannot simply click on synchronise. How should the database know which image belongs to what product.

You have the same problem. It is only easier for you, because you arranged already with the old way, thats it. When you can write a shell script, then you should see that this task are just some more lines in the migrator. Then think about how we wanna pay the development of vm2 and who needs this script. I describe it in words:

"Read path of vm1.1 product image, look in the media table where this path occurs, get id and write to vm2 product."

and now I see that you say, hey the product is not storing medias. jepp flow orientated yes. But when you look object orientated on it, than you see that you just have to call the normale $product->store function. thats it, quite easy.

I like VM 2 but the media handling is more complicate than necessary. Before, such a media table was only used for additional images, not for the main product images.

Which is just a hack! Now all medias are handled on the same way. And it is better for security, when you wanna do multivendor, you MUST NOT allow that a user can set upload paths. It is very hard to make this secure. There are a lot reasons todo it the new way.

[jjk]

import my products from a distri to VM database

just curious - I'm not shure what you mean with "distri". Are you trying to move your products from a VM1.1.x database table or from a different shop software?

In my case I have 1000+ products with 3 images and additional files (pdf) for each one. Adding them (manually) is a lot easier than in the old VM1.1.x. and also much more flexible. However, I must admit, that I actually do NOT want to migrate the old VM1.1.x images on my VM2 website because I definitely want to get rid of the ugly, SEO-unfriendly hash filenames, that were produced by VM1.1.x.

[franzpeter]

Hi jjk,

I import my products from a distributor, which provides csv files with all the product information. And that I do with a php script directly into database as daily cron job, fast, easy and that did work with oscommerce and after I did convert it, it works with Virtuemart too. But sorry, I did put it in the wrong forum, it has nothing to do with migration.

[Milbo]

hey, that is afaik the right forum.

[franzpeter]

jjk,
forgot to mention: what do you you mean with ugly, SEO-unfriendly hash filenames? In case of SEO, I use alt attribute for images. Google does not care about the file name of an image. It prefers the alt attribute.

[jjk]

Google does not care about the file name of an image. It prefers the alt attribute.

Ever read this one: http://www.google.com/support/webmasters/bin/answer.py?answer=114016
However, at the moment Google seems to care more about text next to an image than both, filenames and alt-attributes.

Concerning the "SEO-unfriendly hash filenames" I mean this: "Monaco_Grand_Pri_48786c7e213b2.jpg". VM1.1.x truncates long image filenames after 16 characters and it always adds a hash value to image filenames in order to make them unique.