Limitasyon sa Upload ng Image sa WordPress
Karamihan ay nagpapayo na i-edit ang php.ini. Sa shared hosting madalas hindi pwede. Ang pag-compress muna ng imahe ay laging gumagana.
I-compress ang imahe para bumaba sa limit sa halip na taasan ang limitasyon, dahil sabay na naaayos ng mas maliit na file ang error sa pag-upload at ang bagal ng page. Namamana ng WordPress ang limitasyon nito mula sa PHP, karaniwang 2 MB o 8 MB depende sa host, at sa managed o shared hosting ay madalas hindi mo ito mababago.
Halos bawat artikulo sa paksang ito ay nagtuturo sa iyong i-edit ang php.ini, .htaccess o wp-config.php. Ipinapalagay ng mga tagubiling iyon na may server access ka na wala sa karamihan ng may-ari ng site, at kahit may access pa, dapat itanong kung ang pagtataas ba ng limitasyon ang tamang hakbang.
Saan nanggagaling ang limitasyon
Itinatakda ang limitasyon ng 3 halaga sa PHP, at ang pinakamaliit sa 3 ang nasusunod. Ipinapakita ng WordPress ang resultang numero sa ilalim ng upload box, kaya madalas itong naiiba sa ina-advertise ng host.
- Kinokontrol ng upload_max_filesize ang pinakamalaking solong file na tatanggapin ng PHP.
- Kinokontrol ng post_max_size ang kabuuang laki ng isang submission, kaya dapat mas malaki ito kaysa sa laki ng file.
- Kinokontrol ng memory_limit kung gaano karaming memory ang magagamit sa pag-resize habang gumagawa ng mga thumbnail.
- Maaari ding magdulot ng error ang max_execution_time, dahil maaaring mag-time out ang malaking imahe bago matapos ang pagproseso.
Ang ikatlong halaga ang nagdudulot ng pinakanakalilitong mga error. Ang file na matagumpay na na-upload ay maaari pa ring mag-fail habang gumagawa ang WordPress ng mga laki ng thumbnail nito, na nagreresulta sa sirang imahe sa media library sa halip na isang upload error.
Bakit mas mainam ang pag-compress kaysa pagtaas ng limit
Ang 6 MB na litrato sa isang web page ay problema pa rin tanggapin man ito ng server o hindi. Tinatanggal lang ng pagtataas ng limit ang mensahe ng error ngunit nananatili ang mabigat na file.
Gumagawa ang WordPress ng ilang laki ng thumbnail mula sa bawat upload, kaya ang isang mabigat na orihinal ay dumarami bilang mabibigat na kopya at umuubos ng storage sa buong media library. Ang pag-compress sa ilang daang kilobyte bago mag-upload ay nag-aayos sa error, nagpapaliit sa mga nagagawang sukat, nagpapabilis sa backup, at hindi nangangailangan ng anumang server access.
Paano lumusot sa ilalim ng limitasyon
Upang matagumpay na makapag-upload nang hindi binabago ang server settings, sundin ang 5 hakbang na ito.
- Tingnan ang limitasyong nakasaad sa ilalim ng WordPress upload box, na nagpapakita ng totoong numero para sa iyong host.
- I-resize ang imahe sa display width nito, i-doble para sa mga screen na may mataas na density, dahil ang 4000 pixel na litrato sa 800 pixel na kolum ay nagsasayang ng karamihan sa data nito.
- I-convert sa WebP ang mga litrato at graphics na sa site lamang ipapakita.
- I-compress sa target na 200 KB hanggang 400 KB, na angkop para sa halos lahat ng imahe sa loob ng artikulo.
- I-upload, pagkatapos ay tiyaking tama ang pagkaka-render ng imahe sa buong lapad nito sa parehong desktop at mobile.
Ang pagsunod sa ganyang pagkakasunod-sunod ay karaniwang nagbubunga ng file na 90 porsyentong mas maliit kaysa sa orihinal mula sa camera, nang walang kapansin-pansing pagbabago sa screen. Nawawala ang error sa pag-upload bilang karagdagang benepisyo sa halip na pangunahing layunin.
Inirerekomendang mga sukat para sa nilalaman ng WordPress
Itugma ang lapad ng imahe sa pinakamalapad na espasyong gagamitin nito sa iyong theme, pagkatapos ay i-doble para sa mga screen na may mataas na density. Karamihan sa mga content area ay mas makitid kaysa sa inaakala ng mga may-ari ng site.
| Paggagamitan ng imahe | Display width | Upload width | Target na laki |
|---|---|---|---|
| Imahe sa loob ng artikulo | 700 px | 1400 px | 150 KB hanggang 250 KB |
| Full width feature | 1200 px | 2400 px | 300 KB hanggang 500 KB |
| Hero o header banner | 1920 px | 1920 px | 300 KB hanggang 400 KB |
| Thumbnail o card | 400 px | 800 px | 50 KB hanggang 100 KB |
| Larawan ng may-akda o profile | 150 px | 300 px | Mababa sa 30 KB |
Kailan tamang itaas ang limitasyon
Itaas ang limitasyon kapag nag-a-upload ka ng talagang malalaking file na kailangang manatiling malaki, tulad ng print resolution photography, video, o mga theme package. Totoo ang mga sitwasyong iyon ngunit hindi karaniwan.
Ang isang photographer na nagbibigay ng matataas na resolution na gallery, isang shop na nag-i-import ng malaking plugin, o isang site na nagho-host ng mga nada-download na PDF document ay nangangailangan ng mas mataas na limitasyon. Ang isang blogger na ang litrato mula sa bakasyon ay ipapakita lang nang 700 pixels ang lapad ay hindi nangangailangan nito. Alamin kung para saan ang file bago baguhin ang server setting, dahil ang sagot ay kadalasang compression pa rin.
Paano itaas ang limitasyon kung kinakailangan
Magtanong muna sa host, dahil karamihan sa mga managed provider ay binabago ang halaga kapag hiniling sa loob ng ilang minuto. Mas mabilis itong mareresolba ng mga support ticket kaysa sa configuration files sa anumang hosting plan na naghihigpit sa access sa file.
- Ang mga managed WordPress host ay karaniwang nagpapakita ng setting sa control panel o binabago ito kapag hiniling.
- Ang cPanel hosting ay madalas mayroong MultiPHP INI Editor kung saan direktang maitatakda ang 3 halaga.
- Ang mga virtual private server ay nagpapahintulot sa pag-edit ng php.ini, at pagkatapos ay kailangang i-restart ang PHP service.
- Ang mga pag-edit sa .htaccess ay gumagana sa ilang Apache setup at nagdudulot ng server error sa iba, kaya magtabi ng backup.
- Ang mga plugin na nagsasabing nagtataas ng limit ay hindi maaaring lumampas sa pinapayagan ng server, anuman ang nakasaad sa paglalarawan.
Ang HTTP error na hindi tungkol sa laki ng file
Ang pangkalahatang HTTP error habang nag-a-upload ay karaniwang nangangahulugang naubos ang memory o execution time habang gumagawa ang WordPress ng mga thumbnail, hindi dahil tinanggihan ang file dahil sa laki. Mahalaga ang pagkakaibang ito dahil ang pag-compress sa imahe ay nag-aayos sa parehong dahilan.
Ang malalaking dimensyon kaysa sa laki ng file ang nagpapataas sa paggamit ng memory, dahil kailangang hawakan ng server ang bawat pixel sa memory habang nagre-resize. Ang 6000 sa 4000 pixel na imahe ay nangangailangan ng mas maraming memory kaysa sa ipinapahiwatig ng laki ng file nito. Ang pagbawas sa mga dimensyon bago mag-upload ay nag-aalis sa error kahit na nasa ilalim na ng limitasyon ang mismong file.
Ang mga sukat ng thumbnail na ginagawa ng WordPress
Gumagawa ang WordPress ng hindi bababa sa 4 na karagdagang kopya ng bawat upload, at ang mga theme at plugin ay karaniwang nagdaragdag pa ng ilan. Ang isang litrato ay maaaring maging 8 o 10 file sa disk nang hindi man lang nakikita ng may-ari ng site.
Ang mga default ay thumbnail na 150 pixels square, medium na 300 pixels, medium large na 768 pixels, at large na 1024 pixels, kasabay ng scaled na bersyon na ginagawa ng WordPress para sa napakalalaking upload. Ang mga page builder at gallery plugin ay nagrerehistro rin ng sarili nilang mga sukat bukod pa rito. Ang pag-upload ng mas maliit na orihinal ay nangangahulugang mas maliit din ang bawat nagagawang file, kaya naman ang pag-compress bago mag-upload ay may malaking epekto sa buong library.
Suporta sa WebP sa WordPress
Tinatanggap na ng WordPress ang mga WebP upload simula sa bersyon 5.8, at ipinapakita ng lahat ng kasalukuyang browser ang format na ito. Ang direktang pag-upload ng WebP ay umiiwas sa pangangailangan ng mga conversion plugin na ini-install ng maraming site para sa parehong layunin.
May dalawang paalala. Ang ilang lumang theme at page builder ay nagpapalagay na JPG o PNG ang gamit at maaaring hindi makagawa ng mga WebP thumbnail nang tama, kaya suriin muna ang isang test upload bago i-convert ang buong library. Ang mga imaheng nilalayon para i-download ng mga bisita, tulad ng mga press kit o napi-print na gabay, ay dapat manatiling JPG, dahil nananatiling mahirap gamitin ang WebP sa labas ng mga browser.
Pagsusuri sa bigat ng imahe sa isang live page
Buksan ang developer tools gamit ang F12, lumipat sa Network tab, i-filter ayon sa images at i-reload ang page. Inililista ng panel ang bawat imahe kasama ang totoong transferred size nito, nakaayos mula sa pinakamalaki.
Ang view na iyon ay direktang sumasagot sa tanong sa halip na manghula. Maghanap ng anumang solong imahe na higit sa 500 KB at anumang page kung saan ang kabuuan ng mga imahe ay higit sa 2 MB. Ang pinakamalaking file ang halos palaging unang dapat ayusin, at karaniwan itong isang header image o ang unang litrato sa isang post. Ang pag-aayos sa 2 o 3 imahe ay kadalasang nag-aalis sa halos lahat ng labis na bigat sa isang page.
Pag-aayos sa media library na dati nang mabigat
I-compress ang umiiral na library sa halip na ang mga bagong upload lamang, dahil ang mga lumang post ang nagdadala ng karamihan sa bigat sa isang matagal nang site. Ang isang blog na tumatakbo na nang 5 taon ay maaaring naglalaman ng libu-libong hindi naka-compress na mga imahe.
I-download ang uploads folder, iproseso ito bilang isang batch, at palitan ang mga file gamit ang parehong mga pangalan upang patuloy na gumana ang mga umiiral na post. Ang muling pagbuo ng mga thumbnail pagkatapos nito ay lumilikha ng mga bagong sukat mula sa mas maliliit na orihinal. Mag-backup bago magpalit ng anuman, dahil isa ito sa ilang mga gawain sa imahe na direktang nag-o-overwrite sa mga file.
Pagproseso sa buong uploads folder
I-drop ang folder bilang isang ZIP archive at ang bawat sinusuportahang imahe sa loob nito ay mae-extract, mare-resize, at maiko-compress sa isang proseso. Hanggang 500 file ang napoproseso bawat batch, na sumasaklaw sa karamihan ng maliliit at katamtamang mga site sa ilang ulit lang.
Lahat ay nangyayari sa loob ng iyong browser gamit ang sarili mong processor, kaya ang mga site ng kliyente, hindi pa nai-publish na mga draft, at mga pribadong gallery ay hindi kailanman umaabot sa server. Mahalaga iyon para sa mga ahensyang nagtatrabaho sa ilalim ng kontrata, kung saan ang pag-upload ng media library ng kliyente sa hindi kilalang compression service ay lalabag sa kasunduan kahit walang maging problema.