Gelecek WordPress modüler kodu mu?

Bu yıl WordCamp Miami’de John James Jacoby veya JJJ ile tanışmaktan mutluluk duyuyorum. Birçoğunuz onu Buddypress’in arkasındaki bir kişi olarak tanıyabilirsiniz, ancak onu bir zamanlar ele aldığı diğer eski projeler için tanıyorum. Backpress hakkında ne kadar çok şey öğrenirsem o kadar çok ilgileniyorum. İşte o zaman JJJ ve ben BackPress projesinin dirilişi hakkında konuşmaya başladık. WordPress Temel Kütüphanesi olarak hayatına başlayan backpress hikayesi. Bu, WordPress ekosistemi olmadan, WordPress kodunda herkesin bildiği ve sevdiği tüm PHP işlevlerine erişim sağlayan WP-Accompude dizinidir.
Hızlı değil, beş dakika takıldı. Kullanımı kolay olan CMS gösterge paneli yoktur. Yalnızca kod kütüphanesi. Ne yazık ki, proje öldü – ve kimse onu korumadan ve WordPress’e dönen birkaç kod parçası olmadan proje unutuldu. 2013’ün başlarında nasıl ilgilendiğim ve katıldığım, AngularJS öğrenmeye başladım ve hemen WordPress’e bağlamak istedim. Kendi ham ateşimi kullandığım ilk temayı almayı ve çalıştırmayı başardım. O yıl, Ryan McCue WP-API projesini tanıttı … ve ben büyülenmiştim. Yaklaşık bir yıl sonra, WordPress’in çözüm olmadan tamamen bir çözüm olmadan yapılabileceğini fark etmeye başladım: Tek yapmam gereken WordPress’te bildiğim ve beğendiğim her şeyi almak ve müşterinin yan uygulamasını oluşturmak ve sonra WordPress Gösterge Tablosu silinmek. Neden? Niye? Çünkü artık buna ihtiyacım olmayacak. Kullanıcılar, yönetici vb. İçin kendi gösterge panelimi yapabilirim. Uygulamamın içeriğine uymak varsayılan gösterge tablosundan daha iyidir.
Gösterge paneli sadece başlangıç. Oradan, sunucu tarafından yayınlanan ve işlenen diğer tüm şeyleri ve bunların kaçının gereksiz olduğunu düşünmeye başladım. Ayrı ve modüler ayrıştırma, bir şeyi diğerinden serbest bırakmak veya ortadan kaldırmak anlamına gelir. Modüler çerçeve LEGO ile kodlamaya benzer. Kolay ve verimli bir şekilde işlevsellik parçalarını silebilir ve ekleyebilirsiniz. Bu, WordPress eklentisinin bugün nasıl bulunduğuna benzer – işlevselliği genişletmek için ekleyebilir veya silebilirsiniz. Bir düzeyde, JSON REST API benzer bir işlev sağlar. Bu, WordPress’i ayrı hale getirir, böylece uygulamaları hala ilginç olan ve içeriği veya verileri depolayan WordPress.codecalvary.com benzer bir iş akışını kullanarak çalışır. İstemci tarafını çalıştıran ve yalnızca verileri elde etmek ve depolamak için JSON REST API’sını kullanan AngularJS uygulamasını kullanır. Uygulamanız WordPress’ten tamamen ayrılmışsa, bu iyi çalışır. Peki ya geleneksel bir PHP web uygulaması yürütüyorsanız ve WordPress işlevselliğinin diğer bölümlerini kullanmak istiyorsanız, ancak hepsini değil? İhtiyacınız olmayan WordPress işlevini (ve çalıştırmayı) yine de gerçekleştireceksiniz. Ancak WordPress modülerse, web sitesinin daha sorunsuz ve daha hızlı çalışabilmesi için bileşenleri kolayca silebilirsiniz.
WordPress modülerliğinin bileşenlerini değiştirmek sadece bileşenleri kaldırabileceğiniz anlamına gelmez. Bu aynı zamanda her şeyi birlikte değiştirebileceğiniz anlamına gelir. UI yönlendirici Angularjs mide ve şablon yönetimini oldukça iyi işler. WordPress’in bu işleve müdahale etmesini istemiyorum, bu yüzden WordPress’in hangi PHP şablonlarının yayınlanacağını asla düşünmemesi için bu yönü devre dışı bırakmak istiyorum. Modüler bir kodla bileşenleri silebilir ve daha da önemlisi değiştirebilirsiniz. Aynı örneği kullanarak, dosyaları yüklemek için Laravel veya Symfony’yi kullanmayı tercih ederseniz, bunu kolayca kullanabilirsiniz. Mevcut bağımlılık yönetimi bağımlılıklarla başa çıkmanın kolay bir yolu yoktur. Bir eklenti bir işlev tanımlarsa, sunucuyu önce yüklemeye zorlayamazsınız, bu nedenle diğer eklentiler için belirlenir. Bağımlılık yönetiminizle. Bu, bazı WordPress kancalarının sıfırdan ayarlayabileceğiniz, ancak çok daha verimli bir şekilde işlenebileceğiniz bir öncelik seviyesine benzer. Bağımlılık yönetimi ayrıca daha önce bahsettiğim bileşenleri nasıl yönettiğinizi de içerecektir. Bir dosya ile mümkün olan her bileşeni yükleyebilir veya uygulamanız için kullanmak istediğinizi seçebilirsiniz.
Kod daha iyi, daha iyi test, daha kolay korunma özel olarak tartışmayacağım, ancak WordPress’in nesne yönelimli programlama (OOP) ile oluşturulmadığını belirtmek önemlidir. OOP, PHP’deki gelişmeyi daha kolay ve daha güvenli hale getirir. Carl Alexander OOP hakkında yazmaya devam ediyor ve onu kullanmadaki değeri açıklıyor. Kısacası, OOP kodunun hareket etmesi daha kolay, bileşenler oluşturulması daha kolay, test edilmesi daha kolay ve bakımı daha kolaydır. Öyleyse testle başlayalım. WordPress ekosistemindeki geliştiricilerin çoğu PHP testi ile fazla ilgilenmeyebilir, ancak bu gelişimin önemli bir parçası olmaya devam etmektedir. PHP testi, kodunuzu daha iyi anlamanıza yardımcı olabilir, giren herkes tarafından anlamayı kolaylaştırabilir ve en önemlisi, yanlış bir şey olduğunda size yardımcı olabilir. Gerçek işlevden önce testler yazmayı seviyorum. Bu şekilde kullanıma hazır bir başarısızlığa sahipsiniz ve sadece Gagal olmayan vakalar oluşturuyorsunuz. Şu anda, WordPress’te yapılabilecek birkaç test vardır, ancak olması gerektiği kadar ayrılmadıkları için kolay değildir. Ayrılmış bileşenlerle, testler tek tek bileşenler üzerinde kolayca yapılabilir, bu da bir uzantı kodu oluşturmayı ve bunun için bir revizyon yapmayı kolaylaştırır. Her bir bileşeni test etmek de belirli bileşenleri pakete entegre etmeyi kolaylaştırır, çünkü kodun veya bileşenin bir bölümünde başarısız olan bir test olmadığından emin olabilirsiniz.
Bu beni son noktama götürdü, bu da modüler bir çerçeve ile hayatı kolaylaştırdı: bakım. WordPress bileşenlerden oluşturulursa, bir tek bir bileşene katkıda bulunabilirsiniz ve yalnızca bileşen kodu için test edilebilir. Bu, tüm projeyi korunması, güncellenmesi ve hatta geliştirilmesi çok daha kolay bir yerde yapar, çünkü bunu bileşen başına birer birer yapabilirsiniz. Neden yeni bir şey öğrenmiyorsunuz veya daha iyi bir çerçeve kullanmıyorsunuz? Neden bir güçlük bile? Neden yeni bir şey öğrenmiyorsunuz? Neden zaten istediğinize sahip bir çerçeve kullanmıyorsunuz? Bu, WordPress’in neler yapabileceği hakkında konuştuğumda sorduğum sorum. Kendimi WordPress kabarcıklarına kilitlenmiş olarak görmüyorum. Sürekli kodlar yapıyorum ve yeni teknoloji öğreniyorum. Bu yüzden Angularjs, ReactJs ve Node.js.’yi öğrendim. Ancak, sonunda, WordPress’in harika bir ekosistemi var ve şimdi onsuz bir geliştirici olmayacağım. “Diğer çerçevelerin zaten daha iyi bir temeli var”, WordPress için daha iyi bir şey istememek için geçerli bir neden değildir. Neden keklerimizi alıp yemiyorsunuz? Neden başkalarına yeni bir şeyler öğrenmelerini söyler, daha iyisi için kullandıklarını ne zaman yapabiliriz?
Çerçevenin dirilişi ve vizyonu, bizi kötü bir çerçeveye geri getiren ve önceki yıllardan unutulan ve unutulmayan. WordCamp Miami’de John James Jacoby ve ben projeyi tartışmak için bir halka açık oturum düzenlemeye karar verdik. Google Hangout kötü yönetildiği sürece, projenin dirilişi hakkında birkaç çeşitli inceleme var. Birçoğu bunun ölü bir proje olduğuna inanıyor ve ölü kalmalı. Urgh, sadece ölmesine izin ver @jjj https://t.co/kt3mai0rpw – Ryan McCue (@rmccue) 16 Haziran 2015, böyle zorluklarla karşılaşmaya hazırlanırken duymak istediğiniz bir şey değil. Bununla birlikte, WordPress topluluğunda saygın geliştiricilerden de çok fazla destek var. @Royboy789 ve @jjj’in canlandırıldığını duyduğuma çok sevindim #backpress. Bu #WordPress geliştiricisinin rüyası! – Nick Adams (@NICKADAMSTV) 16 Haziran 2015 Sanırım yeni bir şey için zamanı geldi: WordPress istediğimiz gibi, ama bizi tekrar aşık edebilecek bir çerçeveyle. Bu, bugün WordPress ile ne inşa edemeyeceğinizle ilgili değil, bu yarın WordPress ile ne inşa edebileceğinizle ilgili. WordPress’in bu projeye ihtiyacı var ve WordPress Core koduna katkıda bulunmak zaman alsa da, bu ana yollardan biridir, böylece yüksek seviyeli geliştiricilerin WordPress’i temel sitenin dışında kullanmakla ilgilenmeye devam etmeleri. Konuşmada iki hafta ve tek bir kod satırı yazmamış olsak da, projenin ne olduğu ve ne olabileceğinin vizyonu ile bir araya geldik: temiz bir modüler kod ile bileşenler

Dahili bağımlılık yönetimi
Test etmek daha kolay
Konteynere getirilen en son işlevselliği iyileştirmek veya güncellemek daha kolay bakım
Yaklaşık% 100 uyumluluk mevcut WordPress ile geri çekilir
Bu projeye katılan geliştiriciler, kodumuzu yeniden entegre etmek için çekirdeğin almanın zor bir şey olduğunu biliyorlar; Ancak tüm hedeflerimizi yerine getirirsek (özellikle%100 geri çekilme uyumluluğu) o zaman bu projenin ciddi sayılmaması için gerçek bir neden yoktur. Kodla ilgili yardım etmek veya sadece konuşmanın bir parçası olmak istiyorsanız, Google Hangout’a haftalık olarak Salı günü saat 14: 00’de katılabilirsiniz. Hangout sırasında kullanılan Gitter sohbetimize bir bağlantı içeren Repo Github’da projeyi de izleyebilirsiniz. Veya bizi gelişmiş WordPress’in sponsorluğunda #BackPress Slack kanalında takip edebilirsiniz – katılın ve davet isteyin. BackPress herkes için değil, şimdi OOP veya bileşenle bir kod yapamayabilirsiniz, ancak şimdi kullandığınız kodun daha iyi çalışmasını umursamıyor musunuz?