An override in PrestaShop can make updating harder because it changes the standard behaviour of part of the store and has to stay compatible with the new code. Not every override is a mistake, and not every one will break the next update. The problem starts when nobody knows why it was created, who maintains it and how to test the feature it is responsible for.
What an override actually is
This article is about overriding classes and controllers, not about changing the look of a template. This mechanism lets you replace or extend a piece of PrestaShop’s standard logic. From a store owner’s point of view it means that some operations may work differently than in a clean installation: for example price calculation or the condition that makes a delivery method available.
A hook is an extension point that a module attaches its own behaviour to. An override reaches into existing behaviour more directly. A module, in turn, is a way of delivering a feature and can use various mechanisms, including overrides. So the statement “we did everything in a module” doesn’t answer the question of how deep the intervention goes.
The PrestaShop documentation points out the limitations and the risk of conflicts between overrides, and describes alternative ways of extending the system. The choice depends on the place in the code and the mechanisms available in a given version. The reference point is the official description of overrides. The practical conclusion: before overriding, check whether the same goal can be achieved through a provided extension point.
Why an update can expose the problem
Imagine a modification that takes over the calculation of the delivery fee. It was created for a specific version of the store and uses its arguments and the way it processes data. After an update, the core may pass different data, expect a different type of result or run an extra check earlier. The custom code still assumes the old flow.
This doesn’t always mean a blank page. The store may keep taking orders but calculate a discount differently for a selected group or skip a condition for a particular delivery method. The error only shows up with a specific cart. That is why a test that consists of opening the home page isn’t enough to confirm compatibility.
Copying an entire core method and adding a small change to it needs particular attention. Such a solution may also preserve old logic that the project later fixed. When updating, you have to compare not only what was added but also what changed in the original. The bigger the copy, the more behaviour has to be reassessed.
When an override may be justified
Sometimes the feature you need concerns a place for which the given version provides no suitable extension point. A limited override can then be a sensible choice if the alternative requires a much larger rebuild. This decision must, however, be documented and taken into account in later maintenance. The cost doesn’t end on launch day.
The documentation should include the reason for the change, the supported versions, the code owner and examples of the expected behaviour. You also need information about the alternatives considered. “The client needed a different price” is not enough. “For a customer with contract A, when ordering a full pack, the ERP price applies” lets you prepare a test.
Agree on the condition for removing the override. It may be the arrival of a suitable hook, a module replacement or dropping the feature. Without such a review, temporary code stays for years. Each next person treats it as essential because nobody is sure what will happen once it is switched off.
How to check what is in your store
The review covers the override directory, module code and a comparison of core files with the original release. Directly editing a core file is a separate kind of modification; it doesn’t have to appear on the list of overrides. That is why an empty overrides directory is no proof that the store is still standard.
Ask the developer for a summary that is also understandable to the person responsible for sales. For each change you should be able to see the business function, the place in the code, the source and how to verify it. A class name on its own won’t help you decide whether the modification can be dropped at the next update.
- Which customer or staff action does this piece change?
- Does it come from a module, or was it written for this store?
- Is it used, and on what data can that be confirmed?
- Does another add-on interfere with the same area?
- Which tests will show that the feature works after the update?
Compare against exactly the release that is installed, not any PrestaShop package. Generated files, configuration and store data need separate treatment. When taking over a project, the repository history and older deployment packages help. If they are missing, you need to state clearly which findings could not be confirmed.
How to clean up existing modifications
The first step is to establish the current behaviour. Record sample carts, prices and delivery conditions before changing any code. For rules that affect billing, prepare expected results agreed with the person responsible for sales. An automated test without the correct business answer may only lock in the existing error.
Next, check which features are still needed. Some may have been replaced by a new version of the platform or a module. Others may concern an unused delivery method or a finished promotion. Removing an unnecessary modification can be simpler than rewriting it, but it also requires a trial on a copy and a dependency check.
For the remaining changes, choose how to implement them: an available hook, a service, decoration where the architecture allows it, or a still-maintained override. Moving code to another file isn’t enough if it keeps the same assumptions about the core’s internals. The goal is to reduce dependencies and make testing easier.
Work in stages. First reproduce the behaviour of one feature, compare the results and only then move on. Replacing price lists, the cart and integrations all at once makes it hard to find the source of differences. If the store update is urgent, separate the necessary adaptation from larger clean-up work that can wait for a separate date.
How to test a change before deployment
Test the edge cases, not just the simplest purchase. If the modification concerns a discount, include a reduced product, several items, different customer groups and changing the quantity in the cart. For delivery, check the free shipping threshold, products with different restrictions and changing the address. The list should follow from the rule that was actually changed.
Also compare the saved data: the order total, the values passed to the payment provider and the document sent to the ERP. A correct amount displayed on the page doesn’t guarantee that every system received the same. Record the results together with the code version so the test can be repeated later.
After deployment, watch the area affected by the change. Agree which discrepancies need an immediate response and who checks them. If a 500 error occurs, keep the log and the test data. With a silent pricing error, value comparisons will matter more than monitoring page availability.
How not to be back here in a year
Write into the terms of cooperation an obligation to document core changes and overrides at every acceptance. A change should come with sources, a rationale and a test. Repository access lets you check what was actually deployed, but on its own it doesn’t replace code review.
At the next update, go back to the register of modifications. Check whether the new release offers a simpler solution and whether the feature still has an owner on the business side. Keeping a short, up-to-date list of dependencies is cheaper than reconstructing them during an outage.
Hand this register over together with the code whenever you change contractors and when planning a store update.
Frequently asked questions
Is an override always a mistake?
No. It can address a need for which there is no suitable extension mechanism. It must, however, be a deliberate decision with documentation and a maintenance plan.
How can I tell whether the store has core changes?
Compare its code with the original package of the same release and the deployment history. The admin panel alone won’t show the full picture. Assessing the differences is best left to someone who knows the project structure.
How much does it cost to clean up overrides?
The number of files isn’t a good basis for a quote. One price list change may take more work than several simple overrides. You need a description of the features, dependencies and test cases.
Does this affect the store’s security?
It can, if custom logic bypasses permission checks or validation, or preserves a piece of code that needed a fix. The mere existence of an override doesn’t prove a vulnerability. The specific implementation is what gets assessed.
Before a planned PrestaShop update, collect a list of changes and what they are for. If nobody knows what was overridden, start with a technical audit that translates the code into a scope of work and a risk to sales.