Det er ikke længere valgfrit at køre dit WordPress-websted via HTTPS. Det er ikke kun mere sikkert (alt er krypteret hvor intet sendes i almindelig tekst), men det bygger også tillid, er en ranking faktor for søgemaskiner og giver mere nøjagtige henvisningsdata. Desværre kan webstedsejere støde på flere problemer, når de migrerer fra HTTP til HTTPS. Den ene er ‘mixed content warnings’.
Ydelsesproblemer knyttet til kryptering er for det meste løst takket være HTTP/2, og Let’s Encrypt har ændret hele branchen ved at give dig en nem måde at få gratis SSL-certifikater på.
Vigtigst af alt for online-virksomheder slår webbrowsere som Google Chrome og Mozilla Firefox ned på sider, der ikke kører over HTTPS, og viser strengere advarsler til potentielle besøgende. For eksempel, hvis du bruger ældre TLS-versioner, kan du støde på ERR_SSL_OBSOLETE_VERSION-underretninger i Chrome. Advarsler er den sidste ting, du vil have dine besøgende til at se.
For at hjælpe dig med at undgå disse problemer har vi en grundig guide til, hvordan du migrerer fra HTTP til HTTPS. Efter at have fulgt denne proces kan du dog stadig se mixed content warnings.
I dag viser vi dig et par forskellige måder, du kan løse dette problem på dit WordPress-sted.
Foretrækker du at se videoversionen?
Hvad er en mixed content warning?
En mixed content warning vises i en brugers browser, når WordPress-webstedet, de prøver at besøge, indlæser HTTPS- og HTTP-scripts eller indhold på samme tid. Dette kan forårsage problemer, da HTTP og HTTPS er helt separate protokoller.
Når du migrerer til HTTPS, skal alt køre over denne protokol, inklusive dine billeder, JavaScript-filer og så videre. Nedenfor er nogle eksempler på, hvad der kan ske, hvis noget af dit indhold stadig indlæses via HTTP i stedet.
Eksempler på mixed content warnings
Chrome er i øjeblikket den bedste browser, der bruges af over 77% af internettet. Så følgende advarsel er, hvad de fleste af dine besøgende vil se:
Selvfølgelig er det ikke alle der bruger Chrome.
Her er et eksempel på, hvad der sker i Firefox, når en mixed content warning vises på et WordPress-websted:
Næste er et eksempel på, hvordan denne advarsel ser ud i Microsoft Edge:
Og sådan ser det ud i Internet Explorer:
Som du kan se, er Internet Explorer sandsynligvis et af de værste steder for denne advarsel at blive vist, fordi det faktisk bryder gengivelsen af siden, indtil popup-vinduet klikkes på.
Dette er ikke en fejl, du ønsker at dine besøgende skal se i enhver browser. Det kan løses, men først skal du forstå, hvorfor det sker.
Hvad forårsager mixed content warning?
Vi har fundet ud af, at de mest almindelige mixed content warning vises lige efter, at nogen migrerer deres WordPress-websted fra HTTP til HTTPS. Nogle HTTP-links overføres simpelthen, og dette får mixed content warnings til at starte starte.
Her er nogle yderligere årsager til denne advarsel:
- Du har lige tilføjet en ny tjeneste eller et nyt plugin til dit websted. Især bruger udviklere undertiden absolutte stier (http://yourdomain.com/style.css) i deres plugins eller temaer til at linke til CSS og JavaScript i stedet for at bruge relative stier (/style.css).
- Dine billeder har hardkodede webadresser (såsom http://yourdomain.com/image.png), der kører over HTTP. Disse kunne være inden for indlæg, sider eller endda widgets.
- Du linker til HTTP-versioner af eksterne scripts (hosted jQuery, Font Awesome).
- Du har indlejrede videoskripter, der bruger HTTP i stedet for HTTPS.
Desværre afslører du muligvis ikke den virkelige kilde til problemet, før du starter fejlfinding.
Med det i tankerne skal vi se på nogle metoder, du kan bruge til at rette mixed content warnings.
Sådan løses mixed content warnings (4 trin)
Du kan følge de fire enkle trin nedenfor for at rette dine WordPress mixed content warnings. Denne proces forudsætter, at du allerede har gjort følgende:
- Installeret et SSL-certifikat
- Omdiriger HTTP til HTTPS (hele webstedet)
Vi bruger et eksempel på udviklingswebsted i de følgende eksempler.
Trin 1: Find ud af, hvilke ressourcer der indlæses via HTTP
Den første ting, du skal gøre, er at finde ud af, hvilke ressourcer der stadig indlæses via HTTP.
Husk, at disse advarsler måske kun sker i visse områder af dit websted, ikke globalt. Gå til den side, der beder om advarslen, og start Chrome DevTools ved at trykke på:
- Windows: F12 eller CTRL + Shift + I
- macOS: Cmd + Opt + I
Du kan også åbne Chrome DevTools fra værktøjsmenuen i din browser:
Der er et par steder, du kan tjekke for at finde ud af, hvilke ressourcer der ikke indlæses via HTTPS.
Den første er fanen Konsol. Bemærk, at du muligvis skal opdatere siden, når du har åbnet Chrome DevTools for at kunne indlæse alt korrekt.
Hvis der er fejl med mixed content, fremhæves de enten i rødt eller gult. Typisk ledsages de af oplysninger, der forklarer, at “Denne anmodning er blevet blokeret; indholdet skal vises via HTTPS. Dette betyder, at browserindstillingerne er konfigureret til automatisk at blokere ethvert HTTP-indhold.
I et forsøg på at sikre, at sider kun indlæses via HTTPS, begyndte Chrome at begynde at blokere mixed content som standard med Chrome 79. Senest rullede de ud af funktioner for automatisk at opgradere blandede billeder og medier.
Derfor, når du bruger Chrome DevTools, kan du se meddelelser om blandet indhold, der angiver, at nogle anmodede elementer automatisk blev opgraderet:
Her kan vi tydeligt se, at der er en række usikre elementer, der forårsager advarsler om blandet indhold, herunder et stylesheet og script.
Du vil også bemærke, at der blev anmodet om et usikkert .jpg-billede, som automatisk blev opgraderet til HTTPS. (Bemærk: Hvis dette var i en anden browser end Chrome, blev den ikke automatisk opgraderet).
Du kan også se på fanen Sikkerhed i Chrome DevTools. Dette viser dig enhver usikker oprindelse:
Under fanen Netværk kan du også finde en liste over blokerede anmodninger:
Hvis du ikke bruger Chrome, eller bare vil have en hurtig oversigt over fejlene, kan du også bruge et gratis værktøj som Why No Padlock.
Det scanner en individuel side og viser dig alle de usikre ressourcer:
Dette værktøj er let at bruge. Du kan blot indtaste din URL og klikke på testside, og det viser dig eventuelle fejl, der er til stede. Plus, det er gratis!
Kontrol af HTTPS-advarsler i bulk
Hvis du er bekymret for resten af dit websted, kan du kontrollere det samlet. Her er nogle anbefalede muligheder for at gøre det:
- Der er et gratis lille værktøj kaldet SSL Check fra JitBit, som du kan bruge til at gennemgå dit HTTPS-sted og søge efter usikre billeder og scripts, der vil udløse en advarselsmeddelelse i browsere. Antallet af gennemgåede sider er begrænset til 400 pr. Websted.
- Ahrefs Site Audit tool har evnen til at detektere blandet HTTPS / HTTP-indhold. Hvis du allerede har adgang til denne løsning, eller hvis nogen i dit marketingteam gør det, kan det være en god måde at være grundig på.
- HTTPS Checker er en desktop-software, du kan installere for at scanne dit websted. Det kan hjælpe dig med at kontrollere “ikke sikre” advarsler og indhold efter store ændringer. Den er tilgængelig på Windows, Mac og Ubuntu. Den gratis plan giver dig mulighed for at kontrollere op til 500 sider pr. scanning.
- SSL Insecure Content Fixer er et WordPress-plugin, du kan installere på dit websted for at afdække fejl, der fører til mixed content warnings. Det er gratis at bruge og udfører endda automatisk rettelser for at løse fejlene.
Brug af et af ovennævnte værktøjer kan hjælpe dig med at spare tid over at skulle manuelt kontrollere hver side på dit websted for advarsler og fejl om mixed content. For en grundig vurdering af de potentielle fejl på dit websted kan du overveje at bruge en kombination af disse løsninger.
Trin 2: Kontroller, om HTTP-ressourcer er tilgængelige via HTTPS
Det næste trin er at bekræfte, at ressourcerne, der indlæses via HTTP, er tilgængelige via HTTPS. De er sandsynligvis, du skal bare opdatere linkene.
Lad os som et eksempel sige, at vores mixed content warnings pegede på følgende usikre jQuery-script og .jpg-billede:
- http://ajax.googleapis.com/ajax/libs/jquery/3.31/jquery.min.js
- http://example-site.com/wp-content/50d00acf6e4%2Fpuppy-thumb.jpg?v=1600261043278
Hvis vi tager begge disse URL’er, indtaster dem i vores browsers adresselinje og erstatter “http” med “https” i begyndelsen, kan vi se, at de indlæses fint. Derfor er vi simpelthen nødt til at søge og erstatte på vores websted.
Trin 3: Udfør en WordPress search and replace
Der er mange måder at udføre en WordPress search and replace. I dette afsnit gennemgår vi to forskellige anbefalede muligheder.
Hvis du er nysgerrig, anbefaler vi ikke at bruge et værktøj som Really Simple SSL. Selvom det er et godt plugin, er det bedst ikke at stole på en løsning som denne på længere sigt. Du migrerer ikke tilbage til HTTP senere, så det er bedst at gøre det på den rigtige måde og opdatere dine HTTP-URL’er i din database (som vi viser dig nedenfor).
Hvis du er Kinsta-kunde, kan du bruge vores search and replace tool, som er tilgængeligt lige i MyKinsta-dashboardet.
Gå til siden til værktøjet på dit websted, og klik på Search and replace:
Indtast derefter i søgefeltet den værdi, du vil se efter i databasen.
I dette tilfælde bruger vi vores HTTP-domæne: http://kinstalife.com. Klik derefter på knappen Search. Search and replace tool viser antallet af forekomster for den givne streng.
Marker afkrydsningsfeltet Replace for at fortsætte med udskiftningsprocessen. I feltet Replace with skal du indtaste det, der skal erstatte den værdi, du søger efter. I dette tilfælde bruger vi vores HTTPS-domæne: https://kinstalife.com.
Vi anbefaler også at lade afkrydsningsfeltet Ryd cache, når det er klart, automatisk rense Kinsta-cachen, når search and replace er afsluttet. Klik til sidst på knappen Replace:
Vigtigt: Sørg for, at du ikke medtager noget ledende / efterfølgende hvidt rum i nogen af disse felter, da dette kan give uønskede resultater.
Search and replace alternativer
Hvis du ikke bruger Kinsta, kan du udføre den samme opgave med det gratis Better Search Replace-plugin og derefter slette det, når du er færdig:
Du kan downloade dette værktøj fra WordPress Plugin Directory eller ved at søge efter det i dit WordPress-dashboard.
Efter at have aktiveret det, skal du bare søge efter dit HTTP-domæne (http://yourdomain.com) og erstatte det med dit HTTPS-domæne (https://yourdomain.com):
Som et alternativ kan du også foretage en search and replace det med interconnect/it Search Replace DB PHP Script eller WP-CLI.
Tjek vores video for at lære mere om brug af search and replace i WordPress:
Trin 4: Bekræft, at mixed content warnings er væk
Når du er færdig med search and replace, skal du dobbelttjekke dit websted for at bekræfte, at mixed content warnings er væk. Vi anbefaler, at du besøger dit websted på frontend og klikker dig rundt på et par sider, mens du ser på browserens statusindikator op i adresselinjen.
På vores side kan vi se, at .jpg-billedet nu er rettet, men der forbliver en usikker scriptadvarsel.
Det skyldes, at vi kørte en søgning og erstatter ressourcer, der indlæses fra vores eget domæne. Advarslen jQuery er forårsaget af et eksternt script, der skal opdateres manuelt:
I dette tilfælde skal scriptet tilføjes manuelt til vores WordPress-header (header.php). Det skal bruge en relativ URL, så vi opdaterede den til //ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js:
Search and replace vil sandsynligvis løse alle dine problemer.
Generelt vil du kun løbe ind i yderligere problemer, hvis du har noget hårdkodet på dit WordPress-websted.
Hvis du tror, at der er et eksternt script, der er hard coded i et af dine plugins eller temaer, og du har problemer med at spore det, er du velkommen til at kontakte den relevante udvikler for at få hjælp.
Ingen eksempler på mixed content warnings
Så du ved nu, hvad du skal se efter for at rette disse mixed content errors.
Her er et eksempel på, hvad der sker i Chrome, når alt indlæses korrekt via HTTPS, uden advarsler om mixed content:
Firefox vil tilbyde en lignende meddelelse:
Og her er hvad du kan se i Microsoft Edge:
Selv om ordlyden af meddelelsen kan variere lidt, afhængigt af hvilken browser du bruger, skal du se en meddelelse, der angiver en sikker forbindelse. Hvis du gør det, ved du, at du ikke længere har at gøre med blandede indholdsfejl på dit WordPress-websted.
Hvad med HSTS?
Nogle af jer undrer sig måske over, hvorfor du ikke bare kan bruge HSTS (HTTP Strict Transport Security) til at løse dette problem. HSTS blev oprettet som en måde at tvinge browseren til at bruge sikre forbindelser, når et websted kører over HTTPS.
Det er et sikkerheds header, du kan føje til din webserver og afspejles i response header som ‘Strict-Transport-Security’.
HSTS er dog ikke en hurtig løsning på alle mixed content warnings. HSTS håndterer kun omdirigeringer, mens mixed content warning er en funktion i selve browseren. Du har heller ikke kontrol over, om tredjepartswebsteder aktiverer HSTS.
Derfor skal du altid opdatere dine http://webadresser. Esa Jokinen dykker dybere ned i årsagerne til denne serverfejl-diskussion.
Yderligere anbefalinger (særlige tilfælde)
Hvis du bruger Elementor-sidebyggeren, skal du også gå ind i Elementor-indstillingerne og opdatere dit websteds URL der, så CSS-filerne regenereres med den nye URL.
Når du har gjort det, skal rydning af cachen løse eventuelle usikre advarsler på grund af Elementor. Derudover anbefales det at rense CDN-zonen, hvis du bruger Kinsta CDN.
Resumé
Mixed content warnings kan være frustrerende at håndtere, især når der er en håndfuld årsager, de kan tilskrives. Heldigvis er der nogle enkle trin, du kan tage for at løse disse problemer.
I de fleste tilfælde skal en simpel search and replace hurtigt løse dine mixed content warnings og få dit websted tilbage til det normale på få minutter. Hvis det ikke løser alt, er det sandsynligt, at der er et eller to hardkodede scripts tilbage. Du bliver nødt til at finde dem og opdatere dem manuelt for at rydde denne fejl eller ansætte en udvikler, der kan gøre det for dig.
Hvis du har feedback eller får problemer, så lad os det vide nedenfor i kommentarfeltet!
Head of Content at Kinsta and Content Marketing Consultant for WordPress plugin developers. Connect with Matteo on Twitter.
Skriv et svar