Necesitas mi libro "Claves para abrir una tienda online y que venda" y lo sabes...




Cómo actualizar de Prestashop 1.6 a Prestashop 1.7

Aunque hay algún módulo como este  o servicios como Prestashopmanager, para importar datos y migrar una tienda Prestashop versión 1.6 a la nueva versión 1.7, si no tenemos presupuesto o nuestra tienda es muy grande (el módulo se quedará "colgado" en el proceso de traspaso), tendremos que plantearnos una actualización manual.

Esta actualización pasa por importar los datos de la base de datos actual de la 1.6 a la nuevas base de datos de la 1.7, que independientemente de que use nuevas tablas, las habituales relacionadas con productos, pedidos y clientes, al igual que en cambios de versiones anteriores siempre tienen algún cambio respecto a la otra versión (cambio de nombre de campo, sus propiedades y la inclusión de nuevos campos).

Esta propuesta de actualización manual a Prestashop 1.7 no considera los cambios en archivos y directorios, código fuente y por supuesto plantillas y módulos, estos últimos en su mayoría no serán compatibles con la nueva versión e implica una revisión o actualización de cada elemento, al igual que en la propuesta de Prestashop para la de actualización, sólo se tratan los datos:

"the template system has been rewritten, so your theme will either have to be changed or entirely rewritten. Additionally, your modules will need to be carefully examined and likely adapted, at least in terms of design"

"Take note that this module will only deal with your store’s data. The theme and modules will be those used by default, and your theme from version 1.5/1.6 will be deactivated, as will all of your third-party modules"

Fuente:https://www.prestashop.com/blog/en/prestashop-1-7-answers-questions/)
El objetivo de este artículo se centra en traspasar los datos del catálogo, clientes y pedidos a una nueva instalación de Prestashop 1.7 (una vez tengamos estos datos importados -lo más importante- ya tendremos tiempo de valorar las implicaciones de cambiar o actualizar la anterior plantilla, módulos que usábamos, etc.).

Los pasos para esta actualización o migración de DATOS a Prestashop 1.7 serían:


1) Realizar una nueva instalación de Prestashop 1.7

2) Hacer copia de las tablas actuales de PS 1.6 relacionadas con PRODUCTOS, CLIENTES y PEDIDOS (ej: ps_product_17)

3) Añadir modificaciones a esas tablas para que tengan la misma estructura que PS 1.7 (detalle modificaciones abajo)

Opción 1:
4) Exportar en sql los datos de esas tablas originalmente de 1.6 ahora modificadas para la 1.7 con los datos
5) Insertar datos anteriores en tablas de PS 1.7

Opción 2 (sólo si estamos trabajando en la misma bbdd):
4) Renombrar tablas originales de PS 1.7 (ej: ps_product_ORIGINAL) 
5) Renombrar tablas modificadas de la 1.6 a las tablas originales de PS 1.7 (ej: ps_product_17 a ps_product)

6) Comprobar funcionamiento tienda y acceso a los datos

7) Copiar carpeta imágenes de productos "img/p" de instalación PS 1.6. a directorio instalación PS 1.7





Los archivos SQL de instalación de las respectivas versiones que he tomado como referencia para comparar las versiones de las tablas puedes descargarlos en: https://goo.gl/bthjNJ

Por cierto, ¿te he dicho ya que mi libro sigue de los más vendidos en Amazon?


Modificaciones a realizar en las tablas que se usarán para los datos en PS 1.7


NOTA: Las instrucciones sql las he detallado sólo para la primera tabla "_product" y son orientativas, el nombre de la tabla y/o su prefijo puede variar en cada caso. Tomando como referencia la sintaxis para añadir y renombrar campos se pueden elaborar el resto de sqls.

PRODUCTOS

TABLA "_product"

Nuevo campo isbn (despues de ean13):
ALTER TABLE `_product` ADD `isbn` varchar(13) DEFAULT NULL AFTER ean13
Nuevo campo show_condition (despues de available_date):
ALTER TABLE `_product` ADD `show_condition` tinyint(1) NOT NULL DEFAULT '0' AFTER available_date
Nuevo campo  state (final de tabla):
ALTER TABLE `_product` ADD `state` int(11) unsigned NOT NULL DEFAULT '1'
Campo renombrado id_product_redirected (ahora es `id_type_redirected`):
ALTER TABLE `_product` CHANGE `id_product_redirected` `id_type_redirected` int(10);

TABLA "_product_shop"

Nuevo campo (despues de available_date):
`show_condition` tinyint(1) NOT NULL DEFAULT '0',

Campo renombrado:
"id_product_redirected" ahora es `id_type_redirected`

TABLA "_product_attribute"

Nuevo campo (despues de ean13):
`isbn` varchar(13) DEFAULT NULL,

TABLA "_product_attribute_shop"

Nuevo campo al inicio:
`id_product` int(10) unsigned NOT NULL,

Nuevas claves únicas:
UNIQUE KEY `id_product` (`id_product`, `id_shop`, `default_on`)
TABLA "_product_download"

UNIQUE KEY `id_product` (`id_product`)

TABLA "_product_tag"

Nuevo campo (al final de la tabla):
`id_lang` int(10) unsigned NOT NULL,

Nueva clave:
KEY `id_lang` (`id_lang`,`id_tag`)


TABLA "_specific_price"

KEY `id_product_attribute` (`id_product_attribute`),
KEY `id_shop` (`id_shop`),
KEY `id_customer`(`id_customer`),
KEY `from` (`from`),
KEY `to` (`to`),
UNIQUE KEY `id_product_2` (`id_product`,`id_product_attribute`,`id_customer`,`id_cart`,`from`,`to`,`id_shop`,`id_shop_group`,`id_currency`,`id_country`,`id_group`,`from_quantity`,`id_specific_price_rule`)

TABLA "_image_shop"

Nuevo campo (al inicio de la tabla):
`id_product` int(10) unsigned NOT NULL,

Claves:
PRIMARY KEY (`id_image`, `id_shop`),
UNIQUE KEY `id_product` (`id_product`, `id_shop`, `cover`),
KEY `id_shop` (`id_shop`)

TABLA "_category"

Claves:
KEY `category_parent` (`id_parent`),
KEY `nleftrightactive` (`nleft`, `nright`, `active`),
KEY `level_depth`(`level_depth`),
KEY `nright` (`nright`),
KEY `activenleft` (`active`,`nleft`),
KEY `activenright`(`active`,`nright`)

CLIENTES

TABLA "_customer"

Cambio longitud campo de 32 a 60:
`passwd` varchar(60) NOT NULL,

Nuevos campos (al final de la tabla):
`reset_password_token` varchar(40) DEFAULT NULL,
`reset_password_validity` datetime DEFAULT NULL,

PEDIDOS

TABLA "_orders"

Nuevo campo (despues de round_mode):
`round_type` tinyint(1) NOT NULL DEFAULT '1',

TABLA "_order_invoice"

Nuevo campo (despues de total_wrapping_tax_inc):
`shop_address` text DEFAULT NULL,

Cambio campos decimales de (17,2) a (20,6)

TABLA "_order_detail"

Nuevo campo (despues de product_attribute_id):
`id_customization` int(10) unsigned DEFAULT 0,

Nuevo campo (despues de ean13):
`product_isbn` varchar(13) DEFAULT NULL,

Nuevo campo (al final de la tabla):
`original_wholesale_price` DECIMAL(20, 6) NOT NULL DEFAULT '0.000000',

15 comentarios:

  1. BBDD Prestashop 1.6: http://www.filedropper.com/dbstructure16
    BBDD Prestashop 1.7: http://www.filedropper.com/dbstructure17

    not found


    Lo mejor de Prestashop ? los mejores recursos sobre Prestashop ?

    ResponderEliminar
  2. Tu nick te hace justicia jajajaja. Gracias por el apunte, los enlaces caducan... cosas que pasan pero lo he subido ahora a Google Drive para que no haya quejas de nadie más :)

    He actualizado el enlace en el post y aquí lo tienes: https://goo.gl/bthjNJ

    Saludos.

    ResponderEliminar
  3. Hola,

    Llevo un mes intentando actualizar una web con ps 1.4 y lo primero que pensé fue actualizar a 1.7, pero lo descarté porque no hay módulo one-click hacia esta versión, y probé con una versión beta que no me funcionó.

    Entonces lo primero que hice fue actualizar a prestashop 1.6, y todo bien salvo que todas las versiones 1.6 muestran MAL el precio en la ficha de producto cuando hay combinaciones y descuentos por cantidad.

    Por tanto, y visto que sólo se puede solucionar poniendo otra plantilla (el problema está en product.tpl y no se sabe aún ahora cómo solucionarlo), antes de ello decidí probar otra vez actualizando a 1.7, vía instalación limpia e importando las tablas correspondientes, siguiendo este tutorial, que es el único que encontré. Antes de nada, pude comprobar que el theme "classic" funciona bien con los precios por cantidad y las combinaciones (o atributos), así que seguí adelante.

    He seguido el tutorial al pie de la letra, y he observado que la TABLA "_product_attribute_shop" no necesita ser modificada (en 1.6 está igual), y que sin embargo, todos los campos referidos en el tutorial sobre esa tabla están en realidad en la de "_product_attribute", la cual sólo necesita añadir el campo "isbn" y no se si algún otro más.

    En el resto de los aspectos, el tutorial coincide al 100% con lo que me encuentro, así que todo perfecto.

    El segundo problema lo tuve a la hora de exportar los cambios en la base de datos ps 1.6 (la versión previamente actualizada de mi ps 1.4), e importarlos en la bd de ps 1.7

    El problema es que hay que borrar en ps 1.7 todas las tablas que se vayan a importar, pues de otro modo da errores luego al importarla.

    Pero el verdadero problema, el que quiero consultar, es el que tengo ahora: NO aparecen las categorías. Las tablas de categoría se importaron correctamente, tienen sus datos, incluso el Backoffice me dice que hay 36 categorías inactivas y que la "mejor" categoría es tal, pero la lista aparece vacía. Todos los productos, en la vista de productos, aparecen con el nombre de su categoría principal, pero al abrir cualquier producto en el BO no aparecen las categorías y al intentar desplegarlas no aparece ninguna.

    ¿Qué puede estar pasando?

    Pensaba que el problema era el "id_lang", puesto que el español en mi prestashop 1.6 era el id 3, y en el nuevo prestashop 1.7 es el id 1, he probado a editar todas las tablas que refieren al id lang número 3 y lo he cambiado por el número 1, pero el resultado sigue siendo el mismo, todo se importó correctamente pero las categorías no me aparecen.

    Gracias por su atención y perdonad por el tocho, pero estoy pensando en volver a borrar todo y reintentar con el módulo one-click beta.... O eso o tratar de importar las categorías vía CSV (si consigo exportarlas de alguna manera compatible con el importador nativo de prestashop vía CSV...)

    ResponderEliminar
  4. Actualización: Las categorías ¡Han aparecido! Están en el front office, puedo configurarlas en el módulo de menú principal, y en un producto, puedo buscarlas, aparecen y las puedo asignar....


    ...Pero, NO aparecen en la lista de categorías del BackOffice, ni tampoco al ver cualquier producto desde el mismo BO aparecen sus categorías ni se pueden desplegar las categorías que hay...

    ¿Qué tabla controla esto? ¿Cómo es posible que las categorías estén ahí pero no salgan en el apartado correspondiente del backoffice?

    ResponderEliminar
  5. Por cierto, y por último, los productos salen en la URL con doble id separada por un guion, la primera es su ID normal, la segunda no se de donde sale, pero el caso es que si no pones los dos números en la URL sale un error 404...

    ResponderEliminar
  6. Hola Felipe, gracias por tus comentarios. Migración de 1.4 a 1.7... enhorabuena!

    Respecto a las categorías, no se muestran en el backoffice porque faltará regenerar el árbol.
    Échale un vistazo a este post donde traté ese tema:
    http://abrasutiendaeninternet.blogspot.com/2015/05/organizacion-de-las-categorias-en.html

    Saludos.

    ResponderEliminar
  7. Muchas gracias!

    Lo de la migración de 1.4 a 1.7 no tiene tanto mérito, jeje, actualicé con one-click a 1.6 y todo perfecto, y luego usé la base de datos de 1.6 para el proceso de migración desde una instalación limpia de 1.7

    He probado a crear una categoría nueva desde el BO y ahora aparecen todas en el propio BO (en el front ya aparecían antes) pero si borro o simplemente desactivo esa categoría, vuelven a desaparecer todas... ¡No entiendo nada! En fin, seguiré investigando.

    Tampoco entiendo por qué me genera unos ID de categoría tan grandes (de siete cifras), es un problema que llevo arrastrado desde la 1.4 y no se cómo solucionar... Pero bueno, normalmente lo que hago es importarlas desde CSV y así van con el ID que yo quiero, así que eso no es problema.

    Lo que me mosquea es lo de la doble ID de los productos, cuando uno ponía www.dominio.com/categoria/21-producto ahora pone www.dominio.com/categoria/21-34-producto ¿¿¿¿????? ¿Qué es ese segundo ID?

    ResponderEliminar
  8. Finalmente tengo que volver a probar con prestashop 1.6 + una plantilla de pago.
    En prestashop 1.7 hay un error fatal sin solución: Han cambiado la reescritura de las URL amigables, eso invalida cualquier migración, salvo que en la web anterior no hubiera números de ID y se use un módulo para quitarlos. Pero en mi caso, tengo todas las url con el ID de producto, y ahora PS 1.7 se empeña en llenar la URL de más IDs obligatorias.
    En prestashop 1.6 hay un bug con la plantilla por defecto, pero que se salvará con otra plantilla...
    Un saludo.

    ResponderEliminar
  9. Hola Felipe,

    El segundo número tiene que ser el ean13. Échale un vistazo a la documentación sobre las URLs amigables:
    http://doc.prestashop.com/display/PS17/SEO+and+URLs

    Saludos.

    ResponderEliminar
  10. No, es el campo {-:id_product_attribute} y es obligatorio, por lo que no se puede quitar.

    Menudo chasco que en prestashop no piensen en el desastre que es que una actualización te cambie todas las URL con respecto a las que ya están indexadas en google...

    En este hilo hablan de este problema, y por lo visto, es parte del diseño de PS 1.7: https://www.prestashop.com/forums/topic/554789-how-to-remove-id_product_attribute-from-product-links/?page=2

    Voy a comprobar que con 1.6 no pasa lo mismo porque si ocurre igual, tendré que cambiar definitivamente de plataforma. Porque lo que no es normal, es tener que hacer redirecciones para todos los productos como consecuencia de un cambio de versión...

    ResponderEliminar
  11. He comprobado en la documentación de PS 1.6 que en esta versión no pasa, así que estudiaré si volver a 1.6

    http://doc.prestashop.com/display/PS16/Preferencias+SEO+y+URLs

    Como podrás ver, aquí no está el campo id_product_attribute, mientras que aquí:

    http://doc.prestashop.com/display/PS17/SEO+and+URLs

    Sí que está y es obligatorio, por lo que todas las URL de productos se ven afectadas con el cambio a PS 1.7 y son cambiadas.

    ResponderEliminar
    Respuestas
    1. Sí, efectivamente es el id_product_attribute.
      Y desde luego es una faena respecto al SEO si tienes indexadas y bien posicionadas las anteriores URLs de productos.
      Creo que la solución pasaría por probar algún módulo específico de escritura de URLs que sobreescriba ese requisito de parámetro obligatorio aunque también tengo mis reservas porque he leído que la función es que cada combinación de artículo tenga una URL única (si tu tienda no trabaja con combinaciones, sería una opción a valorar).

      Gracias por compartir tu experiencia.

      Saludos.

      Eliminar
  12. Mi tienda trabaja con combinaciones en todos los productos... Lo dicho, mis opciones son trabajar en 1.6 y explorar opciones de migrar en el futuro a woocommerce por ejemplo.

    ResponderEliminar
  13. Bueno, estoy en la tarea de ejecutar este valioso instructivo.
    Debo aportar por ahora que también se debe modificar
    en la tabla: ps_address la longitud de estos campos, ademas de tenerla encuenta para pasar la data luego al PS-17.
    `lastname` varchar(255) NOT NULL,
    `firstname` varchar(255) NOT NULL,

    ResponderEliminar