Contact Form 7 pyörii yli 5 miljoonalla sivustolla. Se toimii vuosia ilman yllätyksiä: asenna, määritä, unohda. Mutta kun välimuistin laittaa päälle, PageSpeed Insightsin raportteihin alkaa ilmestyä sitkeä rivi: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Sivusto ei kaadu, visuaalisesti kaikki näyttää siistiltä, vain oranssi nopeusmittari pilaa kokonaiskuvan.

Syyllinen ei ole itse lisäosa vaan refill-mekanismi. Kun CF7 havaitsee WP_CACHE-vakion wp-config.php-tiedostossa, se käynnistää AJAX-päivitykset CAPTCHA:lle ja dynaamisille elementeille, mikä on järkevää välimuistitetuilla sivuilla. Ongelma on siinä, että refill kutsuu palvelinta maailmanlaajuisesti. Myös sivuilla, joilla ei ole minkäänlaista lomaketta.

Korjaus on kirurginen muokkaus yhteen tiedostoon, controller.php. Kolme riviä, viisi minuuttia, ja refill-kutsut katoavat raporteista. Menetelmä toimii kaikissa nykyisissä Contact Form 7 -versioissa (mukaan lukien 6.1.6, toukokuu 2026) ja WordPressissä versiosta 6.0 versioon 7.0.

💡 Pikaohje:

• Avaa controller.php-tiedosto lisäosan kansiosta
• Etsi lohko, jossa on WP_CACHE-tarkistus, kolme riviä
• Kommentoi ne pois tai poista ne
• Tallenna tiedosto ja tyhjennä välimuisti kaikilla tasoilla

Mitä refill tekee ja miksi se haittaa nopeutta

Kun define('WP_CACHE', true)-vakio on asetettu wp-config.php-tiedostossa, Contact Form 7 käsittelee jokaista sivua välimuistitettuna. Kehittäjän logiikka on läpinäkyvä: staattinen HTML ei päivitä CAPTCHA:a itsestään, tarvitaan AJAX-päätepiste, joka hakee tuoreen vahvistuskoodin. Refill on juuri tämä päätepiste.

Mutta se toimii kontekstista piittaamatta. Kutsut osoitteeseen /wp-json/contact-form-7/v1/contact-forms/<id>/refill lähtevät kaikilta sivuilta peräkkäin: etusivu, blogi, arkisto, kaikki. Heikolla hostingilla tai projektissa, jossa on kohtuullisesti liikennettä, kymmenet turhat REST-kutsut sivulatausta kohden hidastavat latausaikaa selvästi. GTmetrix ja PageSpeed Insights korostavat refilliä resurssina, joka estää renderöinnin.

Ja kaikkein salakavalin osa: visuaalisesti sivusto toimii. Saat vain "keltaisen" nopeuspisteytyksen etkä heti ymmärrä, mistä kaivaa. Selainkonsoli on hiljaa, ei virheitä, vain numeroita raportissa.

Video: mitä muuta voit tehdä Contact Form 7:n skripteille

Tämä lyhyt englanninkielinen video näyttää vaihtoehtoisen lähestymistavan, CF7-skriptien ja -tyylien ehdollisen lataamisen. Videon tekniikat yhdistyvät täydellisesti korjauksemme kanssa (käsittelemme tätä alla).

Vaiheittainen korjaus: poista refill käytöstä controller.php-tiedostossa

Vaihe 1. Siirry tiedostoon

Polku tiedostoon lisäosan kansiossa:

1
wp-content/plugins/contact-form-7/includes/controller.php

Kaksi tapaa päästä sinne. Hallintapaneelin kautta: tiedostonhallinta cPanelissa (File Manager) tai vastaavassa, laajenna kansiopuu yllä olevan polun mukaisesti. FTP:n kautta: yhdistä asiakasohjelmalla, kuten FileZilla, ja siirry sivuston hakemistoon.

Vaihe 2. Etsi WP_CACHE-lohko

Avaa controller.php millä tahansa tekstieditorilla. Etsi kolme riviä:

1
if ( defined( 'WP_CACHE' ) && WP_CACHE ) {
2
    $wpcf7['cached'] = 1;
3
}

Mekaniikka on yksinkertainen: jos WP_CACHE on määritelty ja aktiivinen, lisäosa asettaa cached = 1 -lipun. Tämä lippu laukaisee refill-kutsujen vyöryn. Contact Form 7:n lähdekoodin mukaan versiossa 6.1.6 (toukokuu 2026) lohko on samassa paikassa eikä ole muuttunut, koko 6.x-haaran historian aikana siihen ei ole koskettu kertaakaan.

Vaihe 3. Kommentoi pois tai poista

On turvallisempaa kommentoida. Laita // jokaisen rivin alkuun:

1
// if ( defined( 'WP_CACHE' ) && WP_CACHE ) {
2
//     $wpcf7['cached'] = 1;
3
// }

Miksi kommentointi poistamisen sijaan: seuraavassa lisäosan päivityksessä controller.php ylikirjoitetaan, ja muokkaus katoaa. Kommentoidun lohkon tunnistaa heti: avasit tiedoston, näit //, muistit. Poistaminen toimii yhtä hyvin, mutta kuukauden tai kahden päästä on helppo unohtaa, mitä tarkalleen leikkasit. Tallenna tiedosto.

Vaihe 4. Tyhjennä välimuisti ja tarkista uudelleen

Muokkauksen jälkeen varmista, että tyhjennät välimuistin kaikilla tasoilla:

• Lisäosan välimuisti: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Palvelimen välimuisti: jos palvelimella on Varnish, Nginx FastCGI tai palvelintason LiteSpeed LSCache, hotellin hallintapaneelissa on tyhjennyspainike.
• CDN: Cloudflare tai QUIC.cloud → Purge Everything.

Suorita nyt uusi testi PageSpeed Insightsissa tai GTmetrixissä. Avaa incognito-tilassa, selaimen välimuisti saattaa näyttää raportin vanhan version.

Virheen, jossa on /wp-json/contact-form-7/v1/contact-forms/<id>/refill, pitäisi kadota osioista "Poista renderöinnin estävät resurssit" tai "Vähennä käyttämätöntä JavaScriptiä". Näkyykö yhä? Tarkista controller.php (muokkaus ei ehkä tallentunut) ja objektivälimuisti (Redis/Object Cache saattaa pitää vanhaa tiedostoversiota muistissa).

Mitä sinun tulee tietää korjauksen jälkeen

Muokkaus ei ole pysyvä. Jokainen Contact Form 7 -päivitys ylikirjoittaa controller.php-tiedoston, ja kolme riviä palaavat. Avaa päivityksen jälkeen tiedosto, varmista, että lohko on taas aktiivinen, ja kommentoi se uudelleen pois. Minuutin työ, mutta helppo unohtaa, pidä tarkistuslistaa.

CAPTCHA saattaa hajota. Refill suunniteltiin alun perin CAPTCHA:lle välimuistitetuilla sivuilla. Jos käytät Contact Form 7:n sisäänrakennettua CAPTCHA:a (ei Google reCAPTCHA:a), vahvistuskoodi lakkaa päivittymästä refillin poistamisen jälkeen, eikä lomake lähetä. Kaksi ratkaisua: vaihda Google reCAPTCHA v3:een, se toimii erillisen API:n kautta eikä ole riippuvainen refillistä; tai älä kommentoi controller.php-tiedostoa, vaan määritä CF7-resurssien ehdollinen lataus filttereiden kautta (tästä lisää alla). Testattuasi muokkauksen jälkeen, lähteekö lomake normaalisti? Hienoa, unohda koko asia.

Vaihtoehtoinen lähestymistapa, filtterit wpcf7_load_js ja wpcf7_load_css. Ne eivät poista refilliä käytöstä, mutta estävät Contact Form 7:ää lataamasta skriptejä ja tyylejä sivuilla, joilla ei ole lomaketta. Lisää teeman functions.php-tiedostoon:

1
add_filter( 'wpcf7_load_js', '__return_false' );
2
add_filter( 'wpcf7_load_css', '__return_false' );

Ja sivulla, jolla lomake on, wp_head-koukun sisällä, palauta liput arvoon true. Tämä poistaa turhat resurssit kaikkialta paitsi lomakkeen sisältäviltä sivuilta. Yhdistä refillin poistamiseen controller.php-tiedostosta saadaksesi maksimaalisen suorituskyvyn.

⁉️🤔 Usein kysytyt kysymykset

Onko controller.php-tiedoston muokkaus pakollinen, jos en käytä CAPTCHA:a?

Kyllä, pakollinen. Refill-kutsut osoitteeseen /wp-json/contact-form-7/v1/contact-forms/<id>/refill lähetetään jokaisella AJAX-syklillä CAPTCHA-asetuksista riippumatta. Visuaalisesti et huomaa niitä, mutta GTmetrix ja Query Monitor kirjaavat turhat REST API -kutsut. Kolmen rivin kommentoinnin jälkeen päätepiste lakkaa vastaamasta, ja nopeus kasvaa.

Miksei vain poisteta WP_CACHE-vakiota käytöstä wp-config.php-tiedostossa?

WP_CACHE-vakio on signaali koko WordPress-ekosysteemille, että sivut voidaan välimuistittaa. WP Rocket, W3 Total Cache, FlyingPress ja muut lisäosat luottavat siihen. Poistamalla WP_CACHE-vakion tuhoat välimuistituksen kokonaan, nopeuden lasku on paljon huomattavampi kuin yksi refill-kutsu. Oikea tapa: pidä välimuistitus, mutta leikkaa sen sivuvaikutus CF7:ssä.

Toimiiko korjaus multisite-ympäristössä?

Se toimii, mutta wp-content/plugins/contact-form-7/includes/controller.php on jaettu koko verkon kesken. Muokkaus vaikuttaa kaikkiin lapsisivustoihin samanaikaisesti. Ennen muutosten tekemistä tarkista, onko verkon muilla sivustoilla lomakkeita, joissa on Contact Form 7:n sisäänrakennettu CAPTCHA. Jos on, testaa lähetys jokaisella muokkauksen jälkeen tai harkitse filtteripoikkeusta yleisen muokkauksen sijaan.

Voiko muokkauksen palauttamisen automatisoida lisäosan päivityksen jälkeen?

Contact Form 7:n dokumentaatiossa ei ole valmista filtteriä juuri näiden kolmen rivin korvaamiseen. Käytännössä tarkistuslista "CF7-päivityksen jälkeen → tarkista controller.php" on luotettavampi kuin mikään räätälöity mu-plugin. Tiedosto muuttuu harvoin, koko 6.x-haaran aikana WP_CACHE-lohkoa ei ole muokattu kertaakaan.

Lomake lakkasi lähettämästä muokkauksen jälkeen, mitä teen?

Tarkista ensin CAPTCHA-tyyppi: Contact Form 7 → Integraatio. Lisäosan sisäänrakennettu CAPTCHA (ei reCAPTCHA) on riippuvainen refillistä vahvistuskoodin vaihtamiseksi. Vaihda Google reCAPTCHA v3:een, se toimii oman API:nsa kautta eikä ole sidottu refilliin. Toinen vaihtoehto: peru controller.php-muokkaus, jätä refill päälle ja määritä CF7-resurssien ehdollinen lataus vain lomakkeen sisältäville sivuille wpcf7_load_js- ja wpcf7_load_css-filttereiden avulla.

Contact Form 7 ja välimuistitus: mitä tehdä vuonna 2026

controller.php-tiedoston muokkaaminen on mikrokirurgiaa, joka poistaa lisäosan ainoan kapean pullonkaulan. Minuutti aikaa, ei ylimääräisiä lisäosia, toimii WordPressissä versiosta 6.0 versioon 7.0 ja kaikissa nykyisissä Contact Form 7 -koontiversioissa.

Haluatko puristaa kaiken irti? Yhdistä: poista refill käytöstä controller.php-tiedoston kautta ja määritä resurssien ehdollinen lataus wpcf7_load_js- ja wpcf7_load_css-filttereillä. Ensimmäinen poistaa refill-kutsut, toinen estää lomakeskriptejä roikkumasta sivuilla, joilla ei ole lomaketta. Yhdessä ne poistavat Contact Form 7:n PageSpeed Insights -raporteista ongelmien lähteenä, täysin.

🔗 Contact Form 7 WordPress.orgissa