- Patryk Marek
- News
- 0 likes
- 175 views
- 0 comments
- PrestaShop, module selection, licence, demo
Before buying a module, confirm three things: whether the package fits your environment, whether it supports the process you need, and what your purchase option includes. A feature name, a PrestaShop version number or an available demo screen does not answer all these questions.
The worksheet below helps you record confirmed information and unknowns. Mark a missing answer as "to be confirmed" rather than treating it as proof of compatibility.
Download the module selection worksheet and an example based on three offers. The ZIP contains a blank CSV form, an example and instructions, all in Polish. Record your environment, confirmation sources and acceptance criteria; do not include passwords or customer data.
1. Describe the exact environment and choose the right package
Record the full PrestaShop and PHP versions, the theme and its version, and the modules with which the new solution must work. For checkout, payment and shipping modules are particularly important; for analytics, tag installation and consent handling; for imports, the supplier's data format and a sample.
A "PrestaShop 9" declaration does not describe every combination of theme, PHP and add-ons. If your store has custom changes, specify the affected area. Ask for confirmation of the correct package and known limitations. Do not assume that the newest package is also intended for an older store.
2. Describe the result, not just the feature name
Prepare one specific scenario. "Returns handling" could mean accepting a request, refunding a payment, producing a carrier label or obtaining a shipment code: these are separate stages. "Supplier integration" does not establish whether combination weights are transferred. A "purchase in GA4" does not yet confirm correct session attribution.
Write down the input, the user's action and the expected result. Use a demonstration sample without customer data or passwords. If an offer does not describe the operation you need, confirm it before buying. If the process needs changing, consult the guide to choosing a module or a dedicated integration (in Polish).
3. A demo shows the solution; a store copy checks your module combination
Establish what the demonstration provides: the customer view, administrator configuration or only selected screens. A working demo home page does not confirm the whole order process. If the panel is restricted, request a demonstration of a particular setting or an explanation of the scenario you cannot check yourself.
Not every offer includes a free trial package. Agree on whether and how it can be checked before purchase. After obtaining the module, test it on a copy of your own store with the required theme, demonstration data and dependencies. Do not trigger real payments, shipments or messages to customers merely to inspect a feature.
4. Separate the licence, update access and support
At PrestaDev, the conditions are set out in section 7 of the Store Terms (in Polish). According to the version read on 6 October 2026, a module licence is perpetual and covers one store or one multistore instance, including a permitted test copy without actual sales. Separate instances do not become a single licence merely because they have the same owner.
The initial purchase includes 12 months of access to development updates and one month of the email support described in the terms. Optional renewal of update access is not a new full licence or a new support period. Not renewing does not remove the right to use the version obtained; these rules do not restrict statutory rights. Work in the store and individual modifications require a separately agreed scope. Before ordering, check the current terms and whether you are selecting the full version or an update.
5. Our example: what does reading a product page actually confirm?
On 6 October 2026, we read the public information for three offers. This example concerns information availability and the limits of inference, not tests of every feature or environment version. The linked product pages are in Polish.
| Offer | What was confirmed | What needs a separate check |
|---|---|---|
| Quick Checkout | The page describes the route from a demonstration product to the cart and order form. | The flow with your store's theme, carriers and payment methods, and the resulting saved order. |
| PD Cookie Pro | The page distinguishes Google signals, GTM and Meta consent integration, and provides acceptance scenarios. | Actual tag activation with no decision, refusal, category selection and withdrawn consent. |
| Sentiell Integration | The page asks for an XML structure sample and an agreed scope before purchase. | Access to your own source and a trial import of the required fields, combinations and updates. The supplier's private feed was not tested. |
Use the same recording method for your choice: evidence, date and a separate list of unknowns. Confirming that a page was read is not a deployment result.
6. Record acceptance criteria before going live
Choose several scenarios matching the module's main purpose. In addition to a successful flow, include a changed decision, invalid data or a connection interruption when relevant to the process. Specify where you will see the result and what should remain unchanged. Prepare a backup and agree on a rollback procedure before changing a live store.
With this information, it is easier to compare PrestaShop modules (Polish catalogue) and ask about a particular offer. Include the module name, environment and expected result in your enquiry; keep access credentials out of the worksheet.
Technical editorial team: PrestaDev.pl. Store Terms and three product pages read on 6 October 2026. The example shows how to check information before purchase. It does not include operational tests of modules in a store. Check the current offer terms before buying.
Comments (0)