Raphaël Malié

It's always a good idea to improve coding standards on an open source project, but it's far to be a priority right now IMO. + what about modules validation ?

The logic is simple x.y.z : - few changes -> increment Z - lot of changes -> increment Y The X number will never change, or maybe in some years. Regards,

Hi Julien, yes but 3 years ago, people were not aware about the override feature, so it was a part of the education plan. But this argument is now invalid I agree Don't forget that PrestaShop is using eval() without these files, and eval() = satan

You deserve an euphemism-award for that Each release of PrestaShop is a proof of your assertion : new bugs and regressions caused by side effects, incompatibilities for some modules or themes between minor versions, performances issues between minor versions, etc.. After 7 years of existence and a lot of developpers who worked on it, I'm still impressed by the number of bugs and the lack of stability / performance. This is the consequence of a bad architecture, and I was already fighting for this cause years ago. Bruno, the CTO, really need to understand that. But we are talking about someone who told me once "There are 2 kinds of developpers : OOP-developpers, and old-fashioned developpers. I'm an old-fashioned developper." A lot of work to improve the architecture in the long term was started in 2011-2012 with the 1.5 version, but sadly the seed was trampled for reasons I won't mention here. It's really worrying to see that absolutly nobody worked on the Collection (new name PrestaShopCollection lol) class during years (https://github.com/PrestaShop/PrestaShop/commits/1.6/classes/Collection.php), while I had no time to finish and optimize this feature. And this feature is still massively used in the code.

Hello, context->cookie is a wrapper for $_COOKIE. So it will be stored locally on the computer

Hello, I added these classes some year before, for same reasons (autocompletion), as you can see in these commits from 2011/2012 : https://github.com/PrestaShop/PrestaShop/commit/c1c857b586bfac3ba956eafccd6a9e75be5d4c0c https://github.com/PrestaShop/PrestaShop/commit/0210a5af36814c7b3422ea5d0474ac3d9553b6c8 https://github.com/PrestaShop/PrestaShop/commit/11a180175c4db40995b77f8def1c09ff2e5fd868 https://github.com/PrestaShop/PrestaShop/commit/5464c1d0ae9d50142429e3068145ff01dc489562 The other reason was to show developpers how to override the code in a "clean" way. Sadly, Remi removed them in this commit https://github.com/PrestaShop/PrestaShop/commit/0cd10335271a9ef9f353a4d965313e812174a98b for bad reasons (IMO). So I'm sad when I read "Thanks to innovacy for research and original idea." (Well I'm kidding, I'm not sad, but it hurts a bit my feelings ) PS : PHPStorm FTW !

In my opinion, adding namespaces without a serious rework of the architecture is pointless. And by serious rework I mean a complete rework (from scratch). Can you transform a rundown building created by interns into a well designed, secured and norm compliants building just with patches ? And without the knowledge from people who designed the first building ? Good luck with that. Namespaces are only usefull with a concret architecture, otherwise it's only marketting. I'm not sure it's time today for a V2 anymore (for reasons given by the old wise Fabien Serny), but I'm sure it was the perfect time years ago to prepare the future. Sadly bad decisions were made. You seem to be very motivated Jerome, it's nice to see and remember me good memories since we were in the same position as you now. But experiences taught me that when the root is rotten, good fruits never grows. And all recents news I heard (and from last month) confirm that. Hope the best, but expect the worst.

Hello, Everything is explained in this documentation : http://doc.prestashop.com/display/PS16/Overriding+default+behaviors It's a way to allow classes overrides. Regards, Ps : please don't call people "nerds", it's a pejorative word

Unfortunately, We noticed that more and more developers subscribe to the forum with the sole purpose of advertising their modules and themes while sharing links to their own commercial websites. This commercial use of the forum does not match with PrestaShop mission for a helpful and fair Community. Rien à voir avec le business modèle de PrestaShop Cloud, entièrement basé sur la vente de modules via la plate forme addons donc ? Pas de problème avec ça, il faut bien faire tourner la boite, et j'imagine que la philanthropie n'est pas la volonté première des actionnaires. Mais de là à ne pointer du doigt que le bien être de la communauté, je trouve la démarche plutôt malhonnête. Et quand on est malhonnête dans ses paroles avec la communauté, c'est qu'on ne la respecte peut être pas tant que ça. 700 000 membres quoi J'en profite pour une petite remarque : j'aime beaucoup le nouveau design du site, c'est propre et clair, du bon taf a été fait. Mais sérieusement, la tronche du mec en page d'accueil craint. A moins d'être en train d'apprendre qu'on vient de remporter pour la 23ème année consécutive le concours mondial de chasteté, je ne vois pas qui peut tirer cette tronche au téléphone. Et puis quel droitier porte sa montre sur le poignet droit ? Et cette coupe de cheveux ! Pour finir avec une citation avant-gardiste : les community manager d'aujourd'hui seront les politiciens de demain #jeSuisCharlie

Ou là https://github.com/PrestaShop/PrestaShop/tree/bootstrap

Salut, Tout ce que tu dis fait désormais parti des bonnes pratiques de développement depuis quelques années. Malheureusement il sera très difficile pour PrestaShop de suivre ces standards sur leur version 1 puisqu'ils doivent rester rétrocompatible avec les modules existant. Si une version 2 arrive un jour, j'espère qu'ils comprendront l'importance d'avoir une bonne architecture logiciel et de suivre ces standards.

Salut, Pour mes deux réponses il faut effectivement se rapprocher de son hébergeur ou avoir quelqu'un qui sait configurer tout ça sous la main. Il est possible de mettre MySQL sur un serveur dédié par exemple, ou de mettre en place des systèmes de maître / esclave afin de répartir le trafic sur MySQL. Perso je ne sais pas le faire car ce n'est pas mon domaine, mais je sais que ça existe et que c'est beaucoup utilisé. Pour ce qui est d'un cache opcode, disons qu'à chaque fois qu'un fichier PHP est exécuté, il est dans un premier analysé et transformé en opcode, et dans un second temps exécuté. Avoir un cache opcode permet de mettre en cache la première étape et donc de gagner un peu en performance, il faut voir ça avec ton hébergeur aussi. ++

Non la 1.4 ne supporte pas xcache pour mettre les requêtes en cache. Mais de toute façon ce type de cache est pourri quelque soit le système derrière, mieux vaut gérer le cache côté mysql. Cela dit vous pouvez toujours installer xcache pour le cache opcode.

Ah mais je ne l'ai pas mal pris, j'insistais juste pour que tu saches que c'était surtout ça la cause Cela dit je pense aussi que comme l'a dit Whoami, il faut morceler ce genre de scripts aussi, c'est plus simple pour les imports Cordialement,

Bah c'est sur que ça vient de là la fuite de mémoire, puisqu'à chaque fois que tu instancies un produit il y a un tableau interne en cache qui se remplie des données récupérées en base, tableau que tu ne peux vider qu'avec clearCache. C'est parce que ce tableau n'est même pas stocké directement dans le produit que le unset() n'a aucun effet.