Jump to content

toup

Members
  • Posts

    10
  • Joined

  • Last visited

toup's Achievements

Newbie

Newbie (1/14)

  • Collaborator Rare
  • First Post Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

2

Reputation

  1. This is long time coming but if it helps anyone using this documentation page : https://devdocs.prestashop-project.org/1.7/modules/concepts/controllers/kpi-blocks/#alter-an-existing-kpi-row I've been adding to one of my module theses two : public function hookActionOrdersKpiRowModifier(array $params) { $params['kpis'] = []; } public function hookActionCustomersKpiRowModifier(array $params) { $params['kpis'] = []; } along with the proper registerHook calls at installation, and it disables the loading of the KPIs on customers and orders pages. It leaves an ugly container, improperly sized, but at least it's not load speed delay. I'll prolly add some CSS at some point to hide theses empty containers.
  2. Hi I would probably do the following 1) create a category (name it however you want) and make it not visible in front, take note if the category ID (let's say it's 123) 2) run this query (of course, replace 123 by whatever your ID is from the previous point) : insert into ps_category_product (id_product,id_category) select distinct id_product, 123 as id_category from ps_product where id_manufacturer = ''; (it will put all the products without a brand into this new category) 3) use "filter by category" on the products page of the back office and filter by your last created category, it will show you your products without a brand. 4) when you're done, you can delete your now useless category
  3. Hey, in phpmyadmin, you should look into ps_orders table, sort it by descending id_cart, write down the value of the biggest cart_id in it (which you can also get in SQL tab by doing "SELECT max(id_cart) as bigid FROM ps_order" if it's simpler for you). Then you add 10 or 100 to this number, and you got your "thenewvalue". The idea here is to make it so ps_cart never gives an ID to a new cart that already exists in ps_orders. ---- As a side note, this issue has been driving me mad, and I never thought about this reason. I applied the fix and my issues seem solved. Thank you very much for the insight, I encourage anyone having issues with an upgraded shop or a shop where you imported orders from an older shop to look into this.
  4. anytime! don't forget to toggle errors back off for production
  5. Have you tried putting the shop in dev mode so it would display errors and give you a clue what's wrong ? Blank pages are rarely showing up without an error If you didn't and don't know how, edit config/defines.inc.php and change define('_PS_MODE_DEV_', false); to define('_PS_MODE_DEV_', true); should be one of the first lines of the file
  6. Hello there, I just realized that when a module can be updated (thru prestashop addons), the "configure" link is not accessible. I'm curious as of why it is the case. In many cases, and specially during developpement cycles, you want to control inbound new code in your project. I know modules are thoroughtly tested but it disturbs me that I have to update a module before to change a setting in it, i'd like to be able to configure the outdated version of my module without updating it, and to have the freedom to review new version changes of the module and decide wether or not my prestashop installation is in shape for getting that upgrade. This shouldn't be an issue in production shops (were all codes/templates overrides are done "right"), but in shops still in developpement, custom code and tweaks in templates/module/core might get overwritten by updating code, and some custom features relying on old code might break on update too. This shouldn't be a risk i'm taking when I just want to tweak a setting somewhere. Am I just working the wrong way or does it disturb anyone else ?
  7. Bonjour, Je cherche à permettre à un client d'utiliser des tags HTML dans des traductions (pour qu'il puisse mettre ses <strong> et ses <br> tranquille). Pour se faire j'ai overridé la classe AdminTranslationsController pour que l'appel à pSQL ne strippe pas les tags lors de l'enregistrement. Lorsque j'enregistre une trad, les tags sont bien enregistrés dedans et visibles après rechargement de la trad dans le back office mais... ... pas en front. Quelqu'un à une idée ? Un usual suspect de la méthode de traduction $this->l("bazkeazea") ou {l s="sdeazdaz"} qui stripperait les tags ? Autre chose ? Merci d'avance Damien
  8. Bonjour, J'ai rencontré un problème similaire, sur seulement un produit. Après avoir pas mal creusé, voici les conclusions auxquelles je suis arrivées : - Cette erreur s'affiche lorsque la méthode "updateQty" de la classe Cart (classes/Cart.php) renvoie "false". - Ce cas de figure peut être causé par les cas suivants : 1) On passe à cette fonction id_product et id_product_attribute (dans le cas d'une déclinaison), pour indiquer quelle déclinaison de ce produit ajouter au panier. Si le code qui entraine l'ajout de ce produit au panier (bouton add to cart par exemple) indique un id_product qui n'est pas le même que l'id_product auquel dans la base de données est rattaché cette déclinaison, la fonction renvoie false (on peut vérifier ça dans la table ps_product_attribute) 2) La boutique est en mode Catalogue (Back office => Préférences => Produits => Mode Catalogue Oui) (logique) 3) Le produit n'est pas "disponible à la vente" (Back office => Catalogue => Produits => Produit en question => "Disponible à la vente" décoché 4) Le couple id_product / id_product_attribute n'est pas disponible dans la table de gestion des stocks (ps_stock_available). C'est le problème que moi j'avais. Je n'ai pas créé mes déclinaisons et produits "à la régulière" et donc j'avais mal fait la partie ajout à cette table, certaines refs avaient sautées. Pour vérifier ça, vérifier que tous les id_product_attribute de ps_product_attribute sont présents dans ps_product_stock_available, si ils sont manquants, les insérer avec le bon id_product, le bon id_shop, et les paramètres de gestion de stock qui vous conviennent. (dans le doute => tout à zéro pour ces paramètres, et ensuite réglage "manuel" dans le back office section stocks du produit en question. (Attention particulière à que faire quand le produit est out of stock) 5) La commande n'est pas autorisée pour ce produit quand il est out of stock (idem ci-dessus, réglage déconnant dans le back office section stock du produit) 6) le paramètre "operator" de la methode "updateQty" n'est ni "up" ni "down" => dans ce cas là, votre code "customisé" d'ajout au panier n'est pas bon, vérifiez votre code ou les modules "tierces" en rapport avec l'ajout au panier pour un appel à cette fonction. 7) Impossiblilité d'écrire dans la table ps_cart_product l'ajout de ce produit au panier. Les raisons peuvent être diverses. Peut être un champ obligatoire dans la table est manquant dans l'appel de la fonction. Surement le plus épineux à débugguer. Il peut s'agir des droits d'écriture sur la table en elle même (dans ce cas : tous les produits sont impactés), ou bien les variables passées à l'ajout qui sont incorrectes. Pour débugguer ça, aller voir dans "updateQty" de Cart.php, vers la fin de la fonction c'est l'appel "Db::getInstance()->insert('cart_product" qui est en cause. 8) Cas hypothétique (pas creusé) : le produit est customizable et la méthode "_updateCustomizationQuantity" de Cart.php renvoie elle aussi "false". A voir ce qui peux poser ce cas de figure. Voilà, je me doute que ce n'est pas d'une grande aide car c'est assez générique, mais vu que pas mal de gens dans ce thread ont l'air de galérer et que j'ai creusé le code et la db pour retrouver mes petits, peut être que quelqu'un pourra en profiter. Bon courage, Damien ps: désolé si c'est un peu fouilli, pas mis en forme et que ça manque d'information, j'ai rédigé ça en vitesse pour ne pas l'oublier, mais trop de taff pour en faire plus là tout de suite. Si quelqu'un a besoin d'éclaircissements, contactez moi
  9. Great stuff. Feel free to keep me posted about anything going on in that field, I'd gladly provide feedback or ideas on the topic.
  10. Hey there, Every time I have to install a new instance of Prestashop (which is basicly 3/4th of the projects I work on), I'm facing the same issues. I would like to streamline download and install process thru scripting (installing thru PHP CLI is possible after all), but here's where I keep failing : - Getting the url of the archive of prestashop (for purposes of using wget/curl on it from my remote host) is actually a chore : the download button on the site is a javascript action, the url of the ressource behind it is a controller. That's a no-no. I found that http://www.prestashop.com/download/old/prestashop_1.6.0.9.zip works, but that implies feeding the version number to the script or command line. I also got the impression that this isn't quite intended. - The only other option I'm left with is "normally" downloading the archive, uploading it thru FTP/SSH to my hosts (sloooow), and proceeding with the install CLI Here are the possible improvements that would make my life better : - having some fixed url for downloading "latest.zip" - having some kind of ressource listing the various stable releases numbers in a machine-readable format (json ?), along with a stable url format (such as the /old/ one cited above) that allows to retrieve the archive of a given version. - having (that would be damn awesome) the "releases" files in the github repository be actual releases (ie: the same things that the archives on the prestashop website), because I think that the release thing in github has this exact purpose. Today, they're just archives of tags of the repository, which means that they're not usable in a production environnement (install-dev and admin-dev, no modules or anything that is submoduled in git, etc) - having a git repository that matches what ends up in the archive. I understand that cloning a git repository and updating the modules is not intended to be a valid "deployment" mechanism, so I would understand if things stood the way they currently are. - having a "build" script in the repository that builds the git repository into the "production-ready prestashop.com" archive Does it seem possible (or wanted) to have such things implemented ? How do YOU guys working with prestashop on a daily basis deal with the issues i'm encountering ? Am I just missing something ? To keep the kind words for the end of this rant, prestashop is an amazing product, and it gets better at every version, it's just a little tedious to start new projects with it, especially when code versionning custom themes/modules and working with several people on dev/staging/prod environnements.
×
×
  • Create New...