Du legger til et kontaktskjema via Contact Form 7 inne i en Elementor Pro-popup. Brukeren fyller ut feltene, klikker «Send», og hele siden lastes på nytt.

Ingen feilmeldinger. Ingen bekreftelse på innsending. Bare en ny lasting og en tapt lead.

Dette er en kjent konflikt: CF7 er avhengig av AJAX-innsending, men inne i en dynamisk lastet popup rekker ikke JavaScripten å binde seg til skjemaet. Resultatet er at nettleseren utfører en standard HTML-innsending, nettopp den som forårsaker ny lasting.

Problemet har eksistert i årevis, men det fikses med bare to linjer kode. Nedenfor finner du to fungerende løsninger: en moderne (renere og mer pålitelig) og et alternativ fra GitHub, pluss valgfrie forbedringer og en feilsøkingssjekkliste.

💡 Rask oversikt:

• Rotårsak: CF7 initialiseres ved sidelasting, men popupen med skjemaet dukker opp senere, så skriptet vet ingenting om innholdet
• Løsning 1: reinitialiser CF7 når elementor/popup/show-hendelsen utløses; JavaScript venter på at popupen åpnes og plukker opp skjemaet
• Løsning 2: spor klikk på knappen som åpner popupen med en forsinkelse for animasjonen; denne metoden stammer fra en GitHub-diskusjon om Elementor
• Valgfritt: tilbakestill skjemaet ved gjenåpning og lukk popupen automatisk etter vellykket innsending
• Feilsøkingssjekkliste: nettleserkonsoll, jQuery-konflikter, bufringsplugins

Hvorfor CF7 spesifikt feiler i en popup

Contact Form 7 er bygget på AJAX: skjemaet sendes inn uten ny lasting, feltvalidering skjer umiddelbart, og feil- eller suksessmeldinger vises øyeblikkelig. Hele denne mekanismen binder seg imidlertid til DOM-en ved sidelasting via et kall til wpcf7.init().

Elementor Pro laster popup-innhold dynamisk, etter DOMContentLoaded-hendelsen. Når en bruker klikker på en knapp og popupen åpnes, settes HTML-en inn i dokumentet, men CF7 vet ingenting om det. Skjemaet inne i popupen forblir uinitialisert.

Det som skjer videre: uten en aktiv AJAX-behandler utfører nettleseren en standard HTML-skjemainnsending. action-attributtet utløses, og siden lastes på nytt. Popupen lukkes naturlig (tilstanden tilbakestilles ved navigasjon). Brukeren ser en ny lasting og forlater siden.

Mange utviklere prøver å behandle symptomene: de blokkerer popupen fra å lukkes via event.stopPropagation(), overstyrer Elementors interne funksjoner eller forhindrer skjemainnsending med e.preventDefault(). Ingen av disse metodene adresserer rotårsaken (den manglende CF7-initialiseringen). Noen ødelegger til og med popup-animasjoner eller selve Elementor på tvers av hele nettstedet.

Det finnes bare én pålitelig løsning: vent på at popupen åpnes og kall eksplisitt wpcf7.init() for hvert skjema inni.

Løsning 1: reinitialisering ved popup-åpning (moderne tilnærming)

Denne metoden bruker Elementors innebygde elementor/popup/show-hendelse. Plasser koden i det aktive temaets functions.php eller legg den til via et snippets-plugin som Code Snippets.

Opprett en sikkerhetskopi av functions.php før du redigerer.

1
/**
2
 * Reinitialize Contact Form 7 when opening an Elementor popup.
3
 * Fixes page reload after form submission.
4
 */
5
function sdstudio_cf7_reinit_in_popup() {
6
    ?>
7
    <script>
8
    jQuery( document ).on( 'elementor/popup/show', function() {
9
        document.querySelectorAll( '.wpcf7 form' ).forEach( function( form ) {
10
            if ( typeof wpcf7 !== 'undefined' ) {
11
                wpcf7.init( form );
12
            }
13
        });
14
    });
15
    </script>
16
    <?php
17
}
18
add_action( 'wp_footer', 'sdstudio_cf7_reinit_in_popup' );

Etter lagring åpner du popupen med skjemaet og tester det: fyll ut de påkrevde feltene feil og klikk «Send». Valideringsmeldinger skal vises umiddelbart uten ny lasting. Send deretter inn skjemaet korrekt og bekreft at suksessmeldingen også vises inne i popupen.

Koden venter på elementor/popup/show-hendelsen, som garantert utløses etter at popup-innholdet er rendret. Deretter finner querySelectorAll alle CF7-skjemaer i gjeldende DOM, og wpcf7.init() kobler tvungent AJAX-validering og -innsending til hvert enkelt. Sjekken typeof wpcf7 !== 'undefined' beskytter mot feil hvis CF7 av en eller annen grunn ikke har lastet.

Løsning 2: sporing av klikk på popup-knappen (alternativ metode)

Denne tilnærmingen er postet i Elementors GitHub-diskusjon #7798 av brukeren @drinkmaker. I stedet for å spore popup-åpning overvåker den klikk på en knapp eller lenke med href='#elementor-action', som er nøyaktig slik Elementor utløser popuper.

setTimeout(..., 800)-forsinkelsen gir tid til popupens visningsanimasjon før koden finner og initialiserer skjemaet. .elementor-markøren forhindrer at det samme skjemaet initialiseres to ganger.

1
/**
2
 * Alternative initialization of CF7 in Elementor popups.
3
 * Source: https://github.com/elementor/elementor/issues/7798 (drinkmaker)
4
 */
5
function sdstudio_elementor_cf7_alt_init() {
6
    ?>
7
    <script type='text/javascript'>
8
        jQuery( document ).ready( function() {
9
 
10
            jQuery( document ).on( 'click', "a[href='#elementor-action']", function() {
11
 
12
                setTimeout( function() {
13
 
14
                    jQuery( '.elementor-popup-modal form.wpcf7-form:not(.elementor)' ).each( function( index ) {
15
                        wpcf7.initForm( jQuery( this ) );
16
                        jQuery( this ).addClass( 'elementor' );
17
                    });
18
 
19
                }, 800 );
20
 
21
            });
22
 
23
        });
24
    </script>
25
    <?php
26
}
27
add_action( 'wp_footer', 'sdstudio_elementor_cf7_alt_init' );

Hvilken metode du bør velge: den første (som bruker elementor/popup/show-hendelsen) er å foretrekke fordi den er avhengig av Elementors dokumenterte API, er renere og ikke er avhengig av timeouts. Den andre har vært kamptestet i produksjon i årevis og fungerer som en pålitelig Plan B hvis den første av en eller annen grunn ikke virker.

Valgfritt: tilbakestill skjema ved gjenåpning

Når en bruker lukker popupen og åpner den igjen, forblir skjemafeltene utfylt. Dette er forvirrende: det er uklart om skjemaet ble sendt inn eller ikke. Et lite tillegg til den første løsningen fikser dette:

1
/**
2
 * Reset CF7 form each time an Elementor popup opens.
3
 */
4
function sdstudio_cf7_reset_on_popup_open() {
5
    ?>
6
    <script>
7
    jQuery( document ).on( 'elementor/popup/show', function() {
8
        jQuery( '.wpcf7 form' ).each( function() {
9
            this.reset();
10
            jQuery( this ).find( '.wpcf7-not-valid' ).removeClass( 'wpcf7-not-valid' );
11
            jQuery( this ).find( '.wpcf7-response-output' ).hide();
12
            jQuery( this ).find( '.wpcf7-not-valid-tip' ).remove();
13
        });
14
    });
15
    </script>
16
    <?php
17
}
18
add_action( 'wp_footer', 'sdstudio_cf7_reset_on_popup_open' );

Funksjonen tilbakestiller feltverdier med reset(), fjerner CSS-klasser fra ugyldige felt, skjuler innsendingsmeldinger og fjerner valideringstips. Brukeren ser alltid et rent skjema.

Valgfritt: lukk popup etter vellykket innsending

Etter en vellykket innsending er det fornuftig å automatisk lukke popupen etter 1,5 sekunder, slik at brukeren får tid til å lese bekreftelsen uten å måtte lete etter lukkeknappen:

1
/**
2
 * Auto-close Elementor popup after successful CF7 submission.
3
 */
4
function sdstudio_close_popup_on_cf7_success() {
5
    ?>
6
    <script>
7
    document.addEventListener( 'wpcf7mailsent', function() {
8
        setTimeout( function() {
9
            jQuery( '.dialog-close-button' ).trigger( 'click' );
10
        }, 1500 );
11
    }, false );
12
    </script>
13
    <?php
14
}
15
add_action( 'wp_footer', 'sdstudio_close_popup_on_cf7_success' );

wpcf7mailsent-hendelsen utløses når serveren bekrefter at e-posten er sendt. Forsinkelsen på 1500 ms gir brukeren tid til å lese suksessmeldingen. Klikk på .dialog-close-button bruker Elementors standard lukkeknapp. I motsetning til forsøk på å kalle popup-API-et direkte, er denne metoden stabil på tvers av alle versjoner.

Feilsøkingssjekkliste

Hvis skjemaet fortsatt laster siden på nytt etter at du har lagt til koden, gå gjennom disse trinnene:

• Nettleserkonsoll. Åpne DevTools (F12 → Console) og se etter røde JavaScript-feil. En vanlig årsak er at jQuery ikke laster eller er i konflikt med et annet plugin.

• Bufring. Plugins som WP Rocket, Autoptimize eller cache på vertsnivå kan minimere og kombinere skript. Deaktiver aggressiv JS-optimalisering midlertidig og test igjen.

• jQuery i noConflict-modus. Hvis et tema eller plugin pakker jQuery inn i noConflict, erstatt jQuery med $ ved hjelp av en passende wrapper, eller bruk den fullstendige jQuery-formen.

• Popup-ID. Forsikre deg om at skjemaet er inne i den nøyaktige popupen som utløses av en knapp med href='#elementor-action'. For popuper som åpnes via andre utløsertyper (for eksempel på en timer), er den første metoden med elementor/popup/show mer pålitelig.

• Plugin-konflikt. Deaktiver andre plugins én etter én og test, spesielt de som legger til sine egne valideringsskript eller endrer skjemaatferd.

• CF7-versjon. Disse løsningene er testet på Contact Form 7 versjon 5.7+ og Elementor Pro 3.5+. Hvis CF7-versjonen din er under 5.7, kan wpcf7.init()-funksjonen ha et annet navn; oppdater pluginet.

⁉️🤔 Ofte stilte spørsmål

Hvorfor fungerer CF7 på en vanlig side, men feiler i en popup?

Når en vanlig side laster, er DOM-en allerede bygget, og CF7 har tid til å initialisere alle skjemaer. Elementors popup laster innhold asynkront, etter at CF7 har fullført arbeidet sitt. Skjemaet havner i DOM-en, men uten en tilknyttet JavaScript-behandler. Derfor hjelper det ikke å sjekke «det fungerer på en separat side»: lastebetingelsene er fundamentalt forskjellige. Løsningen er alltid tvungen reinitialisering når popupen åpnes, uavhengig av om skjemaet fungerer andre steder.

Kan jeg klare meg uten kode, ved å bruke et plugin eller en innstilling?

Det finnes ikke noe ferdig plugin som lar deg «krysse av i en boks så fungerer det» for denne feilen. Problemet ligger i skjæringspunktet mellom to uavhengige produkter (Elementor og CF7), og hver av dem fungerer korrekt alene. Tredjeparts tillegg som WPB Popup for Contact Form 7 løser problemet annerledes: de lager sine egne popuper i stedet for å fikse Elementor. Koden over er det minste nødvendige inngrepet. Du legger den til én gang i functions.php, og den krever ikke oppdateringer når nye versjoner av CF7 eller Elementor kommer ut.

Den første metoden fungerte ikke. Hva bør jeg sjekke før jeg bytter til den andre?

Sjekk tre ting. For det første: elementor/popup/show-hendelsen er tilgjengelig fra og med Elementor Pro 2.7; hvis versjonen din er lavere, bruk den andre metoden med en gang. For det andre: åpne konsollen og skriv typeof wpcf7; hvis den er undefined, har ikke CF7-pluginet lastet JavaScripten sin (se etter feil eller konflikter). For det tredje: forsikre deg om at skjemaet inne i popupen har klassen .wpcf7; uten den vil ikke querySelectorAll('.wpcf7 form')-velgeren finne noe. I de aller fleste tilfeller fungerer den første metoden umiddelbart. Hvis ikke, bruk den andre: den har vært bevist på hundrevis av nettsteder gjennom årene.

Må jeg legge til alle tre snuttene, eller er ett nok?

Den første snutten (reinitialisering) er det essensielle minimumet. Den andre er et alternativ; legg den bare til hvis den første ikke løste problemet. Tilbakestilling av skjema og automatisk lukking av popup er valgfrie forbedringer du kan legge til etter behov: tilbakestilling er nyttig hvis popupen åpnes flere ganger i løpet av ett besøk; automatisk lukking er nyttig hvis popupen brukes til forespørsler og ikke inneholder lang bekreftelsestekst. Alle tre snuttene er uavhengige og kan fungere samtidig. Det er ingen konflikter mellom dem.

Etter fiksen sendes skjemaet, men e-postene kommer ikke frem. Er dette relatert?

Nei, problemer med e-postlevering er et separat tema som ikke er relatert til at CF7 fungerer inne i en popup. Hvis skjemaet etter at du har brukt fiksen viser en suksessmelding (grønn kant), fungerer AJAX-innsendingen korrekt. E-poster som ikke kommer frem: sjekk SMTP-innstillinger, vertens spamfiltre og mottakeradressen i CF7-skjemainnstillingene. For pålitelig levering, bruk et SMTP-plugin som Post SMTP eller FluentSMTP i stedet for standard wp_mail()-funksjonen, ettersom verter ofte blokkerer utgående PHP-post.

Påvirker denne løsningen andre CF7-skjemaer på nettstedet?

Nei. Begge metodene er isolerte: den første venter på at en Elementor-popup åpnes, den andre sporer bare lenker med href='#elementor-action'. Vanlige CF7-skjemaer plassert på sider og i widgeter fortsetter å fungere normalt; de initialiseres ved sidelasting og forblir upåvirket. Det eneste forbeholdet: hvis nettstedet ditt bruker aggressiv bufring med skriptsammenkobling, legg til popup-koden i ekskluderingene for minimering for å unngå dobbel kjøring.

Er det verdt å bry seg med tilpasset kode i 2026

Begge pluginene, Contact Form 7 og Elementor Pro, er aktivt utviklet og oppdatert. CF7 holder sin posisjon som det mest populære WordPress-skjema-pluginet med over 5 millioner aktive installasjoner. Elementor Pro brukes på hvert fjerde WordPress-nettsted.

Likevel har feilen beskrevet her ikke blitt fikset på kjernenivå i noen av pluginene, og vil sannsynligvis aldri bli det. Årsaken er arkitektonisk: CF7 er ansvarlig for skjemaer, Elementor er ansvarlig for dynamisk innhold, og initialisering av skript i dynamisk lastet DOM forblir utviklerens ansvar.

Den gode nyheten: fiksen er triviell, koden legges til én gang, og den krever ikke vedlikehold. Velg den første metoden (elementor/popup/show-hendelsen): den er den reneste, og du kan glemme problemet. Hvis skjemaet i popupen brukes til kritiske leadgenereringsscenarier, legg også til tilbakestilling av felt og automatisk lukking: brukeropplevelsen vil bli merkbart forbedret.

Se videoen over: den viser hele prosessen med å sette opp en popup med Contact Form 7 i Elementor. Denne visuelle trinnvise veiledningen utfyller snuttene som er gitt her, og hjelper deg med å unngå feil under monteringen.