gbert1

Je tente de faire un override de Product.php avec la version 1.5.3.1 mais il n'est jamais appelé. (j'en avais fait un qui fonctionnait avec la 1.4.8) Je travaille avec une version 1.5.3.1 installée à partir de zéro. J'ai modifié /classes/stock/StockAvailable.php pour y intégrer le patch de Rémi Gaillard du 16 janvier : http://scm.prestashop.com/changelog/PrestaShop_v.1.5?cs=d0074ed72491292b2ec4b8fe8ceb87f7585c2e72 portant sur : Hook actionUpdateQuantity was not called for product without attributes which depends on the physical stock Il n'y a normalement rien d'autre à faire que surcharger override/classes/Product.php puisque dans la 1.5 sa coquille existe. C'est bien ça. Qu'aurais-je oublié ? Merci par avance des regards éclairants sur mon problème. <?php class Product extends ProductCore { public static function actionUpdateQuantity($product, $id_order = NULL) { parent::actionUpdateQuantity($product, $id_order); mon code... } } ?>

Je réouvre ce topic car j'ai le même problème : ma surcharge de Product.php ne s'exécute pas. Je suis en 1.5.3.1 J'ai fait comme Weetabix40 : j'ai réinstallé le répertoire override Il n'y a normalement rien d'autre à faire que surcharger override/classes/Product.php puisque dans la 1.5 sa coquille existe. C'est bien ça. Qu'aurais-je oublié ? Merci par avance des regards éclairants sur mon problème. <?php class Product extends ProductCore { public static function actionUpdateQuantity($product, $id_order = NULL) { parent::actionUpdateQuantity($product, $id_order); $chaine = 'actionUpdateQuantity'; $chemin = '/homez.abc/xyz/www/librairie'; $file_output = fopen($chemin."/test_aUQ.txt", "wb"); if ($file_output) { fputs($file_output,__file__.' - '.__line__.' - '.$chaine); fclose($file_output); } } } ?>

Merci aux contributeurs de ce fil. Après avoir bcp galéré, voici ce que j'ai dû faire de mon côté pour que ça marche bien : 1/ Supprimer la catégorie "Accueil" dans mon CSV 2/ Ordonner les catégories pour qu'aucune parente n'apparaisse avant ses filles 3/ Insérer une colonne "Racine(0/1)" mise systématiquement à 0 (on pourrait l'éviter à l'import mais ça facilite) 4/ Supprimer tous les caractères accentués --> Pas d'accents dans le CSV ! Par ailleurs, j'avais des catégories redondantes, ça c'était un bug de ma part (enfin... de mon client). Il faut évidemment aussi bien penser à sauter la ligne de titre et à supprimer les catégories existantes.

Sur Ikoula oui. Sur OVH, je crois, mais n'ai pas trouvé encore.

J'ai téléphoné à OVH. Par ailleurs, j'ai testé sur un hébergement où je peux switcher entre CGI et FastCGI (Ikoula) : je confirme.

ça ne marche pas chez OVH mutualisé à cause du FastCGI si vous passez sur un hébergement avec CGI (au lieu de FastCGI), ça marche

@gandal76fr : votre solution marche nickel, merci Toujours à propos des webservices, j'avais trouvé un bug dans la création de tags qui a été résolue lors du Prestashop Camp de décembre par un des développeurs (très sympa d'ailleurs). Je pense que depuis le patch qu'il avait créé a été intégré dans les dernières versions.

J'ai progressé (grâce à ce post sur le forum ovh) mais sans avoir encore trouvé la solution. C'est un problème lié à l'hébergement OVH mutualisé. Il est dû à l'utilisation de FCGI au lieu de CGI par OVH. Les variables d'authentification sont rendues vides avec FCGI. Donc dispatcher.php n'a rien à se mettre sous la dent et redemande donc ad libitum. Il faut donc faire une petite pirouette pour récupérer ces variables (nous avons besoin seulement de l'identifiant, pas du mot de passe). Il faut pour cela combiner (ou autre solution ?) deux règles de réécriture : 1/ une qui place HTTP Authorization dans $_SERVER['REMOTE_USER'] RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L] il faut ensuite modifier dispatcher.php pour parser la variable REMOTE_USER au lieu d'aller chercher l'id dans $_SERVER['PHP_AUTH_USER'] (ou dans $_GET['ws_key'] ?) 2/ celle de Prestashop qui redirige l'appel www.monsite.com/api/?requete vers le sous-répertoire contenant le script d'aiguillage, cette règle est la suivante : RewriteRule ^api/?(.*)$ /webservice/dispatcher.php?url=$1 [QSA,L] Et ça (vu mon niveau en url rewriting) je ne sais pas faire, ni si c'est possible. Une seule règle ? Deux ? Dans quel ordre ? J'ai essayé mais sans trouver. Merci de votre aide.

Mes webservice fonctionnent en local avec MAMP. Je lis, crée, met à jour des produits. Quand j'installe sur OVH mutualisé (90plan), ça ne marche pas. J'ai une erreur 401 : HTTP REQUEST HEADER GET //api/product_features HTTP/1.1 Authorization: Basic ******** Host: www.******.com Accept: */* HTTP RESPONSE HEADER HTTP/1.1 401 Unauthorized Set-Cookie: 90plan=R4114022451; path=/; expires=Sun, 09-Oct-2011 17:38:08 GMT Date: Fri, 07 Oct 2011 05:28:32 GMT Server: Apache/2.2.X (OVH) X-Powered-By: PHP/5.2.17 WWW-Authenticate: Basic realm="Welcome to PrestaShop Webservice, please enter the authentication key as the login. No password required." Vary: Accept-Encoding Content-Length: 0 Content-Type: text/html; charset=utf-8 Ma version : PS 1.4.4.1 ce qui me trouble est qu'en local la ligne X-Powered-By (ci-dessous) est différente de la ligne X-Powered-By (ci-dessus) sur OVH HTTP/1.1 200 OK Date: Fri, 07 Oct 2011 05:37:38 GMT Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8l DAV/2 PHP/5.3.6 X-Powered-By: PrestaShop Webservice Ma réécriture d'URL est bien activée (mais pas détectée par le BO dans Outils/Service web) PHP 5 est bien activé (comme on peut le voir dans l'entête http) J'ai désactivé et rééactivé smarty 3 (voir ce post). J'ai vidé les caches de Firefox et Chrome. Je sèche..... Merci de votre aide.

Je m'autoréponds : en mettant à jour de la 1.4.2.5 vers la 1.4.4.1, le code ci-dessus fonctionne. J'ai toutefois augmnenté psCompatibleVersionsMax dans PSWebServiceLibrary.php Gilles

Bonjour, Je n'arrive pas à créer un nouveau produit avec les webservices alors que j'arrive à en modifier un. J'ai suivi les conseils donnés par damien13 dans ce fil Mon code est le suivant : require_once('./PSWebServiceLibrary.php'); try { $webService = new PrestaShopWebservice('http://localhost:8888/prestashop','28AUJBRMA4VFY1HFDQCSSO32FSTKLR4P',false); $opt['resource'] = 'products?schema=synopsis'; $xml = $webService->get($opt); // champs requis $xml->product->quantity = 0; $xml->product->price = 1; $xml->product->out_of_stock = 2; $xml->product->link_rewrite->language[0][0] = 'LIEN'; $xml->product->name->language[0][0] = 'NOM'; unset($xml->product->associations->categories->category); $xml->product->associations->categories->addChild('category')->addChild('id', 1); unset($xml->product->associations->combinations->combinations); unset($xml->product->associations->product_option_values->product_options_values); unset($xml->product->associations->product_features->product_feature); $opt = array('resource' => 'products'); $opt['postXml'] = $xml->asXML(); $xml = $webService->add($opt); } catch(PrestaShopWebserviceException $ex) { $trace = $ex->getTrace(); $errorCode = $trace[0]['args'][0]; if ($errorCode==401) { echo 'Mauvaise cle authentification curl'; } else { echo 'Autre erreur : <br />'; echo $ex->getMessage().'<br />'; echo 'Code : '.$ex->getCode().'<br />'; echo 'Trace : '.$ex->getTrace().'<br />'; echo $ex->getFile().'<br />'; echo $ex->getLine().'<br />'; } } J'ai bien utilisé synopsis et vidé les required inutilisés. Qu'est-ce qui manque ou est en trop ? Merci de votre aide par avance. Gilles

En fait, les champs avec l'attribut <id required="true"/> doivent être renseignés.

Dans le XML, il semblerait que ce sont tous les champs avec l'attribut not_filterable positionné..... <manufacturer_name not_filterable="true"></manufacturer_name>

Oui Damien13, ça marche avec : unset($xml->product->id_default_image); unset($xml->product->position_in_category); unset($xml->product->manufacturer_name); unset($xml->product->unity); unset($xml->product->date_add); unset($xml->product->date_upd); Comme le remarque itself, ce n'est pas documenté. Je m'étais douté pour le champ manufacturer_name car il est effectivement calculé (peut-être demeure-t-il dans la structure pour garder une compatibilité ascendante). Normalement, il ne devrait pas être en dur dans products. Merci en tout cas damien13, sans votre post j'étais dans l'obscurité la plus totale.

Je me réponds à moi-même : il suffisait (au lieu de me prendre la tête à chercher à installer ce module) d'installer la toute dernière version de MAMP 2.0 car la mienne était 1.9 puis de rajouter dans /Applications/MAMP/conf/apache/httpd.conf la classique ligne : LoadModule auth_basic_module modules/mod_auth_basic.so de bien sûr redémarrer MAMP et ça roule