WordPress popup slider werkt niet na update: fix in 45 min

WordPress popup slider werkt niet na update is een van de meest voorkomende meldingen die ik krijg van klanten die zelf hun plugins bijhouden. Op maandagochtend belt een klant uit Terneuzen: “De pop-up met kortingscode voor nieuwe bezoekers is weg, en de homepage-slider laadt leeg. Ik heb alleen maar plugins bijgewerkt.”

De ergernis is begrijpelijk. Vaak zie je de fout niet in de admin. De site “werkt” gewoon, alleen de interactieve delen niet.

In dit stuk lees je hoe ik zulke problemen systematisch fix. Je krijgt de commando’s die je zelf kunt gebruiken, plus de route in cPanel, Plesk, DirectAdmin en RunCloud. Reken op 30 tot 60 minuten van diagnose tot volledige fix, mits je toegang hebt tot je hostingpaneel of FTP.

WordPress popup slider werkt niet na update: wat er onder de motorkap gebeurt

Voor je iets fixt is het belangrijk om te begrijpen wat er waarschijnlijk gebeurd is. Popups en sliders zijn bijna zonder uitzondering afhankelijk van JavaScript (meestal jQuery) en van CSS voor positionering en zichtbaarheid. Er zijn drie klassen problemen die ik het vaakst tegenkom:

1. jQuery version mismatch. WordPress core bundelt sinds versie 5.6 een moderne jQuery (3.x). Sommige plugins laden nog zelf een oudere versie of gebruiken de deprecated $.browser-syntax die in jQuery 3 is verdwenen. Als de slider-plugin oudere jQuery vereist en een andere plugin (of het thema) laadt de nieuwe versie, breekt de slider-init.

2. no-conflict mode niet toegepast. WordPress draait jQuery standaard in noConflict mode: jQuery in plaats van $. Als een plugin ergens $(document).ready(...) gebruikt zonder wrapper, crasht dat script op moderne WP-installaties. Na een update van een andere plugin die JS-loading beïnvloedt (bijvoorbeeld een cache-plugin met “defer JS”), wordt dit ineens zichtbaar.

3. CSS z-index conflict of stacking context. De popup wordt technisch getriggerd en zit in de DOM, maar is onzichtbaar. Dat komt doordat een ander element er boven staat, bijvoorbeeld een nieuwe versie van je thema of een cookiebar. Of doordat de parent-container een overflow: hidden heeft gekregen. De browser-console laat geen JS-errors zien: het lijkt alsof “niks gebeurt” maar technisch werkt alles.

Ter verdieping: Slider Revolution documenteert deze conflict-klassen expliciet omdat het bij hun helpdesk consistent de top-3 tickets is.

Stap 1: Browser console openen en fouten lezen

Voordat je één plugin deactiveert, doe je dit. Open de pagina waar de popup/slider zou moeten werken, druk F12 (of Cmd+Option+I op macOS), klik het tabblad Console, en herlaad de pagina met Ctrl+Shift+R (harde herlaad, negeert cache).

Kijk naar drie signalen.

Uncaught TypeError: $ is not a function

Dit betekent no-conflict-issue. Een plugin gebruikt $ waar jQuery had gemoeten. Meestal de laatst-geupdate plugin.

Uncaught TypeError: Cannot read properties of undefined (reading 'fn')

Dit is een klassieke jQuery-versie-mismatch. Twee versies van jQuery worden geladen en de tweede overschrijft de eerste voordat de plugin z’n init afmaakt.

Refused to execute script from '...' because its MIME type ('text/html')

Dit betekent dat een JS-bestand een 404 teruggeeft (server serveert de fout-pagina in plaats van het script). Vaak na een migratie of na een plugin-update die de bestandsstructuur wijzigde.

Als je geen errors ziet maar de popup verschijnt nog steeds niet, is het waarschijnlijk een CSS z-index probleem. Ga verder met stap 5.

Stap 2: Cache leegmaken in de juiste volgorde

Voordat je aan plugins gaat sleutelen, alle caches leeg. De volgorde is belangrijk, omdat je anders oudere gecachte assets blijft zien.

1. Server-side page cache (Cloudflare, LiteSpeed, WP Rocket, W3 Total Cache): vaak een “Clear all cache”-knop bovenin de WP-admin toolbar.
2. Plugin cache (specifiek voor de slider/popup-plugin, meestal een “Purge cache”-optie in de plugin-settings).
3. CDN cache (Cloudflare dashboard → Caching → Purge Everything, of BunnyCDN → Purge).
4. Browser cache: hard reload met Ctrl+Shift+R of via DevTools → Network tab → “Disable cache” aanvinken tijdens debug.

Voor LiteSpeed Cache in het bijzonder: Toolbox → Purge → Purge All + LSCache. Als je hosting op LiteSpeed-server draait (bij Antagonist en TransIP komt dat regelmatig voor), zit er ook een server-level cache die je via het hostingpaneel moet leegmaken.

Stap 3: Plugin-conflict test in troubleshooting mode

Health Check & Troubleshooting (van het WordPress-team zelf, gratis) is hiervoor de veiligste tool. Het schakelt alle plugins uit en de standaardtheme aan, alleen voor jouw admin-sessie. Andere bezoekers zien de site normaal. Installeren.

WordPress admin → Plugins → Add new → zoek "Health Check" → Install → Activate
Tools → Site Health → Troubleshooting → Enable Troubleshooting Mode

Ga nu naar de pagina met popup/slider. Als het werkt in troubleshooting mode, weet je zeker dat het een plugin-conflict is. Activeer nu plugins één voor één via de “Troubleshooting”-menu in de admin-toolbar. Herlaad de pagina na elke activatie. Bij de plugin die het opnieuw breekt: dat is je conflict.

Als je geen admin-toegang hebt (bijvoorbeeld omdat wp-admin zelf ook stuk is), doe je dit handmatiger via FTP of hostingpaneel:

Via DirectAdmin (Antagonist, Vimexx, mijn.host)

1. Log in → File Manager → navigeer naar public_html/wp-content/.
2. Klik met rechtermuisknop op de map plugins → Rename → plugins-off.
3. Alle plugins zijn nu gedeactiveerd. Refresh je site.
4. Werkt het? Rename terug naar plugins → activeer plugins één voor één via wp-admin.

Via Plesk (Argeweb, en op VPS bij TransIP en Combell)

1. Domains → jouwsite.nl → Files (Plesk File Manager).
2. Navigeer naar httpdocs/wp-content/.
3. Selecteer plugins-map → Rename in het rechtermenu → plugins-off.
4. Refresh site, activeer terug.

Via cPanel (o.a. Neostrada)

1. Log in → File Manager.
2. Navigeer naar domains/jouwsite.nl/public_html/wp-content/.
3. Klik plugins aan → Rename in de bovenbalk → plugins-off.

Via RunCloud, ServerAvatar, GridPane (managed VPS)

1. SSH-connect naar je server, of gebruik de web-shell in het paneel.
2. Voer uit.

cd /home/username/webapps/jouwsite/wp-content
mv plugins plugins-off

1. Refresh, dan back.

mv plugins-off plugins

Via Hostinger hPanel

1. Files → File Manager.
2. domains/jouwsite.nl/public_html/wp-content/.
3. Rechts-klik plugins → Rename → plugins-off.

Voor grote sites met veel plugins is handmatige toggle traag. Als je SSH-toegang hebt, doet WP-CLI het sneller.

# Alle plugins deactiveren
wp plugin deactivate --all

# Één plugin tegelijk activeren via een loop
for plugin in $(wp plugin list --status=inactive --field=name); do
    echo "Testing: $plugin"
    wp plugin activate $plugin
    echo "Refresh site now, then press Enter to continue..."
    read
done

Stap 4: Rollback van de verdachte plugin

Zodra je de conflicterende plugin hebt geïdentificeerd, is de snelste fix vaak een rollback naar de vorige versie. Dit koop je tijd om te wachten op een fix van de developer.

Optie A: WP Rollback plugin (grafisch)

Plugins → Add new → zoek "WP Rollback" → Install → Activate
Plugins → geïnstalleerd plugins-overzicht → onder de conflicterende plugin verschijnt nu een "Rollback"-link
Klik → kies de vorige stabiele versie → Confirm

Optie B: WP-CLI (SSH)

# Check huidige versie
wp plugin get slider-revolution --field=version

# Rollback naar specifieke versie (bijvoorbeeld 6.6.11)
wp plugin install slider-revolution --version=6.6.11 --force

# Bevestig dat rollback gelukt is
wp plugin get slider-revolution --field=version

Optie C: Handmatige FTP-rollback

1. Download de oude versie van de plugin. Voor gratis plugins: https://wordpress.org/plugins/plugin-slug/advanced/ → onderaan “Previous versions”.
2. Voor premium plugins: developer-account of licentie-portaal.
3. Deactiveer de plugin in wp-admin (belangrijk!).
4. Via FTP: verwijder /wp-content/plugins/plugin-slug/.
5. Upload de oude versie-map.
6. Reactiveer in wp-admin.

Belangrijk: rollback is een tijdelijke maatregel. Rapporteer de bug aan de plugin-developer via het support-kanaal of het WP.org forum. Zet auto-updates voor deze plugin uit tot je hebt getest of de volgende release het probleem oplost. Onder Plugins → Auto-updates: klik “Disable auto-updates” voor de plugin.

Stap 5: CSS z-index en stacking context debuggen

Als browser-console schoon is en plugin-toggle-test niks oplevert, ligt het aan CSS. Open opnieuw DevTools (F12), maar nu het tabblad Elements (of Inspector in Firefox). Klik het “select element”-icoon (pijl in kader), klik ergens waar de popup zou moeten staan.

Als de popup wél in de DOM zit maar onzichtbaar is, zie je hem in de Elements-tree hoogstwaarschijnlijk als een

met een class als .popup-container, .slider-wrapper, of .modal-overlay. In het Styles-paneel rechts kun je de computed CSS zien.

Zoek naar deze rode vlaggen.

• display: none: de popup is niet gerenderd. Waarschijnlijk een JS-trigger die niet vuurt. Terug naar stap 1.
• visibility: hidden of opacity: 0: vaak animation-related, kijk of de openingsklasse (bijvoorbeeld .is-open) wordt toegevoegd door JS.
• z-index: 999 vs een concurrent element met z-index: 10000: klassiek. Overschrijf via een custom CSS-regel.

/* Voeg toe via Appearance → Customize → Additional CSS */
.popup-container,
.pum-container {
    z-index: 999999 !important;
}

• Parent met overflow: hidden: de popup zit binnen een container die alles buiten zijn grenzen afknipt. Verplaats de popup naar -niveau via de plugin-settings (meestal een optie “render popup as body child” of “portal target”), of overschrijf.

/* Voorzichtig — dit heeft impact op andere elementen in dezelfde parent */
.popup-parent {
    overflow: visible !important;
}

Stap 6: Server-side JS-loading debuggen

Als niks van bovenstaande werkt, zit het probleem dieper. Meestal in hoe scripts worden geladen. Twee tools helpen:

Query Monitor (gratis plugin): laat per pagina zien welke JS/CSS-bestanden worden geladen en van welke plugin. Installeer, refresh je pagina, klik in de admin-toolbar op de melding → tab “Scripts”. Kijk naar de laad-volgorde.

Browser Network-tab (F12 → Network → filter op JS): laat zien of scripts een 404, 403 of 500-statuscode teruggeven. Rode entries zijn direct problematisch.

Een veelvoorkomende oorzaak: een cache-plugin met “defer JS” of “delay JS execution” ingeschakeld heeft na een update de slider-JS onterecht uitgesteld. Uitschakelen bij LiteSpeed Cache: Page Optimization → JS Settings → JS Delayed Execution → toggle uit voor specifieke plugin-handles. Bij WP Rocket: Cache → File Optimization → JavaScript → “Delay JavaScript execution” → in de exclusion-list toevoegen: slider-revolution, popupmaker, of welke plugin-slug relevant is.

Veelvoorkomende scenario’s met concrete oplossingen

Scenario A: Popup Maker stopte met werken na WP core 6.7 update

Diagnose: Console toont Uncaught TypeError: PUM is not defined. Popup Maker’s globale JS-object niet geladen.

Oorzaak: WP core update wijzigde de wp_enqueue_script-priorities. Popup Maker’s script laadt nu vóór jQuery.

Fix: Update Popup Maker naar de laatste versie (fix in 1.20+). Als je op oude versie moet blijven, add dit in functions.php.

add_action('wp_enqueue_scripts', function() {
    wp_dequeue_script('popup-maker-site');
    wp_enqueue_script('popup-maker-site', 
        POPMAKE_URL . 'assets/js/site.min.js', 
        array('jquery'), POPMAKE_VERSION, true);
}, 20);

Scenario B: Slider Revolution slaagt “loading” pijl niet meer over

Diagnose: Slider blijft op de loading-spinner staan. Console toont Cannot read properties of undefined (reading 'set').

Oorzaak: GreenSock (GSAP) versie-conflict tussen theme en Slider Revolution.

Fix: In Slider Revolution → Globals → JavaScript settings → schakel “Load GSAP from CDN” uit. Als het theme z’n eigen GSAP bundelt, geef je nu Slider Revolution voorrang met z’n eigen versie.

Scenario C: Elementor Popup animaties werken niet

Diagnose: Popup verschijnt maar zonder de opening-animatie, of “flickert” kort en verdwijnt.

Oorzaak: Meestal een cookie-consent-plugin die op body { opacity: 0 } staat tot consent, waarbij animation-transitions vastlopen.

Fix: In je cookie-plugin, exclude de popup-selectors uit de opacity-block. Voor Complianz: Instellingen → Advanced → Custom CSS class exceptions → voeg .elementor-popup-modal toe.

Preventie: dit voorkomt herhalingsproblemen

Rollback is symptoombehandeling. De echte fix is een workflow die updates veilig maakt.

1. Staging-omgeving voor major updates. De meeste Nederlandse hostings (Antagonist, TransIP, Hostinger, Combell, SiteGround) bieden 1-klik staging aan. Alle plugin-updates test je eerst daar, klik dan pas “Deploy to production” na visuele check van popup, slider, contactform, checkout.

2. Selectieve auto-updates. Zet auto-updates uit voor de plugins die interactieve elementen leveren (slider, popup, formulier, page-builder). Laat auto-updates aan voor security-plugins en WordPress core minor releases.

// In wp-config.php
define('WP_AUTO_UPDATE_CORE', 'minor'); // Alleen minor + security auto

En in Plugins-overzicht: klik “Enable auto-updates” alleen voor niet-visuele plugins (Yoast SEO, Wordfence, backup-plugins).

3. Backup vóór elke plugin-update. UpdraftPlus (gratis of premium), JetBackup bij Cloudways, of Jetpack VaultPress. Zorg dat er een backup ≤7 dagen oud is, en dat je één-klik-restore kunt uitvoeren.

4. Monitoring van visuele regressies. Voor sites waar popup/slider commercieel belangrijk zijn (leadgen, salesfunnel), gebruik een tool als Better Uptime met “keyword monitoring”, die waarschuwt zodra een specifieke tekst niet meer op de pagina staat. Of maandelijkse Screaming Frog crawl vergelijken met vorige maand op page-weight en element-count.

5. Plugin-inventaris audit elke 3 maanden. Deïnstalleer plugins die je niet gebruikt (elke inactieve plugin blijft een update-risico). Vervang niche-plugins door multi-purpose (bijvoorbeeld één page-builder in plaats van page-builder + slider-plugin + popup-plugin).

Wanneer een echte webmaster inschakelen

Los dit zelf op als je binnen 60 minuten een oorzaak vindt. Lukt dat niet, dan kost verder prutsen je meer dan een uur uitbesteden. Bel in deze gevallen iemand in.

• Meerdere fixes proberen geen resultaat oplevert en je frontend voor bezoekers al 2+ uur stuk is.
• Je een production-site hebt zonder werkende backup.
• De site iDEAL of Mollie draait en checkout is affected, met omzetimpact per uur.
• Je in wp-admin geen “Site Health” toegang meer hebt (deeper compromise mogelijk).

Voor mijn klanten kost dit type incident meestal 1 tot 2 uur werk (€70 tot €140), inclusief documentatie van de root-cause en de preventie-checklist voor de volgende keer.

Vast door dit type incident?

Als je in de bovenstaande stappen vastloopt of geen tijd hebt om te troubleshooten met omzetimpact, stuur me een mail via /contact/. Ik kijk binnen 4 uur mee tijdens kantoortijden (spoedhulp buiten kantoor in overleg), en factuur je alleen de daadwerkelijk bestede tijd zonder minimumafname.

Wat je krijgt

Loop je vast met dit probleem?

Stuur me een mail via /contact/. Binnen 24 uur reactie tijdens kantooruren.

Contact