WordPress lastet uten CSS og bilder: én mappetillatelse var årsaken

Et WordPress-nettsted kan se fullstendig ødelagt ut selv om både sidene, databasen og admin-området fortsatt virker. Dette nettstedet lastet som stort sett uformatert HTML: designet var borte, bildene ødelagte, navigasjonen redusert til vanlige lenker, og deler av kontrollpanelet manglet styling. Årsaken var verken skadevare eller en mislykket oppdatering. Det var én enkelt mappetillatelse på wp-content som stille blokkerte serveren fra å levere hvert eneste stilark, skript og bilde på nettstedet.

Denne kundecasen går gjennom undersøkelsen, den faktiske årsaken på servernivå, og hvorfor det å lese nettleserens egne feilsvar betydde mer enn å installere noe på nytt. Har nettstedet ditt mistet stilingen og du vil ha kortversjonen først, dekker siden vår om WordPress-hjelp hva du bør sjekke og hva du bør la være å røre.

Problemet: teksten lastet, alt annet ga 404

Det offentlige nettstedet leverte HTML-innholdet sitt, men nesten ingen av de visuelle eller interaktive ressursene fulgte med. For en besøkende så nettstedet ut som om det var strippet ned til ren kildekode.

Symptomene:

• Sider som lastet uten sitt vanlige design
• Ødelagte bilder over hele nettstedet
• Ustilet navigasjon og sideelementer
• Manglende styling fra plugins og tema
• Deler av WordPress-kontrollpanelet som lastet feil
• Hundrevis av feil i nettleserkonsollen

Selve WordPress-installasjonen var tilgjengelig, noe som fortalte oss at databasen og PHP-kjernen fortsatt kjørte. Feilen lå spesifikt i å hente filer fra wp-content-mappen. Nettopp det skillet, at applikasjonen virker mens de statiske filene ikke gjør det, er det som pekte hele undersøkelsen mot serveren i stedet for mot nettstedet.

Utelukke de åpenbare mistenkte

Et så dramatisk symptom frister til en rask gjetning, og raske gjetninger blir dyre her. Et nettsted som laster som ren HTML kan like gjerne skyldes skadevare, en ufullstendig migrering, manglende plugin-filer, en feil i PHP-konfigurasjonen eller ødelagte omskrivingsregler. Hver av disse fører til en helt forskjellig reparasjon, og feil reparasjon kan gjøre mer skade enn det opprinnelige problemet. Så vi utelukket dem i stedet for å anta.

Skadevare. En skanner hadde flagget en infeksjonsadvarsel, og siden skadevare kan endre filer, databaseoppføringer og serverregler, måtte den tas på alvor. Vi inspiserte filene skanneren pekte på. Ingenting var faktisk skadet eller injisert. Advarselen var en falsk positiv, av det slaget disse skannerne jevnlig produserer, og vi la skadevare til side som årsak til visningsproblemet i stedet for å la en skummel merkelapp styre diagnosen.

PHP-konfigurasjon. Vi gikk gjennom serverens PHP-innstillinger og løftet dem til fornuftige produksjonsverdier på veien: 512 MB minnegrense, 64 MB grense for opplasting og POST, 120 sekunders kjøretidsgrense og en høyere grense for input-variabler. Verdt å gjøre for serverens helse, men vi ventet ikke at det var årsaken, og det var det ikke. PHP-grenser styrer hvordan applikasjonen kjører; de får ikke statiske .css-, .js– og bildefiler til å returnere 404 Not Found. Dette var eliminering, ikke løsningen.

Omskrivingsregler. Vi inspiserte .htaccess. WordPress-reglene var standard, uten uvanlige omdirigeringer eller omskrivinger som kunne forklare manglende ressursfiler. En feilaktig omskrivingsregel er en virkelig vanlig årsak til at WordPress svikter, så vanlig at vi har skrevet en egen guide om hvordan AI-genererte .htaccess-regler ødelegger WordPress, men her var den ikke synderen.

Nettverksfanen i nettleseren viste mønsteret

Det avgjørende beviset kom fra Chrome DevTools, i Konsoll- og Nettverksfanene. Nettleseren fikk 404 Not Found-svar på ressurser som tilhørte flere urelaterte plugins og det aktive temaet på én gang.

De feilende forespørslene spente over ressurser fra WooCommerce, Yoast SEO, Popup Maker, WP Mail SMTP, Click to Chat og YOOtheme-rammeverket. URL-ene lå under:

• /wp-content/plugins/ (CSS og JavaScript)
• /wp-content/themes/ (CSS og JavaScript)
• /wp-content/uploads/ (bilder)

Dette er detaljen som løste det. Hvis filene til én enkelt plugin hadde forsvunnet, ville bare den ene pluginen oppført seg feil. Men ressurser fra mange uavhengige plugins, temaet og opplastingsmappen sviktet alle samtidig. Urelaterte komponenter skader ikke seg selv på samme tid. Det ene de deler, er den overordnede mappen sin, så problemet lå nesten helt sikkert på wp-content-nivået, ikke inne i noen enkelt plugin eller tema.

Årsaken: en mappetillatelse publikum ikke kunne passere

Vi sjekket rettighetene på wp-content-mappen. Den var satt til 750.

Den verdien gir lese-, skrive- og passeringstilgang til eieren, lese- og passeringstilgang til gruppen, og ingenting i det hele tatt til alle andre. Om det bryter et offentlig nettsted, avhenger fullt og helt av hvilken bruker webserveren leverer filer som. På mange oppsett kjører serveren som nettstedets eier eller gruppe, og da ville 750 vært helt greit. På dette webhotellet var det ikke det: prosessen som leverte statiske filer, nådde dem som «andre», og «andre» hadde ingen tilgang til å gå inn i mappen. Dermed kom hver forespørsel etter en fil inne i wp-content tilbake som 404, selv om filene lå akkurat der på disken.

Det er derfor teksten på nettstedet lastet mens designet ikke gjorde det. PHP-applikasjonen, kjørt av eieren, kunne lese alt den trengte. Nettleseren, som hentet statiske ressurser gjennom den offentlige stien, var stengt ute fra den samme mappen.

Løsningen: 755 på mappen, ikke løsere enn det

Vi endret wp-content-mappen fra 750 til 755. Det legger til passeringstilgang for alle, samtidig som skrivetilgangen forblir hos eieren alene:

• Eier: lese, skrive, passere
• Gruppe: lese, passere
• Alle andre: lese, passere

Deretter bekreftet vi den standardiserte rettighetsstrukturen for WordPress på tvers av nettstedet, slik den offisielle dokumentasjonen beskriver i sin guide om filrettigheter:

• Mapper: 755
• Filer: 644

Vi satte 755 bare på det som trengte det, og holdt oss unna 777, en vanlig og farlig snarvei som gjør filer skrivbare for hvem som helst. Målet var minst mulig tilgang som lar serveren gjøre jobben sin, ikke mest mulig tilgang som får feilen til å forsvinne.

Etter rettighetsendringen og en oppdatering av siden lastet temastylingen, navigasjonen, skriptene og det store flertallet av visuelle komponenter igjen.

Resultatet

Nettstedets design ble gjenopprettet uten å bygge WordPress-installasjonen på nytt og uten å røre databasen. Tilbake på plass: temastyling, plugin-CSS, JavaScript-funksjonalitet, strukturert navigasjon, sidelayouter, det meste av bildene og normal presentasjon på forsiden.

Ett ærlig forbehold. Etter at hovedproblemet var løst, fortsatte et mindre antall bilde-URL-er å returnere 404. De var et annet problem enn rettighetsfeilen: konkrete mediefiler som faktisk manglet i opplastingsmappen, eller databasereferanser som pekte på filer som ikke lenger fantes. Notatene våre bekrefter at design- og innlastingsproblemet ble løst. De bekrefter ikke at hver siste manglende mediefil senere ble lastet opp på nytt, og det sier vi heller enn å antyde en ryddigere slutt enn grunnlaget bærer.

Hvorfor diagnosen var det som betydde noe

Det ville vært lett å arkivere dette som skadevare, en mislykket oppdatering, et ødelagt tema, en ufullstendig plugin-installasjon, en PHP 8.3-kompatibilitetsfeil eller en korrupt .htaccess. Hver av de tolkningene fører et destruktivt sted: å installere WordPress på nytt, bytte ut plugins eller rulle tilbake til en gammel sikkerhetskopi, alle med sin egen risiko og ingen av dem rettet mot en mappetillatelse. Nettstedet ville etter all sannsynlighet endt opp i dårligere forfatning, med den faktiske årsaken urørt.

Å sjekke nettleserens svarkoder og lete etter et mønster på tvers av urelaterte ressurser isolerte feilen til én enkelt delt innstilling. Det er den samme tilnærmingen som ligger bak de øvrige gjenopprettingene våre: vi sporet et eldre nettsted som brøt sammen etter en PHP-oppdatering tilbake til sin egentlige årsak på samme måte, og skilte en reell sikkerhetshendelse fra vanlig havari da vi undersøkte og gjenopprettet et kompromittert Multisite-nettverk.

Lærdom: når et nettsted mister designet, les Nettverksfanen først

Når WordPress leverer teksten sin, men mister stilingen, er den synlige siden bare halve diagnosen. Det mest nyttige beviset ligger som regel i nettleserens Nettverksfane, i svarkodene knyttet til hver mislykkede ressurs.

En systematisk sjekk går gjennom:

• Om forespørsler etter CSS og JavaScript returnerer 404, 403 eller 500
• Om de forespurte filene fysisk finnes på serveren
• Om domenet peker mot riktig dokumentrot
• Om .htaccess inneholder unormale regler
• Om mappe- og filrettigheter er riktige for webhotellet
• Om noen faktisk manglende medier forklarer de gjenværende feilene

Her brakte én enkelt korreksjon av en mappetillatelse tilbake mesteparten av nettstedet. Det er argumentet for bevisstyrt feilsøking fremfor å installere WordPress på nytt eller bytte ut komponenter som aldri var ødelagt.

Trenger du hjelp med et WordPress-nettsted som har mistet designet?

Når et nettsted plutselig laster uten styling, viser ødelagte bilder eller kaster utbredte ressursfeil, ligger årsaken ofte i hosting-konfigurasjonen snarere enn i temaet eller sidebyggeren. Vi undersøker hele forespørselsstien, fra nettleseren gjennom WordPress-installasjonen til serveren, før vi utfører noen reparasjon. Er det der du står nå, start med en gratis diagnose på siden vår om WordPress-hjelp, eller les mer om WordPress-feilrettingstjenesten vår. Virker nettstedet, men du mistenker at det er skjørt under overflaten, forteller en WordPress-helsesjekk deg hva som står i fare før det blir en krise.