Warning: You are browsing the documentation for PrestaShop 1.7, which is outdated.
You might want to read an updated version of this page for the current version, PrestaShop 8. Read the updated version of this page
The PrestaShop project receives dozens of contributions every week, and every single one of them is reviewed by project maintainers. The review process ensures that only changes that meet a certain quality standard are merged in the codebase.
Ready to contribute code? Here are the rules you need to follow to get your Pull Request (or “PR”) accepted.
The following guidelines apply to all code contributions to the project.
Not following these rules may lead to your contribution being rejected by project maintainers.
Each time you want to work on a contribution, create a local dedicated branch based on the appropriate project branch (described below). Using separate branches for your contributions will allow you to submit multiple contributions at the same time, and update your contributions easily during the code review process.
Contributions should be based on the appropriate branch, depending on the nature of your change:
Maintainers will only accept contributions to branches that are subject to new releases.
develop branch.For more information, see Supported branches.
Configure git to use your real name and email address. This helps maintainers give you credit for your work.
Consider configuring your work email address, especially if you work on PrestaShop on your company’s time:
git config --global user.name "Your Name"
git config --global user.email [email protected]
Make your commits atomic. Ask yourself if what you are doing is one or several tasks: there should be only one complete fix or change per commit. Doing this makes it easier to review, cherry-pick and revert changes.
Avoid merge commits in your Pull Request. They make the commit history more difficult to understand, and they can lead to hidden changes which are not visible by reviewers. If you need to resolve conflicts with the base branch, rebase your branch instead.
Some source files like SCSS and JavaScript need to be compiled to work on a PrestaShop shop.
We used to require these compiled files to be committed and included in the same Pull Request as the source changes.
1.7.7.x branch, compiled assets are still required and should be committed.develop branch, assets are no longer versioned and should no longer be committed.More information in this article.
Make sure to follow these guidelines:
Changes submitted through your Pull Request will be reviewed by PrestaShop maintainers.
Reviewing code is hard, takes a lot of time, and can be exhausting. Making your pull request as easy to review as possible will help in getting it accepted swiftly.
Take time to describe your change. Completing the Pull Request Form, explaining the reasons behind your technical choices as well as any part of the code that could be tricky to understand – these simple tasks can help maintainers understand your change and be confident about accepting them.
Avoid submitting very large PRs when it can be avoided. If you modified a lot of files or a very big number of lines, it is unlikely that you’re addressing a single issue: please try and submit one PR for each issue you solve. This way, a problem in one change won’t block other valid changes from being merged.
A PR with a lot of changed lines will take a long time to review, and consequently the reviewer might miss possible issues. If your PR is too big, it may be rejected due to risk of regressions.
Keep an eye on your PRs. The longer it takes to merge a PR, the more it is likely that it will be blocked by merge conflicts. Whenever a Pull Request is rebased, it has to be reviewed again, thus increasing the time to merge, thus increasing the risk of conflicts…
Adding third party software in the core or in a module can sometimes be faster and easier than developing it from scratch and then maintaining it. PrestaShop uses composer and NPM to manage such dependencies.
Before proposing to add a new dependency, make sure you do this:
Discuss with project maintainers. Explain why do you want to add this dependency and how it will help solve the project.
Consider the dependency’s stability. Recently created libraries may have not yet reached maturity and may have errors or introduce breaking changes regularly.
Consider the dependency’s support. If the dependency is maintained by a single person or lacks contributors, bugs may take a long time to be fixed. Similarly, the lower the number of people working on a project, the higher the risk of it getting abandoned.
Consider the dependency’s license. Dependencies included in PrestaShop must be compatible with PrestaShop’s license. Here’s a list.