Če knjižnica predstavnosti spletnega mesta WordPress zraste na več deset gigabajtov, lahko naložene datoteke premakneš tudi v objektno shrambo (Amazon S3, Cloudflare R2, Backblaze B2). Spletno mesto nato slike streže iz shrambe, z lastno domeno (na primer media.pelda.hu), na gostovanju pa lahko sprostiš prostor. Nalaganje in prepis naslovov opravi vtičnik za prenos (WP Offload Media ali Media Cloud).

To se ne splača vsakomur. Prenos pomeni novo storitev, nove dostopne ključe in novo mesto za varnostno kopiranje ter vtičnik, ki mora delovati po vsaki posodobitvi WordPressa in PHP. Če knjižnica predstavnosti udobno gre na tvoje gostovanje in bi le rad pospešil streženje slik, je CDN preprostejši: slike enako streže s strežnika blizu obiskovalca, brez premičnih delov (pospešitev spletne strani s CDN).

Kako deluje prenos?

Vtičnik opravlja dve ločeni stvari, njuno zamenjevanje pa povzroči največ pokvarjenih selitev:

1. Ob nalaganju kopira. Ko WordPress v mapi wp-content/uploads pripravi sliko in njene sličice, jih vtičnik vse naloži v shrambo. Nastavitev odloči, ali lokalne datoteke ostanejo. Le brisanje sprosti prostor, le ohranitev pa da pot nazaj.
2. Ob prikazu prepiše naslov. Naslov slik se spremeni v naslov shrambe (ali tvoje lastne domene). Podatkovna baza se za to ne spremeni, zato se je mogoče vrniti z izklopom vtičnika. Graditelji strani pa celoten naslov slik pogosto vpišejo v vsebino; teh to ne prepiše.

Iz ene naložene fotografije je lahko skupaj s sličicami ducat datotek. Če pri kopiranju sličice manjkajo, se velika slika naloži, na manjših zaslonih (in na zaslonih visoke ločljivosti) pa stran ostane brez slike.

Katero shrambo izbrati?

Vse tri govorijo isti vmesnik, združljiv s S3, vtičniki jih obravnavajo enako. Razlika je v zaračunavanju prometa in načinu streženja:

	Amazon S3	Cloudflare R2	Backblaze B2
Odhodni promet	plačljiv (prek CloudFront ugodnejši)	ni pristojbine za promet, operacije so plačljive po kosih	brezplačen do trikratne shranjene količine, proti partnerskemu CDN (na primer Cloudflare) neomejeno
Javno streženje	CloudFront ali spletni naslov shrambe	le za lastno domeno ali Workerjem; naslov r2.dev je le za razvoj	s CDN pred njim
Prednost	najširša podpora vtičnikov in orodij, pravila življenjskega cikla, upravljanje različic	promet ne stane	najcenejše shranjevanje

Konkretnih cen namerno ne navajamo: spreminjajo se, strošek pa je odvisen od tega, koliko je prometa v primerjavi s shranjevanjem. Izmeri svojo knjižnico predstavnosti (glej spodaj) in računaj z lastnimi kalkulatorji ponudnikov.

1. Izmeri knjižnico predstavnosti

V vmesniku Terminal v cPanelu (skupina Napredno) ali prek SSH:

cd ~/public_html
du -sh wp-content/uploads
find wp-content/uploads -type f | wc -l
wp post list --post_type=attachment --format=count

Število datotek je zaradi sličic tipično deset- do petnajstkratnik števila prilog. Če jih je veliko več, nekaj ustvarja odvečne velikosti; to je dobro urediti pred selitvijo. Največje datoteke pokaže tudi vmesnik Poraba diska v cPanelu (preverjanje porabe diska).

2. Shramba in ključ z ozkimi pravicami

Pri ponudniku ustvari shrambo (bucket) in ključ API, ki daje pravice branja in pisanja le za to eno shrambo. Ne uporabljaj ključa za celoten račun. Zapiši si tudi naslov končne točke, združljive s S3 (pri R2 https://<id-racuna>.r2.cloudflarestorage.com, pri B2 https://s3.<regija>.backblazeb2.com).

3. Lastna domena za shrambo

Preden kar koli prepišeš, shrambo poveži z lastno poddomeno (na primer media.pelda.hu). Tako lahko ponudnika pozneje zamenjaš brez spremembe naslova. Pri R2 jo dodaš na strani Settings shrambe v razdelku Custom Domains, če je domena v Cloudflare; pri S3 s CloudFrontom, pri B2 s CDN pred njo. Preverjanje z vnaprej naloženo testno sliko:

curl -sI https://media.pelda.hu/wp-content/uploads/2026/10/proba.jpg | head -5

Videti moraš odgovor 200 in glavo content-type: image/jpeg. 403 pomeni, da je domena dodeljena, javni dostop pa ni vklopljen; pri R2 je to najpogostejši vzrok, da „ne deluje”.

4. Kopiranje obstoječih datotek

Pri manjši knjižnici predstavnosti (nekaj GB) to opravi tudi lastno orodje vtičnika: WP Offload Media in Media Cloud znata naložiti obstoječe priloge in pri tem izpolniti tudi lastno evidenco.

Pri veliki knjižnici predstavnosti je hitreje in zanesljiveje kopirati s programom rclone, ki po prekinitvi nadaljuje in primerja s kontrolno vsoto. Na gostovanjih aWh rclone ni nameščen, vendar lahko z zagonom na svojem računalniku kopiraš neposredno z gostovanja v shrambo, prek SFTP (na gostovanjih cPanel s ključem SSH, na vratih 4231). Z ukazom rclone config nastavi dve povezavi: eno vrste sftp za gostovanje (tarhely) in eno vrste s3 za shrambo (tarolo), nato:

rclone copy tarhely:public_html/wp-content/uploads tarolo:sajat-tarolo/wp-content/uploads --transfers 8 --progress
rclone check tarhely:public_html/wp-content/uploads tarolo:sajat-tarolo/wp-content/uploads --one-way

Na koncu ukaza check naj bo 0 differences found. Če je javil napako, znova zaženi ukaz copy: kopira le manjkajoče datoteke. Po kopiranju zaženi tudi lastno orodje vtičnika, da vtičnik ve, katera priloga je že v shrambi; brez tega starejše slike še naprej streže z gostovanja.

5. Nastavitev vtičnika

Dostopnega ključa ne shranjuj v podatkovno bazo (ta pride v vsako varnostno kopijo in vsako kopijo staging), temveč v datoteko wp-config.php. WP Offload Media na primer bere konstanto AS3CF_SETTINGS; točen identifikator ponudnika navaja dokumentacija vtičnika:

define( 'AS3CF_SETTINGS', serialize( array(
    'provider'          => 'SZOLGALTATO',
    'access-key-id'     => 'KULCS_AZONOSITO',
    'secret-access-key' => 'TITKOS_KULCS',
) ) );

V vmesniku vtičnika vnesi shrambo, predpono poti (wp-content/uploads, kot si kopiral), vklopi streženje z lastno domeno in brisanje lokalnih datotek pusti izklopljeno. Preverjanje:

wp eval 'echo wp_get_attachment_url( 123 ), PHP_EOL;'
wp eval 'echo wp_get_attachment_image_srcset( 123, "large" ), PHP_EOL;'

Namesto 123 vpiši pravi identifikator priloge (wp post list --post_type=attachment --field=ID --posts_per_page=1). Oba ukaza morata izpisati naslov https://media.pelda.hu/….

6. Zadnja sinhronizacija

Medtem ko je kopiranje teklo, so lahko na spletno mesto prišle tudi nove slike. Znova zaženi ukaza copy in check iz 4. koraka, nato orodje vtičnika. Drugi zagon premakne le še nekaj datotek.

Preverjanje

• V skrbniškem vmesniku naloži novo sliko in preveri, ali njen naslov kaže na lastno domeno in ali se je datoteka pojavila v shrambi.
• Zahtevaj vse velikosti slik starega prispevka (vse naslove iz srcset): vsak mora vrniti 200. 403 ali 404 kaže na nepopolno kopiranje.
• Če je graditelj strani v vsebino vpisal celoten naslov slik, ga lahko prepišeš z ukazom wp search-replace (https://pelda.hu/wp-content/uploads → https://media.pelda.hu/wp-content/uploads), vedno najprej s poskusnim zagonom.

Brisanje lokalnih datotek vklopi šele tedne pozneje, po temeljitem preverjanju, če sploh. Od tedaj je shramba edini izvod: varnostna kopija spletnega mesta knjižnice predstavnosti ne vsebuje več, zato potrebuješ ločeno varnostno kopijo shrambe.

Pogoste napake

Opozorilo o mešani vsebini. Če je naslov slik postal http://, jih brskalnik na strani HTTPS blokira. V vtičniku vklopi vsiljevanje HTTPS in preveri, ali je potrdilo lastne domene veljavno (mixed content).

Pisave se ne naložijo. Za spletne pisave (in nekatere druge vrste datotek) brskalnik uporablja pravilo CORS: z druge domene jih naloži le, če shramba pošlje glavo Access-Control-Allow-Origin. Za navadne slike to ne velja, zato slike delujejo, pisava pa se tiho zamenja. Na shrambi nastavi pravilo CORS za naslov svojega spletnega mesta, za zahteve GET in HEAD.

Prezgodaj izbrisane lokalne datoteke. Če je bilo brisanje vklopljeno med nepopolnim kopiranjem, nekaterih datotek ni nikjer. Iz dnevne varnostne kopije obnovi mapo wp-content/uploads (obnovitev iz JetBackup), jo znova kopiraj v shrambo, manjkajoče sličice pa ustvari znova: wp media regenerate --only-missing.