Bağımlılık Yönetimi ve WordPress: Bir Öneri

'Bağımlılık cehennemi' tüm yazılımların karşılaştığı bir sorundur ve son birkaç yıldır WordPress alanında üçüncü taraf kod kitaplıkları kullanan daha fazla eklentiyle çirkin yüzünü büyütüyor.

Amazon S3 eklentimiz WP Offload S3 ile birkaç ayda bir bu sorunla karşılaşıyoruz. Bu, Lezzetli Beyinler için çok gerçek bir sorundur ve konunun iyi bir somut örneği olarak hizmet edebilir.

Sorun

Eklentimiz, WordPress medya kitaplığına yüklediğinizde medyayı Amazon S3'e aktarır ve bunu yapmak için AWS SDK'yı (Amazon Web Hizmetleri eklentisi olarak paketlenmiştir) kullanırız. SDK, sürüm 2 ve 3 arasında bazı önemli değişiklikler geçirdi ve bu, SDK'nın gerekli minimum PHP sürümünü 5.3'ten 5.5'e yükseltmesine neden oldu. Tüm WordPress kurulumlarının %42.7'si PHP 5.2, 5.3 veya 5.4'e sahip sunucularda çalıştığı için, minimum PHP 5.5 şart koşmak eklentimiz için işe yaramaz.

Müşteriler, AWS SDK'ya dayanan ve onu paketleyen başka bir eklentiyle birlikte Offload S3'ü kullandığında, bu eklenti v2 kullanmıyorsa, uyumsuz kitaplık sorunuyla karşılaşırız. WordPress eklentileri etkinleştirildikleri sırayla yükler ve PHP dosyaları gerektiği gibi yükler ve sınıfları çağrıldıkları gibi (otomatik yükleyiciler kullanılırken) yükler, bu nedenle eklentinin önce SDK kodunu çağıran gerçek bir piyangodur. Diğer eklenti acı çeken eklentidir.

Bu konuyla ilgili en sinir bozucu şey, bunun en iyi niyetlere sahip olmaktan kaynaklanmasıdır! Geliştiriciler, verimli olmak ve tekerleği yeniden icat etmekten kaçınmak için üçüncü taraf kodunu kullanır. Kod başkaları tarafından yazılmıştır ve birçok kişi tarafından test edilmiş ve kullanılmıştır.

Neden kütüphaneyi ad alanı veya önek eklenmiş olarak eklentinize dahil etmiyorsunuz? Bu işe yarayacak, hiçbir çatışma olmayacaktı. Ibericode çalışanları, eklentilerine Pimple paketini dahil etmek için bunu yaptılar. Sivilce küçük bir iki dosya paketi olduğu için bu onlar için iyi çalışıyor. Ama bu sadece ölçeklenmiyor. Bunu AWS SDK kadar büyük bir şey için manuel olarak yapmak çok fazla iş olur ve paket her güncellendiğinde tekrar tekrar yapılmasını gerektirir. Üçüncü taraf kitaplıklarını yönetmeyi ve bir kod tabanına entegre etmeyi kolaylaştırdığı için insanlar genel olarak Composer'a yöneliyor. Ama ne yazık ki Besteci genellikle bu sorunun suçlusu olarak görülüyor.

Bu Besteci Sorunu DEĞİLDİR!

WordPress topluluğu, Composer'a (PHP dünyasının geri kalanının aksine) katılmaya çalışırken, yanlış fırçayla katranlanmadan zaten yeterince zorlanıyor!

Sorun zaten orada, Besteci olmadan, onu belirgin bir şekilde fark etmiyorsunuz. Herhangi bir üçüncü taraf kitaplığı, Composer kullansanız da kullanmasanız da herkese açık eklentilerinizle paketlemek WordPress ile ilgili sorunlara neden olacaktır.

Alain Schlesser – Post Status Slack.

Peter Suhm, tam da bu sorun nedeniyle, WordPress ile Composer kullanmanın tehlikeleri hakkında yazdı, ancak neyse ki Coen Jacobs, hatasını belirtmek için Composer'ın savunmasına atladı. Bu, Peter ve Coen arasında, ironik bir şekilde Composer kullanarak Coen'den potansiyel bir çözüm geliştirmeye yardımcı olan bazı tartışmalara yol açtı. Birden çok composer.json dosyasını çalışma zamanında birleştirmek için Wikimedia için oluşturulmuş Composer Merge Plugin'den yararlanır.

Composer fiili PHP paketi ve bağımlılık yöneticisi olduğu için bu çok mantıklı, ancak bağımlılıklarını yönetmek için kendi composer.json dosyalarını kullanan birden fazla eklentiye sahip olabilecek tüm WordPress sitesinde çalışması için biraz eğilmeye ihtiyacı var. Bu sadece Coen'den bir konsept kanıtı ama buradaki yönü seviyorum ve daha sonra Composer ile sorunu çözmeye geri döneceğim.

İdeal Yaklaşım

Ryan McCue, WordPress'teki eklenti bağımlılıkları sorununu nasıl çözeceği hakkında, teknik uygulamalara çok fazla odaklanmayan, daha çok bir son kullanıcı deneyiminden neyin gerekli olduğuna dair harika bir makale yazdı. Özetlemek gerekirse, çözümün şunları yapması gerekir:

• Bir eklenti yüklenmeden önce bağımlılıklarla olası çakışmaları yakalayın
• Kurulum, bir eklentinin bağımlılıklarını yüklemeyi otomatik olarak yapmalıdır.
• Eklentiye yapılan güncellemeler bağımlılığa duyarlı olmalı ve güncellemeler çakışma yaratacaksa durup uyarmalıdır.

Bir proje olarak WordPress, geliştiriciye değil, kullanıcıya çok odaklanır. 'Seçenekler değil kararlar', son yıllarda projenin birçok özelliğine öncülük eden bir mantradır, otomatik arka plan güncellemeleri önemlidir. Bağımlılık yönetiminin aynı şekilde ele alınması gerekir, burada kullanıcının çok fazla düşünmesi gerekmez ve sadece onlar için çalışır.

Bu tür bir çözüm, çok fazla alanı kapsayan ve bazı büyük zorluklarla karşı karşıya olan büyük bir sorundur. Kritik olarak, Ryan çözümün nereye oturması gerektiğine değiniyor – WordPress çekirdeği:

Buradaki nihai hedef, temel entegrasyondur. Çözüm sonunda çekirdekte bitmezse, her yerde olmadığı için proje başarısız olur. Bu olursa, ihtiyacınız olanı atın ve tekrar deneyin, ancak birçok kullanıcı için geçerli bir çözüm olması için özünde olması gerekir.

Bir teklif

Ben en iyi WordPress geliştiricisi değilim. Besteci kullanabilirim ama uzman değilim. Ben kesinlikle bir PHP uzmanı değilim ve yazarken bu soruna ayak uydurmak üzereyim, ama… Sorunun çözülebileceğini düşünüyorum ve işte bir çözüm ve olası temel özellik eklentisi için üst düzey teklifim .

Daha önce de belirttiğim gibi, Coen'in Besteci tabanlı çözümüyle kesinlikle doğru yolda olduğunu hissediyorum ve bunların bir kısmı doğrudan onun projesinden ilham alıyor, ancak bence bunu daha ileri götürmemiz gerekiyor.

1. Besteci aracılığıyla Üçüncü Taraf Kodu

Üçüncü taraf kodunu kullanan herhangi bir eklenti veya temanın bağımlılıklarını bir composer.json dosyası kullanarak tanımlaması gerekir ve satıcı dizinini dağıtmamalıdır.

2. Özde Besteci

WordPress, son kullanıcıların manuel olarak yükleme ihtiyacını ortadan kaldıran Composer ile birlikte gelmek zorunda kalacaktı. Bu, İstekler veya Basit Pasta gibi WordPress'in gerektirdiği diğer herhangi bir kitaplık gibi olacaktır.

3. Özel Besteci Davranışı

Ardından, WordPress ile entegre olmak için Composer'ın temel davranışını yoğun bir şekilde özelleştirmemiz gerekecek. Spesifik olarak, bu, eklentinin composer.json dosyasını okumak, onu diğerleriyle birleştirmek ve bağımlılıkları kurmak için eklenti/tema yükleme işlemiyle bütünleşir.

Çakışmaları yakalaması ve kullanıcıyı sorunlar hakkında bilgilendirmek için (yönetici kullanıcı arayüzü veya CLI aracılığıyla) yanıt vermesi gerekir. Bir eklenti güncellenirken de bununla ilgilenmesi gerekir.

Drupal, 2013'ten beri benzer Besteci Yöneticisine sahip:

Composer Manager, katkıda bulunan her modülün, modüle özgü gereksinimleri listeleyen kendi besteci.json dosyasıyla birlikte gönderilmesine izin verir. Daha sonra bulunan tüm modüllerin gereksinimlerini birleştirilmiş besteci.json dosyasında birleştirir. Bu, tüm modüller arasında paylaşılan tek bir satıcı/dizin ile sonuçlanır, bu da kod tekrarını ve sürüm uyumsuzluklarını önler.

4. Paket Korumalı Alan

Teklifimin son kısmı biraz daha mavi gökyüzü düşüncesi, ancak Coen'in yakın tarihli bazı çalışmaları bana umut verdi. WordPress ve kullanıcılar için ideal senaryo, çatışmalarla hiç uğraşmak zorunda kalmamaktır. Her eklenti, başkalarına müdahale etme tehdidi olmadan bağımlılıklarını güvenli bir şekilde çalıştırabilmelidir. Aynı sınıfın birden çok sürümünü yüklemek PHP'de mümkün değildir, ancak ad alanlarını veya sınıfları önek olarak yalıtmak için kullanmak işe yarayabilecek bir şeydir ve daha önce Composer perspektifinden tartışılmıştı.

Mozart, PSR-0 ve PSR-4 uyumlu paketlere özel bir ad alanıyla otomatik olarak önek ekleyen Coen'den yeni bir komut dosyasıdır, böylece bir eklenti tarafından güvenle kullanılabilirler. Bu tür bir işlevselliği WordPress'in Composer bölümüne eklemek, eklentiler tarafından kullanılan tüm bağımlılıkların korumalı alana alınacağı ve hiçbir çakışma olmayacağı anlamına gelir. Elbette, sınıf haritası otomatik yükleyicileri olan veya ad alanları olmayanlar gibi diğer paket türlerini desteklemek için Mozart'a daha fazla çalışma yapılması gerekecek ve bu yaklaşım, tür ipucu ve bağımlılık enjeksiyonunu kullanan daha karmaşık paketlerle mücadele edecek, ancak potansiyel var.

Hususlar

Bu teklifle ilgili bazı bariz sorunlar var, bir tanesi Composer'ın minimum PHP 5.3 gereksinimine sahip olmasıdır. Bu teklif o zamana kadar bu yazıdaki sözlerimin ötesine geçerse, WordPress'te PHP 5.2 desteğinin geçmişte kalacağı konusunda iyimserim. Ve eğer değilse ve bu proje çekiş kazanırsa, umarım minimum sürüme çarpma argümanına ek ağırlık olarak hizmet eder.

Bir sonraki en büyük sorun evlat edinmedir. Bu, şimdiye kadar Vahşi Batı kodlama uygulamalarının etkin bir şekilde ne olduğu konusunda, insanların eklentileri yazma biçiminde sismik bir değişim olacak. Dahil edilen herhangi bir üçüncü taraf kodunun Composer aracılığıyla yapılması gerekecektir. WordPress.org eklenti inceleme ekibinin gemide olması gerekecek ve mevcut eklentilerin bazı otomatik incelemeleri bir seçenek olacaktır. Ayrıca, WP-CLI artık bir WordPress.org projesi olduğundan, bir composer.json dosyası eklemek için bir eklentiyi iskeleye daha tanımlanmış bir standart eklemek mantıklı olacaktır.

Paketler korumalı alana alınmadıysa ve çakışmalar hala bir sorunsa, Composer'ı bu şekilde kullanmak sürüm oluşturma konusunda bir soruna neden olur. Pek çok paket gereksiz yere katı SemVer gereksinimlerine sahiptir. Sadece bir değişiklik yapabilir veya bir PR gönderebilirseniz, bu önemli değil. Gereksinimleri çok katı olduğu için bir eklenti yükleyemeyen son kullanıcılar için oldukça sorunlu olacaktır. WordPress'in burada karar verme konusunda akıllı olması ve son kullanıcı deneyiminin zarar görmemesi için kısıtlamaları makul sınırlar içinde geçersiz kılması gerekir.

Performans başka bir endişe kaynağıdır. WordPress'in tipik olarak çalıştığı sunucular, genellikle çok fazla bellek tüketmeyen web isteklerini sunmak için optimize edilmiştir. Besteci bağımlılık çözümlemesi, zaman zaman çözülmesi gereken 100.000'den fazla kural düğümünden oluşan bir ağaç oluşturan, bellek açısından yoğun bir süreçtir. Bu, güvenilir bir şekilde çalışması için kolayca 256 MB ve hatta 512 MB bellek gerektirebilir. Neyse ki bu geliştiriliyor, ancak birden fazla bağımlılık gerektiren eklentilere sahip bir WordPress kurulumu, şüphesiz kurulum süresini artıracak ve bir zip dosyasını indirip çıkarmaktan daha fazla sunucu kaynağı tüketecektir.

Son olarak, benim için bir sorun uygulamadır. Ne yapılması gerektiğini görebiliyorum ama tam olarak nasıl yapılacağını göremiyorum. Bu tür bir proje üzerinde çalışmak için birden fazla kişiye ihtiyaç var ve bunu bir özellik projesine dönüştürmek için nereden başlayacağımı bilmiyorum.

Alain Schlesser'a bu öneriye yardım ettiği, düşüncelerimi gözden geçirdiği ve (sürekli) sorularımı yanıtladığı için teşekkür ederim.

İleriye gidiyor

Teklifin çok daha fazla planlamaya ve düşünmeye ihtiyacı var ama bunun mümkün olduğuna inanıyorum. Peki yanımda kim var? Alain'in hevesli olduğunu biliyorum, ancak şu anda oldukça meşgul!

Teklifle ilgili herhangi bir öneriniz veya yorumunuz varsa veya bu yardım etmek isteyeceğiniz bir şeyse, yorumlarda bana bildirin.