The best way to modify PrestaShop behavior is to override the core files in the overrides directory of the installation.
This technique would really be the best if all module developers were conscientious and methodical about doing things perfectly.
Because, when a function in a class is already overloaded, the installation of a module cannot automatically install the overload and it will be necessary to intervene manually by merging the two overloads in the same code if it is possible.
To avoid these problems, I force myself to always find the class or the function of a class that will be perfect and that will be little used to do something else by another module.
So I don't hesitate to add functions in class overloads to avoid overloading another class for a few lines of code.
So for the 1.7, I worked on the calculation of taxes because it should be known that all prices are always recorded excluding taxes in PrestaShop and that taxes are added to each call of a price.This was done quite easily but when testing the entire purchase chain I found that the PDF invoices continued to display the tax insert with a 20% tax rate but a 0€ tax amount.
So I had to override the invoice generation class to get the state it should have if no tax was applied to this country.
To go further, I thought that it could be interesting for a user of my module that it can work indifferently on PrestaShop 1.6 and PretaShop 1.7 to facilitate the migration if he has not yet estimated that the version 1.7 was stable enough.
So I had fun adapting this module for PrestaShop version 1.6 which still took me a lot of time to find a way around all the obstacles.
There are some functions, when called by methods in Taxes, stubbornly refuse to work. It's quite common in web development on third party projects to not understand why something that seems obvious doesn't want to work.
Once again, I had to find a simple and efficient way to get around this blocking point without damaging PrestaShop structure and performance.
This was done without overriding another class and thus, as explained before, opening the door to a problem with the installation of my module.
The time I take to tweak these details is not only for the beauty of the code, but to save me hours of support for customers in trouble.
My module must be installed in one click and require no intervention.
Here, it will be enough to make sure that the UK currency is well installed, that the country is well active, with its tax rule adapted to its taxation and that my module will have identified it well during its installation.
This is where the implementation of a dynamic FAQ that will analyze the configuration of the store brings all its added value.
If with all this, you do not manage to make your module work properly, do not hesitate to talk to me about it, a button is present to access a personalized support in one click.
1.3.0 - 01/10/2021
- Addition of several tests to facilitate the configuration of the module
- Addition of a FAQ answering the main questions asked by the first users of the module
- Added display of UK VAT number and EORI number on all invoices over the registered limit
1.2.0 - 01/08/2021
- Added compatibility with PrestaShop 1.6
1.1.0 - 01/07/2021
- Correction on the calculation of the total basket excluding tax and shipping costs
1.0.0 - 01/05/2021
- Initial version