6.2Recurring problems (playbook)
The essentials in 30 seconds
- A symptom first: reproduce and describe the problem before touching code or files.
- A likely cause, not a guess: the playbook links each symptom to known causes and a targeted action.
- The net before the action: a backup and a test environment prevent a failure from turning into data loss.
Samir thread — the incident log
Samir keeps an incident log for the sites he maintains. Each entry records the symptom the user saw, the likely cause and the action that fixed the problem. Over the months, the same families recur: white screen after an update, 500 error, mixed content, silent form, 404 links and a blocked order.
Reflex: name the symptom, verify the cause, apply the targeted action — and fix the underlying issue behind a recurring incident.
One incident, one symptom
The first mistake is fixing things at random. Start by reproducing the incident and describing it precisely: which page, which form, which user, which data. A clear symptom already cuts diagnosis time.
The right reflex: the net
Before any risky operation, back up and work on a copy when possible. The goal is not to avoid every mistake, but to be able to roll back without losing content or orders.
Look for the cause, not a culprit
A recurring incident often hides a missing foundation: an abandoned plugin, postponed updates, backups never tested. Fixing the symptom is not enough if the cause returns the following month.
| Symptom | Likely causes | Actions |
|---|---|---|
| White screen after an update | plugin conflict, incompatible theme or insufficient PHP memory | restore the backup, deactivate plugins one by one, read the logs and increase memory if justified (L3.1, L5.1) |
| 500 error across the whole site | fatal PHP error, corrupted .htaccess file or memory limit reached | check server logs, restore the file or the backup, fix the faulty plugin (L3.4, L5.1) |
| Mixed content after moving to HTTPS | old http URLs in the database or in a template | replace the URLs, force HTTPS and check the loaded resources (L3.4, L5.2) |
| Silent contact form | mail sending not configured, missing SPF/DKIM or conflicting plugin | configure SMTP, send a real test and check the spam folder (L3.5) |
| 404 links after changing permalinks | rewrite rules not regenerated or missing redirects | re-save the permalinks, check .htaccess and add the necessary redirects (L1.5, L5.2) |
| Blocked order or refused payment | gateway in test mode, currency or country misconfigured, broken checkout page | check WooCommerce settings, payment logs and place a test order again (L4.1) |
Ready-to-say script — qualifying an incident (30 s)
“Can you tell me on which page, which form and which user the problem appears, and since when? I reproduce it, check the logs and fix the cause before testing again.”
Keep this for framing an incident with a client in a hurry.
Ready-to-say script — announcing a rollback (20 s)
“I am restoring the backup to bring the site back online, then I will look for the cause on a copy. The public site stays stable during diagnosis.”
Reassure: a rollback is not a failure, it is protection.
Copy-paste template — incident sheet
SYMPTOM: [page / form / message]
USER: [profile]
SINCE: [date / time]
REPRODUCED: yes / no
LIKELY CAUSE: [plugin / server / URL / setting]
ACTION: [description]
TEST AFTER FIX: yes / no
BACKUP / ROLLBACK: yes / noCopy-paste template — diagnostic order
1. Describe the symptom and reproduce it
2. Back up before any action
3. Read the server and WordPress logs
4. Isolate: plugin, theme, setting, server
5. Fix on a copy if possible
6. Test the complete journey
7. Document the cause and the solutionShowcase site
The most frequent incidents: form, HTTPS, white screen after an update.
Shop
Add orders, payments and confirmation emails to the diagnosis.
High-traffic site
Check cache, server and database before concluding it is a WordPress problem.
No staging
Always back up and work during off-peak hours with a rollback plan.
48h challenge — apply tomorrow
Take three real or simulated incidents, fill in the incident sheet and apply the diagnostic order. Note the cause and the regression test. 30 minutes.
- I describe a symptom before acting.
- I link the symptom to a likely cause.
- I back up and test after fixing.
After an update, the site shows a white screen. What is the first useful action?
A recurring incident is not an accident: it signals a foundation to fix (abandoned plugin, postponed updates, untested backup).