Felsökning media bibliotek

För att felsöka varför inte alla bilder visas i WordPress mediabibliotek, kan vi kolla igenom några vanliga orsaker och lösningar. Här är en checklista du kan börja med:

🔍 1. Är bilderna faktiskt uppladdade till WordPress?

• Gå till Media > Bibliotek i adminpanelen.

• Byt visningsläge till Lista istället för rutnät – ibland visas inte alla bilder i rutnätsläget pga JavaScript-problem.

• Kontrollera om filerna finns i mappen via FTP eller File Manager:
  wp-content/uploads/år/månad/
  Finns bilderna där men inte i biblioteket?

🧱 2. Felaktiga filrättigheter

Om bilderna ligger på servern men inte syns i mediabiblioteket:

• Kontrollera filrättigheter – bilderna bör ha behörigheten 644 och mappar 755.

• Om du har SSH-åtkomst eller via FTP, dubbelkolla att användaren som kör WordPress kan läsa bilderna.

🔄 3. Försök återskapa media-poster

Om bilder finns i filsystemet men inte i databasen:

• Använd ett plugin som ”Media Sync” eller ”Add From Server” för att ”importera” bilderna till mediabiblioteket.

  Det skapar poster i databasen för filer som finns på servern men inte är registrerade i WordPress.

🚫 4. Filtyper och filstorlek

• Är filerna ovanligt stora? WordPress kan neka stora filer beroende på serverinställningar.

• Är det tillåtna format? Standardformat är .jpg, .jpeg, .png, .gif, .svg kräver extra plugin/stöd.

📦 5. Teman eller plugins som stör

• Prova att inaktivera alla plugins tillfälligt och se om problemet kvarstår.

• Byt till ett standardtema som Twenty Twenty-Four.

• Ladda om biblioteket – visas nu fler bilder?

🐘 6. PHP-minnesgräns eller andra serverbegränsningar

• Kontrollera PHP error loggar – ibland kan minnesgräns (memory limit) eller timeout orsaka att bilder inte laddas korrekt.

• Öka memory_limit i php.ini eller wp-config.php (t.ex. define('WP_MEMORY_LIMIT', '256M');)

Vill du att jag hjälper dig kolla något av det här mer i detalj – t.ex. skapa ett kort kodsnutt för att kolla filrättigheter, eller föreslå ett plugin för att synka bilder? Har du tillgång till servern (FTP, cPanel eller liknande)?

Ja, det stämmer – det kan finnas två olika filstrukturer i WordPress beroende på inställningar, plugins och hur sajten har utvecklats över tid. Här är de två vanligaste:

📁 Standard WordPress-filstruktur för uppladdade bilder

Det vanliga sättet:

📌 Förklaring:

• WordPress skapar undermappar baserat på år/månad vid uppladdning.

• Flera kopior av bilden genereras i olika storlekar, t.ex. -150x150, -300x200 (beroende på inställningar i WordPress och teman).

🗂️ Alternativ struktur – t.ex. med plugins eller specialanpassning

I vissa fall hittar man t.ex.:

Eller:

📌 Varför händer det här?

• Någon har avaktiverat tidsbaserad uppladdning via:

  Inställningar > Media > ”Ordna mina uppladdningar i månatliga och årliga mappar”

• Eller ett plugin (t.ex. WooCommerce, ACF, formulär-plugins, externa API:er) laddar upp bilder i en egen mappstruktur.

• Vissa teman eller utvecklare laddar upp bilder direkt utan att registrera dem i mediabiblioteket.

🔧 Kolla vilken struktur du använder just nu

Gå till:

Inställningar > Media
Där finns en ruta:
☑️ Ordna mina uppladdningar i månatliga och årliga mappar
Om den är avbockad sparas bilder i /uploads/ utan år/månad-mapp.

🔍 Tips för att hitta bilder

• Via FTP: Kolla både i wp-content/uploads/2025/04/ och direkt i uploads/

• Via databas: I tabellen wp_posts, där post_type = 'attachment' och guid pekar på filens URL

Vill du att jag hjälper dig analysera vad som används hos dig? Du kan dela exempel på två olika sökvägar till bilder så kan jag se skillnaden.

Aha! Eftersom du använder WordPress Multisite, så blir det ytterligare en dimension i filstrukturen – varje sajt i nätverket har sin egen uppladdningsmapp. Det förklarar varför det kan se ut som att två olika strukturer används.

🏗️ Filstruktur i WordPress Multisite

När du använder Multisite, hanteras mediabiblioteket separat för varje sajt. Filvägarna ser då ut så här:

🟦 För huvudwebbplatsen (site ID = 1):

🟨 För en undersajt (t.ex. site ID = 2):

Mappen sites/2/ anger att det är en annan webbplats inom nätverket. Det här är standardstrukturen i Multisite.

🔍 Vanliga orsaker till ”saknade” bilder i Multisite

1. Du kollar i fel sajts mediabibliotek
   Bilder är inte delade mellan sajter i nätverket. Om du är inne på sajt A, ser du inte bilder uppladdade till sajt B.

2. Direktuppladdning via FTP
   Om någon har laddat upp bilder direkt i uploads/2025/04/ istället för uploads/sites/2/2025/04/, kommer de inte synas i mediabiblioteket för sajt 2.

3. Felaktiga filvägar eller URL:er
   Om en undersajt försöker visa en bild från huvudwebbplatsens mapp (eller tvärtom) men den inte har behörighet.

✅ Vad du kan göra

• 🔍 Kolla wp-content/uploads/sites/[site-id]/ för att se undersajtens bilder.

• 📦 Använd ett plugin som Media Sync på den sajten du är inne i – det registrerar bilder som finns i filsystemet men inte i databasen.

• 🛠️ Undersök om något plugin (t.ex. WPML, ACF eller tredjeparts-plugin) ändrar uppladdningsvägar eller blandar media mellan sajter.

• 🤓 Kontrollera blog_id i databasen (wp_blogs och wp_posts med post_type = 'attachment') – varje sajt har en egen wp_[n]_posts-tabell.

Vill du att jag hjälper dig kolla exakt vilken sajt (eller mapp) en viss bild borde ligga i? Du kan skicka bildens URL så kollar jag vilken väg som gäller i multisite.

Aha – nu börjar bilden klarna rejält! 🕵️‍♂️ Det du ser är en blandning av två olika lagringssystem för multisite, beroende på när nätverket skapades och vilken version av WordPress som användes.

🗂️ blogs.dir vs uploads/sites

🔸 Äldre multisite-installationer (pre WordPress 3.5)

Använde:

Exempel:

🔹 Nyare multisite-installationer (WordPress 3.5 och framåt)

Använder:

Exempel:

📌 Viktigt:

• Båda strukturerna kan samexistera om du uppgraderat från en äldre multisite.

• WordPress stöder fortfarande blogs.dir om det finns där – men nya uppladdningar bör gå till uploads/sites.

🤔 Varför blandas det?

Här är några vanliga orsaker:

1. Äldre sajter i nätverket använder blogs.dir, medan nyare använder uploads/sites.

2. Manuell migrering eller import har lagt bilder i fel mapp.

3. Något plugin eller specialkod pekar på gamla sökvägar.

4. Hardcodade länkar i databasen till gamla /files/-URL:er (typ /files/2025/04/bild.jpg istället för /wp-content/uploads/sites/2/...).

🔧 Vad du kan göra

✅ 1. Kontrollera UPLOADS-konstant i wp-config.php

Om den finns:

→ Det tvingar WordPress att använda blogs.dir istället för standard uploads/sites.

✅ 2. Kolla om blogs.dir används i .htaccess eller rewrite rules

WordPress brukar ha en rewrite så här:

→ Det omdirigerar gamla länkar som /files/2025/04/bild.jpg till rätt mapp.

✅ 3. Mappa om gamla länkar

Om du vill konsolidera allt till nya strukturen:

• Flytta filer från blogs.dir/[id]/files/ till uploads/sites/[id]/

• Uppdatera databasen så URL:erna pekar rätt

  • Leta efter /files/ och ersätt med /wp-content/uploads/sites/[id]/

Använd t.ex. plugin som:

• Better Search Replace

• Velvet Blues Update URLs

⚠️ Backup först! Detta kan påverka många inlägg/bilder.

Vill du gå över helt till den nya strukturen, eller bara förstå vad som händer just nu? Jag kan hjälpa dig med ett migreringsskript eller guide om du vill flytta allt till uploads/sites.

Tack! Den där raden i din .htaccess:

…betyder att din multisite fortfarande använder det äldre blogs.dir-systemet (eller åtminstone stödjer det för bakåtkompatibilitet).

🔍 Vad gör den här regeln?

Den omdirigerar URL:er av typen:

till ett PHP-script:

…som i sin tur hämtar filen från wp-content/blogs.dir/[site-id]/files/... på servern.

💡 Vad betyder det för dig?

✅ 1. Du har två parallella system:

• Nyare bilder går till wp-content/uploads/sites/[id]/

• Äldre (eller vissa importerade) bilder ligger i blogs.dir/[id]/files/

✅ 2. Bilder som använder /files/ i URL:en är beroende av ms-files.php

• Det är en liten prestandaförlust, eftersom bilderna går genom PHP i stället för direktservering.

✅ 3. Du kan migrera till den nya strukturen – men det kräver omskrivning av länkar och flytt av filer.

🚀 Vill du modernisera och bli av med blogs.dir?

1. Flytta filer (per sajt):

Flytta allt från:

till:

2. Uppdatera länkar i databasen

Sök och ersätt:

• /files/2025/04/bild.jpg
  → /wp-content/uploads/sites/2/2025/04/bild.jpg

Använd t.ex. Better Search Replace eller WP-CLI:

3. Ta bort RewriteRule när allt är migrerat (valfritt)

När du är säker på att inga länkar längre använder /files/, kan du ta bort den raden från .htaccess.

Vill du att jag hjälper dig skapa ett litet PHP-script som automatiskt:

1. Flyttar filer från blogs.dir till uploads/sites

2. Uppdaterar länkar i inlägg för en viss sajt?

Eller vill du bara låta båda systemen leva parallellt ett tag till?

Yes – du har helt rätt, och jag förklarar gärna i detalj så du får full koll på hur det funkar i WordPress Multisite med blogs.dir-strukturen:

📂 Struktur i blogs.dir – sajt för sajt

✅ 1. Huvudsajten (root site / site ID 1)

Den ligger INTE under blogs.dir, utan har sina bilder här:

📌 Det är standard för huvudsajten – alltså precis som i en vanlig WordPress-installation.

✅ 2. Undersajter (site ID 2, 3, 4…)

De har sin egen katalogstruktur under blogs.dir – alltså:

Där 2, 3 etc. motsvarar den interna ID:n för varje sajt i nätverket.

📦 Sammanfattning

🧭 Bonus: Hur vet du vilket ID en sajt har?

• Gå till Nätverksadmin > Webbplatser, håll musen över en sajt → kolla URL:en:

  bash

  KopieraRedigera

  /wp-admin/network/site-info.php?id=2


  Då vet du att sajtens ID = 2 → blogs.dir/2/ eller uploads/sites/2/.

Vill du ha hjälp att:

• Lista alla sajter och deras mappvägar?

• Flytta från blogs.dir till uploads/sites?

• Kolla om några inlägg länkar till /files/ och behöver uppdateras?

Jag kan hjälpa dig med allt från script till handpåläggning 👨‍🔧

Bra att du har uppdaterat sökvägarna i databasen – men om WordPress fortfarande visar sökvägar som /files/..., så finns det sannolikt något annat i spelet som genererar eller manipulerar länken.

Här är en strukturerad felsökningsguide för just detta fall:

🧠 Varför syns fortfarande /files/ i mediabiblioteket eller på sajten?

🧩 1. WordPress använder ms-files.php för undersajter – om inget annat anges

Även om du har uppdaterat sökvägarna i databasen (t.ex. i guid, post_content etc.), så:

• WordPress kan dynamiskt bygga URL:en som /files/... för media i multisite via en filter/hook.

• Funktionen wp_get_attachment_url() översätter fysiska sökvägar till URL:er via bl.a. get_blog_details() och inbyggda multisite-rewrites.

🛠️ 2. Kolla om upload_path är satt för sajten

Gå till databasen och kolla tabellen:

Sök efter fältet:

Om värdet är satt till t.ex.:

→ Då tvingar det WordPress att generera /files/-URL:er, oavsett vad som står i guid eller post_content.

✅ Lösning:

• Radera raden med upload_path eller sätt den till tomt ('')

• Kontrollera även upload_url_path – det ska också vara tomt eller korrekt pekande på wp-content/uploads/sites/2

🪝 3. Har du ett plugin eller custom code som filtrerar bild-URL:er?

Sök i ditt tema eller plugins efter filter som:

eller:

→ Dessa kan skriva om sökvägen tillbaka till /files/ även om du uppdaterat databasen.

✅ Rekommenderade steg

1. Kolla upload_path & upload_url_path i databasen för sajt-ID

2. Sök efter filter i funktioner eller plugins som påverkar upload_dir

3. Testa att ladda upp en ny bild på sajten – hamnar den i uploads/sites/... eller blogs.dir/...?

   • Om den hamnar rätt men länken ändå blir /files/, vet vi att det är något i genereringen som spökar.

4. (Valfritt) Rensa cache – både server-, browser- och ev. WordPress-cache/plugin-cache.

Vill du att jag hjälper dig skriva ett litet PHP-snutt som loggar exakt vilken URL wp_get_attachment_url() returnerar för en viss bild? Det kan visa vad som pågår bakom kulisserna.

Aha! Där har vi det! 🔍
Om du använder WP Offload Media (tidigare WP Offload S3) så är det den som tar över genereringen av media-URL:er – inklusive att ibland fortsätta visa gamla länkar om det inte är helt konfigurerat.

💡 Vad WP Offload Media gör

• Flyttar dina bilder från wp-content/uploads till en extern lagring (som S3, DigitalOcean Spaces, Google Cloud Storage etc).

• Byter automatiskt ut bild-URL:er i inlägg, mediabibliotek osv.

• Kan behålla eller ta bort lokala kopior beroende på inställningar.

🛠️ Varför du fortfarande ser /files/

1. Bilderna är inte offloadade än

Om WP Offload Media inte har hunnit eller kunnat ladda upp vissa filer, så används fortfarande WordPress’ interna logik – vilket för multisite = ms-files.php → /files/.

2. Gamla bilder har inte uppdaterats i metadatan

Bilder som fanns innan Offload Media aktiverades kan fortfarande ha gamla vägar (t.ex. /files/2023/06/bild.jpg), även om du uppdaterade guid i databasen.

3. Offload Media har caching aktiverad

De genererade URL:erna kan vara cachelagrade (transients, object cache, CDN), och visar då fortfarande gamla länkar tills det uppdateras.

✅ Så här fixar du det

🔁 1. Force offload av bilderna igen

Gå till:

Media Library > WP Offload Media > Tools

• Kör: Offload all unattached media

• Eller använd Regenerate Attachment Metadata (om du har t.ex. ”Regenerate Thumbnails”-plugin eller via WP-CLI).

🧹 2. Rensa cache

• Objektcache (t.ex. Redis eller Memcached)?

• CDN-cache? (Cloudflare, Bunny, etc.)

• WordPress-page cache?

Rensa allt efter du offloadat igen.

🔍 3. Kolla varje bilds metadata

Under fliken Media → välj en bild → scrolla ned:

• WP Offload Media visar där var bilden lagras och vilken URL den använder.

• Om du ser ”This file has not been offloaded”, klicka på knappen ”Offload”.

✨ Tips: Få koll med WP-CLI

Kör i terminal (om du har tillgång):

För att se vilka filer som är offloadade eller inte. Du kan även köra:

För att tvinga en ny offload av alla lokala filer.

Vill du ha hjälp att skriva ett litet script eller kommando för att tvinga om-offload eller massuppdatera? Jag kan anpassa det efter din miljö.

Tack – då vet vi att du kör WP Offload Media Lite, vilket har vissa begränsningar jämfört med Pro-versionen. Det förklarar varför vissa bilder fortfarande visas via /files/ – Lite-versionen gör nämligen inte fullständig omskrivning av gamla bilder automatiskt.

🧩 Vad WP Offload Media Lite inte gör:

1. ❌ Ingen automatisk migrering av redan uppladdade filer

2. ❌ Ändrar inte befintliga post_content, guid eller metadatan för gamla inlägg

3. ❌ Gör ingen offload av ”unattached” media (sånt som inte är kopplat till ett inlägg)

Därför syns fortfarande /files/ trots att du uppdaterat sökvägar.

✅ Så här kan du gå vidare

1. 🔁 Gör en manuell offload av gamla bilder

Tyvärr måste du i Lite-versionen:

• Öppna varje gammal bild i Media Library

• Klicka på “Offload” manuellt
  → Då laddas filen upp till molnet och får ny URL

🧠 WP Offload Media Lite offloadar bara nya uppladdningar automatiskt.

2. 🛠️ Alternativt: Använd plugin + regenerering

Installera dessa:

• ✅ Regenerate Thumbnails

• ✅ (ev.) Enable Media Replace
  → Dessa hjälper till att trigga metadata-omskrivning så WP Offload Media ser filerna som ”nya” och offloadar dem.

3. 💡 Snabbare workaround med WP-CLI (om du har tillgång)

→ Det triggar ombyggnad av bildens metadata, vilket kan få WP Offload Media Lite att offloada bilderna om de laddats upp från början av WP.

4. 🚀 Uppgradera till Pro (valfritt)

WP Offload Media Pro har:

• Automatiskt stöd för att offloada gamla bilder i bulk

• Omskrivning av gamla URL:er i innehåll

• Integrering med CDN + cache flushing

Det är inte ett måste – men sparar mycket tid i just den här situationen.

👇 Vill du…

• Skriva ett litet script/snutt som offloadar alla bilder?

• Skapa en översikt av vilka bilder som ligger kvar lokalt vs i molnet?

• Automatisera detta över hela multisiten?

Jag hjälper gärna, oavsett om du vill hålla dig till Lite eller bygga något eget.

Yes – du har helt rätt. I WP Offload Media Lite är den stora begränsningen just detta:

🔒 Du kan inte offloada gamla filer – bara nya uppladdningar offloadas automatiskt när du laddar upp dem via mediabiblioteket.

Så även om du klickar runt i mediabiblioteket finns ingen manuell ”Offload”-knapp för befintliga filer i Lite-versionen. Det är en Pro-feature.

🔁 Alternativ du har just nu

🅰️ 1. Ladda om bilderna (manuellt)

Det funkar, men det är brutalt långsamt:

• Hämta originalbilden från blogs.dir/... eller uploads/...

• Ta bort den från mediabiblioteket

• Ladda upp den igen → Då kommer den automatiskt offloadas

Men… det är ju inte skalbart.

🅱️ 2. Kombinera med script eller WP-CLI (om du vill hacka det lite)

Ett exempel på hur du kan tvinga ett system att tro att en gammal fil är ny, är att:

• Regenerera attachment metadata (wp_generate_attachment_metadata)

• Trigga wp_update_attachment_metadata

• Låta WP Offload Media Lite “kroka på” och offloada

Men det kräver kod – och är inte officiellt supportat.

🅾️ 3. Uppgradera till WP Offload Media Pro

Jag vet, inte den roligaste lösningen – men ärligt talat:

🧹 Om du har hundratals bilder utspridda i olika undersajter i en multisite… så är Pro-versionen typ det enda rimliga sättet att få full offload automatiskt + uppdatering av gamla URL:er i innehåll.

→ Här är jämförelsen mellan Lite och Pro

Vill du göra ett eget offload-script?

Om du vill jobba runt detta själv (utan att uppgradera), kan jag hjälpa dig att:

✅ Skriva ett PHP-snutt som går igenom alla bilder i en sajt
✅ Kopierar filerna till t.ex. S3 eller annan molnlagring
✅ Uppdaterar metadatan så WP tror de är “offloadade”

Lite ”guerilla-style” men det funkar 😄