Anında Görüntü İşleme, Düzeltmekten Daha Fazla Soruna Neden Oluyor

2017-03-07 Güncellemesi: Artık anında görüntü işleme için daha iyi bir çözüm sunuyoruz.

Görüntüler, ağın ekmek ve tereyağıdır. Görüntüler ve diğer medyalar olmasaydı, web oldukça farklı olurdu ve neredeyse zenginleştirici olmazdı; odayı gerçekten birbirine bağlayan bir kilim gibidirler. Bununla birlikte, WordPress topluluğunda anında (OTF) görüntü işleme kitaplıklarını kullanma konusunda endişe verici bir eğilim var. Temalar ve eklentiler, WordPress'in yerleşik görüntü yeniden boyutlandırma işlevinden OTF işleme kitaplıkları lehine vazgeçtiğinde önlenebilir uyumluluk sorunları ortaya çıkar.

Bu makalede, WordPress'te OTF işlemenin etkilerini, görüntü standartlarını izlemenin faydalarını ve bir WordPress ortamında görüntülerle (ve daha sonra diğer geliştiricilerle) nasıl geçinileceğini ele alacağım .

Anında Görüntü İşleme Neler Oluyor

Çok derine dalmadan önce, OTF görüntü işlemenin ne olduğunu, nasıl tespit edileceğini ve genellikle WordPress projelerinde nerede bulabileceğinizi kısaca açıklamalıyım. Anında kırpma olarak da bilinen OTF görüntü işleme, geliştiricilerin URL parametreleri (eski okul) veya manipülasyon sınıfları (günümüzde daha yaygın bir yaklaşım) kullanarak görüntüleri yeniden şekillendirmesine, kırpmasına ve filtrelemesine olanak tanır. OTF işlemeyi kullanmak, geliştiricinin bir defaya mahsus, özel boyutlar tanımlamasına ve görüntülerin ihtiyaç duyduğu şekilde işlenmesine olanak tanır.

Birçok geliştirici, kullanım ve uygulama kolaylığı nedeniyle OTF işlemeyi kullanır. Herhangi bir PHP tabanlı CMS'de OTF işlemeyi kullanmaya başlamak genellikle bir WordPress eklentisi eklemek veya yalnızca bir dosya eklemek kadar basittir. Ayrıca, ön uç geliştiriciler, basit, özlü sözdizimleri nedeniyle birçok OTF kitaplığını kullanabilir. Bu esneklik sayesinde, geliştiriciler araç kutularını projeden projeye yalın tutabilir ve tasarım (ön uç) ile geliştirme (arka uç) arasında daha fazla örtüşme sağlayabilir.

Kulağa harika geliyor mu? Pratikte değil.

WordPress'te OTF işlemeyi bulabileceğiniz iki ortak alan, eklentiler/temalar ve özel çözümlerdir. Tema ve eklenti geliştiricilerinin Aqua, VT, TimThumb veya Smart Image Resize gibi bir manipülasyon sınıfına güvenmeleri yaygındır (bir eklentinin veya temanın OTF işlemeyi kullanıp kullanmadığından emin değilseniz, şu sınıflar için kaynak koduna bakın: Aqua_Resizer, VT, TimThumb, Smart_resize_image vb.).

Ayrıca, çok sayıda müşteri işi yapan tasarım/reklam ajanslarında özel kırpma çözümlerinin yaygın olduğunu gördüm. Geliştiriciler genellikle zaman sıkıntısı çeker ve onları bulabilecekleri kısayollar ararlar – bundan yıllar önce suçlu olduğumu biliyorum.

Belki Bu Sadece Senin Görüşün, Adamım

Şimdiye kadar birçoğunuzun muhtemelen sorduğunu hayal ediyorum…

"Önemli olan ne? OTF işlemeyi kullanarak görüntülerimin amaçlandığı gibi çıktısını alabiliyorum, hantal WordPress görüntü boyutlarını kullanmama gerek yok ve bu çok hızlı. Neden umursayayım? Belki standartlaştırılmış WordPress görselleri sadece sizin fikrinizdir dostum!”

Cevap, başkalarıyla iyi geçinmek kadar basit.

Tüm eklentiler ve temalar aynı kurallara/kalıplara uyuyorsa, uyumluluk sorunları minimumdur. Ancak, bir eklenti saparsa, diğer eklentiler/temalar ve WordPress çekirdeği ile etkileşime girerken bir dizi soruna neden olabilir.

Bunun akla gelen bir örneği, WP Offload S3'ün ortak OTF işleme kitaplıkları (eklentiler veya temalarda bulunur) ile eşleştirilmesidir. WP Offload S3, tüm medya kitaplığınızı (ve tüm geçerli görüntü boyutlarını) S3'e yerleştirmenize ve bir CDN aracılığıyla sunmanıza olanak tanır. Tahmin edilebilir sonuçlar sağlamak için, görüntüleri ve medya kitaplığını işlemek için büyük ölçüde standartlaştırılmış WordPress kurallarına güveniyoruz. Bunun gibi standartlaştırılmış kodları hedefliyoruz, çünkü özel çözümleri barındırmak kaybedilen bir savaştır.

WP Offload S3 ile, OTF'de kırpılan görüntüler, veritabanında görüntü kaydı olmadığından ( post veya postmeta verileri biçiminde) görüntülerin ayrıntılarını belirleme yolumuz olmadığından genellikle yüklenmez. Bir OTF işleme kitaplığı bu bilgiyi veritabanına kaydederse, genellikle postmeta olarak kaydedilir, ancak standart ek meta verileri yerine özel anahtarlardan yararlanır. Bu "meta veri yok" senaryosunun nihai sonucu, eksik resimler veya S3'e yüklenemeyen resimler olabilir ve resimlerin son kullanıcılar için yüklenmemesine neden olabilir.

OTF işlemenin diğer birkaç büyük bilet etkisi…

• Performans – Bir görüntü her kırpıldığında, OTF işleme kitaplığını yükler. 100'lü resimlerin bulunduğu bir sayfada bu, sunucu kaynaklarında bazı ciddi artışlara neden olabilir. Şimdi 1000'lerce kullanıcının aynı anda o sayfayı ziyaret ettiğini hayal edin.

• Gelecek Dostu – WordPress görüntüleri sonraki her sürümde daha iyi hale geliyor. Örneğin, v4.7'de, daha iyi önizlemeler dahil olmak üzere medya kitaplığına PDF geliştirmeleri geliyor; ne kadar serin! Bu tek sürümde eklenen diğer birçok özellikten bahsetmiyorum bile. OTF görüntü işleme kitaplıkları, hemen hemen aynı geliştirici kaynaklarına sahip değildir.

• Güvenlik – Bu kitaplıkların çoğu güvenlik sorunlarıyla boğuşuyor. Dosya dahil etme istismarları, birçok OTF işleme kitaplığı için yaygın bir yerdir ve bundan yararlanmak çocuk oyuncağıdır. Örneğin TimThumb, milyonlarca sitenin sorun yaşamasına neden olan güvenlik açıklarından yıllar içinde birçok kez etkilenmiştir.

• Duyarlı Görüntüler – OTF kitaplıkları, OTF kitaplıklarının farklı bir boyutta çıktı aldığı her örnek için gereken kod uzunluğu nedeniyle, duyarlı görüntülerle çalışırken anında uygulama çekiciliğini hızla kaybeder. WordPress'in temel işlevi (kutudan çıktığı gibi) sağlam, duyarlı görüntü desteği içerir.

Geçmişten ders alalım ve temel işlevlerle birlikte inşa edelim.

Görüntüler Doğru Yapıldı

Neyse ki, tüm eklentilerin birlikte çalışabilmesini sağlamak için WordPress'teki görüntüleri işlemenin daha iyi yolları var. Bugün OTF işleme kitaplıklarından yararlanıyorsanız ve bu noktada kabusları yeniden düzenleme konusunda endişeleniyorsanız, WordPress görüntüleri doğru şekilde işlemeyi kolaylaştırdığından endişelenmeyin.

Resim Boyutları Ekleme

v2.9'dan bu yana WordPress, özel görüntü boyutları için desteğe sahiptir. Zamanla, görüntü boyutları özelliği olgunlaştı ve bir tema bağlamında (hepsini değilse de) özel görüntü boyutu ihtiyaçlarının çoğunu desteklemesi gerekiyor.

add_image_size function ve after_setup_theme eylemini kullanarak, bir işlevsellik eklentisine veya hatta function.php dosyanıza yeni bir görüntü boyutu uygulamak çok kolaydır. Kısa bir örneğe bakalım…

 if ( ! function_exists( 'biglebowski_theme_image_sizes' ) ) { function biglebowski_theme_image_sizes() { add_image_size( 'feed-cropped-thumb', 300, 150, true ); // cropped, 300 x 150 add_image_size( 'feed-header', 600 ); // 600 x unlimited } add_action( 'after_setup_theme', 'biglebowski_theme_image_sizes' ); }

Bu basit işlevle, çakışan kodu kontrol ettik, iki yeni görüntü boyutu kaydettik ve after_setup_theme eylemine bağlandık. Görüntü boyutları WordPress içinde kayıtlı olduğundan, artık ara_görüntü_boyutları gibi filtreleri ve eylemleri kullanabiliriz.

Görüntüler için yerleşik WordPress işlevselliğini kullanmak bu kadar basitken neden kullanmıyorsunuz?

Uyarılar ve Araçlar

Genellikle görüntü boyutlarını kullanırken, yeni bir görüntü boyutu kaydettiğiniz veya mevcut olanı değiştirdiğiniz için görüntüleri yeniden örneklemeniz/yeniden oluşturmanız gereken durumlarla karşılaşırsınız. İşte bu noktada bazı kullanışlı araçlar devreye girebilir.

Küçük Resimleri Yeniden Oluştur , resimlerinizi tüm etkin resim boyutlarıyla yeniden oluşturmanıza olanak tanıyan basit ve hafif bir eklentidir. Bu araç, medya kitaplıkları için kullanışlıdır ancak daha büyük kitaplıklarda tamamlanması biraz zaman alabilir.

WP CLI , şu anda Daniel Bachhuber tarafından sağlanan WordPress için bir komut satırı arabirimidir; takip etmek isteyeceğiniz keskin bir adam. wp media regenerate kullanarak komut satırı aracılığıyla medya yenilemeleri gerçekleştirebilirsiniz ve bunlar tüm geçerli görüntü boyutlarında yeniden oluşturulur. Bu araç, daha büyük medya kitaplıkları için ve komut satırı erişiminizin olduğu ortamlarda kullanışlıdır.

2000'lerin başından beri CSS büyük ölçüde olgunlaştığı ve tarayıcı standartları için yarıştığı için çok sayıda belirli görüntü boyutu oluşturmanıza gerek olmadığını belirtmekte fayda var (Teşekkürler, Bay Zeldman). Genellikle daha büyük resimler kullanabilir ve bunları geleneksel CSS ile DOM'da hafifçe yeniden boyutlandırabilirsiniz. clip-path ve resize gibi CSS3 özellikleri için ileriye dönük destek, tarayıcılar tarafından daha fazla destekleniyor ve hedef kitlenize bağlı olarak ihtiyaçlarınız için uygun olabilir.

Ağırlık kaldırma

Zamanın % add_image_size geliştirici ihtiyaçlarının çoğunu karşılayabileceğini iddia ediyorum. Imagick veya GD gibi güçlü görüntü işleme araçlarına ihtiyaç duyanlar için, medyayı ve medya kitaplığını çevreleyen temel işlevlerden yararlanmayı şiddetle tavsiye ederim. Ancak, PHP resim kitaplıkları diyarına adım atmanız gerekiyorsa , lütfen WP_Image_Editor sınıfını seçin. v3.5'ten bu yana, bu sınıf, GD ve Imagick'teki işlevlerin çoğunu soyutlamıştır ve görüntüleri değiştirirken (filigranlar veya renk filtreleri gibi) sunucu tarafında daha ağır kaldırma için bir araçtır.

42'lik bir ek kimliğine sahip mevcut bir WordPress eki zaten yüklenmiş olarak WP_Image_Editor güvenle (bir görüntüyü yansıtmak/çevirmek için) kullanarak kısa bir parçaya bakalım.

 // Include if needed require_once ABSPATH . "wp-includes/class-wp-image-editor.php"; // Base image/attachment $attachment_id = '42'; $image_path = get_attached_file( $attachment_id ); // Load the editor $modified_image = wp_get_image_editor( $image_path ); // Check for any errors when loading WP_Image_Editor if ( ! is_wp_error( $modified_image ) ) { // Flip the image, crank up the quality $modified_image->flip( false, true ); $modified_image->set_quality( 100 ); // Save image file, update metadata $saved_image = $modified_image->save(); $meta_data = wp_generate_attachment_metadata( $attachment_id, $saved_image['path'] ); wp_update_attachment_metadata( $attachment_id, $meta_data ); }

İmajımızı yükledik ve manipülasyon için onu WP_Image_Editor sınıfımıza aktardık. Ardından görüntü dosyasını kaydettik ve onunla ilişkili meta verileri güncelledik. Meta verileri güncellemek olan bu son adım, görüntü boyutlarını, görüntünün dosya boyutunu vb. değiştiriyorsanız oldukça önemlidir. Bir ekin meta verilerini güncellerken, başkalarının (ve kendinizin) erişmesine ve daha fazla çalışmasına izin veren önemli bilgileri veritabanına kaydedersiniz. eki ile. Bu, görüntülerin uygun şekilde silinmesini içerir. Bir görüntünün ilgili meta verilerine sahip olmak, medya kitaplığından bir görüntü silindiğinde yeniden boyutlandırılmış tüm görüntülerin kaldırılmasını ve geride hiçbir yetim görüntü boyutu kalmamasını sağlamanıza olanak tanır.

Tamamen yeni bir görüntü yüklüyorsanız (WordPress veya API gibi harici bir kaynak aracılığıyla), daha karmaşık görüntü işleme için yine de WP_Image_Editor sınıfını kullanabilirsiniz. Yükleme işleminin çoğunu (dosya kaydetme, meta veri çıkarma, vb.) tek bir işlevde gerçekleştirdiği için, ilk yükleme için media_handle_upload emin olmak isteyeceksiniz.

Daha fazla güce ihtiyaç duyduğunuz nadir durumlarda umut vardır; WP_Image_Editor sınıfını genişletebilirsiniz! Bu, kalbin zayıflığı için değildir ve standardizasyonun raylarından çabucak çıkabilir. Ancak, temel sınıfı sorumlu bir şekilde genişletirseniz ve her zaman medya kitaplığından yararlanırsanız, WP_Image_Editor öğesine daha fazla seçenek ve yöntem ekleyebilmelisiniz. Bunun örnekleri için WP_Image_Editor_Imagick ve WP_Image_Editor_GD sınıflarına bakın. Temel düzenleyici sınıfını, özellikle ilgili iki PHP görüntü kitaplığı için çalışacak şekilde genişletirler ve çok iyi yorumlanırlar.

Geliştirmenin başlarında, görsel ihtiyaçlarınıza (özellikle daha ağır kaldırma gerektirenlere) uyumluluk göz önünde bulundurularak yaklaşırsanız, diğer eklentiler, temalar ve WordPress çekirdeği ile iyi oynamak için doğru yolda olacaksınız.

Buradan Nereden?

WordPress çekirdeği her zaman güncellenir ve bununla birlikte kararlılık, güvenlik ve yeni özellikler gelir. Yalnızca 4.7'deki eklemeler, medya kitaplığını daha da genişletmek için önemlidir ve bu, tek bir sürümdür.

Ayrıca, WordPress'in görüntüleri işleme biçiminde bir eksiklik bulduğunuzu varsayalım. WordPress'in gerçek güzelliği, açık kaynak olmasıdır. Trac bileti göndererek, WordPress Core Slack'te sohbet ederek veya özellik hakkında bir blog yazısı yazarak WordPress topluluğuyla yeni bir özelliği tartışabilirsiniz. Bir hata bulursanız, bunu bildirme ve/veya kendiniz düzeltme yetkisine sahipsiniz.

Sonunda WordPress topluluğunu OTF görüntü işleme kitaplıklarından kurtaralım ve bunun yerine temel işlevlere güvenelim. Hepimiz aynı kurallar kümesine göre çalışıyorsak, diğer geliştiricinin koduyla (bir tema veya eklenti) uyumluluk kolay olmalıdır .