Question 1

What PrestaShop versions do your modules support?

Accepted Answer

Each module states its own supported PrestaShop range on its product page, check there for the exact version it covers. Most modules in the catalogue ship a single ZIP that detects the host version at install time and loads the right code path, so the same purchase keeps working as you upgrade your store over time.What "supported" means in practice:We run regression tests on a fresh install of each supported version before every release.Bug reports against any supported version are handled under the same support policy. No "sorry, that version is too old".A few modules require a newer core because the PrestaShop API they rely on did not exist in older versions; this is noted on the product page.If your store is on a very old, unmaintained core, the safer route is to upgrade PrestaShop first, we don't backport to cores that no longer receive security fixes.

Question 2

What exactly is mypresta.rocks?

Accepted Answer

mypresta.rocks is a small, focused team of PrestaShop developers based in Tychy, Poland. We've been building PrestaShop modules since 2013 and registered the company in 2018.We develop, sell and support 150+ modules covering SEO, checkout, performance, search, analytics and more. The point that matters for you: PrestaShop is the only thing we do, we're not a general agency that also touches other platforms. When you buy a module, support comes from the people who wrote it.Browse what we make in the module catalogue, or read the longer story on our about page.

Question 3

Do you offer free installation?

Accepted Answer

Premium-module support includes guidance with installation and configuration for three months. If you want our team to perform the installation, contact us to agree what is included, any separate service, and the schedule before work starts.See our support policy for what is covered.

Question 4

Do I need to use Google Tag Manager, or can I use GA4 directly?

Accepted Answer

Either works, and you can run both at once. Turn on the GTM platform and enter your container ID if you want everything to flow through Tag Manager, the module pushes all ecommerce events to the dataLayer in GA4 Enhanced Ecommerce shape, so any tag you build there receives them. Prefer to skip GTM? Turn on the GA4 platform, enter your Measurement ID, and the module loads gtag.js and sends events to Analytics directly.Marketing Revolution, tracking platforms with separate GTM and GA4 setup.Each platform is enabled on its own, so running GTM and GA4 together is fine: many shops use GTM for custom tags and triggers while GA4 direct handles native event tracking. The common mistake is double-counting, if GTM is already firing a GA4 tag from the dataLayer, don't also enable the GA4 direct platform for the same property, or you'll record each event twice. Pick one path to GA4 and keep it.In the module these are separate adapters with separate required fields: GTM needs a CONTAINER_ID, while GA4 direct needs a MEASUREMENT_ID. The master tracking switch must be enabled first; if tracking is disabled, or if a platform is active but missing its required ID, the front-office scripts for that platform are not injected.GTM route: enable GTM + CONTAINER_ID = GTM-XXXXXXX; create GA4 tags inside Tag Manager from dataLayer events.Direct route: enable GA4 + MEASUREMENT_ID = G-XXXXXXXXXX; leave GTM out of the GA4 path.GA4 direct also has optional settings that GTM does not use in the same way: IP anonymization, user ID tracking for logged-in customers, and an API secret for server-side resend of missed purchases. GTM is better when you want one container to control several vendors; GA4 direct is cleaner when you only want the module to send the standard GA4 ecommerce events without building tags in GTM.This is part of Marketing Revolution, which unifies tracking for Google, Meta, ChatGPT Ads and more from one place.

Question 5

How many modules do you currently offer?

Accepted Answer

We currently offer 150+ modules, grouped into areas like SEO and traffic, conversions and sales, checkout, and customer experience. The catalogue grows as we find new problems worth solving for store owners.Browse the full range on our module catalogue.

Question 6

Can I test the module before buying?

Accepted Answer

Yes. We run live demo stores where you can try a module's front-end and back-office with full functionality. It is the quickest way to see exactly how a module behaves before you spend anything. Browse them on our demo page.

Question 7

Will this module slow down my store?

Accepted Answer

If you're worried a tracking module will make your PrestaShop store slow, here's the honest answer: Marketing Revolution is lighter than running a separate module for each platform. Instead of 8 to 16 separate JavaScript SDKs, each adding its own DOM queries and event listeners, you get one unified event layer that all platforms share.It also loads gtag.js once and shares it between GA4 and Google Ads when both are active, so you don't pay for that script twice. The honest limit: every platform you enable still adds its own SDK script, so turning on all 16 platforms is more JavaScript than turning on 3. Enable only the platforms you actually use and the overhead stays small.If raw speed is your real concern, pair it with Performance Revolution, which handles caching and front-end optimisation directly.

Question 8

Do your modules work with PrestaShop multistore?

Accepted Answer

Most do. PrestaShop multistore is opt-in per module, and the depth of support varies, so the honest answer is "usually yes, but check before you rely on it."What we can say concretely about our modules in a PrestaShop multistore setup:Per-shop settings. Modules that store configuration save it with id_shop / id_shop_group context, so each store keeps its own setup and respects the multistore selector in the back office.Per-shop content, anything that creates database rows (FAQ entries, sitemap rules, custom blocks) is tied to the active shop.Per-shop templates. Front-end templates can be overridden in themes//modules//, the same way you override core templates.Modules that work closely with core. Like SEO Revolution and Performance Revolution. Are built and run in multistore environments. Smaller utility modules usually work too, but may not surface every option in the multistore selector. If multistore is critical to your setup, check the product page or ask us first, we'd rather you know before you buy than after you install.

Question 9

What happens if a module doesn't work on my store?

Accepted Answer

Premium modules include 3 months of support from purchase. Each module has one 30-day evaluation window: without a prior demo, request a full refund within 30 days of purchase; any demo days used count towards those same 30 days. After this window, a refund is possible only for a defect in the module's core function that we cannot fix, under our refund policy. We strongly recommend testing on a staging copy first. You install at your own risk; we are not responsible for effects on your shop. Book our paid installation and configuration service if you want us to carry that responsibility.When you report an issue, send us your PrestaShop version, the module version, and the exact error or screenshot so we can reproduce it quickly. Most reports turn out to be a theme or third-party module conflict, which we help you isolate. For self-checks before contacting us, see our PrestaShop troubleshooting guide.

Question 10

What is Meta Conversions API (CAPI) and do I need it?

Accepted Answer

Meta Conversions API (CAPI) sends purchase events to Meta from your server instead of relying only on the visitor's browser. In Marketing Revolution, the Meta server-side sender uses your Pixel ID and CAPI access token, then posts purchase events to Meta's Graph API. The point is to recover purchases that browser tracking can miss because of ad blockers, consent timing, checkout redirects or a customer closing the confirmation page too early.CAPI settings connect server-side tracking with your Meta Pixel setup.CAPI works with the missed-purchase resender. The module logs purchase tracking, the scheduled resend task runs every hour, looks back over the configured window, and sends missed orders through the configured server-side APIs. For Meta, the payload includes the Purchase event, currency, value, product contents, order ID and enhanced matching data. Email, phone, first name, last name, city, postcode, state and country are normalized and SHA-256 hashed before sending; client IP and user agent are sent unhashed because Meta expects those fields in that form.Minimal CAPI checklist:1. Meta Pixel ID in the Meta platform settings.2. Meta CAPI access token in the Meta platform settings.3. Optional Test Event Code while validating in Meta Events Manager.4. Enable Resend Missed Purchases if you want the hourly server-side recovery job.5. Keep the browser pixel enabled too, because CAPI complements it rather than replacing normal frontend tracking.Event flow:Customer reaches order confirmation -> browser pixel tries to send Purchase.Marketing Revolution logs the purchase tracking attempt.Hourly cron task -> ResendMissedPurchases finds completed orders not logged as tracked inside the lookback window.MetaConversionsApi::sendPurchase() -> POST /{pixel_id}/events with Purchase, value, currency, contents, order_id and hashed customer data.Meta Events Manager -> use the Test Event Code first, then remove it for live traffic.You need CAPI if Meta ads matter to your reporting or optimization. If you do not run Meta campaigns, it is optional. If you do run Meta campaigns, it is one of the highest-impact tracking improvements because it reduces the gap between real PrestaShop orders and what Meta can attribute.

Question 11

Can you build a custom module for my specific needs?

Accepted Answer

Yes. We take on custom PrestaShop module work when none of our existing modules cover what you need. We run shops ourselves, so we look at a request the way a merchant would: what problem it solves and whether it's worth building.Tell us what you're trying to do. send us the details and we'll give you an honest read on feasibility, timeline and cost before any work starts. If a custom module isn't the right path, or one of our existing modules already does the job, we'll say so. Not every request is something we can take on, but you'll always know upfront.

Question 12

Do you provide support after purchase?

Accepted Answer

Yes. Every premium module purchase includes three months of free support and updates through our ticket system, and support can be extended with paid packages. Whether you need help with configuration, troubleshooting, or a customisation question, your tickets are answered by working PrestaShop developers, we run shops ourselves, not by an outsourced support desk. Free modules come without a support entitlement, but genuine bug reports are always welcome. For full details, see our support policy.

Question 13

How does the missed purchase resender work?

Accepted Answer

It recovers purchases that browser-side tracking missed: the module logs the purchase events it does capture, and the hourly cron compares recent valid PrestaShop orders against that log to find any order that never produced a purchase event. Each missed order is then replayed server-side.Resends go out through the GA4 Measurement Protocol and/or the Meta Conversions API. This only runs if you have entered the server-side credentials - a GA4 API secret and/or a Meta access token; without them there is no channel to send through, so the job skips. You choose how far back it looks: 6, 12, 24, 48 or 72 hours. ChatGPT Ads also sends every purchase through the OpenAI Conversions API; failed server events can be retried, and withdrawn consent stops orders still waiting to be sent.The feature is off by default. To use it, enable missed purchase resending, keep purchase logging enabled, and make sure the module's cron is running; the module registers an hourly resend_missed_purchases task. The default lookback is 24 hours, and the lookup selects valid PrestaShop orders in that window that have no purchase row in the module's tracking log.GA4 resend: requires the GA4 Measurement ID and API secret. The module sends the purchase through Measurement Protocol.Meta resend: requires the Meta Pixel ID and Conversions API access token. A Meta test event code can be used while testing.Logging: after a successful resend, the cron writes a purchase log entry with source cron_resend, so recovered orders are recorded and will not be resent again.A useful detail: this is not a magic replay of the customer's exact browser session. For a missed order, the module rebuilds the order payload from PrestaShop order data and sends it server-side. That is still valuable for purchase attribution and reporting, though browser-only details that were never captured may not exist for the resend.The resender is built into Marketing Revolution, our all-in-one tracking module.

Question 14

What languages are your modules available in?

Accepted Answer

Our store and the module admin screens are available in English, German, French, Polish, Italian, and Spanish. The customer-facing output of most modules follows whatever languages you have set up in your PrestaShop store. The text shown to shoppers comes from your own translations, not from hardcoded strings. More about us: about mypresta.rocks.

Question 15

Does MPR FAQ add SEO schema and index controls to PrestaShop FAQ pages?

Accepted Answer

Yes. FAQ Manager gives you indexing control over your FAQ instead of letting search engines crawl every thin question and search page - so you decide exactly which answers are worth indexing.Indexing is decided per page type, and you stay in charge:FAQ landing page - indexable by default (index/follow), since it is your real entry point.Individual question pages - opt-in. You turn on a master switch, then mark the specific questions worth indexing. Only those use index/follow and can be added to the XML sitemap; the rest stay out.Search results pages - always noindex, so you do not pollute the index with internal search URLs.Category and tag pages - category pages are optionally indexable and can be included in the sitemap when category sitemap policy and the per-category indexable flag allow it. Tag pages are kept out of the sitemap.There is also structured data. The module can emit FAQPage schema on a question page; this output is configurable and off by default, so you turn it on only if a structured-data consumer needs it. The real focus here is the index controls - schema and robots tags are about steering which pages search engines crawl, not a guaranteed outcome.See FAQ Manager for the full feature set.The defaults are strict on purpose: schema is disabled by default, individual question pages are not indexable by default, the FAQ hub is indexable, category and tag pages are not indexable by default, search pages are never indexable, and sitemap inclusion is enabled only for page types allowed by the SEO policy. That keeps a new FAQ from flooding the index before you have reviewed which answers deserve standalone search visibility.For individual question schema, the controller only builds FAQPage JSON-LD when the question is active, published, indexable, has non-empty question and answer text, and the relevant schema policy allows it. Hub schema is also limited: it selects a small set of active, published, indexable questions sorted by usefulness and visibility signals, rather than dumping every draft or low-value answer into structured data.The sitemap hook follows the same discipline. It can add the hub URL, category URLs that are active and indexable when category sitemap policy allows them, and question URLs that are active, published, have a slug and are marked indexable. A draft, preview, noindex or unpublished question should therefore stay out of the sitemap even if it exists in the FAQ tables.The admin configuration also warns that Google has reduced FAQ rich-result display, so FAQ schema should not be treated as a magic rankings switch. The practical SEO value is editorial control: publish useful answers, index the ones that can stand alone, and keep search pages, thin tags and unreviewed questions out of the index.

Question 16

Are your modules compatible with my theme?

Accepted Answer

If your goal is to customise a theme safely, the cleanest approach on PrestaShop is a child theme. Your changes live in the child and survive parent-theme updates. Our free Child Theme Generator scaffolds one for you.It generates a ready-to-use child theme for these parent themes:Classic, the default PrestaShop theme.Hummingbird, the lightweight PrestaShop 8/9 theme.Warehouse, the popular PrestaShelf/Warehouse parent.The generated child ships a config/theme.yml that points at the chosen parent and sets use_parent_assets, so the child inherits the parent's styling out of the box. It also scaffolds a custom.css and custom.js for your own tweaks, plus optional template overrides when you need to change parent markup.Put your CSS, JavaScript and template changes in the child theme, and a later update to the parent won't overwrite them.

Question 17

Does Marketing Revolution work with Consent Mode v2?

Accepted Answer

Yes. Marketing Revolution includes a Consent Mode v2 bridge that connects supported cookie banners to Google's consent signals. It is designed to detect four consent platforms automatically: MPR Cookies Revolution, Cookiebot, any IAB TCF v2 banner, and OneTrust.When the bridge runs with window.mprMarketingConfig.consentMode available, it sets Google's default consent for analytics and ads to the configured default values, usually denied for an EU-style setup, and then updates consent when the visitor accepts the relevant categories. The bridge passes consent state to Google; it does not block third-party scripts on its own. Script blocking remains the job of the cookie banner or CMP.There is an important current-code ordering caveat. The bridge exits immediately if window.mprMarketingConfig is not already defined, while the header template prints platform init scripts and page event scripts before it defines that config object. Because of that, the current build does not guarantee that denied/default consent is applied before Google tags or page events run. For strict Consent Mode sequencing, verify the actual rendered order in your theme or adjust the module so the config and default consent command are present before any Google init/event scripts.Consent Mode is disabled by default in the module settings. When enabled and when the bridge has the config object in time, the default module values are denied for analytics storage and denied for ads storage unless you deliberately change them.The bridge sends Google's v2 consent fields: analytics_storage, ad_storage, ad_user_data and ad_personalization. It also leaves functionality_storage and security_storage granted, and uses a wait_for_update window of 500 milliseconds so a CMP update can arrive before Google processes hits.Default EU-style setup: Consent Mode enabled; analytics default = denied; ads default = denied; CMP accepts analytics + marketing; bridge updates Google consent to granted.If your CMP is not one of the supported integrations, you need a small custom bridge that calls the same update path when the visitor changes consent. Without that, Google will keep whatever consent state was last sent to it, even though the banner UI changed.Marketing Revolution handles the tracking side; for the banner itself see Cookies Revolution, our GDPR consent module.

Question 18

Are your modules open-source?

Accepted Answer

No. Our modules are commercial software under a proprietary license. You do, however, get the full PHP source code: nothing is obfuscated, encrypted, or wrapped in ionCube. You can open every file, your developers can audit it for security or compatibility, and you can adapt minor parts to your shop's specifics.What our license terms allow: install on the domains covered by your license, customise overrides and templates for your own use, and keep using the version you bought indefinitely. What you may not do: redistribute, resell, sublicense, or republish the core code, fork it as a derivative product, or remove the original copyright notice.Open code matters in practice: every PrestaShop or PHP change is visible and fixable, security reviews are possible, and you are never locked out of your own shop if a vendor stops responding.

Question 19

Can I use this alongside my existing Google Analytics module?

Accepted Answer

You can, but never let two modules inject the same Google Analytics tag, that double-counts every event and inflates your reports. Pick one module per platform: if you enable GA4 in Marketing Revolution, disable or uninstall any other GA4 module first, and vice versa.Marketing Revolution > Platforms, enable one tag source so you don't double-track alongside an existing GA module.If you want a single dedicated PrestaShop Google Analytics module instead, our standalone Google Analytics GA4 module handles GA4 on its own (browser plus server-side Measurement Protocol and Consent Mode v2). Running it side by side with another GA pack is fine only if exactly one of them is sending GA4. The other should keep GA4 switched off.It is also fine to split platforms: use Marketing Revolution for, say, TikTok, ChatGPT Ads and Pinterest while a separate module owns GA4. The rule is one tag per platform, not one module per store.Marketing Revolution is built around a master tracking switch plus platform-specific adapters. That means a safe mixed setup is possible: for example, keep your existing GA4 module active, leave the GA4 adapter disabled in Marketing Revolution, and enable only TikTok, Pinterest, ChatGPT Ads, Reddit or Meta in Marketing Revolution. The front office config exposes the active platform slugs, so Debug Mode makes it easy to see what the module thinks is active.Unsafe: another module loads G-XXXXXXXXXX and Marketing Revolution GA4 direct also loads the same measurement ID.Usually safe: Marketing Revolution pushes GTM dataLayer events while a separate GA4 module owns direct GA4, as long as the GTM container is not also firing GA4 ecommerce tags for the same property.Safe split: existing GA4 module owns GA4; Marketing Revolution owns Meta, ChatGPT Ads, TikTok, Pinterest, Snapchat, Reddit or other non-GA platforms.When testing, open the page source or browser network panel and search for the GA4 Measurement ID and GTM container ID. Seeing one intentional owner is normal; seeing the same GA4 property loaded from multiple modules is the warning sign.

Question 20

What monitoring data can the module store?

Accepted Answer

Performance Revolution stores technical monitoring data about your shop, but not every monitoring table has the same privacy profile. RUM rows are built around timings, URL, device class and shop context rather than customer profile fields; slow-query logging is different because it stores raw SQL text and stack-trace context, so treat it as potentially sensitive diagnostic data if your queries contain customer, cart or order identifiers.Concretely, the module keeps these tables:Performance metrics - timed measurements with a metric type, value and JSON context, used to chart how the shop behaves over time.Aggregated metrics - rolled-up values by hour, day, week and month, including sum, average, min, max and count, so dashboards remain usable on longer date ranges.Slow queries - query hash, SQL text, execution time, controller, stack trace, occurrence count and first/last seen timestamps. The schema may contain extra placeholders, but the profiler path records those fields rather than rows examined or rows sent.Real-user monitoring (RUM) - browser timing data from sampled visits: TTFB, FCP, LCP, CLS, FID and INP, plus DOM timing fields, a resource-timing summary, URL, device type and shop.RUM aggregates - hourly per-URL, per-device sample counts and averages for the RUM metrics. The aggregate schema includes a p75_lcp column, but the current aggregation query does not populate it.Common mistake: treating all monitoring data as equally low-risk. RUM is timing/device diagnostics, but slow-query rows can expose whatever was present in the SQL statement. Restrict access to those diagnostics the same way you would restrict access to database logs.The defaults are deliberately conservative. Fragment cache is enabled with a 3600-second TTL, query cache is enabled, metrics are enabled, the slow-query threshold defaults to 0.1 seconds, metric retention defaults to 30 days, profiling is off by default, and RUM sampling defaults to 0.1, meaning roughly 10 percent of eligible page views are measured. On a low-traffic shop, that sampling rate can make RUM charts look sparse until enough visitors have been measured.The front script collects browser timings with the Performance APIs, then sends them with sendBeacon when available and falls back to XHR. The RUM controller accepts JSON POST data, validates that a URL exists, stores sanitized timing/resource fields, and returns a 204 response with no-store/noindex headers. The controller also removes Set-Cookie headers, so the beacon endpoint itself is not creating customer cookies.For cleanup, the query profiler records slow SQL by hash and updates the occurrence count and last-seen time when the same query recurs. Raw RUM data can be aggregated into hourly summaries and older raw rows are removed after aggregation, keeping long-term dashboards usable without storing every individual beacon forever. The important limitation is that current RUM aggregation stores averages and counts, not a calculated 75th percentile LCP.

Language

Currency

PrestaShop Module FAQ

Browse by category

Most helpful answers

Also in our Knowledge Base

Still have questions?