( Résolu ) Mise À Jour Génial Le Bouton !

[le-lutin31]

Tout le monde vante les belles avancées de la 1.4, j'ai donc fait une mise à jour classique.

 

de 1.3.7, je mets à jour en 1.4.4.1, impossible ! droit sur les images refusé.

 

Je vire tout et je recommence en mettant la version 1.4.4.0, finalisation erreur sql déjà signalé dans ce forum.

 

Back Office, super, front office page blanche !

 

Je change le .htaccess, je force la compilation, rien à faire, toujours une page blanche.

 

Je vois le bouton mise à jour et là, j'avoue avoir été soufflé ! je clique en moins d'une minute, ma boutique était à jour en version 1.4.4.1

 

Je ne sais absolument pas pourquoi, mais ensuite tout a fonctionné, l'erreur sql a été réparée.

 

Petit bémol les tables mysql pour la version 1.4.4.1 sont au nombre de 173 en version mise en ligne, avec la mise à jour, j'en ai 176 des anciennes tables de la 1.3.7 sont toujours là, d'où l'importance de mettre à jour en MylSAM, sinon on se retrouve avec 2 types de tables et on a une ERROR 500.

 

Attention aussi lors des mises à jour seuls les thèmes et modules natifs de Prestashop doivent être copiés et mis en ligne, sinon, c'est le bazar et y a plein d'erreurs.

 

Bref, je voulais dire un GRAND MERCI pour le bouton "Mise à jour" qui me rappelle le module de mise à jour de Jeckyl. À voir la démo du module de Jeckyl sur son site on pourrait croire que le bouton "mise à jour" est un clone, de son module.

 

Bref, cette version après amélioration pour faciliter la mise à jour est une réussite et c'est un outil performant pour les commerçants.

 

MERCI PRESTASHOP ET À TOUS CEUX QUI ONT TRAVAILLÉ POUR METTRE AU POINT ET CORRIGER CETTE VERSION.

[olea]

sinon on se retrouve avec 2 types de tables et on a une ERROR 500.

 

Ca pose problème de mixer les 2 types de tables dans une même base ?

[le-lutin31]

 

Ca pose problème de mixer les 2 types de tables dans une même base ?

Apparemment, j'ai lu que oui dans le forum. De part mon expérience sur mes tentatives de mises à jour, on a des erreurs, mais en plus il est impossible de mettre une base comme cela sauvegardée en back office sur le serveur car on a une erreur sql

[Patric]

Bonjour,

 

Content que cette fonctionnalité te plaise tant.

Je pense que tu n'es pas la seule à qui ça va rendre un grand service. Selon moi c'était l'une des principales lacunes de PrestaShop. A chaque nouvelle release, la Communauté regrettait son absence et j'avais beaucoup insisté pour qu'elle soit intégrée. J'ai été ravi d'apprendre que c'était chose faite.

[olea]

Cette fontion est effectivement pratique.

 

Toutefois, elle ne fait pas tout.

Avant l'upgrade, il faut s'assurer :

1/ qu'on a/aura un thème compatible avec la nouvelle version (sinon, certaines fonctionnalités se comporteront bizarrement)

2/ que les modules non natives sont compatibles également avec la nouvelle version, voir même qu'ils disposent eux-même d'une procédure d'upgrade.

3/ au passage, certaines fonctions de Presta ne sont pas identiques entre 2 versions, ca peut poser problème également (cf PSCFI-3006)

4/ pour le backup, bien faire attention que ce qui s'est passé entre l'upgrade et le backup (nouveaux clients.nouvelles commandes) sont perdus au backup.

 

 

Donc fonction bien pratique, mais bien analyser ce qu'elle implique avant de l'utiliser (et surtout faire des sauvegarde)

[Asenar]

Bonjour,

 

Bravo pour avoir réussi à mettre à jour de la version 1.3.7 via l'onglet autoupgrade, je savais même pas que c'était possible !

 

Il y a quand même encore un tas de petites corrections à faire : sur certaines configuration serveur une fonction n'existe pas et nous n'avons pas pensé à la gérer, on ne peut pas choisir de "laisser les modules activés", et quelques autres détails...

 

Le fait de mixer les deux types de table, ça m'étonne que des problèmes se posent car prestashop n'utilise pas (aujourd'hui en tout cas) les fonctionnalités de innoDb (contraintes de clefs étrangères, etc.), tu aurais le lien de là où tu as lu ça ? De quelle erreur sql parle-t-on ?

 

Pour répondre à Olea,

1° Nous tentons d'être toujours rétrocompatible pendant le changement de version vers une version mineure (et majeure aussi) : il y a eu un loupé en 1.4.3 pour les adresses, on sera plus minutieux sur les prochaines releases.

2° upgrade module prévue en 1.5, sinon oui je suis tout à fait d'accord avec toi

3° La fonction autoupgrade native se transformera en module en 1.4.5 (et le module sera utilisable en 1.3.x, peut être même version précédente)

4° évidemment. Il faudrait penser à des options pour exclure (ou protéger) au moins peut être les données ps_employee et ps_access (ou au moins les mot de passe, mais ça me semble tout de même très compliqué à faire). Pour les clients/commandes c'est à voir mais c'set plutôt complexe (et si y'a des nouveaux produits qui disparaissent avec la restauration ? faudrait rajouter les tables produits, donc catégories, donc etc. etc.)

[olea]

1° Nous tentons d'être toujours rétrocompatible pendant le changement de version vers une version mineure (et majeure aussi) : il y a eu un loupé en 1.4.3 pour les adresses, on sera plus minutieux sur les prochaines releases.

 

Hormis les adresses, les thèmes 1.4 apportaient des fonctionnalités non supportées par les thèmes 1.3, ne serait-ce que dans la gestion de l'affichage des prix :

- le mode catalogue

- les prix par unités

Un thème 1.3 peut à peu près être utilisé sur 1.4, mais le front ne se comportera pas forcément tel que la config le voudrait (je ne parle même pas du CCC)

 

La gestion des remises et des remises par quantité est différents entre 1.3 et 1.4 (gestion des specificPrices) : je n'ai pas testé comment se comporte un thème 1.3 sur 1.4 concernant ce point-là, mais potentiels problèmes à ce niveau.