Press "Enter" to skip to content

Migracja danych ze sklepu PrestaShop 1.4 do PrestaShop 1.7. Czy to możliwe? TAK!

Admin 4

Dziś pokażemy jak z grubsza przenieść dane w PrestaShop o całe 3 wersje do przodu. Czyli zupelnie pomijamy 1.5 i 1.6 🙂 Zadanie wydaje się dość karkołomne, ale jest do wykonania:)

Poradnik dotyczy dokładnie migracji z wersji PS 1.4.6.2 do PS 1.7.6.1. Zatem miej na uwadze, że struktura tabel w innych wersjach może się nieznacznie różnić.

Ustawienie prefixów tabel w MySQL

Przede wszystkim będziemy kopiować tabele po stronie MySQL. Pozwoli nam to na migrację nawet gigtantycznej ilości danych (kilkadziesiąt tys. produtków i wiecej). Po za prostotą – zapytania nie obciążają tak serwera i są nieprównywalnie szybsze niż import przez CSV..

W tym celu przyjmujemy podstawową zasadę:

  1. Prefix tabel MySQL w sklepie PS17 będzie mial postać: pr_
  2. Prefix tabel MySQL w sklepie PS14 będzie mial postać: ps_

Prefix – czyli „wstawka” którą zaczynają się nazwy tabel.

To kluczowe, ponieważ pozwoli nam na umieszczenie zrzutów baz z obu sklepów w 1 bazie danych MySQL i operowanie pomiędzy tabelami.

Dlatego w instalacji nowego sklepu PS17 zmień te prefixy w programie PhpMyAdmin, następnie uwzględnij tą zmianę w pliku:

app/config/parameters.php

Jeśli stary sklep PS14 nie ma prefixu ps_ tylko jakiś inny – odpowiednio go zmodyfikuj albo uwzględniaj to w poniższych zapytaniach.

Program PhpMyAdmin umożliwia łatwą podmianę prefixów:

Podmiana prefix tabel MySQL w PhpMyAdmin

Po tak przygotowanych prefixach, umieść zrzut starej bazy w bazie danych nowego sklepu. Poprzez zakładkę „Import” w PhpMyAdmin. Finalnie baza nowego sklepu musi mieć „swoje” tabele zaczynające się od „pr_” i „doklejone” tabele starego sklepu zaczynające się od „ps_”.

OK, zdaje się że jest to już jasne i możemy przystąpić do działania 🙂

Przygotowanie instalacji nowego sklepu.

Dobrze aby nowy sklep poza odp. ustawieniem prefixów – miał możliwość wyczyszczenia danych. Tzn. niech będzie to najlepiej czysta instalacja PS.

Uwaga ! Poniższe zapytania będą bezpowrotnie czyścić dane w nowym sklepie i miej to na uwadze 🙂

Języki

Dane będą powielane ze starego sklepu. Zatem, jeśli sklep posiada kilka języków – muszą one na nowym sklepie być założone z tymi samymi ID. Ewentualnie potem w zaimportowanych tabelach trzeba będzie odpowiednio te ID przestawić. NIestety ta druga opcja mimo, że trudniejsza w wykonaniu jest mniej pozbawiona błędów.

Przybliża to artykuł: https://pskrk.com/przeniesienie-kombinacji-produktow-ze-sklepu-w-wersji-1-4-do-najnowszej-1-6-1-2/#Przyklad_z_innymi_ID_jezykow

Import kont klientów i ich adresów.

Importujemy adresy:

TRUNCATE pr_address;
INSERT INTO `pr_address`(

  `id_address`	,
  `id_country`	,
  `id_state`	,
  `id_customer`	,
  `id_manufacturer`	,
  `id_supplier`	,
  `alias`	,
  `company`	,
  `lastname`	,
  `firstname`	,
  `address1`	,
  `address2`	,
  `postcode`	,
  `city`	,
  `other`	,
  `phone`	,
  `phone_mobile`	,
  `vat_number`	,
  `dni`	,
  `date_add`	,
  `date_upd`	,
  `active`	,
  `deleted`	

) SELECT 

  `id_address`	,
  `id_country`	,
  `id_state`	,
  `id_customer`	,
  `id_manufacturer`	,
  `id_supplier`	,
  `alias`	,
  `company`	,
  `lastname`	,
  `firstname`	,
  `address1`	,
  `address2`	,
  `postcode`	,
  `city`	,
  `other`	,
  `phone`	,
  `phone_mobile`	,
  `vat_number`	,
  `dni`	,
  `date_add`	,
  `date_upd`	,
  `active`	,
  `deleted`	

FROM ps_address;

 

Jak widać na początku zapytań czyścimy tabele nowego sklepu poprzez polecenie TRUNCATE.

Import kont klientów:

TRUNCATE pr_customer;
INSERT INTO `pr_customer`(

  `id_customer`	,
  `id_gender`	,
  `id_default_group`	,
  `secure_key`	,
  `note`	,
  `email`	,
  `passwd`	,
  `last_passwd_gen`	,
  `birthday`	,
  `lastname`	,
  `newsletter`	,
  `ip_registration_newsletter`	,
  `newsletter_date_add`	,
  `optin`	,
  `firstname`	,
  `active`	,
  `deleted`	,
  `is_guest`	,
  `date_add`	,
  `date_upd`	

) SELECT 

  `id_customer`	,
  `id_gender`	,
  `id_default_group`	,
  `secure_key`	,
  `note`	,
  `email`	,
  `passwd`	,
  `last_passwd_gen`	,
  `birthday`	,
  `lastname`	,
  `newsletter`	,
  `ip_registration_newsletter`	,
  `newsletter_date_add`	,
  `optin`	,
  `firstname`	,
  `active`	,
  `deleted`	,
  `is_guest`	,
  `date_add`	,
  `date_upd`	

FROM ps_customer;

 

Jeśli zapytanie zwróci błąd np. przez brak domyślnego języka dla klienta odp. zmodyfikuj strukturę tabeli i ustaw domyślną wartość. Np. dla języka będzie to:

ALTER TABLE `pr_customer` CHANGE `id_lang` `id_lang` INT(10) UNSIGNED NULL DEFAULT '3';

 

Strukturę (domyślne dane dla kolumn) mozna łatwo modyfikować poprzez PhpMyAdmin

Przeniesienie haseł klientów

Tutaj dochodzi kwestia haseł. Jak widać w zapytaniu importu wyżej – dokładnie kopiujemy wartość hash haseł klientów. Możesz spróbować dodać ten sam „cookie_key” w pliku:

app/config/parameters.php

Co „_COOKIE_KEY_” w pliku:

config/settings.inc.php

Może to pozwolić na zachowanie tych samych haseł klientów. Jednak nie jest to pewne i całkiem możliwe że będą musieli oni sobie ustwić nowe hasła. Kwestia do sprawdzenia.

Ustawienie grupy klienta.

Większość klientów będzie w grupie „Klient”. W PS17 id tej grupy to 3. Aby to przypisać użyj:

UPDATE `pr_customer` SET id_default_group = 3;

 

Dodatkowo wypełnij tebelę:

TRUNCATE pr_customer_group;

ALTER TABLE `pr_customer_group` CHANGE `id_group` `id_group` INT(10) UNSIGNED NOT NULL DEFAULT '3';

INSERT INTO pr_customer_group (id_customer) SELECT (id_customer) FROM pr_customer;

 

W ten sposób wszyscy klienci będą klientami 🙂

Jeśli chcesz to rozgraniczyć na „gości” (w PS id tej grupy to domyślnie 2) to musisz odp. zmodyfikować te zapytania wg Twoich danych.

Przeniesienie kategorii

Ok jedziemy z asortymentem. To tak naprawdę podstawowe dane do przeniesienia.

Główna tabela kategorii:

TRUNCATE pr_category; 
INSERT INTO `pr_category`(
 
  `id_category` ,
  `id_parent` ,
  `level_depth` ,
  `nleft` ,
  `nright` ,
  `active` ,
  `date_add` ,
  `date_upd` ,
  `position` 
 
) SELECT 
 
  `id_category` ,
  `id_parent` ,
  `level_depth` ,
  `nleft` ,
  `nright` ,
  `active` ,
  `date_add` ,
  `date_upd` ,
  `position` 
 
FROM ps_category;

 

Grupy kategorii

TRUNCATE pr_category_group; 
INSERT INTO pr_category_group SELECT * FROM ps_category_group;

 

Tabele językowe kategorii:

TRUNCATE pr_category_lang; 

INSERT INTO pr_category_lang ( 

  `id_category` , 
 `id_lang` , 
 `name` , 
 `description` , 
 `link_rewrite` , 
 `meta_title` , 
 `meta_keywords` , 
 `meta_description` ) 

SELECT 

 `id_category` , 
 `id_lang` , 
 `name` , 
 `description` ,
 `link_rewrite` , 
 `meta_title` , 
 `meta_keywords` , 
 `meta_description` 

FROM ps_category_lang;

 

Tabela kategorii dla multistore.

Podobnie jak w przypadku produktów – patrz niżej po prostu ją sklonujemy narzucająć ID = 1 dla ID sklepu.

TRUNCATE pr_category_shop; 

INSERT INTO pr_category_shop ( 

  `id_category` , 
  `id_shop` , 
  `position`

) SELECT 

 `id_category` , 
 1 , 
 `position`

FROM pr_category;

 

Przeniesienie produktów.

Podstawowa tabela produktowa:

TRUNCATE pr_product;
INSERT INTO `pr_product`(
`id_product`	,
  `id_supplier`	,
  `id_manufacturer`	,
  `id_tax_rules_group`	,
  `id_category_default`	,
  `on_sale`	,
  `online_only`	,
  `ean13`	,
  `upc`	,
  `ecotax`	,
  `quantity`	,
  `minimal_quantity`	,
  `price`	,
  `wholesale_price`	,
  `unit_price_ratio`	,
  `additional_shipping_cost`	,
  `unity`	,
  `reference`	,
  `supplier_reference`	,
  `location`	,
  `width`	,
  `height`	,
  `depth`	,
  `weight`	,
  `out_of_stock`	,
  `quantity_discount`	,
  `customizable`	,
  `uploadable_files`	,
  `text_fields`	,
  `active`	,
  `available_for_order`	,
  `condition`	,
  `show_price`	,
  `indexed`	,
  `cache_is_pack`	,
  `cache_has_attachments`	,
  `cache_default_attribute`	,
  `date_add`	,
  `date_upd`
  ) 
SELECT 
  `id_product`	,
  `id_supplier`	,
  `id_manufacturer`	,
  `id_tax_rules_group`	,
  `id_category_default`	,
  `on_sale`	,
  `online_only`	,
  `ean13`	,
  `upc`	,
  `ecotax`	,
  `quantity`	,
  `minimal_quantity`	,
  `price`	,
  `wholesale_price`	,
  `unit_price_ratio`	,
  `additional_shipping_cost`	,
  `unity`	,
  `reference`	,
  `supplier_reference`	,
  `location`	,
  `width`	,
  `height`	,
  `depth`	,
  `weight`	,
  `out_of_stock`	,
  `quantity_discount`	,
  `customizable`	,
  `uploadable_files`	,
  `text_fields`	,
  `active`	,
  `available_for_order`	,
  `condition`	,
  `show_price`	,
  `indexed`	,
  `cache_is_pack`	,
  `cache_has_attachments`	,
  `cache_default_attribute`	,
  `date_add`	,
  `date_upd`	
FROM ps_product;

 

Tabela bliźniacza produktowa (w zależnośc od ID sklepu) dla multistore:

W PS14 nikt nawet nie marzył o multistore więc po prostu ją sklonujemy z ID sklepu = 1. 🙂

TRUNCATE pr_product_shop;
INSERT INTO `pr_product_shop`(

 `id_product`	,
 `id_shop`	,
  `id_category_default`	,
  `id_tax_rules_group`	,
  `on_sale`	,
  `online_only`	,
  `ecotax`	,
  `minimal_quantity`	,
  `low_stock_threshold`	,
  `low_stock_alert`	,
  `price`	,
  `wholesale_price`	,
  `unity`	,
  `unit_price_ratio`	,
  `additional_shipping_cost`	,
  `customizable`	,
  `uploadable_files`	,
  `text_fields`	,
  `active`	,
  `redirect_type`	,
  `id_type_redirected`	,
  `available_for_order`	,
  `available_date`	,
  `show_condition`	,
  `condition`	,
  `show_price`	,
  `indexed`	,
  `visibility`	,
  `cache_default_attribute`	,
  `advanced_stock_management`	,
  `date_add`	,
  `date_upd`	,
  `pack_stock_type`	

) SELECT 

 `id_product`	,
 1,
  `id_category_default`	,
  `id_tax_rules_group`	,
  `on_sale`	,
  `online_only`	,
  `ecotax`	,
  `minimal_quantity`	,
  `low_stock_threshold`	,
  `low_stock_alert`	,
  `price`	,
  `wholesale_price`	,
  `unity`	,
  `unit_price_ratio`	,
  `additional_shipping_cost`	,
  `customizable`	,
  `uploadable_files`	,
  `text_fields`	,
  `active`	,
  `redirect_type`	,
  `id_type_redirected`	,
  `available_for_order`	,
  `available_date`	,
  `show_condition`	,
  `condition`	,
  `show_price`	,
  `indexed`	,
  `visibility`	,
  `cache_default_attribute`	,
  `advanced_stock_management`	,
  `date_add`	,
  `date_upd`	,
  `pack_stock_type`	

FROM pr_product;

 

Tabela opisowa dla produktów:

TRUNCATE pr_product_lang;

INSERT INTO `pr_product_lang`(

   `id_product`,
  `id_lang`,
  `description`,
  `description_short`,
  `link_rewrite`,
  `meta_description`,
  `meta_keywords`,
  `meta_title`,
  `name`,
  `available_now`,
  `available_later`

) SELECT 

   `id_product`,
  `id_lang`,
  `description`,
  `description_short`,
  `link_rewrite`,
  `meta_description`,
  `meta_keywords`,
  `meta_title`,
  `name`,
  `available_now`,
  `available_later`

FROM ps_product_lang;

 

Powiązanie produktów z kategoriami:

TRUNCATE pr_category_product; 
INSERT INTO pr_category_product SELECT * FROM ps_category_product;

 

Przeniesienie cech produktów

Tutaj pomocny może być artykuł:

Przeniesienie cech produktów ze sklepu PrestaShop w wersji 1.4.x do 1.6.x lub 1.7.x

TRUNCATE pr_feature_product;
TRUNCATE pr_feature_value;
TRUNCATE pr_feature_value_lang;

INSERT INTO pr_feature_product SELECT * FROM ps_feature_product;
INSERT INTO pr_feature_value SELECT * FROM ps_feature_value;
INSERT INTO pr_feature_value_lang SELECT * FROM ps_feature_value_lang;

 

Tabele ze zdjęciami produktów – import

TRUNCATE pr_image;
INSERT INTO pr_image SELECT * FROM ps_image;

TRUNCATE pr_image_lang;
INSERT INTO pr_image_lang SELECT * FROM ps_image_lang;

ALTER TABLE `pr_image_shop` CHANGE `id_shop` `id_shop` INT(10) UNSIGNED NOT NULL DEFAULT '1'; 

TRUNCATE pr_image_shop;
INSERT INTO `pr_image_shop`(

  `id_image`	,
  `id_product`	,
  `cover`	

) SELECT 

  `id_image`	,
  `id_product`	,
  `cover`	

FROM pr_image;

 

Przeniesienie grup atrybutów.

Jest to najbardziej problematyczny element, jednak do zrobienia. Prosimy o zapoznanie się najpierw z artykułem gdzie to bardziej przybliżyliśmy:

przeniesienie kombinacji produktów ze sklepu w wersji 1.3-1.4 do 1.6.x [AKTUALIZACJA]

Należy tutaj uważać, ponieważ w wersji PS14 dane są nieco odmiennie składowane i często można natrafić na problemy. Szczególnie z duplikatami kluczy.

W każdym razie spróbuj zrealizować te polecenia celem importu danych.

Tabela łącząca produkty z atrybutami:

Przed importem jest konieczna modyfikacja struktury starej tabeli:

ALTER TABLE `ps_product_attribute` CHANGE `default_on` `default_on` TINYINT(1) UNSIGNED NULL DEFAULT '0'; 

UPDATE `ps_product_attribute` SET `default_on` = NULL WHERE `default_on` = 0;

 

Import:

TRUNCATE pr_product_attribute;

INSERT INTO `pr_product_attribute`(

   `id_product_attribute` 	,
  `id_product` 	,
  `reference` 	,
  `supplier_reference` 	,
  `location` 	,
  `ean13` 	,
  `upc` 	,
  `wholesale_price` 	,
  `price` 	,
  `ecotax` 	,
  `quantity` 	,
  `weight` 	,
  `unit_price_impact` 	,
  `default_on` 	,
  `minimal_quantity` 	

) SELECT 

     `id_product_attribute` 	,
  `id_product` 	,
  `reference` 	,
  `supplier_reference` 	,
  `location` 	,
  `ean13` 	,
  `upc` 	,
  `wholesale_price` 	,
  `price` 	,
  `ecotax` 	,
  `quantity` 	,
  `weight` 	,
  `unit_price_impact` 	,
  `default_on` 	,
  `minimal_quantity` 	

FROM ps_product_attribute ;

 

Tabela kombinacji atrybutów:

TRUNCATE pr_product_attribute_combination; 
INSERT INTO pr_product_attribute_combination SELECT * FROM ps_product_attribute_combination;

 

Tabela łącząca kombinacje z odp. zdjęciem:

TRUNCATE pr_product_attribute_image; 
INSERT INTO pr_product_attribute_image SELECT * FROM ps_product_attribute_image;

 

Tabela multistore dla atrybutów:

TRUNCATE pr_product_attribute_shop;
INSERT INTO `pr_product_attribute_shop` (

   `id_product`,
   `id_shop`,
   `id_product_attribute`,
   `wholesale_price`,
   `price`,
   `ecotax`,
   `weight`,
   `unit_price_impact`,
   `default_on`,
   `minimal_quantity`,
   `available_date`

) SELECT 

   `id_product`,
   1,
   `id_product_attribute`,
   `wholesale_price`,
   `price`,
   `ecotax`,
   `weight`,
   `unit_price_impact`,
   `default_on`,
   `minimal_quantity`,
   `available_date` 

FROM pr_product_attribute;

 

Uzupełnienie ilości.

Operuje tym tabela pr_stock_available (domyślnie ps_stock_available). Prezentujemy tutaj podstawowe wypełnienie tej tabeli.

TRUNCATE pr_stock_available;

INSERT INTO `pr_stock_available` ( 

`id_product`, 
`id_product_attribute`

) SELECT 

`id_product` , 
`id_product_attribute` 

FROM pr_product_attribute;

UPDATE `pr_stock_available` SET `id_shop` = 1, `quantity` = 100 WHERE `id_product_attribute` > 0 ;

 

Jednak konieczny jest skrypt PHP który poprawi spójność danych w tej tabeli. Tzn. samo zapisanie produktu w adminie to wykonuje, jednak tylko dla konkretnego produktu. Nasz skrypt – wykonuje to masowo:) Aby go użyć zapraszamy do artykułu:

Skrypt PHP to akutalizacji i przebudowy tabeli ps_stock_available [PrestaShop 1.7] [PrestaShop 1.6]

W razie problemów z którymś zapytaniem zapraszamy do kontaktu albo komentarzy.

W przypadku problemów z tym zagadnieniem zapraszamy do zapozniania się z ofertą:

grafika:wallpaperflare.com

  1. Łukasz Łukasz

    Z bazy danych PS1.6 przeniosłem wszystkie kategorie do bazy PS1.7

    Następnie zrobiłem to samo z produktami. Na stronie sklepu mam produkty dostępne natomiast nie są one widoczne w backoffice.

    Dodatkowo klikając „dodaj nowy produkt” przekierowuje mnie do głównej strony panelu administracyjnego.

    Co zrobiłem źle?

    • Admin Admin

      Najlepiej zakutalizuj PS16 do takiej samej wersji jak ten PS17 i przenieś wszystkie tabele produktowe ps_produkt* oraz te co łączą produkty z kategoriami. Dochodzi jeszcze tabela ps_stock_available. Ogólnie nie jest to łatwe zadanie..

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

Zobacz także !
Właśnie zmagasz się z formularzem kontaktowym, który nie działa w PrestaShop…