Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

My shop has a problem: where to start

Your shop no longer behaves the way it did yesterday, and you don't yet know why. This section gathers thirty failures sorted by what you actually see on screen rather than by technical cause: you start from the symptom, the page leads you to the likely origin.

Describe my issue Send a message

A store screen in alert with diagnostic paths branching to several possible causes, one lit in amber.

Who this section is for

You are here because something is wrong and the error message, when there is one, tells you nothing. Checkout no longer completes, the admin refuses to open, a page stays blank, or the site answers in ten seconds when it used to answer in one. At that moment the question is not which supplier to hire: it is where the failure comes from.

These pages are written for someone who has no diagnosis yet. They start from what can be seen — a screen, a behaviour, a warning email from the host — and work back towards the possible causes, most frequent first. None of them assumes you can read code.

How the section is organised

The thirty pages fall into four families. Display failures: blank page, missing images, theme broken after an edit, mobile layout gone wrong. Functional failures: payment impossible, checkout blocked, emails not received, imports and exports failing, a sync that stopped. Infrastructure failures: 500 error, 504 error, database connection refused, domain no longer pointing anywhere, expired certificate. And management situations: a site left without maintenance, an unreachable previous supplier, a failure that appeared right after an update or a hosting change.

If your symptom is in the list below, go straight to that page. If you hesitate between several, start with the one that separates a site failure from a hosting failure: it is the first fork in the diagnosis, and it stops you searching on the wrong side.

Display or server: the distinction that saves time

A display failure still lets the server answer: a page does come back, it is simply empty, wrong or badly styled. A server failure prevents the answer from existing at all: the browser gets a 500, 502 or 504, or waits until it times out. In the first case the cause is nearly always in the theme, a module, the cache or a file path. In the second it sits with PHP, the database or the hosting configuration.

Either way the reflex is the same: open the error log before touching anything. On PrestaShop the useful information is in var/logs/ and in the host's own log; on WordPress the WP_DEBUG_LOG constant writes to wp-content/debug.log. A single line there often names the offending file. Changing the site before reading it means erasing the trace that held the answer.

The four most useful pages first

In this section

Frequently asked questions

I can't name my symptom, where do I start?
With the page that separates a site failure from a hosting failure. It needs no technical skill: it has you check three things visible from a browser, and the result sends you to the right family of pages.
Do I need FTP or SSH access to follow these pages?
Not for the diagnosis. Most checks are done from the shop admin or from the hosting panel. File access becomes necessary at the point of fixing, and the pages say so when it does.
Do these pages apply to both PrestaShop and WooCommerce?
Yes: the symptoms described here are common to both platforms, and Shopify shares some of them. Where the steps differ by platform, the page gives both paths rather than one.
My shop is down right now, do I really have to read first?
Read at least the paragraph that identifies the cause: it takes five minutes and it avoids the moves that make things worse, such as reinstalling a module or clearing a cache before noting the error message.
The site is working again on its own, should I still investigate?
Yes. A failure that clears by itself is nearly always a temporary saturation: PHP memory, a heavy scheduled task, a traffic spike, a full disk. It comes back, usually at the worst moment, and the log for that period still holds the trace.

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

etat
plateforme
declencheur
acces (facultatif)
url (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Related pages