When a WordPress site breaks, one sentence I hear very often is:
“But it worked yesterday.”
I understand why people say this.
But from a debugging point of view, this sentence does not help at all.
Let me explain why — in a simple way.
Websites don’t change by themselves (usually)
A WordPress website does not randomly break overnight.
Something always changes, even if no one notices it immediately.
That “something” can be:
- a plugin auto-update
- a theme update
- a WordPress core update
- a hosting PHP version change
- a cache clear
- a small CSS or settings change
So when someone says “it worked yesterday”, what they really mean is:
“I’m not sure what changed.”
That’s okay — but it’s important to understand this difference.
“Yesterday” is not a technical reference point
From a developer’s point of view, we don’t debug based on time.
We debug based on changes.
Questions that actually help are:
- What was updated last?
- Was any plugin installed or removed?
- Did hosting settings change?
- Was any custom code added?
“Yesterday” does not answer any of these.
Auto-updates are silent troublemakers
Many sites have:
- plugin auto-updates enabled
- theme auto-updates enabled
- WordPress auto-updates enabled
These updates usually happen without notification.
So the site may look fine one day,
and break the next day — even if no human touched it.
This is very common.
Hosting changes happen without warning
Hosting providers sometimes:
- upgrade PHP versions
- change server configurations
- restart services
- migrate servers
These changes can break:
- older plugins
- outdated themes
- poorly written code
Again, nothing “visible” changed — but technically, everything did.
Caching hides problems until it doesn’t
Sometimes:
- cache shows the old working version
- visitors see cached pages
- admin sees something different
Then suddenly:
- cache expires
- problem becomes visible
So the issue was already there —
it just wasn’t visible earlier.
Debugging needs facts, not feelings
“It worked yesterday” is an emotional statement.
Debugging needs:
- logs
- recent changes
- update history
- reproducible behavior
When I debug a site, I never start with time.
I start with:
- what changed
- where it changed
- how it affects the system
A better way to say it
Instead of saying:
“It worked yesterday”
A much better thing to say is:
- “A plugin was updated yesterday”
- “Hosting changed PHP version”
- “We installed a new plugin recently”
- “We don’t know what changed”
Even “I don’t know” is more useful than guessing.
Why this matters in real support work
Clear communication saves time.
When clients understand this:
- debugging becomes faster
- fixes become cleaner
- trust improves
As a support-focused developer, I don’t judge this statement —
I just translate it into something useful.
Final thoughts
Websites don’t break because of time.
They break because of changes.
Once you stop thinking in terms of “yesterday”
and start thinking in terms of “what changed”
debugging becomes much calmer and more effective.
