Skip to content

Kõik WordPressist, veebiarendusest — ja mitte ainult

🐛 Contact Form 7 - refilli vahemälu probleemi lahendamine

🐛 Contact Form 7 - refilli vahemälu probleemi lahendamine

Contact Form 7 töötab enam kui 5 miljonil saidil. See toimib aastaid ilma üllatusteta: paigalda, seadista, unusta. Kuid lülita sisse vahemälu ja PageSpeed Insightsi aruannetesse ilmub püsiv rida: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Sait ei jookse kokku, visuaalselt on kõik korras, ainult oranž kiirusnäidik rikub pildi.

Süüdlane pole pistikprogramm ise, vaid refill-mehhanism. Kui CF7 näeb failis wp-config.php konstanti WP_CACHE, käivitab see AJAX-uuendused CAPTCHA ja dünaamiliste elementide jaoks, mis on vahemällu salvestatud lehtede puhul mõistlik. Probleem on selles, et refill pöördub serveri poole globaalselt. Isegi lehtedel, kus pole ühtegi vormi.

Lahendus on ühe faili, controller.php, täpne redigeerimine. Kolm rida, viis minutit ja refill-päringud kaovad aruannetest. Meetod töötab kõigi praeguste Contact Form 7 versioonidega (sh 6.1.6, mai 2026) ja WordPressiga alates 6.0 kuni 7.0.

💡 Kiirülevaade:

  • Ava fail controller.php pistikprogrammi kaustas
  • Leia plokk WP_CACHE kontrolliga, kolm rida
  • Kommenteeri need välja või kustuta
  • Salvesta fail ja tühjenda vahemälu kõigil tasanditel

Mida refill teeb ja miks see kiirust kahjustab

Kui failis wp-config.php on määratud konstant define('WP_CACHE', true), käsitleb Contact Form 7 iga lehte vahemällu salvestatuna. Arendaja loogika on läbipaistev: staatiline HTML ei uuenda CAPTCHA-t ise, vaja on AJAX-lõpp-punkti, mis tõmbab värske kontrollkoodi. Refill ongi täpselt see lõpp-punkt.

Kuid see töötab konteksti arvestamata. Päringud aadressile /wp-json/contact-form-7/v1/contact-forms/<id>/refill saadetakse kõigilt lehtedelt järjest: avaleht, blogi, arhiiv, kõik. Nõrgal hostinguplatvormil või korraliku liiklusega projektis aeglustavad kümned tarbetud REST-päringud lehevaate kohta laadimisaega märgatavalt. GTmetrix ja PageSpeed Insights tõstavad refilli esile kui renderdamist blokeerivat ressurssi.

Ja kõige salakavalam osa: visuaalselt sait töötab. Sa saad lihtsalt „kollase" kiirusskoori ega mõista kohe, kust kaevata. Brauseri konsool on vaikne, vigu pole, ainult numbrid aruandes.

Video: mida veel saab Contact Form 7 skriptidega teha

See lühike ingliskeelne video näitab alternatiivset lähenemist, CF7 skriptide ja stiilide tingimuslikku laadimist. Video tehnikad sobivad suurepäraselt kokku meie parandusega (käsitleme seda allpool).

Samm-sammuline parandus: keela refill failis controller.php

1. Samm. Mine failini

Faili asukoht pistikprogrammi kaustas:

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

Kaks võimalust sinna jõudmiseks. Hostingupaneeli kaudu: failihaldur cPanelis (File Manager) või samaväärses, laienda kaustapuu ülaltoodud teed mööda. FTP kaudu: loo ühendus kliendiga nagu FileZilla ja navigeeri saidi kataloogi.

2. Samm. Leia WP_CACHE plokk

Ava controller.php mis tahes tekstiredaktoris. Leia kolm rida:

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

Mehaanika on lihtne: kui WP_CACHE on defineeritud ja aktiivne, seab pistikprogramm lipu cached = 1. See lipp käivitab refill-päringute kaskaadi. Contact Form 7 lähtekoodi kohaselt on plokk versioonis 6.1.6 (mai 2026) samas kohas ega ole muutunud, kogu 6.x haru ajaloo jooksul pole seda kordagi puudutatud.

3. Samm. Kommenteeri välja või kustuta

Ohutum on kommenteerida. Pane // iga rea algusesse:

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

Miks kommenteerimine kustutamise asemel: järgmisel pistikprogrammi uuendusel kirjutatakse controller.php üle ja redaktsioon kaob. Väljakommenteeritud ploki tunned kohe ära: avasid faili, nägid //, meenus. Kustutamine toimib samuti hästi, kuid kuu või paari pärast on lihtne unustada, mida täpselt välja lõikasid. Salvesta fail.

4. Samm. Tühjenda vahemälu ja kontrolli uuesti

Pärast redigeerimist tühjenda kindlasti vahemälu kõigil tasanditel:

  • Pistikprogrammi vahemälu: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
  • Serveri vahemälu: kui host kasutab Varnishit, Nginx FastCGI-d või serveritaseme LiteSpeed LSCache'i, on hostingu paneelis tühjendusnupp.
  • CDN: Cloudflare või QUIC.cloud → Purge Everything.

Nüüd käivita kordustest PageSpeed Insightsis või GTmetrixis. Ava inkognito režiimis, brauseri vahemälu võib näidata aruande vana versiooni.

Viga teatega /wp-json/contact-form-7/v1/contact-forms/<id>/refill peaks kaduma jaotisest „Likvideeri renderdamist blokeerivad ressursid" või „Vähenda kasutamata JavaScripti". Ikka veel seal? Kontrolli faili controller.php (redaktsioon ei pruukinud salvestuda) ja objektivahemälu (Redis/Object Cache hoiab mõnikord vana failiversiooni mälus).

Contact Form 7 täitmisviga PageSpeed Insightsi aruandes

Mida pead pärast parandust teadma

Redaktsioon ei ole püsiv. Iga Contact Form 7 uuendus kirjutab controller.php üle ja kolm rida tulevad tagasi. Pärast uuendust ava fail, veendu, et plokk on jälle aktiivne, ja kommenteeri see uuesti välja. Minut tööd, kuid lihtne unustada, hoia meelespead.

CAPTCHA võib katki minna. Refill oli algselt mõeldud CAPTCHA jaoks vahemällu salvestatud lehtedel. Kui kasutad Contact Form 7 sisseehitatud CAPTCHA-t (mitte Google reCAPTCHA-t), lakkab pärast refilli keelamist kontrollkood uuenemast ja vormi ei saa esitada. Kaks lahendust: mine üle Google reCAPTCHA v3-le, see töötab läbi eraldi API ega sõltu refillist; või ära kommenteeri controller.php-d, vaid seadista CF7 ressursside tingimuslik laadimine filtrite kaudu (sellest lähemalt allpool). Testisid pärast redaktsiooni, vorm esitatakse normaalselt? Suurepärane, unusta ära.

Alternatiivne lähenemine, filtrid wpcf7_load_js ja wpcf7_load_css. Need ei keela refilli, kuid takistavad Contact Form 7-l skriptide ja stiilide laadimist lehtedel, kus vormi pole. Lisa teema faili functions.php:

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

Ja lehel, kus vorm asub, wp_head konksu sees, sea lipud tagasi väärtusele true. See eemaldab tarbetud ressursid kõikjalt, välja arvatud vormidega lehtedelt. Kombineeri refilli keelamisega controller.php kaudu, et saavutada maksimaalne jõudlus.

⁉️🤔 Korduma kippuvad küsimused

Kas controller.php redigeerimine on kohustuslik, kui ma CAPTCHA-t ei kasuta?

Jah, kohustuslik. Refill-päringud aadressile /wp-json/contact-form-7/v1/contact-forms/<id>/refill saadetakse igal AJAX-tsüklil, sõltumata CAPTCHA seadetest. Visuaalselt sa neid ei märka, kuid GTmetrix ja Query Monitor tuvastavad tarbetud REST API päringud. Pärast kolme rea väljakommenteerimist lakkab lõpp-punkt vastamast ja kiirus kasvab.

Miks mitte lihtsalt keelata WP_CACHE failis wp-config.php?

Konstant WP_CACHE on signaal kogu WordPressi ökosüsteemile, et lehti võib vahemällu salvestada. WP Rocket, W3 Total Cache, FlyingPress ja teised pistikprogrammid tuginevad sellele. WP_CACHE eemaldamisega hävitad vahemällu salvestamise täielikult, kiiruse langus on palju märgatavam kui üks refill-päring. Õige viis: säilita vahemälu, kuid lõika välja selle kõrvalmõju CF7-s.

Kas parandus töötab multisite-keskkonnas?

See töötab, kuid wp-content/plugins/contact-form-7/includes/controller.php on jagatud kogu võrgu ulatuses. Redaktsioon mõjutab kõiki alamlehti üheaegselt. Enne muudatuste tegemist kontrolli, kas teistel võrgu saitidel on Contact Form 7 sisseehitatud CAPTCHA-ga vorme. Kui jah, testi pärast redaktsiooni igal saidil vormi esitamist või kaalu globaalse redaktsiooni asemel filtri erandit.

Kas redaktsiooni taastamist pärast pistikprogrammi uuendust saab automatiseerida?

Contact Form 7 dokumentatsioonis pole valmisfiltrit täpselt nende kolme rea asendamiseks. Praktikas on meelespea „pärast CF7 uuendust → kontrolli controller.php" usaldusväärsem kui ükski kohandatud mu-plugin. Fail muutub harva, kogu 6.x haru jooksul pole WP_CACHE plokki kordagi redigeeritud.

Vorm lakkas pärast redaktsiooni esitamast, mida teha?

Esmalt kontrolli CAPTCHA tüüpi: Contact Form 7 → Integratsioon. Pistikprogrammi sisseehitatud CAPTCHA (mitte reCAPTCHA) sõltub refillist, et kontrollkoodi vahetada. Mine üle Google reCAPTCHA v3-le, see töötab läbi oma API ega ole refilliga seotud. Teine võimalus: võta controller.php redaktsioon tagasi, jäta refill lubatuks ja seadista CF7 ressursside tingimuslik laadimine ainult vormidega lehtedel filtrite wpcf7_load_js ja wpcf7_load_css kaudu.

Contact Form 7 ja vahemällu salvestamine: mida teha aastal 2026

controller.php redigeerimine on mikrokirurgia, mis eemaldab pistikprogrammi ainsa kitsa pudelikaela. Minut aega, ei mingeid lisapistikprogramme, töötab WordPressiga alates 6.0 kuni 7.0 ja kõigi praeguste Contact Form 7 versioonidega.

Tahad maksimumi välja pigistada? Kombineeri: keela refill controller.php kaudu ja seadista ressursside tingimuslik laadimine filtrite wpcf7_load_js ja wpcf7_load_css abil. Esimene eemaldab refill-päringud, teine takistab vormiskriptide rippumist lehtedel, kus vorme pole. Koos eemaldavad need Contact Form 7 PageSpeed Insightsi aruannetest probleemide allikana, täielikult.

🔗 Contact Form 7 WordPress.org-is