eontech

Glad to hear you got it working. You may still want to look into how to do the same thing using overrides to stop any future version upgrades from over-writing your changes. At any rate, it will be useful if you marked this as solved as described here: Serge

assuming that you have a custom 'Thank you' CMS page, you can add the single line, mentioned before to mylogout() function in CustomerCore class. You can either modify the core class directly in /classes/customer.php file or create an override of this class (to be able to update your prestashop version and still preserve the changes you made). Look up how to create an override elsewhere and see if that's the route you'd like to take. You only need to include the functions you change in your override class. This should work regardless of whether an order was placed or not.

Hi, I believe if you create an override for customer.php class (in the /override folder) with a single copy of mylogout() function you can add this line to the end of that function after: ... $this->logged = 0; Tools::redirect('/path_to_your_custom_page');

Apologies in advance, for any errors in this post. I'm not a frequent poster of any forums. My question is for a PS module developer veteran. I have developed my first multi-store carrier module for a European country's national postal service. The module is 1.4+ compliant and since it's release into the wild, a few weeks back, appears to be working very well without any serious issues. The module was coded using Prestashop standard for codesniffer, so using François Gaillard excellent validation tool, it passes configuration and compatibility but shows some relatively minor errors. In particular: 1. Showing css, js & img folders, not being in the root folder as structural errors. The change would take seconds but I would prefer to keep root folder as clean as possible and keep these view related folders separate. 2. Most 'forbidden' items are valid and easy to replace, but one or two are simply wrong as there is no other logical alternative. As you may well know the Prestashop core code itself is far from passing all of these validation rules. So the question is, how important is this? and what do you consider best practice or good enough? TIA Serge

Hi Vekia, Perhaps I should've phrased it better. That is correct. The only way I know, is to replace the module php file and keep/track the changes, in the case of upgrading. I just needed to confirm that there is currently no better option as far as module php file goes. Overriding everything else seems fine. Would you say "/override/modules/blockwhatever/blockwhatever.php" is a reasonable place for it? perhaps as a possible future feature request??

hello, maybe a Q for the Gurus Why can we not override an existing module's main php file? apologies, if this has been answered properly, but what I've found so far seems to be rather vague. this is my 1st post and since my intro to Prestashop 3 weeks ago. Reading though the docs/forum I've managed to, successfully make, from simple theme/template/css tweaks to the more complex, override core classes: category, product/ add custom fields, new sql queries and rewire them including BO forms, templates etc. The mechanism works very well and core files can be upgraded without impact since they're untouched. Obviously overwriting the module's php file works fine too and with some house-keeping copies can be kept before & after the change; but why can't this be extended to say: /override/modules/blockcategories(e.g.)/blockcategories.php ??