Modern WordPress Geliştirmeye Nasıl Yaklaşılır (1. Bölüm)

Yayınlanan: 2022-03-11

WordPress kod tabanının bir karmaşa olduğu bir sır değil. Şahsen, ne zaman geçsem, tek istediğim kıvrılıp ağlamak. Öte yandan, WordPress rekabetinin çok önündedir. Kullanımı kolay ve güçlü bir CMS muazzam bir girişimdir ve WordPress bunu sağladığı için popülerliğini korumaktadır.

Öyleyse neden WordPress çekirdeğindeki kodun kalitesini önemseyelim? Çalışıyor, değil mi?

Evet, çalışıyor ve 15 yıllık kod tabanının gönüllü bakıcıları tarafından tamamen yeniden düzenlenmesi pek olası değil. Ne yazık ki, bu aynı zamanda çok sayıda geliştiriciyi en iyi uygulamaları ve modern geliştirme tekniklerini takip etmedikleri için mazur gösteren bir "WordPress yolu" kodlama örneği olarak işlev gördüğü anlamına gelir. Pek çok WordPress eklentisi ve temasının kötü bir kodu var ve eski uygulamaları körü körüne takip etmek yalnızca trendi sürdürüyor.

Ama hala işini yapan kötü kod kimin umurunda? Pekala, hiçbir şey bedava değildir ve birileri kötü yapılan bir iş için para öder. WordPress kod tabanının kendisi ile, bakımcıları minnetle zamanlarıyla öderler. Ancak kendi kodunuzla ödeme yapan müşterinizdir.

Orta derecede karmaşık herhangi bir sistem için, ilk geliştirmenin maliyeti, onu sürdürmenin maliyetiyle karşılaştırıldığında önemsizdir ve bakım aynı zamanda yeni işlevler eklemek anlamına gelir. Kötü tasarlanmış ve uygulanmış bir yazılımı düzeltmek için bir geliştirici kiralamak, başlangıçtan itibaren düzgün bir şekilde geliştirmekten birkaç kat daha pahalıya mal olacak.

Ucuz çözümler, uzun vadede her zaman en pahalı olanlardır. Ya da bütçeleri bitince terk edilirler. Kanıtlanmış yazılım tasarım ilkelerini ve uygulamalarını takip ettiğimizde, aslında müşterilerin parasını kurtarıyoruz. Bu yöntemler abartılmış bir heves ya da değişiklik olsun diye değiştirilmemiştir. Buradaki bilgelik, toplu geliştirici deneyiminden doğar ve onu takip etmek gerçekten işe yarar.

Açıkçası, bu, birkaç satır CSS veya birkaç özel gönderi ve yeniden yazma eklemek gibi gerçekten basit görevler için geçerli değildir. Ancak birkaç eklentiyi (veya daha yaygın olarak birkaç düzine eklentiyi) bir araya getirmek veya Visual Composer tarafından desteklenen bir siteyi çalkalamak zaten yazılım mühendisliği değildir.

Bu kendi başına kötü bir şey değil - bazı çözümlerin bu kadar basit olması, WordPress'in bu kadar popüler olmasının nedenidir. Ancak bu seride gerçek WordPress geliştirmesinden bahsedeceğim: önemli PHP, HTML, CSS ve JavaScript kodu yazmak. Bu makalede genel iş akışıyla başlayacağım ve ardından WordPress ön uç geliştirmeye odaklanacağım.

Modern WordPress Geliştirme İş Akışı

Genel olarak kalite kodu:

  • Okunabilir. Kodun ne yaptığını ve nedenini anlamak kolaydır.
  • Modüler. Net bir amacı olan küçük kod bloklarını anlamak, geliştirmek ve test etmek kolaydır.
  • Yeniden kullanılabilir. Benzer sorunları çözmek için zaten geliştirilmiş modülleri yeniden kullanmak, geliştirmeyi önemli ölçüde hızlandırır.
  • Bakım yapılabilir. Eski işlevselliği değiştirmek veya yeni özellikleri tanıtmak kolaydır.

Ana sonuçların - daha düşük geliştirme ve sahip olma maliyeti - burada değinmeyeceğim birçok yan ürün avantajı var.

Bunun yerine, hangi geliştirme tekniklerinin ve en iyi uygulamaların kaliteli kod üretmenize yardımcı olabileceğine odaklanacağım. Sürüm kontrolü ile başlayalım.

Sürüm Kontrolünü Kullan

Bu Git'i kullanmak anlamına gelir. Ne yazık ki, FTP üzerinden üretimde “kovboy kodlaması” hemen hemen hala bir şey. Kısa bir süre önce İngiltere merkezli bir ajans için çalıştım ve kod tabanlarının her tarafında buna benzer adlara sahip dosyalar vardı:

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

Bir WordPress sitesine girerken yapmanız gereken ilk şey, onu sürüm kontrolü altına almaktır. Tanking Sunucuları, WordPress geliştirme hatalarının eğlenceli bir retrospektifidir. Git'i kullanarak bunları ve muhtemelen herkesin başına gelen benzer aksilikleri düzeltmek çok kolay olurdu.

Kodunuzda bir hata yaptınız ve tüm site mi çöktü? git reset her şeyi eski haline döndürür. Yeni sürüm güncellemesi her şeyi mi bozdu? git reset bir zaman makinesi gibi çalışır. Bazı kötü niyetli kodlar birdenbire mi ortaya çıktı? git status , yeni dosyaları, silinen dosyaları veya izlenen dosyalarda yapılan değişiklikleri gösterir. Ardından, orijinalleri geri yükleyerek git checkout .

.git Klasörünün Açığa Çıkmasına Dikkat Edin

Tamam, Git'i kullanmak açıkça önemlidir. Ancak bunu yaptığınızda Git deponuzun saldırıya uğramasını önlemek de aynı derecede önemlidir. Sorun, .git klasörleriniz açıkta olduğunda ve kimlik bilgilerinizi bu klasörlerde sakladığınızda ortaya çıkar.

Standart bir WordPress kurulumu tamamen genel bir web klasöründe bulunur ve .git klasörünün de orada olması çok muhtemeldir. Açıkçası, Git deposunda oturum açma kimlik bilgileri saklanmamalıdır, ancak çoğu depo, dışarıya sızdırılmaması gereken bazı hassas bilgiler içerir.

Bu nedenle .git klasörüne genel erişim engellenmelidir. Apache kullanıyorsanız, aşağıdaki parçacığı .htaccess dosyasının üstüne eklemek, .git klasörüne ve günlük dosyalarına erişimi de engeller. Günlük dosyaları genellikle hassas bilgiler içerir, bu nedenle onları da kullanılamaz hale getirmek akıllıca olur. Farklı web sunucusu kurulumları için lütfen DevOps uzmanınızdan yardım isteyin.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Ayrı Ortamlar Kullanın

Canlı sitelerde geliştirme yapmayın; bu, kesinti ve mutsuz müşteriler için bir reçetedir. Tamam, ama nasıl kurmalısın?

İdeal olarak, kodun her zaman bir yöne gittiği üç geliştirme ortamı olmalıdır: yerel → evreleme → üretim. Bu, çarpışmaları önlemek için kanıtlanmış bir yöntemdir. Tüm çekirdek, eklenti ve tema güncellemeleri önce yerel olarak yapılır, ardından hazırlık aşamasında test edilir ve son olarak üretime dağıtılır.

Örneğin, sunucuya özel yapılandırma ayrı bir dosyada saklanabilir. Her yerel ve hazırlama ortamı için bir wp-config-local.php oluşturabilirsiniz. ( .gitignore dosyanıza eklemeyi unutmayın!) Ardından aşağıdaki parçacığı wp-config.php dosyasına ekleyin:

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Genellikle farklı ortamlar kurmanın en iyi yolu ortam değişkenlerini kullanmaktır. Bu konsepte aşina değilseniz, Roots gibi eksiksiz bir modern çözüm kullanmanızı tavsiye ederim.

WP-CLI'yi kullanın

WordPress komut satırı arayüzü (WP-CLI), WordPress kurulumlarını yönetmek için son derece kullanışlı bir araçtır. WP-CLI'ye erişime sahip olmak, neredeyse tüm WordPress API işlevlerini çalıştırma yeteneğine sahip olmak anlamına gelir. Örneğin, WP-CLI ile kullanıcıları ve şifrelerini ekleyebilir, kaldırabilir ve düzenleyebilirsiniz. Bir siteyi yeni devraldıysanız ve site sahibi kendisini kilitlediyse kullanışlıdır.

Başka bir örnek, ilk kurulumun WP-CLI ile çok kolay olmasıdır. Bunlar birkaç komutla gerçekleştirilebilir:

  • Çekirdek, tema ve eklentileri indirme
  • Veritabanında arama ve değiştirme
  • Yönetici kullanıcı ekleme

Ayrıca, bu eylemler komut dosyası haline getirilebilir ve otomatikleştirilebilir.

Gelişmiş Dağıtım Seçeneklerini Kullanın

Otomasyondan bahsetmişken, aşağıdakiler gibi bazı dağıtım teknolojilerini ve süreçlerini öğrenmeye değer:

  • Sürekli entegrasyon/sürekli dağıtım/teslimat (CI/CD)
  • Liman işçisi
  • Otomatik testler (ön uç regresyon testleri dahil)

Versiyon kontrolünü kullanmamaktan Docker ile ilgilenmeye geçmek büyük bir adımdır ve tipik bir tek kişilik WordPress projesi için muhtemelen bunaltıcı olacaktır. Barındırma sağlayıcınıza bağlı olarak bazı seçenekler mümkün olmayabilir. Ancak gelişmiş dağıtım, ekipler ve daha büyük projeler için olmazsa olmazdır.

Linting kullanın

Her büyüklükteki proje için olsa da, linting çoğu geliştirici için bir nimettir. Linting, kodunuzu hatalara karşı otomatik olarak kontrol etmek anlamına gelir. PHPStorm gibi tam özellikli bir IDE, bunu kutudan çıkar çıkmaz yapar; ancak, VSCode veya Sublime Text gibi daha basit editörler, linter adı verilen özel bir programa ihtiyaç duyar. Bunu ayarlamanın bir yolu, editörünüzü bir dosyayı her kaydettiğinizde bir linter çalıştıracak şekilde yapılandırmaktır.

PHP_CodeSniffer, PHP için fiili linterdir. Sözdizimi hatalarını kontrol etmenin yanı sıra, kodunuzun PSR-2 gibi stil yönergelerine uyup uymadığını da kontrol edebilir. Bu, aşağıdaki kodlama standartlarını büyük ölçüde basitleştirir.

JavaScript için ESLint popüler bir linterdir. Kapsamlı bir kural kümesine sahiptir ve oradaki tüm JavaScript türleri ve çerçeveleri için özel yapılandırmaları destekler.

Buradaki güçlü bir kullanım örneği, tüm kodun dağıtılmadan önce otomatik olarak doğrulanması için bir CI/CD oluşturma işlem hattına linting eklemektir.

Modern WordPress Ön Uç Geliştirme Teknikleri

Artık genel WordPress projeniz için uygun bir iş akışı ayarlandığında, ön uç için en iyi uygulamalara geçelim.

Modern Takımları Kullanın: Sass ve ES6+

Ön uç geliştirme dünyası sürekli değişiyor ve her zaman hareket halinde. Bir zamanlar Sass'ın CSS yazmak için en iyi araç olduğunu düşündük - ve Gutenberg öncesi WordPress geliştirmesi için hala öyle - ama sonra herkes CSS-in-JS ve stil bileşenleri hakkında konuşmaya başladı.

WordPress bile direnemedi ve bu yeni teknolojilerden birkaçını aldı. Yeni blok düzenleyici Gutenberg, React ve bir REST API üzerine inşa edilmiştir.

Bu temel ön uç teknolojileriyle kesinlikle hız kazanmalısınız:

  • ES6+. WordPress belgeleri buna ESNext diyor ve hatta onu kullanmayı teşvik ediyor.
  • Sas. Henüz JS'de CSS olayına girmediyseniz, WooCommerce tarafından kullanılır ve CSS yazmanın en iyi yolu.
  • Web paketi. WordPress çekirdeği bile artık Webpack ve Babel kullanıyor.

ES6 ve Sass, sırasıyla modern JavaScript ve CSS'dir ve Webpack, tüm bu modern özellikleri geriye dönük uyumluluk konusunda endişelenmeden kullanmanıza izin veren bir araçtır. Web paketi, bir tarayıcıda kullanılmak üzere dosyalar oluşturan bir ön uç uygulama derleyicisi olarak adlandırılabilir.

jQuery'den Vue.js'ye veya React'e geçiş

WordPress çekirdeği ve neredeyse tüm WordPress eklentileri jQuery'ye bağlıdır, bu nedenle onu kullanmayı bırakamazsınız. Aslında, birkaç <div> s gizlemek veya bir kerelik AJAX isteği yapmak gibi basit görevler için bu şekilde yapmaya alıştığınızda kullanmayı bırakmanın bir anlamı yok. jQuery yine de yüklenecek ve kullanımı basit ve kolay.

Karmaşık uygulamalar, jQuery'nin mücadele ettiği yerlerdir: Takip etmesi zor mantık, geri arama cehennemi, global değişkenler ve HTML şablonu yok. Bu açıkça, ön uç uygulamasını düzenlemenin farklı bir yolunu gerektirir.

React gibi modern ön uç kitaplıkları, nesne yönelimli programlama (OOP) ilkelerini kullanır ve ön uç uygulama mimarisini modüler, yeniden kullanılabilir bileşenler halinde düzenler. Bir bileşen, belirli bir öğe için tüm kodu, işaretlemeyi ve "bileşen durumunu" (değişkenleri) içerir. Bir öğe hemen hemen her şey olabilir: Bir düğme, giriş alanı, kullanıcı formu veya WordPress REST API arka ucundaki son gönderileri görüntüleyen bir pencere öğesi. Bileşenler, hiyerarşik bir ilişki oluşturan diğer bileşenleri içerebilir.

Günümüzde web sayfalarının karmaşıklığıyla birlikte, bir uygulamayı bileşenlere ayırmak, her karmaşıklıkta bakımı yapılabilir, hızlı web uygulamaları oluşturmanın kanıtlanmış bir yoludur. Bileşenler yüksek oranda yeniden kullanılabilir, yalıtılmış ve bu nedenle kolayca test edilebilir "tuğlalar"dır, bu nedenle bu kavramı öğrenmek gerçekten faydalıdır.

Şu anda trend olan iki bileşen tabanlı kitaplık var: Vue.js ve React. React bariz bir seçim olurdu çünkü zaten Gutenberg tarafından kullanılıyor. Ancak, modern JavaScript'te yeni olan biri için Vue.js ile başlamak daha iyi olabilir.

React, ES6 özelliklerini, sınıflarını, tescilli JSX sözdizimini ve Webpack derleme işlem hattını hemen kullanarak sizi derin uca götürür. Öğrenme eğrisi oldukça diktir.

Öte yandan Vue.js, çok daha yeni başlayanlar için uygundur ve sadece bir <script> etiketi bırakılarak kullanılabilir. Vue.js, düz JavaScript (ES5), HTML ve CSS kullanır. Yeni kavramlara giriş çok daha aşamalıdır.

Birkaç Vue.js projesi üzerinde çalıştıktan sonra, React'in derinliklerine dalmak için daha hazırlıklı olacaksınız. Her zaman ihtiyaç duyulduğundan değil, örneğin Gutenberg gelişimi bunu gerektiriyor.

WordPress REST API'sini kullanın

WordPress' REST API, WordPress'ten uzaktan veri istemek ve değiştirmek için yalnızca standartlaştırılmış bir arayüzdür. Tamamen farklı bir kodlama yönteminden çok bir yazılım mimarisi meselesidir. Aynı eski jQuery AJAX parçacıkları biraz farklı parametrelerle kullanılabilir.

En önemli faydası? WordPress REST API, arka uç ve ön uç arasındaki iletişimi standart hale getirdiğinden, kodunuzdaki modülerlik, yeniden kullanılabilirlik ve okunabilirlik yolunda büyük bir adımdır. HTML ve PHP'nin birlikte karıştırıldığı bu korkunç şablonlar ve karışıma atılan bazı SQL'lerin gitmesi gerekiyor. Şablonlar yalnızca parametre olarak iletilen veriler için yer tutuculara sahip HTML olduğunda, bu verileri PHP'de veya bir REST API aracılığıyla bir ön uç uygulamasına geçirmek arasında büyük bir fark yoktur.

Ayrıca WPGraphQL'ye bakmak isteyebilirsiniz. Sonunda WordPress REST API'sinin yerini alabilir veya almayabilir, ancak hızlı bir şekilde çekiş kazanıyor.

Gutenberg'i Öğrenin (Müşteriler Yakında İsteyecek)

Gutenberg'in nihai hedefi, diğer planların yanı sıra tam site özelleştirmesidir.

Bu, nihayetinde platformun tüm yayıncılık deneyimini etkileyecek yeni bir WordPress Core modelinin temelini oluşturuyor.

GitHub'daki WordPress Gutenberg proje sayfası

Gutenberg, WordPress geliştiricilerinden büyük tepki aldı. WordPress çekirdeğiyle birleştirmeye karşı argümanlardan bazıları şunlardı:

  • Son kullanıcıların önemli bir kısmı buna ihtiyaç duymaz, bu nedenle çekirdeğin bir parçası değil, isteğe bağlı bir eklenti olmalıdır.
  • Bazı siteleri kırdı
  • Sadece hazır değildi ve daha fazla cila ve daha az hata kullanabilirdi.

Bununla birlikte, WordPress'i blog platformu olarak kullanan içerik yazarları için Gutenberg, eski editörden açıkça daha iyi bir deneyim sunuyor.

Gutenberg'in devre dışı bırakılması gerektiği sürece desteklenecektir, evet. Ama şimdi yumuşatmak akıllıca bir fikir: Bir müşteri size yaklaştığında ve Gutenberg geliştirmesini istediğinde, hazır olacaksınız.

Hızlanma Zamanı: “WordPress Yolu” Bile Gelişiyor

WordPress geliştirmede yukarıda açıklanan tüm araç ve tekniklerin kullanılmasına karşı en yaygın argüman şudur: İşleri yapmanın “WordPress yolu” hala işe yarıyor ve bu yolun tüm bu yeni parlak şeylerden daha iyi olması gerekiyor.

Ancak artık WordPress çekirdek geliştiricilerinin en son gelişmelerden haberdar olduğunu gördünüz. Sadece bu da değil, bariz avantajları nedeniyle çekirdeğin daha yeni bölümlerinde mümkün olduğunca kullanıyorlar. Bizi geride tutan tek şey, kimsenin yeniden düzenlemeyeceği eski koddur.

WordPress ve WooCommerce bir süredir yeni teknolojileri uygulayan ve kullanan “özellik eklentileri” geliştirme uygulamasını takip ediyor. Zamanı geldiğinde, bu eklentiler, Gutenberg'in yaptığı gibi, çekirdekte birleştirilir. WooCommerce ayrıca kendi React projesine sahiptir. WordPress REST API ayrıca ayrı bir eklenti olarak başladı ve şimdi WordPress çekirdeğinin bir parçası.

Soru, yeni şeyler öğrenip günlük işlerimde kullanıp kullanmamamız değil, nasıl . Cevap "yavaş yavaş", her seferinde bir adım. Ya yeni bir şey öğrenin ya da iyi bildiğiniz bir şeyi yeni ve farklı bir şekilde yapın.

Örneğin, Webpack'i tüm eski komut dosyalarınızla nasıl kullanacağınızı öğrenin. Web paketi, yeni ES6+ kodunuzu eski tarayıcılarla uyumlu "düz" JavaScript'e aktarabilir. Ayrıca komut dosyalarını küçültebilir ve bir araya toplayabilir. Bu yeni bir şey. Tamamlandı? Ardından, ES6 özelliklerinden yararlanarak JavaScript'inizi yeniden yazın. İyi bildiğiniz şeyi yapmanın yeni bir yolu.

Sonuç: Webpack ve ES6'yı öğreneceksiniz. Profesyoneller olarak adım atmalı ve geri adım atmamalıyız. Her zaman öğrenmeye devam edin. Ve bunu yaptığınızda paylaşın: Toptal, WordPress geliştirme en iyi uygulamalarının bir listesini tutar ve buna topluluk katkılarını memnuniyetle karşılar.

Serimizin 2. Kısmında, modern WordPress arka uç geliştirmenin PHP kısmına dalacağız.