Akinek évek óta van honlapja, annak folyamatosan nő a képeinek száma a háttérben. Ha ezek nincsenek megfelelően karbantartva, akár a tárhelyet is megtölthetik.
AZ ALÁBBI MEGOLDÁSOK SZAKÉRTŐ ÁLTALI HASZNÁLATA ELŐTT BIZTONSÁGI MENTÉST KELL KÉSZÍTENI!
Sok eset előállhat, amikor szükségtelen mértékben vannak jelen a médiaelemek, illetve amiért megtölthetik a tárhelyet. A legfontosabbakat szedtem össze ebben a cikkben!
Médiatár vs. szerverre feltöltött képek, fájlok
Fontos tudni, hogy a a médiatárba csak azok a képek, fájlok kerülnek be, amelyeket a Médiatár menü alatt, vagy egy oldal, bejegyzés, esetleg termék szerkesztésekor töltött fel a honlapra.

Ha FTP-n, külön is töltött fel fájlokat, az a médiatárban nem jelenik meg alapértelmezetten. De persze ezeket is be lehet importálni a Médiatárba.
A nem használt elemek törlése
Ezek a médiaelemek könnyen törölhetőek a Media Cleaner bővítménnyel. A másik blogomon írtam már róla.
Az „eredeti” képek törlése
A WordPress 5.3-as verziója óta van egy olyan funkciója, hogy a feltöltött képeket 2560 pixel széles verzióban (ha nagyobb az eredeti) újragenerálja, és a kisebb verzió kerül felhasználásra. Ez szuper funkció, csak a háttérben megmaradnak az „eredeti” fájlok. Ezeket központilag a Delete Unscaled Images bővítménnyel lehet törölni.
Letöltés:
Tesztelt verzió | Aktuális verzió
Arra figyelni kell, ha az eredeti képek URL beágyazással használva voltak, akkor a bővítmény használata elérhetetlen képhivatkozásokat fog eredményezni!
Különböző képverziók generálásának leállítása
Több megoldás is generálhat extra mennyiségű képeket.
WordPress képverziók (képméretek)
A Beállítások => Média alatt meg lehet nézni, hogy egy-egy feltöltött képből milyen méreteket generál a rendszer. Ennek oka, hogy minden feltöltés esetén lehessen választani 3 méret közül, és ne az eredeti kép legyen mindenhová berakva. Hátránya, hogy a háttérben sok felesleges kép tárolódik.

A szükségtelen méreteknél érdemes 0x0 pixel méretűre állítani a képgenerálást.
Alapesetben ezek a méretek egy-egy képnél:
- Bélyegkép: 150x150px
- Közepes méret: 300x300px
- Nagy méret: 1024x1024px
- Teljes méret: az eredeti kép.
Kinézet által generált képverziók
Vannak olyan kinézetek, amelyek kismillió dolgot tudnak, és hogy ez mindig jó megjelenést adjon, sok verzióban generálódik egy feltöltött képből kisebb verzió.
FTP-n meg lehet nézni egy-egy feltöltésnél, hogy mennyi verzió generálódik belőle:

Látható, hogy egy feltöltésből generálódik még 7 különböző verzió. Az eredeti 175 KB méretű kép így összesen ~419 KB-ot foglal.
A kinézetekben a add_image_size funkció adja meg, hogy milyen képméreteket generáljon. A szükségtelen méreteket hasonló kódrészletekben lehet megtalálni, és 0x0 pixelre állítani:

Bővítmények által generált képverziók
A kinézetnél írt logika alapján bővítmények is generálhatnak egy-egy képből felesleges verziókat.
TMP fájlok törlése
Ha van a szerveren tmp (ideiglenes mappa a feltöltéseknek) mappa, abban is irtózatos mennyiségű fájl tud felgyűlni. Egy példa:

Vannak szerverek, ahol a mappa automatikusan, rendszeresen ürül. Van ahol nem. Érdemes erre is figyelni, hiszen látható a képen, hogy extrém esetben több száz megabyte tárterületet foglalhatnak az itt megjelenő fájlok (a képen majdnem 200000 kép van).
BAK fájlok törlése
Ha BAK verzióban az eredeti képek biztonsági mentése megtörténik, az alapból duplikálatja a képek mennyiségét.
Automatikus importálások kordában tartása
A képek akkor szoktak irreális mértékbe elszaporodni egy weboldalon, ha valamilyen automatizmussal időről-időre lefut egy importálás funkció, ami mindig hoz új tartalmat, de esetleg a régi, törölt tartalmak médiaelemeit nem kezeli. Ha ilyen funkciója van a weboldalon, azt is érdemes megvizsálni, hogy nem okoz-e gondot.
Főbb problémaforrások lehetnek:
- Ismételt importálás futtatáskor a képek létrejönnek másolatként. Ha nem az importálásnál, de más miatt történik duplikálás, akkor annak okát kell keresni.
- Megszűnt tartalomnál csak a tartalom kerül törlésre, de a hozzá tartozó kép nem.
- Ha importáláskor nem csatolódik az importált kép a megfelelő tartalomhoz. Ebben az esetben a leválasztott képek törlésével a ténylegesen használatban lévő képek is törlődni fognak!
Ezeket minden importálásnál javítani kell, hogy kibukik a hibás működés.
Ezen felül ellenőrizni kell, hogy ismételt importáláskor a médiatárból törölt képek újra felkerülnek-e. Erre azért van szükség, hogy tömeges, automatizált képtörlésnél könnyen visszarakhatóak legyenek az esetlegesen szükségtelenül törölt képek.
A művelet idejére Broken Link Checker is kell az oldalra, az is találhat hiányzó, ám szükséges képet a rendszerben.
Feltöltött képek (automatikus) tömörítése
A feltöltött képeket mindig érdemes veszteségmentesen tömöríteni. Ha sok kép, esetleg automatizálva kerül fel a weboldalra, akkor a Smush Image Optimization bővítményt kell telepíteni, és beállítani (eredeti képekre is hasson, 80%-os minőség, stb.) megfelelően. Ez minden feltöltésnél elvégzi automatikusan a tömörítést.
Esettanulmány – összefoglaló
Egy ügyfélnél 147 GB adattartalom, 718000+ fájl volt a szerveren. Mutatom:

Ebből:
- Volt 2 db nagy fájl a weboldalon, ami együtt kitett 106 (!!) GB-ot. Ezek törlésével jelentős hely szabadult fel.
- 200000 (!!) fájl tmp fájl volt.
- 497000+ fájl a médiatárba feltöltött 80000+ kép különböző verziója volt:

A cikkben írt ellenőrzések, és alapos előkészület után egy hónap (teszt, hogyha balul sül el valami, ne legyen katasztrófa) „Leválasztott” megjelölésű képeit töröltük. Az eredményt idézem:
A 2025/10 hónapból kitöröltem 3765 leválasztott fájlt, ami (31774 fájlból 13 523 maradt) 18221 (!!! – darabonként 4,84 verzió) verzióban volt a /web/wp-content/uploads/2025/10 mappában. Így ebben a mappában a korábbi 3,94 GB-ból maradt ennyi: 1,87 GB. Azaz csak 1 mappán 2 GB hely meg lett spórolva.
Miután mindent rendben találtunk, utána célszerű volt végigmenni minden hónapon. Illetve azért, hogy a véletlen törlést kizárjam, azonosítottam azonos struktúrájú fájlneveket (pl.: vizjeles-xxxxx, vagy éppen 58… karaktersorozatokat tartalmazó fájlok – de minden weboldalnál más és más minták ismétlődhetnek), és először ezek közül takarítottam ki a leválasztottakat (de azért átpörgettem gyorsan a törlés előtt minden listát).
A feladat végén felkerült olyan bővítmény (SiteEase Bulk Delete Manager), amivel időnként pár kattintással lehet törölni a leválasztott fájlokat. Elsőre azért nem lehetett ezt megoldani, mert a meglévő eszközök elhaltak ekkora képmennyiségen.
Szükség esetén a Regenerate Thumbnails bővítménnyel ismét le lehet generáltatni a különböző szükséges képméret-verziókat.
További lehetőség:
Delete Unscaled Images bővítménnyel az eredeti képek törlése, hogy csak a használt verziók maradjanak meg.
Az eredmény a tárhelyen:
Sokkal kisebb méretű weboldal, kevesebb tárhelyköltség, kiszámíthatóbb működés.
Az eredmény az adatbázisban:
Az adatbázis mérete is csökkent, hiszen a képek törlésével a wp_postmeta tábla mérete jelentősen csökken. Eredetileg 296,2 MB volt a teljes MySQL adatbázis mérete.
Az előtte-utána állapot összefoglalója:
A 106 GB-nyi mentés nélkül (ahol 2 fájlt töröltem, és ennyi felszabadult) az alábbi eredményt értem el a fentiek elvégzésével (a tmp fájlokat sem számolva):
| Tétel | Előtte | Utána | Különbség |
|---|---|---|---|
| Weboldal mérete | 41,3 GB | 21,2 GB | -48,67% |
| Fájlszám a tárhelyen | 518295 | 227048 | -56,19% |
| Fájlszám az uploads könyvtárakban | 497297 | 206074 | -58,56% |
| Médiatár elemek | 85418 | 33008 | -61,37% |
| MySQL adatbázis mérete | 296,2 MB | 124,4 MB | -58,00% |
A fentiek után egyébként nagyjából 2-300 kép maradt a Médiatárban, ami nem volt csatolva sehová. Ennek oka, hogy egyszerűbb volt ezeket (az összmérethez képest „semmi” a méretük) meghagyni, mintha töröltem volna, és kiderült volna később, hogy ezekre mégis szükség van.
Felmerülhet kérdésként, hogy nem lehetett volna ezt a 2-300 képet is törölni, és ha valamelyik hiányzott volna, akkor a médiatárba egyszerűen visszatölteni? Nem, mert a szerveren év/hó mappában tárolódnak alapesetben a képek, így mondjuk egy 2025. áprilisában feltöltött kép 2026. februári újrafeltöltés eredményeképpen a korábbi wp-content/uploads/2025/04 mappa helyett a wp-content/uploads/2026/02-es mappába kerül, amivel a korábbi elérhetőségre mutató hivatkozások nem állnak helyre.
3 lépés maradt, amit még „elvarratlan” szálnak láttam ezen a ponton:
- Csatolni kell a leválasztott képek közül egy (hosszú távon is megmaradó) oldalhoz azokat, amelyek törlése „necces” volt. Ezzel elérjük azt, hogy ezután a jövőben, az újonnan keletkező leválasztott képek törölhetővé válnak különösebb „gondolkodás” nélkül.
- Telepíthető a „SiteEase Bulk Delete Manager” (aktuális verzió | tesztelt verzió) bővítmény, amiben pár kattintással törölhetőek a leválasztott képek. Ezt mondjuk havonta 1x elvégezve kordában lehet tartani a weboldal méretét, mert a leválasztott képek mennyisége remélhetőleg soha nem lép át újra egy kritikus szintet.
- A fentiek után is folyamatosan jönnek létre leválasztott képek. Azt gondolom, hogy az importálás nem tudja azt kezelni, hogy egy-egy tartalomhoz (hirdetés) tartozó képeket is töröljön, ha megszűnik egy hirdetés. Lehet(ne) ezzel foglalkozni, hogy megnézzük, beállítható-e, de a mostani állapot alapján szerintem egyszerűbb az 1-2) pontok elvégzése hosszabb távon is.
A fentiek után mondhatjuk azt, hogy egy hasonló kaliberű feladattal végeztünk.




