Have you ever wondered how the PrestaShop Addons Team proceeds with the validation ?
We are going to show you how to spare time so that you can pretty much “validate” your own module before submitting it to the Addons Marketplace. First you might want to read the Technical Tools and the Good Practices.
As you probably know, there are 3 types of submissions : New, Minor update, Major update. We do not handle them with the same standards:
Let’s now give you more details on how we handle them all.
What is a “New” Module? Actually, it is a zip file. Your module is the product and since you can submit several zips per product, let’s use the right words.
Simple: the very first time you submit a zip for your module, it is called a “New” zip. Please, do not try to submit your module if you have never used the Validator. That tool runs several checks to make sure your module will run smoothly on PrestaShop. As the current version is closed source, a document summarize the different checks made by it.
After meeting each requirement provided by the Validator, here’s a list of extra points we check:
The presence of DROP/ALTER of PrestaShop tables.
The use of iframes is highly discouraged for security reasons, although they are implemented in different part of the core like in Payment Modules.
Therefore we need to check what your processes are, to ensure the security of the content that will be injected by this iframe into all the shops that will install the module. When submitting your module, the validation team will review the reasons why an iFrame is needed for this business and what are the measures taken by the provider to prevent attacks.
Every hook. If any of them is empty, we decline the zip.
Missing index.php files in your directories ? We decline.
Modules are required to follow a specific folder convention. Files must be in the right folder.
We examine every SQL request to make sure you did cast your variables. Use (int) or pSQL() accordingly.
If you have php files to handle ajax or external calls, make sure to secure that file.
The use of serialize() is forbidden.
Do not load any external content.
Attention: We do have extra rules for Payment Modules as this type of modules require higher security. Note that there are some modules which create the Order with a pending order status before the payment processing (1). While other wait for the payment system’s approval to create it (2).
Make sure you double check the id_cart before creating the order.
if (2), make sure the amount you use to validateOrder() comes from the external payment system. Do not use Cart->getOrderTotal();
For (2), when receiving a call to process the payment, make sure you double check the source of the call using a signature or a token. Those values must not be known of all.