How to migrate PrestaShop 1.6 to PrestaShop 1.7? Part 2

Refreshing the information

Get changes among source and objective data sets

Presently you have recovered your information from the creation shop, you need to adjust it to the new design prior to embeddings it on your new data set.

An effective method to get the progressions is getting a data set design diff between the 2 running shops. MySQL gives another device to this called mysqldiff.

Note this utility might be not quickly accessible on your current circumstance, regardless of whether you have the mysql customer introduced. For example on Ubuntu, an extra bundle should be introduced:

apt install mysql-utilities

This device can be run anyplace, as long as you can get to the two workers and data sets. The essential utilization of this order requires the accompanying boundaries:

mysqldiff --server1=user:pass@host:port:socket --server2=user:pass@host:port:socket db3:db4

You need to give the qualifications to your MySQL servers. In case the source and the objective information bases are on a similar worker, the –server2 boundary can be excluded. db3 and db4 are individually the source and the objective data sets of your information.

Getting the construction diff will require extra choices, as given in this model:

mysqldiff --server1=root:[email protected]:3307 --changes-for=server1 --skip-table-options --force prestashop16:prestashop

• Every one of our information bases are on a similar worker, that is the reason just –server1 is given,
• We need to realize what are the progressions to apply on the 1.6 variant to fit the 1.7 design, so we need –changes-for=server1
• We just need structure changes. –skip-table-choices eliminates diff about autoincrement and so forth
• Of course mysqldiff will just reveal to you the information bases are not the equivalent and will return right away. Giving –force will make the device print out insights concerning the distinctions found.

An illustration of yield is accessible in https://gist.github.com/Quetzacoalt91/9cef61ebbf12c139f44d27035d3cb1fd. The progressions are removed from a diff structure between a PrestaShop 1.6.1.18 data set and another under PrestaShop 1.7.3.2.

It seems the design from PrestaShop has not radically changed from 1.6 renditions, albeit a few sections type has advanced. Setting up your information for PrestaShop 1.7 ought not need an excessive number of changes on your CSV records.

Applying structure change

This progression must be imitated however many occasions as you have tables standing by to be moved. The import step will be simpler in the event that you ensure the information you move fits the objective construction. This part will assist with recognizing the progressions to apply contingent upon the diff made during the past advance.

A couple of notes:

• Not all distinctions require an adjustment in your information,
• Fundamental changes should be possible utilizing accounting page proofreader,
• Complex alterations will require manual work.

New segment

Any new segment added to the data set requires a similar work on your CSV record. Keep an eye on the new shop what default esteem applies to the new section, by checking in the accompanying request:

• The information base mapping,
• The ObjectModel (organizer classes of PrestaShop),
• The Entity (organizer src/PrestaShopBundle/Entity).

Model with the table truck:

--- `prestashop16`.`ps_cart`
+++ `prestashop`.`ps_cart`
@@ -18,6 +18,7 @@
`allow_seperated_package` tinyint(1) unsigned NOT NULL DEFAULT '0',
`date_add` datetime NOT NULL,
`date_upd` datetime NOT NULL,
+ `checkout_session_data` mediumtext,
[...]

Before:

CSV table before column addition

After:

CSV table after column addition

In this model the new segment checkout_session_data has no default esteem and the current information on our PrestaShop shows an unfilled section. As the section permits invalid qualities, we keep all lines vacant.

Section has a similar kind, yet not a similar size

Model with address:

- `lastname` varchar(32) NOT NULL,
+ `lastname` varchar(255) NOT NULL,

On the off chance that a segment keeps its sort yet just builds its size, it doesn’t need any change on your side. The new form offers more space to your content prior to being shortened.

You will most likely notification similar change on your table keys:

- `id_attribute_group` int(10) unsigned NOT NULL,
+ `id_attribute_group` int(11) NOT NULL,

This change doesn’t infer anything on your side. This is a primer work for building relations between our tables.

Section eliminated

This sort of progress is simpler than adding a segment.

- `scenes` tinyint(1) NOT NULL DEFAULT '1',

Open the connected CSV, eliminate the section and save.

Anyway remember sometimes the section may have been moved to another table. On the off chance that this happens, you should move the substance of your section to another CSV.

A model is accessible for the table store, a few sections have been moved to the table store_lang to permit limited information to be utilized. Information should be moved to another CSV, and copied however many time as you have dialects introduced on your shop.

Default esteem vanished

- `position` int(10) unsigned NOT NULL DEFAULT '0',
+ `position` int(11) NOT NULL,

Here once more, nothing to stress over, as there is no change required on your information. The default esteem is currently overseen by the ORM. Be that as it may, if the past rendition didn’t show NOT NULL, this could expect you to add a default esteem on the unfilled columns.

Essential key/special list refreshes

On the off chance that the essential key or one extraordinary key on a table advances/is added, the import of your current information can fall flat on the off chance that it doesn’t regard the new unicity rules.

- PRIMARY KEY (`id_feature`,`id_product`),
+ PRIMARY KEY (`id_feature`,`id_product`,`id_feature_value`),

+ UNIQUE KEY `name_UNIQUE` (`name`),

In the event that you see this sort of diff, watch that you don’t have similar gathering of qualities more than once. Is bound to occur if a segment is eliminated from a section bunch, or if a key is added.

Redirection for debilitated items

This change is explicit to the table item.

- `redirect_type` enum('','404','301','302') NOT NULL DEFAULT '',
- `id_product_redirected` int(10) unsigned NOT NULL DEFAULT '0',
+ `redirect_type` enum('','404','301-product','302-product','301-category','302-category') NOT NULL DEFAULT '',
+ `id_type_redirected` int(10) unsigned NOT NULL DEFAULT '0',

At the point when an item is debilitated, the dealer can decide to which other page clients will be diverted to in the event that they attempt to get to it. On PrestaShop 1.7 the quantity of alternatives has expanded, and a redirection to a classification page is presently conceivable.

For information coming from PrestaShop 1.6, existing redirections should be refreshed.

• Column table redirect_type:

Old meaning: 301
New meaning: 301-product

Old meaning: 302
New meaning: 302-product

• Column id_product_redirected: Name is now id_type_redirected

On the off chance that you traded your information in CSV, doing this change will be simple with an accounting page manager, as Microsoft Excel or LibreOffice Calc. Simply try to keep a similar document augmentation while saving.

Much of PrestaShop materials is our WIKI: https://softsprint.net/wiki/

Here is a model when the mentioned update (changes show up in green).

Before (Original position):

After position:

Shop subtleties

You will see that in the shop table the segment id_theme has been supplanted by theme_name. PrestaShop doesn’t store information about topic in devoted tables any longer. The lone data remaining is the topic name utilized by each shop.

As relocating to PrestaShop 1.7 infers losing the subject utilized on the shop underway, simply state “exemplary” in this segment for each shop.

Previously:

After:

Here you can read the 1st part of the article: https://softsprint.net/2021/03/16/how-to-migrate-prestashop-1-6-to-prestashop-1-7-part-1/

In case you’d like to buy an original PrestaShop addon or get the professional support, follow our partner’s site: https://prestashop.support