rom1 Posted June 8, 2015 Share Posted June 8, 2015 La mise à jour d'un catalogue 1.1.0.5 vers 1.6.0.9, après avoir généré de multiples erreurs sql, m'affiche à la première connexion à l'admin l'erreur suivante : [PrestaShopException] get list params is not valid at line 2689 in file classes/controller/AdminController.php correspondant au code 2683. 2684. /* Check params validity */ 2685. if (!Validate::isOrderBy($order_by) || !Validate::isOrderWay($order_way) 2686. || !is_numeric($start) || !is_numeric($limit) 2687. || !Validate::isUnsignedId($id_lang)) 2688. throw new PrestaShopException('get list params is not valid'); 2689. 2690. if (!isset($this->fields_list[$order_by]['order_key']) && isset($this->fields_list[$order_by]['filter_key'])) 2691. $this->fields_list[$order_by]['order_key'] = $this->fields_list[$order_by]['filter_key']; 2692. 2693. if (isset($this->fields_list[$order_by]) && isset($this->fields_list[$order_by]['order_key'])) Évidemment je n'ai pas accès au formulaire de connexion, cette erreur apparaissant avant. L'erreur semble provenir de id_lang qui serait vide donc invalide. Les deux appels à la méthode dans ce script transmettent $this->context->language->id comme valeur. La langue du contexte semble donc non définie. Comment remédier à cela ? Link to comment Share on other sites More sharing options...
Olivier CLEMENCE Posted June 8, 2015 Share Posted June 8, 2015 Ca n'est pas la bonne solution mais si jamais ta boutique est en une seule langue et que c'est bien l'id_lang qui pose problème tu peux fixer sa valeur manuellement. $id_lang = 1. Sa te permettra de voir si ta théorie est bonne et si tu n'as qu'une seule langue ça ne posera pas de problème. Link to comment Share on other sites More sharing options...
rom1 Posted June 9, 2015 Author Share Posted June 9, 2015 Merci pour cette réponse. En fait j'ai découpé le test ligne 2685 à 2687 et c'est bien le validate ($id_lang) qui a réagit. J'ai effectivement fixé à la main la langue (2 pour fr) mais les menus de l'admin affichent le nom du menu plutôt que sa traduction façon CamelCase (AdminOrderPreferences). Ce n'est effectivement pas une solution. Finalement j'ai trouvé l'origine de l'erreur par hasard : ne JAMAIS, lors d'une mise à jour, dupliquer les tables dans la même base en changeant le préfixe par le « chercher et remplacer » d'un éditeur de texte ; ça remplace aussi les variables de configuration PS_ comme PS_LANG_DEFAULT ... Link to comment Share on other sites More sharing options...
Olivier CLEMENCE Posted June 9, 2015 Share Posted June 9, 2015 Ah ben oui forcément Bon ben content que tu es réussi à solutionner ton problème Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now