FR EN

Your update broke the site, or refuses to go through

You ran the update, and since then nothing works the way it used to. Or you ran nothing at all: a module updated itself, your host changed the PHP version overnight, and the site paid for it. Sometimes it is the other way round, and the update refuses to start because a module nobody maintains any more has been blocking it for months.

Sometimes nothing is plainly broken, which is almost worse: the site answers, but badly, without a single error message to show. In every one of these cases the hard part is knowing where to start, and that is exactly our job. We look at what the update changed, trace it back to the cause, back everything up before touching anything and quote a price before we intervene.

  • Backup before touching anything
  • Price quoted before we intervene
  • Call back in under ten minutes

Mon Site Bug assistant

human takeover within minutes

18:36
18:36

What is your request about?

Three situations

Who ran the update

Whatever update problem you are facing, it almost always falls into one of these three cases. An "I updated this module and the site has been broken since" puts us straight on the trail. But finding the cause is not your job.

Describe my situation
You ran it

A home-made PrestaShop or WordPress update

You launched the version upgrade, or simply updated a module, and everything broke. If you know which one, tell us, it puts us straight on the trail. If not, we compare the state before and after, and we isolate the change responsible. You do not have to understand what happened.

Your agency ran it

The job is delivered, the site no longer works as before

The job went through and since then the site is broken, or it no longer works the way it should. What was touched often goes beyond the update itself: a theme adjusted along the way, a module disabled to get it through. We ask for the date and the details, and reconstruct them if need be. The report we hand you is useful to your provider too.

Nobody ran it

The automatic update, the sneakiest one

Mostly under WordPress: a plugin updates itself overnight and crashes the site. The same goes for the PHP version your host changes without warning. Nobody touched anything, nobody knows when, so you have nothing to tell us. The date, though, is in the server logs, and that is where we go and get it.

The core of the site

Updating your CMS

Migrating PrestaShop to its latest version, or WordPress, means changing the core of the site. Everything built on it has to follow, and what does not follow breaks. Here are the most common cases, from the upper layers your customer sees down to the machine.

Describe my situation Update: your site can break. An update can introduce incompatibilities and cause critical errors.

What your customer sees

  1. The theme

    It was not built for this version

    A theme bought five years ago, or made to measure, relies on functions the new version has removed. The site runs but displays wrongly, sometimes only on certain pages. It is the easiest symptom to underestimate, and the most visible to your customers.

  2. Custom code

    What was written for you does not survive

    A feature developed for your site, by us or by someone else. Nobody will publish a fix, since this code exists nowhere but on your site. That is code recovery work: we read it, understand the original intent, and rewrite what needs rewriting.

  3. The modules

    They fall one after another

    A shop usually runs around fifty of them, though it can be far more, 170 say (yes, you read that right). It only takes three or four with no version ready for the new release, and they are the ones bringing the rest down. We identify them one by one and decide for each: update, replace, or disable long enough to reopen the shop.

  4. The database

    The data does not go through

    Between two major versions, the database structure changes. A migration that stops halfway leaves half-converted tables: the orders are there, but the old back office can no longer read them and the new one cannot yet. This is the case where you must not relaunch anything.

  5. The CMS core

    The update refuses to start

    PHP version too old, not enough disk space, blocking file permissions, or a module the assistant flags as incompatible. The site is not broken, it is frozen on a version that is ageing, and every month makes the upgrade heavier.

  6. The server and PHP

    The ground shifts under your feet

    The new CMS version demands a more recent PHP, the host switches over, and code that had worked for years stops dead. Two updates then happen on the same day, and the outage rarely comes from the one you suspect.

Where the update comes in

The most common case

A module or plugin update

It is the most common case we see, close to one time in two*. A single component is enough to bring a whole site down when it touches the cart, the payment or the display. The upside is that the culprit is unique, and we isolate it fast.

  1. You updated a module and everything broke

    The classic scenario. Tell us which one and we go straight to it: we return to the version that worked, or we fix the incompatibility when rolling back would reopen a security hole.

  2. The module updated itself

    Automatic updates are the rule under WordPress, the exception under PrestaShop. A plugin updates overnight, the site crashes in the morning, and you did nothing. The file modification dates tell which one moved.

  3. The licence has expired

    We see it regularly. A paid module stops receiving its updates when the subscription ends, often without anyone noticing. It keeps working, until the day the CMS moves.

  4. Two modules step on each other

    Each works on its own, the two together do not. After an update, two extensions fight over the same hook or the same page. We isolate them by disabling them one at a time, a slow method but a safe one.

  5. You no longer know which one

    You clicked "update all", or nothing at all, and the site has been broken since. It is the normal case and it is no problem: the server logs and the file dates tell what moved and when.

* Figures drawn from our real intervention statistics, frozen on 30 August 2026.

The assistant is at the top of the page

Do you recognise yourself in one of these cases?

Describe it in two lines. A technician calls you back in under ten minutes, and the first quarter of an hour of research is free.

Describe your outage in two lines… or call us on 01 84 20 89 46

Before, during, after

How far the update got

Tell us which one is yours, it saves us the first quarter of an hour of searching.

Describe my situation

It went all the way, and the site works badly

Nothing is plainly broken, but something is wrong. Slowness, a feature that answers one time in two, a display that jumps. It is the hardest case to describe, and often the one left to drag on the longest.

It stopped halfway

The process cut out in the middle: execution time exceeded, not enough memory, connection lost. The site ends up in an in-between state, neither the old version nor the new one. It can be repaired, but the update must not be relaunched on top.

You cancelled it after a failure

You went back and the site came back up, except that pieces of the new version stayed in place. Extra tables, orphan files, inconsistent cache. It holds until the next attempt.

You restored a backup instead

A reasonable decision in an emergency: the site works again as before. Still, the update remains to be done, and the orders placed between the backup and the restore may have vanished. We check both.

Questions we get asked

It is the most common case. Many requests arrive with "the site does not work any more" and nothing else. Finding the cause is part of the job: you describe what you see, we trace it back to the origin in the server logs and the file modification dates.

No, not before we have looked. Relaunching on top of an in-between state is the move that turns a repairable outage into an inconsistent database. Leave the site as it is, even if it looks ugly, we start from there.

Rarely. An update almost always fixes security holes, and undoing it reopens them. We prefer to repair the compatibility. If restoring remains the only reasonable option, we tell you before, not after.

Possibly, those placed between the backup and the restore. We compare the two states and tell you what is missing, even before we come back to the update itself.

No, and that is the reason for the first step: we back up files and database before touching anything. Whatever happens next, the state in which you hand us the site remains recoverable.

It depends on what broke, and we tell you after the diagnosis, not before. The order, on the other hand, is always the same: we restore access and sales first, and finish the rest afterwards. A site that takes orders again cannot wait for the perfect fix.

That is our daily bread. Three possible ways out: make it compatible ourselves, replace it with a maintained equivalent, or remove the feature when nobody uses it any more. We tell you which one, and what it costs, before we start.

That is the goal. Repairing without lifting the blockage would leave you on an ageing version, and the problem would come back at the next update, worse. The end-of-intervention report says what to keep an eye on for the next one.

Not systematically. They fix security holes, switching them off exposes you. What can be fixed, though, is no longer having to suffer them: a backup that runs before every update, and a staging site for major version upgrades. We tell you what is reasonable in your case.

For debugging, yes. An outage rarely reproduces anywhere other than where it happens, so we go and look for it where it is. For a major version upgrade, on the other hand, we set up a staging site and only switch over once you have seen the result.

We do not set it beforehand. We look first, free of charge for a quarter of an hour, then we quote an amount. You accept or decline, and that amount no longer moves: if the intervention takes longer than expected, the difference is on us.

We handle just about everything that exists, whatever the CMS or framework, on one condition: having access to the source code. A closed site, hosted on a platform that gives no access to its files, is the only case we cannot take on.

Has an update been blocking you since this morning?

Describe the situation in two lines. A technician calls you back in under ten minutes, and the search for the origin is free for a quarter of an hour.

Get a free diagnosis

or call us on 01 84 20 89 46

Customer reviews of our update repairs Google reviews left after a real intervention.

  • Google

    We've been working with MonSiteBug for a while now, and it's a real pleasure to be able to rely on them. Their professionalism, exceptional responsiveness, and the quality of their work make our lives so much easier. Whether it's Youssef with his solutions tailored to our needs or the rest of the extraordinary team who provide us with top-notch work, we can truly depend on MonSiteBug and have complete faith in them. Fouad, who handles our support, doesn't just fix the bugs we report to him: as soon as he spots an error or an area for improvement, he takes the initiative and offers us concrete solutions to simplify our daily operations across our entire IT ecosystem. It's this responsiveness and proactive approach that make all the difference. We can tell he truly understands how we work and anticipates our needs rather than waiting to be asked. High-quality technical support combined with a genuine commitment to customer service. Thank you Fouad and the entire MonSiteBug team, we recommend you without hesitation! The Pro Sprayer Team

    PRO SPRAYER
    PRO SPRAYER
    3 months ago
  • Google

    Excellent service, quick and efficient repair, very professional!!!

    Patrick Doisneau
    Patrick Doisneau
    6 months ago
  • Google

    Super efficient and fast support and execution. Very competent and helpful team. Very reasonable prices. Great experience!

    Tea and More Luxembourg
    Tea and More Luxembourg
    7 months ago
  • Google

    Absolutely perfect. A fatal error on my website following a module update was fixed in under an hour by Youssef and his team. What a pleasure to work with such efficient professionals. I recommend them without hesitation.

    Radio Ham Electronic
    Radio Ham Electronic
    8 months ago
  • Google

    Thanks to my website bug for their website maintenance and repair service. Another successful fix. And some great advice too.

    stéphane Prévot
    stéphane Prévot
    9 months ago
  • Google

    Excellent! Smooth communication and instant resolution.

    Muriel BOUHET
    Muriel BOUHET
    10 months ago