De site is niet stuk. Hij laadt, de teksten staan er, de knoppen doen het. Maar hij ziet er niet meer uit zoals gisteren. De kolommen op de homepage staan onder elkaar in plaats van naast elkaar. Het lettertype is teruggevallen op iets standaards. De huisstijlkleur is weg, de header is hoger, en op de telefoon staat het menu half buiten beeld. Iemand heeft een update gedraaid, en de opmaak is meegegaan.

Een verschoven layout in WordPress na een update is een van de meest frustrerende storingen, omdat er geen foutmelding is om vanuit te gaan. Toch zijn er maar een handvol oorzaken, en die zijn vrij eenvoudig uit elkaar te houden. In dit artikel loopt u ze van meest naar minst waarschijnlijk af.

Eerst uitsluiten: is het de cache?

Voordat u ergens aan gaat sleutelen, wilt u zeker weten dat u naar de echte site kijkt. Na een update worden CSS-bestanden vaak gewijzigd, maar een cacheplugin, uw browser of een dienst als Cloudflare kan de oude CSS nog bewaren terwijl de nieuwe HTML al wordt geladen. Die combinatie ziet er precies uit als een kapotte lay-out.

  1. Leeg de cache van uw cacheplugin (WP Rocket, LiteSpeed Cache, W3 Total Cache of wat u gebruikt).
  2. Heeft u Cloudflare of een andere CDN, leeg ook daar de cache.
  3. Bekijk de site in een privévenster of met Ctrl+F5.
  4. Gebruikt u een optimalisatieplugin die CSS samenvoegt of minimaliseert? Zet die functie tijdelijk uit en kijk opnieuw.

In onze ervaring is bij ruwweg een derde van de meldingen na deze stap alles weer in orde. Dan hoeft u niet verder te lezen, maar noteer wel welke plugin de oude CSS vasthield.

Oorzaak 1: aanpassingen in het thema zijn overschreven

Dit is de grote. Een webbouwer heeft ooit kleuren, afstanden of lettertypen rechtstreeks in de bestanden van het thema aangepast, in style.css of functions.php. Bij een thema-update worden die bestanden vervangen door de nieuwe versie, en alle aanpassingen zijn weg. De site valt terug op het standaarduiterlijk van het thema.

U herkent dit aan een lay-out die niet zozeer kapot is als wel “anders”: generieke kleuren, standaardlettertypen, een andere breedte. De oplossing is niet om de aanpassingen opnieuw in de themabestanden te zetten, want dan gebeurt het bij de volgende update weer. De oplossing is een child-thema: een klein extra thema dat de aanpassingen bewaart en het hoofdthema met rust laat. Waarom dat werkt en hoe u het opzet, leest u in onze uitleg over child-thema's. Haal de verloren aanpassingen intussen uit de back-up van vóór de update; vergelijk het oude en nieuwe style.css naast elkaar.

Oorzaak 2: de pagebuilder en het thema lopen niet meer gelijk

Elementor, Divi, WPBakery en Beaver Builder hebben elk een eigen manier om kolommen, afstanden en breedtes te berekenen. Als de pagebuilder wordt bijgewerkt maar het thema niet (of andersom), kunnen die berekeningen uiteenlopen. Typische verschijnselen: kolommen die onder elkaar vallen, containers die de volle breedte innemen, afstanden die verdubbelen.

Bij Elementor is de meest voorkomende oorzaak de overstap van de oude sectie-kolomstructuur naar flexbox-containers, en bij grote versiesprongen het uitzetten van oude compatibiliteitsopties. Kijk in de instellingen van de pagebuilder onder Functies of Experimenten en zet recent gewijzigde opties terug. Werk daarna het thema en de bijbehorende themaplugin (bij veel premium thema’s een aparte “core”-plugin) bij naar de nieuwste versie, in die volgorde: eerst thema, dan themaplugin, dan pagebuilder.

Oorzaak 3: aangepaste CSS staat op een plek die is gewist

Naast de themabestanden zijn er nog drie plekken waar aangepaste CSS kan staan: het veld Extra CSS in de Customizer, de CSS-instellingen van de pagebuilder, en een aparte CSS-plugin. Bij het wisselen van thema of bij het omzetten van een klassiek thema naar een blokthema wordt het Customizer-veld soms leeggemaakt. Het gevolg is dat kleine maar zichtbare details verdwijnen: de kleur van links, een verborgen element dat opeens weer zichtbaar is, een aangepaste knop.

Controleer alle drie de plekken. Is het veld leeg, dan zit de oude inhoud in de database van uw back-up onder de themainstellingen. Een specialist kan die er in enkele minuten uithalen.

Oorzaak 4: een lettertype of icoon laadt niet meer

Als alleen de lettertypen anders zijn, of als er overal vierkantjes staan waar iconen hoorden, dan laadt een extern bestand niet. Dat gebeurt na updates die Google Fonts lokaal gaan hosten (goed voor de AVG, maar de instelling moet wel kloppen), na het inschakelen van een strengere beveiligingsheader die externe bronnen blokkeert, of doordat een iconenbibliotheek (Font Awesome) in een nieuwere versie andere namen gebruikt. Open de browserconsole (F12) en kijk naar rode meldingen bij Netwerk; die noemen precies welk bestand ontbreekt.

Oorzaak 5: een WordPress-update heeft de blokstijlen veranderd

Grote WordPress-versies wijzigen af en toe de standaardopmaak van blokken: afstanden rond afbeeldingen, de breedte van groepen, de weergave van knoppen. Sites die op de blokkeneditor zijn gebouwd zonder eigen thema-instellingen, merken dat als kleine verschuivingen op alle pagina’s tegelijk. De oplossing zit in de instellingen van het thema onder Uiterlijk → Editor → Stijlen, of in een paar regels CSS in het child-thema.

Wat u zelf doet en wanneer u hulp inschakelt

Zelf: cache legen, in een privévenster kijken, pagebuilder-instellingen terugzetten en het thema bijwerken. Ook het vergelijken van het oude en nieuwe style.css is te doen als u een beetje thuis bent in code.

Hulp inschakelen als de site door een bureau is aangepast dat u niet meer kunt bereiken, als u geen back-up van vóór de update heeft, of als de verschuiving alleen op mobiel of in één browser optreedt. Een bugfixer voor WordPress zet dan de oude opmaak terug vanuit de back-up, verhuist de aanpassingen naar een child-thema en test de site daarna in de gangbare browsers en schermformaten.

Een accountantskantoor in Amersfoort belde met precies dit verhaal: na een thema-update was de site “een ander bedrijf geworden”. Het vorige bureau had 400 regels CSS rechtstreeks in het thema gezet. Terugzetten vanuit de back-up en verhuizen naar een child-thema kostte twee uur. Sindsdien overleven de aanpassingen elke update.

Conclusie

Bij een verschoven lay-out na een update begint u altijd met de cache. Daarna kijkt u naar de meest waarschijnlijke oorzaak: overschreven aanpassingen in het thema. Dan de pagebuilder, dan verdwenen CSS, dan lettertypen en blokstijlen. Wat u ook vindt, zorg dat aanpassingen na het herstel in een child-thema of in de Customizer staan en niet meer in de themabestanden zelf. Dat is het verschil tussen dit één keer meemaken en dit bij elke update meemaken.