PrestaShop monitoring from checkout to cron
XICTRAQ checks cart, checkout, webservice and cron runs of your PrestaShop shop and reports when an embedded third-party script changes its content. What the cookieless tracker captures in PrestaShop on its own, and what it does not, is listed further down.
Check these PrestaShop paths first
- Uptime monitoringCart page, with or without friendly URLs
/index.php?controller=cart&action=show - Uptime monitoringCustomer login page
/index.php?controller=authentication - Uptime monitoringProduct search with a search term
/index.php?controller=search&s=test - Browser monitoringFrom product page via cart to checkout
/index.php?controller=order - API monitoringWebservice with key in the Authorization header
/api/
Why a reachable homepage is not enough
You extend PrestaShop with modules. According to the developer documentation, they attach to specific shop events through hooks and mostly insert content into a page. Payment and shipping modules mainly act in cart and checkout – if something goes wrong there after a module update, the homepage can keep responding normally.
Then there are tasks that run via crontab: for example updating exchange rates via cron_currency_rates.php in the admin folder, or exports and syncs that you or a module trigger. If they stop, the shop stays reachable – and a plain availability check sees none of it.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with subpages for cart, login and search, browser checks for the path to checkout, API checks for the webservice, heartbeats for cron tasks and script integrity for externally embedded scripts.
XICTRAQ usually treats PrestaShop maintenance mode as an outage: the maintenance page answers with HTTP 503, and neither the English default text nor its German translation from the language pack contains any of the maintenance phrases the check node uses to recognise planned maintenance. If your maintenance text contains “Wartungsarbeiten” or “Wartungsmodus”, however, the page counts as maintenance and outage and content alerts pause – even if maintenance mode is accidentally left on. So create a maintenance window for updates; outage and subpage alerts stay silent during it.
Where PrestaShop shops break – and which module notices
Maintenance mode stays on after an update
In maintenance mode, PrestaShop shows visitors a maintenance page with HTTP 503, while allowed IP addresses and – by default – employees signed in to the back office see the normal shop. Anyone checking from an allowed address or with an open back office session therefore notices nothing. Uptime monitoring checks from the check nodes and treats the default maintenance page as an outage as long as their addresses are not allowed; outside a maintenance window, an alert follows.
Checkout breaks after a module update
An update of a payment or shipping module or of the theme changes the checkout, and a step no longer loads. A browser check set up for this adds an item to the cart, opens checkout and verifies that the expected elements appear, without submitting the order. If a step fails, it stores a screenshot of that point.
Cart or login fails, homepage does not
The homepage can keep responding while cart, customer login or search return an error, for example after updating a module that hooks into those pages. XICTRAQ checks monitored subpages on every uptime run; if one fails, a separate alert names the affected path.
Exchange rates or exports stop updating
After a server move or a deleted crontab entry, a cron task no longer runs. A heartbeat ping after the call then goes missing and XICTRAQ reports a missed heartbeat; calling the /fail address triggers a failure alert. The ping proves the call, not its effect: if the key in the cron_currency_rates.php address no longer matches, for example after the shop has been renamed, the call has no effect and reports no error.
A third-party script changes its content
Modules can embed scripts from third-party providers, for example for payment or chat. Script integrity stores the SHA-256 hash of externally embedded scripts in the source of the homepage and of the pages of your verified website that you check in the live scan (up to twelve per page), and reports when one changes or becomes unreachable; scripts added later are included without a report at the next live scan. It does not reach scripts that only load in checkout, because PrestaShop redirects from checkout to the cart when the cart is empty; nor does it cover files your shop serves from /modules/ or /themes/ under its own address. This is an indication, not conclusive proof of security.
Webservice returns errors
ERP or marketplace connections can access the shop through the webservice. If the Authorization header no longer reaches PrestaShop after a server change, authentication fails; the developer documentation points to the CGIPassAuth directive for this. An API check calls /api/ with your key and verifies status code, response time and an expected text in the XML response; if the response deviates twice in a row, an alert follows.
How XICTRAQ recognises PrestaShop
PrestaShop is recognised in two places: in the live scan and in the tracker. Neither works for every shop; this determines what appears in the technology overview, the CRA cockpit and analytics.
- The live scan lists PrestaShop as the shop system when the page source contains a generator meta tag with “PrestaShop” or addresses containing /prestashop/js or /modules/prestashop; the default themes Classic and Hummingbird output no generator tag. If the shop loads module scripts individually, for example under /modules/ps_shoppingcart/, PrestaShop at least appears under “Additional detected technologies”.
- The ongoing technology detection on the check nodes does not include PrestaShop. If it finds nothing, however, a PrestaShop finding from the live scan stays in place.
- The tracker recognises PrestaShop pages by the JavaScript object prestashop, which PrestaShop writes into its shop pages, or by the elements #product-details and [data-product]. It reads product views from the structured product data (JSON-LD), and add-to-cart click, checkout start and order completion from the markup.
- In the CRA component cockpit, a PrestaShop shop recognised as the shop system appears without a version number and is therefore marked as not assessable. There is no matching against security advisories for PrestaShop.
- Detection of the order amount is built around the Classic theme. Hummingbird, the default theme since PrestaShop 9.1, and custom themes differ from it; there you pass amount and order number through the JavaScript API.
What the tracker captures in PrestaShop
The cookieless tracker reads product views from the structured product data that Classic and Hummingbird output, and recognises add-to-cart click, checkout start and order completion from the markup. Order number and amount do not arrive reliably this way; pass both yourself as described in the note below.
Captured by the tracker on its own
- Product views with reference (otherwise product ID), name, price and currency from the product page’s JSON-LD data, plus category and brand (manufacturer, otherwise shop name)
- Clicks on “Add to cart” (.add-to-cart and [data-button-action="add-to-cart"]) as a cart event
- Checkout start on the order page when its path contains “order” or “bestellung”
- Order completion on the order confirmation page, in Classic with the amount from the total row
- Events a module places in the dataLayer: view_item, add_to_cart, begin_checkout and purchase with ecommerce.value
Not captured automatically
- The order number: in Classic, the tracker takes a word of the label instead of the reference, such as “Order” or “Bestellnummer”. Automatically detected purchases in the same shop language therefore share one identifier and only count when no purchase with that identifier came in during the previous 30 days; in Hummingbird, the number is missing entirely
- A reliable amount: in Hummingbird, the tracker reports the purchase with an amount of 0, it sets the currency to EUR regardless of the shop, and in Classic a label such as “(tax incl.)” in the total row can distort the amount
- Signed-in customers: the page’s prestashop object contains no customer ID the tracker could read
- Quantity changes, removed items and the cart total on the cart page: the Classic markup does not match the tracker’s selectors
- Whether an item actually made it into the cart: the click on the button is what gets counted, and the tracker reads the product details from the surrounding markup, where they can be incomplete
- Checkout start when the path contains neither “order” nor “bestellung” – for example without friendly URLs under /index.php?controller=order, or with a differently named checkout address in another shop language
- Refunds and credit slips: they are created in the PrestaShop back office, not in the customer’s browser
Pass amount and order number through the JavaScript API once the tracker has loaded, for example in the template checkout/order-confirmation.tpl: xictraq.revenue({$order.totals.total_including_tax.amount}, "{$currency.iso_code}", "{$order.details.reference}"). Make signed-in customers recognisable with {if $customer.is_logged}<meta name="xictraq:user-id" content="{$customer.id}">{/if} in the theme’s head or with xictraq.identify(customerId, { name }). The automatic detection reports the purchase as well: in Hummingbird both reports then count, so revenue is correct but the number of orders is too high; in Classic the automatic report counts when no other one with the same label word came in during the previous 30 days. After adding the call, check in analytics that amount and number of orders are correct.
The right modules for PrestaShop
Frequently asked questions
Does XICTRAQ treat PrestaShop maintenance mode as an outage?
With the English default text and its German translation from the language pack, yes: the maintenance page answers with HTTP 503 and contains none of the maintenance phrases XICTRAQ uses to recognise planned maintenance. If your maintenance text contains “Wartungsarbeiten” or “Wartungsmodus”, the page counts as maintenance, and outage and content alerts pause for as long as it responds that way. For updates, a one-off or weekly recurring maintenance window is the better choice; outage and subpage alerts stay silent during it.
How do I monitor cron tasks in PrestaShop?
Create a heartbeat in XICTRAQ for each task with the schedule of your crontab entry and call its ping address after the actual call. If the ping is missing, XICTRAQ reports a missed heartbeat; the /start and /fail addresses additionally report the start and failure of a run. The ping shows that the call took place, not that the task achieved its goal.
Does XICTRAQ recognise my shop as PrestaShop automatically?
Not always. The live scan looks for a generator meta tag or certain addresses in the page source, and the default themes Classic and Hummingbird output no generator tag. The tracker, on the other hand, recognises PrestaShop pages by the JavaScript object prestashop. You set up subpage, browser, API and heartbeat checks independently of the detection.
Does XICTRAQ check my PrestaShop version for vulnerabilities?
No. The live scan does not read a PrestaShop version number, and there is no matching against security advisories for PrestaShop. The security scan checks general points such as security headers, TLS and exposed files like .git/config, .env or SQL dumps, but no PrestaShop-specific paths. Installing updates for PrestaShop and its modules remains the job of your team or agency.
Why are revenue or order count wrong for PrestaShop?
The automatic detection reads the order confirmation from the markup: in Classic it takes a word of the label instead of the reference, in Hummingbird it reports the purchase without a number and with an amount of 0. Reliable values come from a call to xictraq.revenue() with amount, currency and reference on the order confirmation page or from a purchase event with ecommerce.value in the dataLayer. The automatic report remains alongside, and analytics only counts reports with the same order number once. So after adding it, check that amount and number of orders match.
How does XICTRAQ recognise signed-in customers in PrestaShop?
Not on its own, because the page’s prestashop object contains no customer ID. Output a meta tag xictraq:user-id with the customer number in the theme for signed-in customers, or call xictraq.identify(). Pass the customer number from PrestaShop, not an email address.