Jump to content

Recherche Personne Pour Debugguer Site En 1.4 Depuis Le Passage En Php 5.6 + Devis


Recommended Posts

Bonjour,

 

 

Depuis quelques jours, plein de petits bugs sont apparus sur mon site qui tourne sous prestashop 1.4 et qui est hébergé chez OVH.

 

Peut être dû au fait que petit à petit OVH ne prend plus en charge les anciennes version de PHP ?

 

(authentification impossible en front office, problème de filtre dans l'administration ...)

 

 

Je recherche une personne ayant de bonnes compétences pour regarder mon site et essayer de le débugguer, nous pouvons le rémunérer. Si cette personne peut aussi nous faire un devis si elle est capable de le faire migrer sur une version plus récente de prestashop ?

 

Merci d'avance

  • Like 1
Link to comment
Share on other sites

Pour le filtre en admin j'ai réussi à corriger le probleme avec la méthode suivante : https://www.prestashop.com/forums/topic/94299-resolu-502-bad-gateway-sur-la-pagination-produits-back-office/

 

Par contre le plus inquiétant c'est le problème d'authentification en front office, plus aucun client ne peut passer commande et je sèche je ne trouve pas le bug :( Besoin d'aide SVP !

Link to comment
Share on other sites

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /home/meublesl/www/classes/MySQL.php on line 34

Warning: Cannot modify header information - headers already sent by (output started at /home/meublesl/www/classes/MySQL.php:34) in /home/meublesl/www/controllers/ParentOrderController.php on line 43

Warning: Cannot modify header information - headers already sent by (output started at /home/meublesl/www/classes/MySQL.php:34) in /home/meublesl/www/controllers/ParentOrderController.php on line 44

Warning: Cannot modify header information - headers already sent by (output started at /home/meublesl/www/classes/MySQL.php:34) in /home/meublesl/www/classes/Tools.php on line 74

Link to comment
Share on other sites

Merci @Webbax

Nous avions des erreurs type "502 bad gateway" ou affichage d'une page blanche "(null)" depuis quelques jours sur une 1.4.6.2 (OVH) sur certaines pages du B.O. (paniers, clients...) et même en FO l'impossibilité pour un client de se connecter à son compte. La version PHP a été mise à jour sur la plus récente (5.6) mais cela ne suffisait pas à résoudre le problème.

L'ajout de:  

echo '';//  

derrière la ligne 

foreach ($_POST AS $key => $value) 

(ligne 84, chez nous, de index.php du répertoire admin)

a corrigé les problèmes rencontrés.

 
@wiso88, tu devrais essayer puisque ça fonctionne sur notre boutique en 1.4.6.2
Pour ce qui est des upgrade vers des versions plus récentes, j'ai fait un long post quelque part sur le forum à ce sujet.
Une migration est très complexe car il faudra surement la faire par paliers, sur la dernière 1.4 puis la première 1.5 et ainsi de suite.
Et encore en désactivant, désinstallant les modules et thèmes non natifs.
J'ai une 1.5.6.2 qui était en 1.4.6.2 migré en 3 étapes.
Par contre, sur une 1.5.6.2 on a tenté un up vers la 1.6.1 sans succès... pour l'instant. 
Link to comment
Share on other sites

Bonjour,

 

Je vous invite à :

Désactiver le mode dev dans defines.inc.php : define('_PS_MODE_DEV_', false);
 

Mais surtout dans le fichier config.inc.php

@ini_set('display_errors', 'off');
define('_PS_DEBUG_SQL_', false);

Le moindre message d'erreur au mauvais endroit (au moment du header) peut casser l'identification.

Cette manipulation peut résoudre le problème. Si ce n'est pas le cas, le soucis est plus "important".

 

Merci pour le lien   wiso88  

 

 

 problème Authentification >> Bienvenue, IDENTIFIEZ-VOUS  affiche une page blanche (null)

ensuite j ai essayer dans la page récapitulatif d une commande déja inscrit ?

 cela me bloque TOUT et affiche une Erreur 

mini_406549ERREUR01.jpg

Link to comment
Share on other sites

Perso je soupçonne plus un module.

J'ai de nombreuses versions installées sur un php 5.6, de la 1.3 à la 1.6.1.4 et toutes fonctionnent. Les 1.3 et 1.4 me pètent des warning et deprecated, pas méchants à corriger et qui, en aucun cas ne font planter le site.

Avez-vous un fichier .ovhconfig à la racine de votre site ? Le phpcgi peut aussi être responsable, car {null}, ce n'est pas du php mais une bouze serveur...

Link to comment
Share on other sites

Généralement oui, les warnings et deprecated ne sont pas gênants.

Ceci dit s'ils interviennent (quels qu'ils soient) avant la création/récupération du cookie, header cassé => kaboom

Ce qui doit être le cas quand c'est au mysql_connect.

 

Perso je soupçonne plus un module.

J'ai de nombreuses versions installées sur un php 5.6, de la 1.3 à la 1.6.1.4 et toutes fonctionnent. Les 1.3 et 1.4 me pètent des warning et deprecated, pas méchants à corriger et qui, en aucun cas ne font planter le site.

Avez-vous un fichier .ovhconfig à la racine de votre site ? Le phpcgi peut aussi être responsable, car {null}, ce n'est pas du php mais une bouze serveur...

Link to comment
Share on other sites

Avez-vous un fichier .ovhconfig à la racine de votre site ? Le phpcgi peut aussi être responsable, car {null}, ce n'est pas du php mais une bouze serveur...

Pour compléter mon précédent post, effectivement, dans notre cas, on a aussi modifié le fichier .ovhconfig comme suit:

app.engine=php
app.engine.version=5.6
http.firewall=none
environment=development

{null} indique effectivement une erreur, temps d'accès (?) trop long, au serveur.

Edited by unanim (see edit history)
Link to comment
Share on other sites

@Eolia, comme le précise Mediacom87, ce fichier se modifie d'abord via votre interface de gestion OVH comme indiqué dans l'aide OVH.

Avec comme pré-requis la modification de votre version PHP depuis la même interface.

 

Après, il est bien sûr possible via votre FTP de récupérer le fichier .ovhconfig et de l'éditer avec le blocnote pour le modifier.
Comme on le ferait avec n'importe quel fichier .php de Prestashop.
Il suffit de renommer l'original en .bak, modifier, enregistrer avec le nom original et le re-balancer via FTP.
Vous testez et si cela ne va pas, vous remettez l'original avec son nom d'origine.

NB: En ce qui concerne les boutiques dont j'ai la charge, on a choisit 

environment=development

au lieu de
 

environment=production

modifié, donc après coup, manuellement; afin que d'éventuelles erreurs apparaissent directement sur le site. Tant pis si côté client, il peut apparaître une page blanche avec message d'erreur, car ceux qui travaillent dessus en permanence les voient et me font remonter les infos instantanément.

Link to comment
Share on other sites

Bonjour,

 

Je vous invite à :

 

Désactiver le mode dev dans defines.inc.php : define('_PS_MODE_DEV_', false);

 

Mais surtout dans le fichier config.inc.php

@ini_set('display_errors', 'off');

define('_PS_DEBUG_SQL_', false);

Le moindre message d'erreur au mauvais endroit (au moment du header) peut casser l'identification.

 

Cette manipulation peut résoudre le problème. Si ce n'est pas le cas, le soucis est plus "important".

 

 

Merci à toi ! Effectivement avec le passage sur une nouvelle version de PHP sur OVH, de nouveaux messages de warning apparaissent et ça fait planter l'authentification et plusieurs autres bugs. En enlevant ces messages, plus de problèmes !

Link to comment
Share on other sites

Merci à toi ! Effectivement avec le passage sur une nouvelle version de PHP sur OVH, de nouveaux messages de warning apparaissent et ça fait planter l'authentification et plusieurs autres bugs. En enlevant ces messages, plus de problèmes !

 

De rien, content que ça remarche et de pouvoir aider.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...