Cobs

Ok c'est un peu difficile de faire sens de tout ça. je vais partir du principe que les zones DSN et configuration Apache chez OVH sont bien configurer. Le 1er message d'erreur est causé par une variable manquante et le deuxieme ressemble a un simple problème de cache. Mais j'ai besoin d'être sûr. Tu peux t'assurer avec ton accès phpmyadmin que chaque installation de prestashop possède bien sa propre base de donnée. Prestashop n'est pas conçu pour avoir plusieurs installation sur la même base de donnée, ça peut rendre le système complètement schizophrène. Inutile d'aller plus loins si ce n'est pas le cas.

Je suppose que tout les identifiants de base de donnée ont été réinitialiser lors de la migration. ça expliquerait que la page home fonctionne mais pas les liens. si c'est le cas, c'est un boulot a un poil technique puisqu'il faut refaire la migration de la BDD en s'assurant de copier les anciens identifiant et de mettre à jour le compteur AUTO_INCREMENT pour toute les tables. Pour en être certain il faudrait d'abord passer la boutique en mode debug pour connaitre le message exact derrière cet erreur 500.

il n'y a pas une erreur sur ce code ? cela me semble récursif. public function hookDisplayUnderTop($params) { return $this->hookDisplayUnderTop($params); } Il faudrait aussi jeter un oeil dans le back office 'modules/positions' pour vérifier que le hook est bien enregistré par Blocktopmenu. Si il ne l'est pas, l'erreur provient probablement de l'override qui n'est pas pris en compte.

Je ne connais pas du tout le fonctionnement de ce module, j'ai quand même fait une recherche rapide et j'ai trouvé 3 emplacements susceptible de lancer des requête GET Dans le fichier themoneytizer.php a la ligne 176. une requête curl a destination de themoneytizer.com. themoneytizer.php:176: $ch = curl_init('http://themoneytizer.com/plugin/websites/?token='.$token); themoneytizer.php:177: curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET"); Ensuite dans les fichier displayformatsform.tpl & displayform.tpl il y a 2 formulaire, ils sont configuré avec la methode POST sur ma version views/templates/admin/displayformatsform.tpl:36: <form action="{$uri|escape:'htmlall':'UTF-8'}" method="post"> views/templates/admin/displayform.tpl:34: <form action="{$uri|escape:'htmlall':'UTF-8'}" method="post">

Tout les fichier concernant les modules sont stocké dans le dossier modules/ Dans votre cas ça doit être modules/moneytiser/moneytiser.php Il faudrait regarder de plus près le code du module pour passer de la methode GET à la methode POST.

Hum, si le processus de paiement (panier, client, commande) n'est pas sur votre site, ça va être extrêmement compliqué de faire intervenir Prestashop là dedans. C'est à votre partenaire d'implémenter une interface de paiement (module bancaire ou paypal ) directement relié à votre compte bancaire. Si vous voulez que la commande apparaisse sur votre back-office en plus, la complexité augmente d'autant plus puisque il faut venir enregistrer la commande avec tout les détails ( prix, produit, frais de port, transporteur, taxes) dans votre base de donnée ( via le webservice Prestashop par exemple ). je ne connais aucun module capable de faire celà.

yeah i already solved it by putting the .tpl at the right place. but for some reasons it didn't worked before. this problem drove me crazy but it's solved now. thanks.

[2 semaines plus tard...] Bon, j'ai réessayé et sans plus d'explication, j'arrive a faire l'override de form.tpl depuis mon AdminController. Pour connaitre précisément l'emplacement où mettre son form.tpl j'ai placé quelques var_dump() dans la fonction createTemplate() de la classe helperCore

did you have to do something else in the controller ? i tried to override list.tpl for weeks but i couldn't find any solutions. only the default template is loaded.

je suis également sur cette problématique et je ne comprends pas pourquoi l'override ne se fait pas alors que dans un module comme gamification, ça passe. Je vois pas encore la différence, je continue de chercher.

l'url rewriting des produits se base sur la valeur link_rewrite du produit tandi que d'autres fonctions de la boutique vérifie la variable PS_REWRITING_SETTINGS. 1. Donc, essaye de vérifier que la fonction "url simplifié" est activé pour les deux boutique dans /préférences/SEO & URLs/ 2. Vérifie également que le module Apache mod_rewrite est bien activé sur ton serveur, je me suis déjà fait avoir comme ça. Non le template et smarty n'ont aucune influence sur l'URL rewriting, ça me paraîtrait très surprenant et je n'ai jamais rien vu dans le code qui irai dans ce sens.

Un override ou un template remplacé par la mise à jour ? Le hook existe t'il toujours ?

Ca m'a l'air OK pour PS 1.6, même si le numéro de ligne peut varié selon le thème que tu utilise.

Ce n'est pas un problème de base de donnée, mais bien une Erreur PHP. 'Adapter_ServiceLocator' n'est pas chargé pendant la requête, peut être un problème de droits d'acces sur les fichiers

Ce code "{if ($product.id_product_attribute!='A partir de')}{/if}" compare l'identifiant de ta déclinaison en base de donnée avec la phrase 'A partir de'. Cela n'a pas de sens. Si tu veux la mention 'A partir de' sur tes vignettes produit, il faut placer cette mention avant la balise <span class="price product-price">. Il n'existe pas de méthode automatique pour afficher automatiquement le prix le plus bas sur les vignettes, le prix qui s'affiche est celui de la déclinaison par défaut. il faut donc définir pour chaque produit, la déclinaison avec le prix le plus bas en tant que déclinaison par défaut. En espérant t'avoir aidé.