OXID monitoring from product page to checkout
XICTRAQ checks the homepage, cart, checkout path and admin login of your OXID shop from the outside and notices when OXID serves its offline page instead of the shop or, with a keyword, the notice about a leftover setup directory. The cookieless tracker reads product views and add-to-cart clicks on product pages from the OXID markup; you add checkout steps and revenue with calls in the template.
Check these OXID pages first
- Uptime monitoringHomepage with a keyword from the page content
/ - API monitoringCart: status and fixed page text
/index.php?cl=basket - Browser monitoringFrom product page via cart into checkout
/index.php?cl=user - Browser monitoringLogin with a test customer
/index.php?cl=account - Uptime monitoringAdmin login as a subpage
/admin/
Why the homepage is not enough for OXID
An OXID eShop controls its pages through the cl parameter: index.php?cl=details for products, cl=basket for the cart, cl=user, cl=payment and cl=order for the checkout steps, cl=thankyou for the order confirmation. When SEO URLs are active, OXID redirects such a standard URL to the stored SEO URL, if one exists. Modules and the theme hook into all of these pages. The homepage can therefore keep answering with HTTP 200 while the cart shows an error or the add-to-cart button stops responding.
On top of that come two pages that OXID itself serves in place of the shop. On a database error or an uncaught error outside debug mode, OXID shows the file offline.html with the title “Maintenance mode / Wartungsarbeiten” and sends HTTP 500 with it. And if the Setup directory is still present in productive mode, visitors see a notice to delete this directory instead of the page they requested.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with a keyword and subpages for the homepage and admin login, API checks with text assertions for the cart, browser checks for the checkout path and customer account, notifications that are not sent by the shop server, and the security scan for publicly accessible files.
Uptime, API and browser checks treat an OXID shop like any other website: what gets checked is determined by the paths, keywords and steps you set up. Let browser checks end before the order is submitted on cl=order so that no real orders are placed.
What can fail in OXID shops
“Wartungsarbeiten” page with HTTP 500
On a database error or an uncaught error outside debug mode, OXID serves the file offline.html with the title “Maintenance mode / Wartungsarbeiten” and status code 500. Despite the title, XICTRAQ does not record this as maintenance, because only a response with HTTP 503 counts as maintenance: the uptime check counts the response as an outage, and the automatic maintenance pause for alerts does not apply. If a shop replaces the page with its own, that page’s status code and text decide.
OXID’s own warning email does not arrive
OXID can send an “Offline warning!” email when the database connection fails, but only to the address in sAdminEmail from config.inc.php, which is empty in the template, at most once per offlineWarningInterval and through the PHP mail function of the shop server. Not every error that leads to the offline page triggers it. XICTRAQ’s uptime check notices the HTTP 500 response from the outside and notifies you through the channels you have set up, independently of the shop’s mail delivery.
Leftover setup directory blocks the shop
If the Setup directory is still present in productive mode, OXID shows visitors a notice to delete this directory instead of the page they requested. OXID does not set an error status for this, so a plain availability check can mistake the page for a working shop. The keyword check of the uptime monitoring fires when a configured word is missing from the homepage. The notice page uses the theme’s base frame with the page title but without header and footer, so pick a word from the visible homepage content rather than the shop name.
Cart returns an error or a blank page
After module or theme updates, the cart can show errors while the homepage and product pages keep loading. An API check requests index.php?cl=basket, follows redirects, for example to a stored SEO URL, and checks a status code and a text that you set as assertions, such as the page heading. If an error status comes back or the text is missing, XICTRAQ reports the failed check.
Add-to-cart button stops working
An error in the theme or a module can break the add-to-cart button even though every page answers with HTTP 200. A browser check opens a product page, clicks the button, which is the #toBasket element in the Flow and APEX themes, opens the cart and verifies by text that the product is listed there. If a step fails, XICTRAQ reports the run as failed and, if the capture succeeds, keeps a screenshot of that step.
Database backup exposed in the web root
After a move, an update or troubleshooting, files such as dump.sql, backup.sql, phpinfo.php or adminer.php are sometimes left in the root directory. The security scan requests a fixed list of such file names in the shop’s root directory, including .env and .git/config, and lists the files it finds with their severity in the report. If the shop answers every unknown URL with HTTP 200, the scan only checks files whose content it can recognise, such as .git/config or phpinfo.php, but not dump.sql. Files with other names or in subdirectories are not found by this probe.
How XICTRAQ recognises OXID
Two components recognise OXID independently of each other: the tracker in the visitor’s browser and the website scan. Uptime, API and browser checks do not distinguish OXID; they check what you configure.
- The tracker switches to its OXID branch when the page carries the cl-details class, which the Flow and APEX themes set on the body of product pages, or contains a product form form.js-oxProductForm. Cart and checkout pages generally lack these markers, so the branch does not apply there.
- Without these markers, only the tracker’s generic detection applies. It recognises checkout and order completion by the path of the URL; for URLs such as index.php?cl=payment the path is /index.php, and the checkout step sits in the parameter.
- The scan lists OXID eShop as the shop system when the HTML contains traces such as /oxseo.php or the string oxidesale. If they are missing, the field stays empty, even if the shop runs on OXID.
- The monitoring agent itself does not recognise OXID. So that a later technology check does not erase the result, the shop system found by the scan is kept.
- Monitoring does not depend on detection: uptime, API and browser checks test the paths, keywords and steps you set up, even if the theme carries no OXID markers.
What the tracker captures in OXID
When the tracker finds OXID markers in the markup, it reads product view and add-to-cart click on product pages straight from the shop pages. It generally does not read checkout steps and revenue from the OXID markup. It sets no cookies for this.
Captured by the tracker on its own
- Page views with referrer and UTM parameters, plus Web Vitals such as LCP, CLS and INP.
- Product views on product pages with name, price and the product ID from the aid field, as far as the theme outputs them the way Flow and APEX do.
- Add-to-cart clicks on product pages, for example on #toBasket, with product ID, name, price and the quantity from the am field.
- Checkout start and purchases with amount and, where provided, order number, if the shop writes them to the dataLayer as begin_checkout and purchase with an ecommerce object, for example through a module.
- JavaScript errors from real visits with message, file and line.
Not captured automatically
- Checkout start and order completion from the OXID markup: the OXID branch generally does not apply on the checkout pages, and the generic detection only sees the path /index.php for URLs such as index.php?cl=order.
- Revenue: the reports only receive the amount if you pass it or the shop writes a purchase with a value to the dataLayer. Tax and shipping costs only arrive through your call, not from the dataLayer, and XICTRAQ does not store the line items of an order from that call.
- Signed-in customers: the tracker has no OXID-specific way to link them, so without a change to the template they stay anonymous.
- Removing items and changing quantities in the cart: the cart rows of Flow and APEX carry none of the identifiers the tracker’s cart observation looks for.
- Add-to-cart clicks in category and search lists: in APEX and in Flow’s grid views the tracker generally does not capture them; in Flow’s line view the OXID branch reads product ID and quantity from the first product form on the page, not from the one that was clicked.
- Whether a product actually landed in the cart: what is counted is the click on the button.
- Cancellations, refunds and orders created in the shop administration. There is no automatic event for them.
Pass missing values through the JavaScript API, called after DOMContentLoaded because the tracker loads deferred: xictraq.checkout("begin") in the template of the first checkout step, xictraq.revenue(amount, "EUR", orderNumber, { tax: tax, shipping: shipping }) in the order confirmation template (page/checkout/thankyou), amounts in euros. Link signed-in customers with <meta name="xictraq:user-id" content="CUSTOMER_NUMBER"> or xictraq.identify(customerNumber, { type: customerGroup }), and refunds with xictraq.refund(orderNumber, amount, "EUR"). After adding the calls, check the first orders in the reports for duplicate or empty purchases.
The right modules for OXID eShop
Frequently asked questions
Does XICTRAQ recognise my shop as an OXID eShop?
In two places, provided the shop carries the matching markers. The tracker recognises OXID by the cl-details class on product pages or by product forms with the js-oxProductForm class, and the scan by traces such as /oxseo.php or the string oxidesale in the HTML. Uptime, API and browser checks do not distinguish OXID; they check the paths and keywords you configure.
Why are checkout start and revenue missing for OXID orders in the reports?
The tracker’s OXID branch reads product view and add-to-cart click on product pages; on the checkout pages and the order confirmation it generally does not apply. Call xictraq.checkout("begin") in the first checkout step and xictraq.revenue(amount, "EUR", orderNumber) on the order confirmation instead. If your shop already writes a purchase event with a value to the dataLayer, the tracker takes the amount and, where present, the order number from there.
What does XICTRAQ report when OXID shows the “Wartungsarbeiten” page?
The standard offline.html page comes with HTTP 500, even though its title reads “Wartungsarbeiten” (maintenance). XICTRAQ therefore records it as an outage, because only a response with HTTP 503 and a maintenance notice in the URL, title or text counts as maintenance. For planned work, set up a maintenance window in XICTRAQ during which alerts for the website pause.
Can a browser check test the OXID purchase path without placing an order?
Yes. A browser check can open pages, click, fill in fields, wait for elements and verify text, URLs or status codes. Let it end before the order is submitted, for example on the payment selection cl=payment or on the order overview cl=order without the final click. For the login at cl=account, use a dedicated test customer rather than a real customer account.
How do I link signed-in OXID customers?
The tracker has no built-in OXID-specific way to do this. Output <meta name="xictraq:user-id" content="CUSTOMER_NUMBER"> in the template for signed-in customers or call xictraq.identify(customerNumber, { type: customerGroup }). Pass a customer number, not an email address or a real name.
Why is monitoring only the homepage not enough for OXID?
In OXID, cart, checkout and customer account run on separate pages such as cl=basket, cl=payment and cl=account. If one of them fails, the homepage can keep loading normally. In addition, with a leftover setup directory OXID shows a notice without an error status, which a plain availability check does not notice. Check these pages individually for that reason and set a keyword for the homepage.