Support » Allmänna frågor » Förhandsgranskning inte likadan som live trots rensad cache i webbläsaren

  • Vi implementerade i förra veckan recaptcha version 2 på våra formulär på sajten (Gravity Forms). Problemet är att man verkar behöva godkänna cookies för att rutan ska dyka upp. Vi implementerade därför istället recaptcha version 3 men nu när vi tagit bort recaptcha version 2 i våra gravity forms formulär försvinner de enbart i förhandsgranskningen/inloggat läge i WordPress men inte i live-läget.

    Har rensat cache-minnet i webbläsaren vilket inte hjälper.
    Vad kan man göra? Förhandsgranskningen i WordPress stämmer nu alltså inte ihop med live-läget på sajten trots rensat cache-minne i webbläsaren.

Visar 1 svar - 1 till 7 (av 7 totalt)
  • Moderator tobifjellner (Tor-Bjorn Fjellner)

    (@tobifjellner)

    WordPress-hemmapulare, Projektledare, Författare, Översättare och Vänlig Själ

    Det kan finnas cache på serversidan också, i synnerhet om ni använder Cloudflare eller något liknande CDN-lager mellan webbplatsservern och besökarna.
    Olika saker att prova:
    – Tryck Ctrl-F5 för att tvinga en djupare omladdning av sidan.
    – Kolla med webbhotellet om det finns någon helsides-cache på servern och hur ni i så fall kan rensa den.
    – Vänta ut cachen (bökigast).

    Trådstartare matte96

    (@matte96)

    Tack för svar!

    CTRL+F5 hjälpte dessvärre inte. Har kontaktat webbhotellet och inväntar svar.

    Försöker rensa cache-minnet inne i WordPress via WP Super Cache men när vi aktiverar plug-inet dyker ett meddelande upp gällande att det finns ett annat tillägg ”advanced-cache.php” som behöver tas bort innan vi kan aktivera WP Super Cache.
    Hittar advanced-cache.php under ”insticksprogram” men osäker på vad det är för något, hur vi använder det och hur vi kan ta bort det?

    Moderator tobifjellner (Tor-Bjorn Fjellner)

    (@tobifjellner)

    WordPress-hemmapulare, Projektledare, Författare, Översättare och Vänlig Själ

    Ett ”insticksprogram” är ett tillägg med extra djup integrering med WordPress.

    Insticksprogram för cachehantering kännetecknas just av att de placerar filen ”advanced-cache.php” på motsvarande ställe i webbplatsens filsystem.
    Den har antagligen placerats där av något annat tillägg, kanske ett tillägg från webbhotellet.

    Om du vill tvinga WordPress att använda Super Cache kan du manuellt radera filen /wp-content/advanced-cache.php i webbplatsens filsystem. (via webbhotellets filhanterare, om det finns någon, annars via FTP)

    Trådstartare matte96

    (@matte96)

    Ok! Då ska vi kolla upp det.
    Är det normalt att man behöver godkänna cookies innan recaptcha-rutan dyker upp?
    Godkänner man inte cookies syns inte rutan, så fort man godkänt cookies dyker rutan upp som den ska.

    Moderator tobifjellner (Tor-Bjorn Fjellner)

    (@tobifjellner)

    WordPress-hemmapulare, Projektledare, Författare, Översättare och Vänlig Själ

    Senaste versionen av reCaptcha använder en rad olika knep för att kolla om en besökare verkar vara en levande person eller inte. Jag kan tänka mig att de verkligen behöver en cookie för att kunna göra detta.

    Trådstartare matte96

    (@matte96)

    Förstår. Kan man sätta cookies som nödvändigt att godkänna direkt när man kommer in på sajten, eller behöver det vara valfritt?

    Nu kommer vi inte ens in på /wp-admin och får upp följande felmeddelande: Ett kritiskt fel har uppstått på webbplatsen. Kolla e-posten till webbplatsens administrationsadress för vidare instruktioner.

    Moderator tobifjellner (Tor-Bjorn Fjellner)

    (@tobifjellner)

    WordPress-hemmapulare, Projektledare, Författare, Översättare och Vänlig Själ

    Det är nog inte att betrakta som en ”nödvändig cookie”, eftersom de flesta nöjer sig med att läsa utan att fylla i några formulär. Så snarare ”funktionsbegränsande”.

    Fråga 2. Det kan vara något tillägg som inte fungerar. Om det där räddningsmejlet kommer fram (beror på en rad faktorer) så innehåller det en genväg för att undersöka problemet via vanliga WordPress-gränssnittet. Om mejlet inte kommer fram behöver du skaffa dig åtkomst till filsystemet (troligtvis via FTP, möjligen via någon ”filhanterare” om ditt webbhotell har en) för felsökning och/eller sätta något tillägg ur spel.

    Det kan tänkas att ditt problem aktiverades om ditt webbhotell flyttade din webbplats till någon av de senaste versionerna av PHP, så jag kopierar in min ”standard-harang” om PHP 8 nedan.

    —————–
    Min gissning är att ditt webbhotell har uppgraderat din webbplats till en modernare version av PHP, den miljö i vilken WordPress körs.
    Den nuvarande planen är nämligen att PHP 7.4 ska sluta att få rättelser av eventuella säkerhetsproblem den 28 november 2022 (ref: https://www.php.net/supported-versions.php ) så många webbhotell börjar nu tvinga upp sina kunder till PHP 8.0 eller 8.1.

    WordPress-kärnan i sig stödjer PHP 8.0 sedan WordPress 5.6, och PHP 8.1 sedan WordPress 5.9 (ref: https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/ ), men det krävs också att alla dina tillägg och ditt WordPress-tema har uppdaterats så att de kan samspela väl med PHP 8.x. (Om den senaste uppdateringen var under de senaste 1-2 åren är det hyfsade chanser att så är fallet. Äldre tillägg kan fortfarande fungera utmärkt om de inte råkar använda någon av de programmeringsfunktioner som ändrats.)

    Ett första steg kan vara att om möjligt växla tillbaka till PHP 7.4 för att se om webbplatsen då fungerar normalt igen, och sedan se till att allt är tillräckligt uppdaterat, WordPress-kärnan behöver vara lägst 5.6 för att PHP 8.0 ska stödjas, o.s.v.
    För att uppdatera ett kommersiellt tema eller tillägg behöver du kontakta respektive utvecklare och kanske köpa en förnyad licens. Men kolla först om du fortfarande vill behålla dina tidigare lösningar. Exempelvis låter WordPress egen inbyggda blockredigerare dig numer göra en hel del som tidigare bara var möjligt med hjälp av s.k. sidbyggare. Och moderna teman, t.ex. ”Twenty twenty-two” har stöd för FSE, redigering av hela webbplatsen via samma typ av blockredigerare. Dessa nya flexibla lösningar kanske är tillräckligt för dina behov.

    Om du behöver felsöka finns det två olika ställen och sätt att kolla.
    I några av de större webbläsarna kan man öppna ”webbkonsolen” som är en del av utvecklarverktygen. Det fönstret bör du vara försiktig med, eftersom det ger dig djup åtkomst till funktioner som vanligtvis är blockerade för sidor (och användaren), men eventuella fel som inträffar i Javascript som körs i webbläsaren, t.ex. kommunikationsfel om servern inte går att nå eller om den svarar med några felkoder kommer att synas där. (Javascript som körs i webbläsaren och som försöker att kommunicera med servern ”programmatiskt” kan t.ex. handla om redigering, mediahantering, o.s.v.)

    Den andra vektorn för felsökning gäller att kolla om några kritiska fel inträffar i webbserverns körning av PHP. (Vilket alltså ofta kan vara orsaken just nu, när många webbhotell tvingar upp sina kunder till PHP 8.x, vilket bl.a. innebär att en del äldre programmeringsformat för hantering av matriser slutar att fungera…), så här är min standardharang om felsökning av PHP:

    ————-
    Förhoppningsvis kan du hitta ledtrådar till vad som spökar genom att TILLFÄLLIGT aktivera PHP-felsökning enligt nedan.

    Följ instruktionerna i https://wordpress.org/support/article/debugging-in-wordpress/ och ändra i filen /wp-config.php raden (För detta behöver du antagligen FTP, som jag kommenterar nedan, och en bra textredigerare, på Windows rekommenderar jag Notepad-plus-plus.)

    define( ’WP_DEBUG’, false );
    till

    define( ’WP_DEBUG’, true );
    define( ’WP_DEBUG_LOG’, true );

    Eventuella fel kommer att skrivas till filen /wp-content/debug.log

    Kom ihåg att efteråt stänga av loggningen. Annars finns risken att loggen tar onödigt mycket plats och att eventuella angripare i framtiden via loggen kan få information om säkerhetsproblem som de kan försöka att utnyttja.

    Om du behöver hjälp med att tolka eventuella felmeddelanden kan du posta dem här. Kolla bara så att du inte av misstag lägger ut någon känslig information.

    För att kunna göra dessa ändringar behöver du använda FTP (t.ex. med FileZilla som klient) för att kunna tanka hem wp-config.php och redigera dem (t.ex. i programmet notepad++ ) och sedan tanka upp den redigerade versionen.

    ———-
    Slutligen: En ytterligare sak som kan vara värda att kolla är om man har något underligt/oväntat i .htaccess
    Grundinnehållet brukar vara 4-5 rader, mellan ”BEGIN WordPress” och ”END WordPress”, men framför allt vissa säkerhetstillägg lägger gärna in massor av regler, och det är inte alltid dessa fungerar snällt med senare versioner av PHP.

Visar 1 svar - 1 till 7 (av 7 totalt)
  • Du måste vara inloggad för att svara på detta ämne.