Jump to content

cybeardjm

Members
  • Posts

    12
  • Joined

  • Last visited

Contact Methods

Profile Information

  • Location
    France
  • Activity
    Agency

cybeardjm's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Hi to all, First let me say that I really like the 1.6 version, BO or FO. I use PS for a travel agency, since version 1.4, and tried many tricks to adapt PS to its needs... With the latest version, it was decided that we started again from scratch. So I'm working on a brand new version, that never got through any update... (even the content is new). Noticed a few "glitches", if you have any ideas: * attributes sorted from the BO are not saved to SQL, although message says so => I had to manually edit the SQL DB to sort the attributes properly... * a negative price for an attribute, doesn't appear in BO, shows "0" (even if fine in SQL DB, e.g. -135 in unit_price_impact) and has no impact on the product page in the shop, generating wrong prices for customers. * when performance is optimized through caches, changes on products' descriptions do not appear in BO, even if saved to SQL. Have to flush the cache, quit and log again... Finally a question: What's the easiest way to allow customers to only pay 30% of total amount to order ("acompte" in French - advance?). There was an addon developped for 1.4 that was never ported to 1.5 or 1.6, and as a B2B agency, I really need this to properly operate the process for some customers. Sincerely DJM Shop: http://www.uvva.fr
  2. Hello, I have the exact same problem, trying to update from 1.5.0.17 to 1.5.1, after upgrading the 1click-update module to 0.8.8 (that appears as 0.8.6 inside the update page). Have the same content as clegeard in config.inc.php => errors are already turned off... Sincerely DJM
  3. OK, Mea Culpa!!! In fact, what happens is not at all connected with the 2 backoffice values... It's simply that shopping_cart.tpl has been changed from 1.4 and that these lines were "hardcoded" in the template around line 168: <!--tr class="cart_total_price"> <td colspan="5">{l s='Total (tax excl.):'}</td> <td colspan="2" class="price" id="total_price_without_tax">{displayPrice price=$total_price_without_tax}</td> </tr> <tr class="cart_total_tax"> <td colspan="5">{l s='Total tax:'}</td> <td colspan="2" class="price" id="total_tax">{displayPrice price=$total_tax}</td> </tr--> Just comment them as I did above, and it's fine. Sincerely DJM
  4. Hi all, agreed with kevpoll, I have the same problem with the latest stable version (1.5.0.17). You can switch "display tax in cart" on or off in BO, this has no effect in FO, although PS_TAX_DISPLAY is correctly set in the DB. Probably some logic i wrong somewhere around the use of $use_taxes in shopping-cart.tpl or we're missing something completely (It worked properly in my previous shop using 1.4). Will have to manually edit the template... Checked the Forge. Found this issue: http://forge.prestashop.com/browse/PSCFV-1640 The answer is: But I might disagree (or not understand the specifics), as shopping_cart.tpl contains the following code: {if $use_taxes} {if $priceDisplay} <tr class="cart_total_price"> <td colspan="5">{if $display_tax_label}{l s='Total products (tax excl.):'}{else}{l s='Total products:'}{/if}</td> <td colspan="2" class="price" id="total_product">{displayPrice price=$total_products}</td> </tr> {else} <tr class="cart_total_price"> <td colspan="5">{if $display_tax_label}{l s='Total products (tax incl.):'}{else}{l s='Total products:'}{/if}</td> <td colspan="2" class="price" id="total_product">{displayPrice price=$total_products_wt}</td> </tr> {/if} {else} <tr class="cart_total_price"> <td colspan="5">{l s='Total products:'}</td> <td colspan="2" class="price" id="total_product">{displayPrice price=$total_products}</td> </tr> {/if} where taxes and their use are indeed tested. This could mean that it's not the display of taxes in cart that is not properly validated, but their use. Once again, this worked in 1.4 Sincerely DJM
  5. Hello, Avant de migrer une boutique existante vers la version 1.5, j'ai installe scratch une nouvelle boutique et j'y apporte les modifs dont j'ai besoin. ( v 1.5.0.17) Dans la version 1.4, j'avais ajoute 2 champs (du meme type que description) dans la fiche produit en BO et FO et tout s'etait bien passe. Je tente de faire la meme chose dans 1.5 ;-) 1 - j'ai donc cree mes 2 champs dans la BDD 2 - J'ai modifie product.tpl de mon theme, et les champs s'affichent bien dans le FO. 3 - maintenant, je veux modifier l'onglet "information" de la fiche produit dans le BO. J'ai donc fait un override de classes/Product.php pour declarer mes 2 strings, les declarer dans l'array "fields" et modifier les 4 fonctions liees au produit (getAccessories, getPricesDrop, getRandomSpecial, getNewProducts). 4 - je dois maintenant les faire afficher dans le BO. Je fais donc un override de admin/themes/default controllers/products/informations.tpl dans override/controllers/admin/templates/controllers/products. => Il ne se passe rien Q1: ai-je oublie qqchose ? Surement... mais quoi ? Q2: mon chemin d'override du template est-il le bon? j'ai tente aussi de mettre mon fichier .tpl dans override/controllers/admin/templates directement sans resultat... Merci de votre aide. Sincerely DJM PS: je me suis appuye sur ce topic pour avancer "indirectement" http://www.prestashop.com/forums/topic/179799-ajout-du-type-checkbox-dans-le-options-dadmintab-override-des-helpers-bo/
  6. Je complète mon test. J'ai transformé RewriteRule ^([0-9]+)\-[a-zA-Z0-9-]*\.html /shop/product.php?id_product=$1 [QSA,L] en RewriteRule ^([0-9]+)\-[a-zA-Z0-9-]*\.html /shop/product.php?id_product=$1 [L] en supprimant donc QSA (pour Query String Append - Query String ajouté en fin d'expression). L'URL résultante est toujours http://www.uvva.fr/shop/11-decouverte-de-la-crete-8j-7n.html?id_product=8 Mais cette fois, la page cible s'affiche au lieu de me donner une page "produit indisponible" comme précédemment, comme si la query-string n'était plus prise en compte. Question : quel impact cela aura-t-il sur le reste du fonctionnement du site ? Question subsidiaire : le .htaccess est-il mis "en cache" par le serveur ou y-a-t-il une forme de latence entre la sauvegarde des modifications et leur prise en compte. Après avoir supprimé les lignes de ma redirection, elle a continué à fonctionner... ??? Sincerely @cybearDJM
  7. Bonjour, j'ai le même souci avec un ?id_product= qui apparait apres la redirection... Suite a un cafouillage dans la sauvegarde d'un produit, j'ai du le recreer par copie. Ainsi, http://www.uvva.fr/s...rete-8j-7n.html est devenu http://www.uvva.fr/s...rete-8j-7n.html càd, l'ID produit a changé de 8 en 11. La boutique est un sous-dossier /shop/. En racine du site, il y a un blog WordPress. Les 2 applis ont chacune leur .htaccess, celui de PrestaShop étant généré automatiquement. J'ai donc créé une redirection 301/permanent de l'ancienne page vers la nouvelle. Mais systématiquement, le résultat s'affiche ainsi : http://www.uvva.fr/s...ml?id_product=8 Où l'on voit que l'ID de l'ancien produit est rajouté en fin du nom de la nouvelle page, ce qui cause une nouvelle erreur. Cela provient peut-être de ces lignes du .htaccess de PrestaShop généré automatiquement, mais je ne vois pas pourquoi : RewriteRule ^([0-9]+)\-[a-zA-Z0-9-]*\.html /shop/product.php?id_product=$1 [QSA,L] ou RewriteRule ^[a-zA-Z0-9-]*/([0-9]+)\-[a-zA-Z0-9-]*\.html /shop/product.php?id_product=$1 [QSA,L] à moins que le QSA ne joue un rôle fort dans ce cas précis. J'ai donc testé l'emplacement de ma ligne de redirection # Produit supprime - DJM - 27112011 Redirect 301 /shop/8-decouverte-de-la-crete-8j-7n.html http://www.uvva.fr/shop/11-decouverte-de-la-crete-8j-7n.html # End à divers endroits de mes 2 .htaccess, mais rien n'y fait, j'ai toujours l'apparition du ?id_product= avec l'ID de l'ancien produit qui apparait... Idem avec Redirect 301 /shop/8-decouverte-de-la-crete-8j-7n.html http://www.uvva.fr/shop/product.php?id_product=11 ou Redirect 301 /shop/product.php?id_product=8 http://www.uvva.fr/shop/product.php?id_product=11 Et là, je sèche... ayant déjà passé plusieurs heures à chercher des idées constructives sur le forum et autres sites... Voilà si qq'un avait une étincelle, je le remercie d'avance... Sincerely @cybearDJM
  8. Thanks dimooz, works fine on 1.4.4.0. Excellent!
  9. OK, re:CSS. In fact product_list.css is not loaded by the page as nowhere in the PHP it"s requested. You can check, as an example, the declaration in the file CategoryController.php that requests this CSS file as an extension to the current loaded styles public function setMedia() { parent::setMedia(); Tools::addCSS(array( _PS_CSS_DIR_.'jquery.cluetip.css' => 'all', _THEME_CSS_DIR_.'scenes.css' => 'all', _THEME_CSS_DIR_.'category.css' => 'all', [color=#0000ff]_THEME_CSS_DIR_.'product_list.css' => 'all'[/color])); if (Configuration::get('PS_COMPARATOR_MAX_ITEM') > 0) Tools::addJS(_THEME_JS_DIR_.'products-comparison.js'); } Ugly/dirty (but quick) method to solve pb: * locate product_list.css in your theme CSS directory, * copy all content from the file, * open shopbyprice.tpl * add <style></style> * in between these tags, paste the content from product_list.css Nice way : I do suppose that the best way to achieve this would be to transform shopbyprice.php so that it extends the main controller...??? Sincerely DJM
  10. OK, made it work in 1.4.4.0 As stated by oleg_ua in January, you have to : - modify shopbyprice.php as he explained above - replace in both template files (shopbyprice.tpl and blockshopbyprice.tpl), quotes like ‘ with single quotes ' - add opening and closing " to all includes in shopbyprice.tpl, such as {include file=$tpl_dir./breadcrumb.tpl} becomes {include file="$tpl_dir./breadcrumb.tpl"} The CSS is still broken so far (same pb as Nabeel Aejaz above), but at least I get the content... Will come back if I find the CSS pb... Sincerely DJM
  11. Hi, using latest version (1.2.1) on PS 1.4.4.0, shop goes blank on every page... If I put index.php as an exception, it loads properly Moved the plugin to right column, page loads only parts of the content... and then stops => page's incomplete and "ugly" ;-) Any idea what to look for, to try to have it work properly... Thx in advance. Sincerely DJM
  12. Hello again, Comme quoi, le fait de poser le problème convenablement pour que d'autres le lisent, aide à dégripper les neurones... Il me manquait la déclaration en début => protected $fieldsValidateLang = array() Dans tous les cas, cette fiche peut servir à tous ceux qui souhaitent ajouter des champs HTML complémentaires en 1.4.4. Bon, je m'attaque au FO, j'ai 2 onglets à faire apparaitre sur la fiche produit... Désolé pour le dérangement... ;-) Sincerely DJM
  13. Bonsoir à tous, Ce que je cherche à faire : ajouter 2 champs HTML sur la page produit en BO (que j'intègrerai ensuite en FO, mais je n'en suis pas encore là) Mes références et sources d'inspiration : comment-ajouter-un-nouveau-champ-sur-la-fiche-produit-et-dans-le-back-office-prestashop et resolu-ajout-champ-text-fiche-produit-back-office-et-front-office Version : PS 1.4.4 - nouvelle installation Pas à pas : * j'ai créé 2 champs (incl & notincl) dans la DB (table ps_product_lang), paramétrés exactement comme "description" * j'ai modifié admin/tabs/AdminProducts.php en y ajoutant les 2 zones de texte correspondantes (en dupliquant/modifiant le bloc de "description") => les champs apparaissent bien dans la fiche produit. Ensuite, pour lire/écrire les champs entre la DB et la fiche produit, j'ai modifié directement classes/product.php (je sais, ce n'est pas bien ;-) ), principalement : * déclaration de mes 2 champs en variables public * modification des fonctions getTranslationsFieldsChild(), getNewProducts(), getRandomSpecial(), getPricesDrop(), getAccessories(). => J'arrive à ajouter/modifier/supprimer le contenu de mes 2 nouveaux champs, mais je n'arrive plus, par exemple, à modifier les caractéristiques d'un produit : lorsque je sauve, je suis redirigé, sans erreur affichée, sur la page principale du catalogue... J'ai donc décidé de passer par un override, en ne mettant dans override/classes/Product.php que les fonctions modifiées, après avoir déclaré en en-tête class Product extends ProductCore. => Les données présentes dans mes 2 nouveaux champs qui pré-existent dans la DB s'affichent bien, mais je ne peux pas modifier le contenu ou en ajouter : à l'enregistrement, et toujours sans message d'erreur - j'ai même droit à "Mise à jour réussie", les nouvelles data saisies sont éliminées. Par contre, les autres fonctions comme la modification d'une caractéristique fonctionnent toujours... =>>> donc, là je sèche. * soit je modifie le product.php original, mes fonctions modifiées opèrent, mais pas les anciennes. * soit je passe par un override, les anciennes sont OK, mais pas mes modifs... C'est comme s'il manquait "qqchose" pour "finir" ou "déboucler" l'override... ;-) J'ai loupé un truc, mais quoi ? Un pro aurait-il une idée ? Je suis là-dessus depuis 2 jours et je sèche lamentablement... Sincerely DJM
  14. Same problem here on a brand new 1.4.1.0 On an other directory + DB on the same server, I did 2 default scratch installations and the problem doesn't exist. I'd say then, that some changes at some point in the global configuration of PS, "break" this "normal" behavior, but I don't know what... unfortunately. I can confirm that commenting the line in .htaccess does indeed work (.htaccess generated automatically from the PS Tools). For those who haven't seen the problem and want to check : go to http://www.onlinevoyages.com, choose any product, try 2 switch language between FR/EN. Same problem if you start with FR or EN. If you change language on the home page or any CMS page or any category page, it works fine. Only product pages generate this problem. sincerely DJM
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More