6.2Recurring problems (playbook)
The essentials in 30 seconds
- Diagnose: a symptom = probable causes = a sequence of actions — you don't fix at random.
- Roots: cache not cleared, image not compressed, missing overlay, over-nesting, a setting made at the wrong breakpoint, a forgotten display condition — most blocks.
- Check: always on a real mobile and after clearing the cache — not just in the editor on a desktop.
Through-line — the sheet taped next to the screen
Nadia keeps this sheet next to her screen in Oran. Verdict after a few projects: three lines served her most — "my changes don't show" (cache), the banner overflowing on mobile, and the form not arriving. For each, she ended up applying the sequence (symptom, causes, actions) instead of guessing.
Symptom observed, causes checked, actions in order: the reflex holds in three steps.
One reflex per symptom
Most Elementor blocks are big classics. Linking each symptom to its probable causes and a sequence of actions saves precious time.
| Symptom | Likely causes | Actions |
|---|---|---|
| My changes don't show | cache (plugin/host/browser) not cleared | clear the site and browser cache; reload; check in private browsing |
| The banner overflows on mobile | no wrap, setting made only on desktop | mobile mode: enable wrap, shrink titles/paddings; test on a real phone |
| Text unreadable on an image | no overlay, insufficient contrast | add a semi-transparent overlay; adapt the text color |
| The site is slow | heavy images, no cache, too many themes/plugins | compress the images (WebP), enable a cache, lighten; re-measure the Core Web Vitals |
| The header/footer doesn't show | display condition not set (Theme Builder) | open the template ▸ Conditions ▸ "whole site" (or targeted pages) |
| The form doesn't send an e-mail | after-submit action misconfigured, WordPress e-mails not delivered | check the e-mail action; set up reliable sending (SMTP); test a real submission |
| Responsive painful to set | over-nesting of containers | open the Navigator; flatten the useless containers; simplify |
| A setting breaks another screen size | setting made at the wrong breakpoint | set in the right mode (it applies to that breakpoint and smaller) |
| Pop-up that annoys / drives people away | triggered on arrival, not closable | trigger after engagement/on exit, once; clear cross; test on mobile |
Ready-to-say script — diagnosing without guessing (30 s)
"My symptom: [invisible changes / banner overflowing / silent form]. I check the probable cause (cache, breakpoint, display condition, SMTP), apply the targeted action and prove it on a real mobile."
Copy-paste template — Elementor diagnosis
SYMPTOM: _______________
PROBABLE CAUSE (cache / wrap / overlay / images / condition / SMTP): ___
TARGETED ACTION: _______________
PROOF (real mobile, cache cleared, e-mail received): _______________Tradesperson / small budget
No formal table: a symptom, the probable cause, the action and the proof, noted.
SME Oran
Factor in local realities: test on a real phone and an ordinary mobile network, not just fast Wi-Fi.
Remote / hybrid
Add a screenshot to the diagnosis: remotely, a written symptom and proof avoid back-and-forth.
Multilingual
Check each symptom in RTL (AR) too: a setting valid in FR may break the mirrored display.
48h challenge — apply tomorrow
Spot 1 current problem (invisible changes, mobile banner, silent form), apply the table line (symptom + checked cause + action) and prove it on a real mobile.
- I can link a symptom to its probable causes.
- I check cache, breakpoint and condition before fixing.
- I prove each fix on a real device.
Nadia's changes don't appear live even though she published. Which reflex does the table apply?
The same problem recurring endlessly is not ten incidents: it's a design problem to fix at the root (structure, style guide, global parts).