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
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.
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.
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.
The migration tool will be started within the next 4 weeks. there will be one.
Milbo, you inform at a forum when will be accessible migration tool?
~Google Translater~
There will be a news and a forum entry
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.
@ 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.
Quote from: franzpeter on July 22, 2011, 10:39:56 AM
@ 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.
Quote from: franzpeter on July 22, 2011, 10:39:56 AM
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."
Quote from: franzpeter on July 22, 2011, 10:39:56 AM
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.
Quote from: franzpeter on July 22, 2011, 10:39:56 AM
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.
Quote from: franzpeter on July 22, 2011, 10:39:56 AM
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.
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.
hey, that is afaik the right forum.
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.
Quote from: franzpeter on July 22, 2011, 15:52:15 PM
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 (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.
@jjk,
I agree (after reading the content of the provided link). But I think product import is important too. Else, we do not need google. It may be a good idea to add a function to VM to synchronise images, but it is not a good idea to use a database table with all product image information, which, while importing data to that table, creates an autoincrement value. Meanwhile the other product info goes to the product table, which creates another autoincrement value and finally try to link the image to the product with another database table, where you need both autoincrement values. It is a little bit difficult to fit together values from two different tables into a third one, if a table like the jos_virtuemart_medias table has absolutely no relation to other product or category relevant tables. In simple words: one hand does not know what the other hand does!
Quote from: franzpeter on July 22, 2011, 18:30:10 PM
it is not a good idea to use a database table with all product image information, which, while importing data to that table, creates an autoincrement value. Meanwhile the other product info goes to the product table, which creates another autoincrement value and finally try to link the image to the product with another database table, where you need both autoincrement values.
This is a completly normal standard behaviour. You can easily use left join to get one dataset. When you want to store clean and performant an array in a database you need your own table for it. It is also done for data integrity, because so we store an image only one time. Medias are also done to be downloadables (not fully implemented yet). Additional it is later in the multivendor scenario also important for multivendor.
Quote from: franzpeter on July 22, 2011, 18:30:10 PM
It is a little bit difficult to fit together values from two different tables into a third one, if a table like the jos_virtuemart_medias table has absolutely no relation to other product or category relevant tables. In simple words: one hand does not know what the other hand does!
this is not true, because there is a xref table, which is like the backbone. Your situation is special. Your distributor is giving you already the paths, but which paths? Are this absolute paths? or absolute Urls?
I do not exactly understand what the sync media means. Does it mean if I create an insert into the database with values for: vendor_id, file_mimetype, file_type and file_url the sync media is able to create the rest of the rows automatically for example the file_title, the datetime and maybe the thumb?
example for an insert with values:
1, '', '', '', 'image/jpeg', 'product', 'images/stories/virtuemart/product/1b0c96d67abdbea648cd0ea96fd6abcb.jpg', '', NULL, NULL, 1, 1, 0, 0, 0, ''
Does it mean if I click on sync_media all the other rows get filled automatically or do I completely misunderstand the sync media thing?
No, synchronise media runs through the directories, which you have defined in the vm config and adds a media entry per file. You may take a look on the function, it is 20 lines.
Another question: Will there be any database changes (MYSQL) in VM 2.1 in case of products, categories a.s.o.. VM 2 contains a lot of changes inside the database. So it means that all modules, components and plugins need a complete overhaul to work with VM 2. So is it time now to start that overhaul or is the database still to see as a work in progress? I do not talk about scripts, just the database tables!
The database tables are stable.
the only thing I remember I maybe change is some fields from int to bigint. But we didnt changed anything at the tables for almost a month now.
There is a database table row in the table jos_virtuemart_manufacturers called published. If I set the published to 0 does it mean that Virtuemart just does not show the manufacturer or does it say that if I unpublish a manufacturer all products of that manufacturer are unpublished too?
Hmm intersting idea. Atm it just means that you cant see the manufacturer in lists choosing them. and afaik, when you click on the manufacturer view, then the manufacturer shouldnt be shown.
CSVI or my cli script for example are able to do such things with unpublished categories (my cli script for manufacturers too). If a category is unpublished and if there are published products inside the category it can unpublish those products too. I could imagine, that it would make sense for manufacturers too.
VM 1.1.xx has the problem, that some search components just look for published or unpublished products. So they may find products from unpublished categories too. In VM 2.xx we have now the same situation for both, the unpublished categories and the unpublished manufacturers. It does not matter whether a manufacturer is published or not, the products may be found anyway.
So maybe some left join queries like a search for jos_virtuemart_products (virtuemart_product_id) and jos_virtuemart_product_manufacturers (virtuemart_product_id) together with published products and unpublished manufacturers to update the jos_virtuemart_products to unpublish would make some sense.
I use it in my cli script too for both to prevent the search component from finding products from unpublished categories or manufacturers.
I was trying to get some information on this topic on how to actually migrate from 1.1x to 2.x.
Ok the tool is there but how does it work? is there any info?
Cause I don't even understand how I'm supposed to migrate. I have VM 1.1.8 do I have to unistall it first? or install 2.0 directly? Do I need to copy files from 1.1.8 via ftp for the migration to 2.0?
Please a bit of basic info on the migration.
@lindapowers
If it would work as expected it would migrate all necessary information from VM 1.1.xx to VM 2.xx.
My personal opinion: I would not recommend to use it on a live shop. For testing purpose, I did use it on my localhost. My Shop has a lot of categories and about 30 000 products. On my localhost I had installed VM 1.1.9 (1.1.8 should work too) with all my data. To install virtuemart 2 I did uninstall VM 1.1.9. The uninstall process does not delete the virtuemart database, only the php files for frontend and backend. VM 2.0 uses new database tables and does not touch the old ones. So I did install VM 2 with the Joomla install component. After that I did choose to migrate (inside Tools from VM 2). I could migrate my customers and the categories from the old VM database. Products and orders did completely fail, maybe 30 000 products are too much for the migrator component. I do not understand why the migration of orders did fail.
But please, do not install VM 2 as live shop, use it for now just for testing purposes on a localhost. Maybe You have better luck with the migration!
Thanks franzpeter, Indeed I had doubts on doing it on a live shop, our shop is much smaller but still I'll wait till the migrator get's more stable/improved.
I think Franz-Peter did not tested the C version. Lindapowers, best is you use akeeba backup install the system at home and tries it there.
where can I find the migration tool from VM 1 to 2 ?
thank you
I am able to migrate the shoppers, the customers and the categories. The manufacturers do not work. While importing I receive the following error:
PHP Notice: Undefined index: in /htdocs/administrator/components/com_virtuemart/helpers/migrator.php on line 754
I did compare the amount of categories in the old vm1 tables and in VM2 tables, seems that the categories did work. All categories are there.
The script tells me, that is has migrated 579 manufacturers. Result is: Looks everything worked correct, migrated 579 manufacturers
But there is just one manufacturer inside the database and in the VM backend inside the jos_virtuemart_manufacturers. Lacks of 578 manufacturers.
Did not continue with the products, because without the manufacturers it makes no sense to continue.
While migrating I receive the following php notice: Undefined index: in /htdocs/administrator/components/com_virtuemart/helpers/migrator.php on line 754. The corresponding part causing that is:
$manu['virtuemart_manufacturercategories_id'] = $oldtoNewMfcats[$oldmanu['mf_category_id']];
I have no manufacturer categories in my VM1 database, only the default, which is indeed migrated into jos_virtuemart_manufacturercategories.
I use the newest VM 2 version virtuemart1.9.8.RC2c_extract_first.zip
ah thanks Peter, great work.
Should the media migration work with the virtuemart1.9.8.RC2d? Did put the category images into the recommended folder and I did control the path in the shop configuration file. Everything seems to be correct. The sync media did work and in the database the category images are in the media table. But the images do not get linked while migrating the categories. Seems that in case of images that the migrator does not work. Category names, descriptions, SEF alias a.s.o. are there in backend and frontend, but no images. Should it work (so it would be a bug) or is it not already implemented to migrate images and link them to the migrated categories?
Quotewhere can I find the migration tool from VM 1 to 2 ?
I would also like to know where to find it.
Thanks and regards
nillew
its IN 2.0
Thanks for reply.
One more Question, please. I have Joomla 1.5.22 with VirtueMart 1.1.8. I want to upgrade to Joomla 1.7 and VirtueMart 2. First I will migrate Joomla and after this I have to Migrate VirtueMart? Is that the right way? Maybe you know where to find a documentation?
Thanks and regards
nillew
I had a VERY hard time with this.
I migrated J1.5 Vmart 1.1 to J1.5 Vmart 2.0
THEN,
Had another copy of the site that I migrated the content to J1.7
THEN, used akeebah to merge the 2 sites. I installed 2..0 on the J1.7. THEN backed UP ONLY the vmart from the 1.5 site, and installed on top of the 1.7 site
https://www.akeebabackup.com/documentation/walkthroughs/item/1084-advanced-site-transfers.html
I would go another way.
I would first dump all vm1 tables. Then I would update to j1.7. Then I would delete the old vm1.1 files, install vm2, copy the vm1 tables back into the db, use migrator.
Using the new virtuemart1.9.8.RC2G I have no success to migrate manufacturers. Categories and Users work fine, with manufacturers it shows that 539 manufacturers did migrate but there are no manufacturers in the VM 2 Tables or the VM 2 backend.
i got my products to migrate - kind of. The product descriptions are working but the images did not. Any insight? The images for the Joomla part of the site are fine but the images for the VM part are not.
Also the migration did mess up the manufacturer. It listed them all now as the same one. There were about 6-8 diff ones before.
Thanks
Quote from: franzpeter on September 14, 2011, 14:49:15 PM
Using the new virtuemart1.9.8.RC2G I have no success to migrate manufacturers. Categories and Users work fine, with manufacturers it shows that 539 manufacturers did migrate but there are no manufacturers in the VM 2 Tables or the VM 2 backend.
Did you get your images to finally migrate? I have the same MFG issue as well... :[
Can we just move the images from
components/com_virtuemart/shop_images/product to
images/stories/virtuemart/product?
The images were working in J1.5.23 with VM 1.19 just a few hours ago and now in J1.7 and VM 1.9.8g they are not (products still there w/o images)
Yes, you must move your images before you do the migration... ahh Important HINT ! thanks!
Quote from: Milbo on September 15, 2011, 05:00:01 AM
Yes, you must move your images before you do the migration... ahh Important HINT ! thanks!
lol - o crap... well, what if we didn't... is there something we can do now?
It should work everything normal except that you do not have the images related to your products.
This is indeed a NO GO. If the product images cannot migrate in a way, that they are related to the products it means, that a user must manually relate the product images to the products. Most shops use a lot of images for the products! What I do not understand is why the manufacturers do not migrate. The migrator does not show an error, it shows that all manufacturers were migrated but they are not in the database table, where the manufacturers are stored.
Quote from: franzpeter on September 17, 2011, 11:32:46 AM
This is indeed a NO GO. If the product images cannot migrate in a way, that they are related to the products it means, that a user must manually relate the product images to the products.
When you do not copy your images into right media directory (configurable in the vm config), the migrator cant find any files. We cant change that. When you copy your files after the migration in the right directories and use then the migrator, everything already migrated wont touched again (we dont want to lose any adjustments maybe already done).
Yeh, your manufacturer problem. I take a look, whats going on there.
I found the error and fixed it. Is in the svn. Use the hints for svn here http://dev.virtuemart.net/projects/virtuemart/wiki/Setting_up_a_Development_Environment and use this page to create your installer http://dev.virtuemart.net/projects/virtuemart/wiki/Create_virtuemart_installer
@Milbo,
The my vice versa question: If I put the images in the right media directory before migration, does the migrator creates the right links to the images if I migrate the products?
Yes !
Is obvious you are working hard on VM 2.0, when things are more stable please make a little tutorial for the migration process, would really help dummies like me ;)
Made a migration successfully bit i have on problem.
Images are not visible.
the media tabel is complete empty....seems that during the process the table has not been filled.
Copied all image folders in the new VM path .
I can see all images in media manager.
But how can i now connect the images to products ? Is there a batch i can run again ?
NO PRICES IN PRODUCT DETAIL VIEW ?
I`m wondering why there are no prices and no "buy button" is visible in products.
I go to admin and open a product => I have to activate the checkbox "Grundpreis berechnen" and save the product => NOW the price and buy button is available in frotend.
Is there a workaround (phpmyadmin) how i can update all products ?
I can not open 500 products and recalculate them one by one... :-[
[attachment cleanup by admin]