Modern PHP ile WordPress Kodunu Geliştirme

WordPress on beş yıl önce doğdu ve tarihsel olarak geriye dönük uyumluluğu koruduğu için kodunun daha yeni sürümleri, PHP'nin daha yeni sürümlerinin sunduğu en son yetenekleri tam olarak kullanamadı. PHP'nin en son sürümü 7.3.2 olsa da, WordPress hala PHP 5.2.4'e kadar destek sunuyor.

Ama o günler yakında bitecek! WordPress, minimum PHP sürüm desteğini yükseltecek, Nisan 2019'da PHP 5.6'ya ve Aralık 2019'da PHP 7'ye çıkacak (her şey plana göre giderse). Sonunda, müşterilerimizin sitelerini bozma korkusu olmadan PHP'nin zorunlu programlama yeteneklerini kullanmaya başlayabiliriz. Yaşasın!

WordPress'in on beş yıllık işlevsel kodu, geliştiricilerin WordPress'i nasıl oluşturduklarını etkilediğinden, sitelerimiz, temalarımız ve eklentilerimiz, memnuniyetle bir yükseltme alabilecek en uygun olmayan kodlarla dolu olabilir.

Bu makale iki bölümden oluşmaktadır:

1. En alakalı yeni özellikler
   PHP 5.3, 5.4, 5.5, 5.6 ve 7.0 sürümlerine (PHP 6 olmadığına dikkat edin) başka özellikler eklendi ve en alakalı olanları keşfedeceğiz.
2. Daha iyi yazılım oluşturma
   Bu özelliklere ve daha iyi yazılımlar oluşturmamıza nasıl yardımcı olabileceklerine daha yakından bakacağız.

PHP'nin “yeni” özelliklerini keşfederek başlayalım.

Sınıflar, OOP, SOLID ve Tasarım Modelleri

PHP 5'e sınıflar ve nesneler eklendi, bu nedenle WordPress zaten bu özellikleri kullanıyor, ancak çok kapsamlı veya kapsamlı değil: WordPress'teki kodlama paradigması, nesne yerine çoğunlukla işlevsel programlamadır (uygulama durumundan yoksun işlevleri çağırarak hesaplamalar gerçekleştirir) yönelimli programlama (OOP) (nesnelerin durumunu manipüle ederek hesaplamalar gerçekleştirme). Bu nedenle, sınıfları ve nesneleri ve bunların OOP aracılığıyla nasıl kullanılacağını da açıklarım.

OOP, modüler uygulamalar üretmek için idealdir: Sınıflar, her biri belirli bir işlevsellik uygulayabilen ve diğer bileşenlerle etkileşime girebilen bileşenlerin oluşturulmasına izin verir ve kapsüllenmiş özellikleri ve kalıtımı yoluyla özelleştirme sağlayarak yüksek derecede kod yeniden kullanılabilirliği sağlar. Sonuç olarak, bireysel özellikler uygulamadan izole edilebildiğinden ve kendi başlarına ele alınabildiğinden, uygulamanın test edilmesi ve bakımı daha ucuzdur; geliştirici zaten geliştirilmiş bileşenleri kullanabildiği ve her uygulama için tekerleği yeniden icat etmekten kaçınabildiği için üretkenlik de artar.

Bir sınıf, private (yalnızca tanımlayıcı sınıfın içinden erişilebilir), protected (tanımlayıcı sınıf ve onun ataları ve miras alınan sınıflardan erişilebilir) ve public (her yerden erişilebilir) kullanılarak görünürlük sağlanabilen özelliklere ve işlevlere sahiptir. Bir işlevin içinden, adlarının $this-> ekleyerek sınıfın özelliklerine erişebiliriz:

 class Person { protected $name; public function __construct($name) { $this->name = $name; } public function getIntroduction() { return sprintf( __('My name is %s'), $this->name ); } }

new anahtar sözcüğü aracılığıyla bir nesneye bir sınıf başlatılır, bundan sonra özelliklerine ve işlevlerine -> aracılığıyla erişebiliriz:

 $person = new Person('Pedro'); echo $person->getIntroduction(); // This prints "My name is Pedro"

Miras alan bir sınıf, ata sınıflarından public ve protected işlevleri geçersiz kılabilir ve ata işlevlerine, onları parent:: ile ekleyerek erişebilir:

 class WorkerPerson extends Person { protected $occupation; public function __construct($name, $occupation) { parent::__construct($name); $this->occupation = $occupation; } public function getIntroduction() { return sprintf( __('%s and my occupation is %s'), parent::getIntroduction(), $this->occupation ); } } $worker = new WorkerPerson('Pedro', 'web development'); echo $worker->getIntroduction(); // This prints "My name is Pedro and my occupation is web development"

Bir yöntem abstract yapılabilir, yani miras alan bir sınıf tarafından uygulanması gerekir. abstract bir yöntem içeren bir sınıfın kendisi abstract hale getirilmelidir, yani somutlaştırılamaz; yalnızca soyut yöntemi uygulayan sınıf başlatılabilir:

 abstract class Person { abstract public function getName(); public function getIntroduction() { return sprintf( __('My name is %s'), $this->getName() ); } } // Person cannot be instantiated class Manuel extends Person { public function getName() { return 'Manuel'; } } // Manuel can be instantiated $manuel = new Manuel();

Sınıflar ayrıca, sınıfın bir nesne olarak somutlaştırılması altında değil, sınıfın altında yaşayan static yöntemleri ve özellikleri tanımlayabilir. Bunlara sınıfın içinden self:: aracılığıyla ve sınıfın adı aracılığıyla + :: dışından erişilir:

 class Factory { protected static $instances = []; public static function registerInstance($handle, $instance) { self::$instances[$handle] = $instance; } public static function getInstance($handle) { return self::$instances[$handle]; } } $engine = Factory::getInstance('Engine');

OOP'den en iyi şekilde yararlanmak için, uygulama için sağlam ancak kolayca özelleştirilebilir bir temel oluşturmak için SOLID ilkelerini kullanabilir ve belirli sorunları denenmiş ve test edilmiş bir şekilde çözmek için desenler tasarlayabiliriz. Tasarım kalıpları standartlaştırılmış ve iyi belgelenmiştir, bu da geliştiricilerin uygulamadaki farklı bileşenlerin birbirleriyle nasıl ilişkili olduğunu anlamalarını sağlar ve uygulamayı global değişkenlerin (örneğin global $wpdb ) kullanılmasından kaçınmaya yardımcı olan düzenli bir şekilde yapılandırmanın bir yolunu sağlar. küresel çevreyi kirletenler.

Ad alanları

Ad alanları PHP 5.3'e eklendi, bu nedenle şu anda WordPress çekirdeğinde tamamen yoklar.

Ad alanları, farklı öğeler aynı ada sahip olduğunda çakışmaları önlemek için kod tabanını yapısal olarak düzenlemeye izin verir - farklı dizinlerde depolandıkları sürece aynı ada sahip farklı dosyalara izin veren işletim sistemi dizinlerine benzer bir şekilde. Ad alanları, PHP öğeleri (sınıflar, özellikler ve arabirimler gibi) için aynı kapsülleme hilesini yapar ve farklı öğeler aynı ada sahip olduğunda, onları farklı ad alanlarına yerleştirerek çarpışmalardan kaçınır.

Ad alanları, öğelerinin nasıl adlandırılacağını kontrol edemediğimizden, üçüncü taraf kitaplıklarla etkileşim kurarken bir zorunluluktur ve öğelerimiz için "Dosya", "Kaydedici" veya "Yükleyici" gibi standart adlar kullanıldığında olası çakışmalara yol açar. Ayrıca, tek bir proje içinde bile, ad alanları, diğer sınıflarla çakışmaları önlemek için sınıf adlarının aşırı uzun olmasını engeller, bu da “MyProject_Controller_FileUpload” gibi adlara neden olabilir.

Ad alanları, namespace anahtar sözcüğü kullanılarak tanımlanır ( <?php açılışından hemen sonra satıra yerleştirilir) ve bir \ :

 <?php namespace CoolSoft\ImageResizer\Controllers; class ImageUpload { }

Yukarıdaki sınıfa erişmek için, ad alanı dahil (ve \ ile başlayarak) adını tam olarak nitelememiz gerekir:

 $imageUpload = new \CoolSoft\ImageResizer\Controllers\ImageUpload();

Veya sınıfı mevcut bağlama aktarabiliriz, ardından sınıfa doğrudan adıyla başvurabiliriz:

 use CoolSoft\ImageResizer\Controllers\ImageUpload; $imageUpload = new ImageUpload();

Ad alanlarını yerleşik kurallara göre adlandırarak ek faydalar elde edebiliriz. Örneğin, PHP Standartları Tavsiyesi PSR-4'ü izleyerek uygulama, dosyaları yüklemek için Composer'ın otomatik yükleme mekanizmasını kullanabilir, böylece karmaşıklığı azaltabilir ve bağımlılıklar arasında sorunsuz birlikte çalışabilirlik sağlayabilir. Bu kural, satıcı adının (örneğin şirketin adı) en üstteki alt ad alanı olarak, isteğe bağlı olarak ardından paket adının ve ancak bundan sonra her bir alt ad alanının aynı ada sahip bir dizine karşılık geldiği bir iç yapı olarak dahil edilmesini sağlar. Sonuç, dosyada tanımlanan öğenin ad alanı ile sürücüdeki dosyanın fiziksel konumunu 1'e 1 eşler.

Özellikler

Özellikler PHP 5.4'e eklendi, bu nedenle şu anda WordPress çekirdeğinde tamamen eksikler.

PHP tekli kalıtımı destekler, bu nedenle bir alt sınıf, birden fazla olandan değil, tek bir üst sınıftan türetilir. Bu nedenle, birbirinden genişlemeyen sınıflar, kodu sınıf mirası yoluyla yeniden kullanamazlar. Özellikler, farklı sınıf hiyerarşilerinde yaşayan sınıflar arasında kodun yeniden kullanılmasını mümkün kılan, davranışın yatay olarak düzenlenmesini sağlayan bir mekanizmadır.

Bir özellik bir sınıfa benzer, ancak kendi başına somutlaştırılamaz. Bunun yerine, bir özellik içinde tanımlanan kodun, derleme zamanında oluşturma sınıfına "kopyalanıp yapıştırıldığı" düşünülebilir.

Bir özellik, trait anahtar sözcüğü kullanılarak tanımlanır, ardından use anahtar sözcüğü aracılığıyla herhangi bir sınıfa aktarılabilir. Aşağıdaki örnekte, tamamen alakasız iki sınıf olan Person ve Shop , aynı kodu bir Addressable özelliği aracılığıyla yeniden kullanabilir:

 trait Addressable { protected $address; public function getAddress() { return $this->address; } public function setAddress($address) { $this->address = $address; } } class Person { use Addressable; } class Shop { use Addressable; } $person = new Person('Juan Carlos'); $person->setAddress('Obelisco, Buenos Aires');

Bir sınıf ayrıca birden fazla özellik oluşturabilir:

 trait Exportable { public class exportToCSV($filename) { // Iterate all properties and export them to a CSV file } } class Person { use Addressable, Exportable; }

Özellikler ayrıca diğer özelliklerden oluşabilir, soyut yöntemler tanımlayabilir ve diğer özelliklerin yanı sıra iki veya daha fazla oluşturulmuş özellik aynı işlev adına sahip olduğunda bir çatışma çözme mekanizması sunabilir.

Arayüzler

Arayüzler PHP 5'e eklendi, bu nedenle WordPress bu özelliği zaten kullanıyor, ancak son derece idareli: çekirdek toplamda ondan az arayüz içeriyor!

Arayüzler, hangi yöntemlerin uygulanması gerektiğini belirten kod oluşturmaya izin verir, ancak bu yöntemlerin gerçekte nasıl uygulanacağını tanımlamaya gerek yoktur. Uygulamanın daha iyi modülerliğine ve sürdürülebilirliğine yol açan bileşenler arasındaki sözleşmeleri tanımlamak için kullanışlıdırlar: Bir arabirim uygulayan bir sınıf, bir kara kutu kod olabilir ve arabirimdeki işlevlerin imzaları değişmediği sürece, kod, teknik borç birikimini önlemeye yardımcı olabilecek, kırılma değişiklikleri yapılmadan istendiğinde yükseltilebilir. Ek olarak, bazı arabirimlerin uygulanmasını farklı bir satıcınınkiyle değiştirmeye izin vererek satıcı bağımlılığını azaltmaya yardımcı olabilirler. Sonuç olarak, uygulamanın uygulamalar yerine arayüzlere karşı kodlanması (ve bağımlılık enjeksiyonu yoluyla gerçek uygulamaların hangilerinin olduğunun tanımlanması) zorunludur.

Arayüzler interface anahtar sözcüğü kullanılarak tanımlanır ve görünürlüğü public olması gereken (varsayılan olarak, görünürlük anahtar sözcüğünü eklemek de onu herkese açık hale getiren) yöntemlerinin imzasını (yani içerikleri tanımlanmadan) listelemelidir:

 interface FileStorage { function save($filename, $contents); function readContents($filename); }

Bir sınıf, arabirimi implements anahtar sözcüğü aracılığıyla uyguladığını tanımlar:

 class LocalDriveFileStorage implements FileStorage { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } }

Bir sınıf, onları , ile ayırarak birden fazla arabirim uygulayabilir:

 interface AWSService { function getRegion(); } class S3FileStorage implements FileStorage, AWSService { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } function getRegion() { return 'us-east-1'; } }

Bir arabirim, bir bileşenin ne yapması gerektiğinin amacını bildirdiğinden, arabirimleri uygun şekilde adlandırmak son derece önemlidir.

Kapanışlar

PHP 5.3'e kapanışlar eklendi, bu nedenle şu anda WordPress çekirdeğinde tamamen yoklar.

Kapanışlar, genel ad alanını tek kullanımlık (veya nadiren kullanılan) işlevlerden ayırmaya yardımcı olan anonim işlevleri uygulamaya yönelik bir mekanizmadır. Teknik olarak, kapanışlar sınıfın örnekleridir Closure , ancak pratikte, büyük olasılıkla herhangi bir zarar vermeden bu gerçeğin mutlu bir şekilde farkında olmayabiliriz.

Kapanışlardan önce, bir fonksiyonu başka bir fonksiyona argüman olarak ilettiğimizde, fonksiyonu önceden tanımlamalı ve ismini argüman olarak iletmeliyiz:

 function duplicate($price) { return $price*2; } $touristPrices = array_map('duplicate', $localPrices);

Kapanışlarda, anonim (yani isimsiz) bir işlev zaten doğrudan parametre olarak iletilebilir:

 $touristPrices = array_map(function($price) { return $price*2; }, $localPrices);

Kapanışlar, use anahtar sözcüğü aracılığıyla değişkenleri bağlamına aktarabilir:

 $factor = 2; $touristPrices = array_map(function($price) use($factor) { return $price*$factor; }, $localPrices);

jeneratörler

Jeneratörler PHP 5.5'e eklendi, bu nedenle şu anda WordPress çekirdeğinde tamamen eksikler.

Jeneratörler, basit yineleyicileri uygulamak için kolay bir yol sağlar. Bir üreteç, bellekte bir dizi oluşturmaya gerek kalmadan bir dizi veri üzerinde yineleme yapmak için foreach kullanan kod yazmaya izin verir. Bir üreteç işlevi, normal bir işlevle aynıdır, ancak bir kez geri dönmek yerine, yinelenecek değerleri sağlamak için gerektiği kadar yield verebilir.

 function xrange($start, $limit, $step = 1) { for ($i = $start; $i <= $limit; $i += $step) { yield $i; } } foreach (xrange(1, 9, 2) as $number) { echo "$number "; } // This prints: 1 3 5 7 9

Argüman ve Dönüş Tipi Bildirimleri

PHP'nin farklı sürümlerinde farklı argüman türü bildirimleri tanıtıldı: WordPress zaten arayüzleri ve dizileri bildirebilir (ki bunu yapmaz: Çekirdekte bir diziyi parametre olarak bildiren bir işlev örneği buldum ve arayüz yok) ve yakında çağrılabilirleri (PHP 5.4'te eklendi) ve skaler türleri bildirebileceksiniz: bool, float, int ve string (PHP 7.0'da eklendi). PHP 7.0'a dönüş tipi bildirimleri eklendi.

Bağımsız değişken türü bildirimleri, işlevlerin bir bağımsız değişkenin hangi türde olması gerektiğini bildirmesine izin verir. Doğrulama, çağrı sırasında yürütülür ve bağımsız değişkenin türü belirtilen değilse bir istisna atar. Dönüş türü bildirimleri aynı kavramdır, ancak işlevden döndürülecek değer türünü belirtirler. Tür bildirimleri, işlevin amacının anlaşılmasını kolaylaştırmak ve çalışma zamanı hatalarının beklenmeyen bir türün alınmasını veya döndürülmesini önlemek için kullanışlıdır.

Argüman tipi, argüman değişken adından önce bildirilir ve dönüş tipi, argümanlardan sonra, öncesinde : ile bildirilir:

 function foo(boolean $bar): int { }

Skaler bağımsız değişken türü bildirimlerinin iki seçeneği vardır: zorlayıcı ve katı. Zorlayıcı modda, parametre olarak yanlış tür iletilirse, doğru türe dönüştürülür. Örneğin, bir dize bekleyen bir parametre için bir tamsayı verilen bir işlev, dize türünde bir değişken alır. Katı modda, yalnızca kesin bildirim türünden bir değişken kabul edilecektir.

Zorlayıcı mod varsayılandır. Katı modu etkinleştirmek için, strict_types bildirimi ile birlikte kullanılan bir declare ifadesi eklemeliyiz:

 declare(strict_types=1); function foo(boolean $bar) { }

Yeni Sözdizimi ve Operatörler

WordPress, func_num_args işlevi aracılığıyla değişken uzunluklu argüman listelerini zaten tanımlayabilir. PHP 5.6'dan başlayarak, fonksiyonun değişken sayıda argümanı kabul ettiğini ve bu argümanların verilen değişkene bir dizi olarak iletileceğini belirtmek için ... işaretini kullanabiliriz:

 function sum(...$numbers) { $sum = 0; foreach ($numbers as $number) { $sum += $number; } return $sum; }

PHP 5.6'dan başlayarak, sabitler, yalnızca statik değerler yerine sayısal ve dize değişmezlerini içeren skaler ifadeleri ve ayrıca dizileri içerebilir:

 const SUM = 37 + 2; // A scalar expression const LETTERS = ['a', 'b', 'c']; // An array

PHP 7.0'dan başlayarak diziler, define kullanılarak da tanımlanabilir:

 define('LETTERS', ['a', 'b', 'c']);

PHP 7.0 birkaç yeni operatör ekledi: Null birleştirme operatörü ( ?? ) ve Uzay Gemisi operatörü ( <=> ).

Null birleştirme operatörü ?? isset() ile bağlantılı olarak bir üçlü kullanma ihtiyacının genel durumu için sözdizimsel şekerdir. Varsa ve NULL değilse ilk işlenenini döndürür; aksi takdirde, ikinci işlenenini döndürür.

 $username = $_GET['user'] ?? 'nobody'; // This is equivalent to: // $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

Uzay gemisi operatörü <=> , iki ifadeyi karşılaştırmak için kullanılır, birinci işlenen sırasıyla ikinci işlenenden küçük, ona eşit veya ondan büyük olduğunda -1, 0 veya 1 döndürür.

 echo 1 <=> 2; // returns -1 echo 1 <=> 1; // returns 0 echo 2 <=> 1; // returns 1

Bunlar, PHP'nin 5.3 ila 7.0 sürümlerini kapsayan en önemli yeni özellikleridir. Bu makalede listelenmeyen ek yeni özelliklerin listesi, sürümden sürüme geçişle ilgili PHP belgelerine göz atılarak elde edilebilir.

Ardından, daha iyi yazılımlar üretmek için tüm bu yeni özelliklerden ve web geliştirmedeki son trendlerden en iyi şekilde nasıl yararlanabileceğimizi analiz edeceğiz.

PHP Standartları Önerileri

PHP Standartları Önerileri, popüler çerçevelerden ve kitaplıklardan bir grup PHP geliştiricisi tarafından, farklı projelerin daha sorunsuz bir şekilde entegre edilebilmesi ve farklı ekiplerin birbirleriyle daha iyi çalışabilmesi için kurallar oluşturmaya çalışarak oluşturuldu. Öneriler statik değildir: mevcut öneriler kullanımdan kaldırılabilir ve yerlerini almak için daha yenileri oluşturulabilir ve yenileri sürekli olarak yayınlanır.

Mevcut öneriler şunlardır:

Bileşenlerde Düşün ve Kodla

Bileşenler, çerçevenin kendisine kilitlenmeden bir çerçeveden en iyi özellikleri kullanmayı mümkün kılar. Örneğin, Symfony, Symfony çerçevesinden bağımsız olarak kurulabilen bir dizi yeniden kullanılabilir PHP bileşeni olarak piyasaya sürüldü; Başka bir PHP çerçevesi olan Laravel, birkaç Symfony bileşeninden yararlanır ve herhangi bir PHP projesi tarafından kullanılabilecek kendi yeniden kullanılabilir bileşen setini yayınladı.

Bu bileşenlerin tümü, genel PHP paketlerinin bir deposu olan Packagist'te yayınlanır ve PHP için son derece popüler bir bağımlılık yöneticisi olan Composer aracılığıyla herhangi bir PHP projesine kolayca eklenebilir.

WordPress, böyle erdemli bir geliştirme döngüsünün parçası olmalıdır. Ne yazık ki, WordPress çekirdeğinin kendisi bileşenler kullanılarak oluşturulmamıştır (arayüzlerin neredeyse tamamen yokluğunun kanıtladığı gibi) ve dahası, WordPress'in Composer aracılığıyla yüklenmesini sağlamak için gerekli olan composer.json dosyasına bile sahip değildir. Bunun nedeni, WordPress topluluğunun WordPress'in bir sitenin bağımlılığı olup olmadığı (bu durumda onu Composer aracılığıyla yüklemek doğru olacaktır) veya sitenin kendisi olup olmadığı (bu durumda Composer iş için doğru araç olmayabilir) konusunda anlaşmaya varmamış olmasıdır. .

Benim düşünceme göre, WordPress'in önümüzdeki on beş yıl boyunca (en azından arka uç CMS olarak WordPress) alakalı kalmasını bekliyorsak, WordPress'in bir sitenin bağımlılığı olarak kabul edilmesi ve Composer aracılığıyla kurulum için uygun hale getirilmesi gerekir . Nedeni çok basit: Terminalde neredeyse tek bir komutla Composer, Packagist'te yayınlanan binlerce paketten bir projenin bağımlılıklarını bildirmeyi ve yüklemeyi sağlayarak, çok kısa sürede son derece güçlü PHP uygulamaları oluşturmayı mümkün kılar ve geliştiriciler sever. bu şekilde çalışıyor. WordPress bu modele adapte olmazsa, Git tabanlı dağıtımların tanıtılmasından sonra FTP'nin gözden düşmesi kadar geliştirme topluluğunun desteğini kaybedebilir ve unutulabilir.

Gutenberg'in piyasaya sürülmesinin WordPress'in sitenin kendisi değil, bir site bağımlılığı olduğunu zaten gösterdiğini iddia ediyorum: Gutenberg, WordPress'i başsız bir CMS olarak ele alıyor ve Drupal Gutenberg'in örneklediği gibi diğer arka uç sistemleriyle de çalışabilir. Bu nedenle Gutenberg, bir siteye güç sağlayan CMS'nin değiştirilebileceğini ve dolayısıyla bir bağımlılık olarak ele alınması gerektiğini açıkça belirtir. Ayrıca, Gutenberg'in kendisinin npm aracılığıyla yayınlanan JavaScript bileşenlerine dayanması amaçlanmıştır (temel taahhütçü Adam Silverstein tarafından açıklandığı gibi), bu nedenle WordPress istemcisinin JavaScript paketlerini npm paket yöneticisi aracılığıyla yönetmesi bekleniyorsa, bu mantığı neden genişletmiyorsunuz? PHP bağımlılıklarını Composer aracılığıyla yönetmek için arka uç?

Şimdi iyi haber: WordPress'i bir sitenin bağımlılığı olarak ele alıp Composer aracılığıyla yüklemek zaten mümkün olduğundan, bu sorunun çözülmesini beklemeye gerek yok. John P. Bloch, WordPress çekirdeğini Git'e yansıttı, bir composer.json dosyası ekledi ve bunu Packagist'te yayınladı ve Roots' Bedrock, WordPress'i modern geliştirme araçları desteği ve gelişmiş bir güvenlik ile özelleştirilmiş bir klasör yapısıyla kurmak için bir paket sunuyor. Ve temalar ve eklentiler de kapsanmaktadır; WordPress teması ve eklenti dizinlerinde listelendikleri sürece, WordPress Packagist altında mevcutturlar.

Sonuç olarak, temalar ve eklentiler açısından değil, bileşenler açısından düşünerek WordPress kodunu oluşturmak, herhangi bir PHP projesi tarafından kullanılmak üzere Packagist aracılığıyla kullanılabilir hale getirmek ve ayrıca temalar ve WordPress'in özel kullanımı için eklentiler. Bileşenin WordPress API'leri ile etkileşime girmesi gerekiyorsa, bu API'ler, ihtiyaç duyulursa diğer CMS'ler için de uygulanabilen bir arayüzün arkasında özetlenebilir.

Görünüm Katmanını Geliştirmek İçin Bir Şablon Motoru Ekleme

Bileşenlerde düşünme ve kodlama önerisini takip edersek ve WordPress'i sitenin kendisinden başka bir sitenin bağımlılığı olarak ele alırsak, projelerimiz WordPress tarafından dayatılan sınırlardan kurtulabilir ve diğer çerçevelerden alınan fikir ve araçları içe aktarabilir.

Sunucu tarafında HTML içeriği oluşturma, düz PHP şablonları aracılığıyla yapılan bir örnektir. Bu görünüm katmanı, basit PHP şablonlarına göre avantaj sağlayan çok özlü bir sözdizimi ve güçlü özellikler sağlayan Twig (Symfony) ve Blade (Laravel) şablon motorları aracılığıyla geliştirilebilir. Özellikle, Gutenberg'in dinamik blokları, bloğun HTML'sini sunucu tarafında oluşturma süreçleri WordPress'in şablon hiyerarşi mimarisinden ayrıldığından, bu şablon motorlarından kolayca yararlanabilir.

Mimar Genel Kullanım Uygulaması

Arayüzlere karşı kodlama ve bileşenler açısından düşünme, sahip olduğumuz her proje için yalnızca belirli bir kullanım için kodlama yapmak yerine, bir uygulamayı genel kullanım için tasarlamamıza ve sunmamız gereken belirli kullanım için özelleştirmemize olanak tanır. Bu yaklaşım kısa vadede daha maliyetli olsa da (ekstra çalışma gerektirir), uzun vadede ek projeler yalnızca genel kullanımlı bir uygulamayı özelleştirmekten daha az çabayla teslim edilebildiğinde karşılığını verir.

Bu yaklaşımın etkili olabilmesi için aşağıdaki hususlar dikkate alınmalıdır:

Sabit Bağımlılıklardan Kaçının (Mümkün olduğunca)

jQuery ve Bootstrap (veya Foundation veya <–en sevdiğiniz kitaplığı buraya ekleyin–> ) birkaç yıl önce olmazsa olmazlar olarak kabul edilebilirdi, ancak Vanilla JS ve daha yeni yerel CSS özelliklerine karşı sürekli olarak zemin kaybediyorlar. Dolayısıyla beş yıl önce kodlanmış bu kütüphanelere dayalı genel kullanımlı bir proje artık günümüzde uygun olmayabilir. Bu nedenle, genel bir kural olarak, üçüncü taraf kitaplıklarına olan sabit bağımlılıkların miktarı ne kadar düşükse, uzun vadede o kadar güncel olacaktır.

İşlevselliklerin Aşamalı İyileştirilmesi

WordPress, kullanıcı yönetimi içeren tam gelişmiş bir CMS sistemidir, bu nedenle kullanıcı yönetimi desteği kutudan çıkarılmıştır. Ancak, her WordPress sitesi kullanıcı yönetimi gerektirmez. Bu nedenle, uygulamamız bunu dikkate almalı ve her senaryoda en iyi şekilde çalışmalıdır: Gerektiğinde kullanıcı yönetimini destekleyin, ancak gerekmediğinde ilgili varlıkları yüklemeyin. Bu yaklaşım da kademeli olarak çalışabilir: Bir müşterinin Bize Ulaşın formunu uygulaması gerektiğini ancak bütçesinin olmadığını, bu nedenle sınırlı özelliklere sahip ücretsiz bir eklenti kullanarak kodladığımızı ve başka bir müşterinin ticari bir eklenti teklifinden lisans satın almak için bütçesi olduğunu söyleyin. daha iyi özellikler. Ardından, işlevselliğimizi varsayılan olarak çok temel bir işlevselliğe kodlayabilir ve sistemde mevcut olan en yetenekli eklentinin özelliklerini giderek daha fazla kullanabiliriz.

Sürekli Kod ve Dokümantasyon İncelemesi

Önceden yazılmış kodumuzu ve dokümantasyonunu periyodik olarak gözden geçirerek, yeni sözleşmeler ve teknolojiler konusunda güncel olup olmadığını doğrulayabiliriz ve değilse, teknik borcun üstesinden gelmek için çok pahalı hale gelmeden önce onu yükseltmek için önlemler alabiliriz. ve her şeyi sıfırdan yeniden kodlamamız gerekiyor.

Önerilen okuma : Dikkatli Olun: Sitenizi Güvensiz Hale Getirebilecek PHP ve WordPress İşlevleri

Sorunları En Aza İndirmeye Çalışın Ama Olduğunda Hazırlıklı Olun

Hiçbir yazılım %100 mükemmel değildir: Hatalar her zaman oradadır, biz onları henüz bulamadık. Bu nedenle, sorunlar ortaya çıktıktan sonra bunların düzeltilmesinin kolay olduğundan emin olmamız gerekir.

Basitleştir

Karmaşık yazılımlar uzun vadede sürdürülemez: Sadece diğer ekip üyeleri bunu anlayamayabileceğinden değil, aynı zamanda onu kodlayan kişinin de birkaç yıl sonra kendi karmaşık kodunu anlayamayabileceğinden. Bu nedenle, yalnızca basit yazılımlar doğru ve hızlı olabileceğinden, basit yazılım üretmek bir öncelik olmalıdır.

Derleme Zamanında Başarısız Olmak, Çalışma Zamanından Daha İyidir

Bir kod parçası, derleme zamanında veya çalışma zamanında hatalara karşı doğrulanabiliyorsa, derleme zamanı çözümüne öncelik vermeliyiz, böylece hata ortaya çıkabilir ve geliştirme aşamasında ve uygulama üretime ulaşmadan önce ele alınabilir. Örneğin, sabitleri define için hem const hem de define kullanılır, ancak const derleme zamanında doğrulanırken, tanım çalışma zamanında doğrulanır. Bu nedenle, mümkün olduğunda, const kullanmak define yerine tercih edilir.

Bu öneriyi takiben, sınıflarda bulunan WordPress işlevlerinin bağlanması, sınıf adına sahip bir dize yerine gerçek sınıfı bir parametre olarak ileterek geliştirilebilir. Aşağıdaki örnekte, Foo sınıfı yeniden adlandırılırsa, ikinci kanca bir derleme hatası üretirken, ilk kanca çalışma zamanında başarısız olur, dolayısıyla ikinci kanca daha iyidir:

 class Foo { public static function bar() { } } add_action('init', ['Foo', 'bar']); // Not so good add_action('init', [Foo::class, 'bar']); // Much better

Yukarıdakiyle aynı nedenle, global değişkenleri kullanmaktan kaçınmalıyız (örneğin global $wpdb ): bunlar yalnızca global bağlamı kirletmekle kalmaz ve nereden geldiklerini izlemek kolay değildir, ayrıca yeniden adlandırıldıklarında hata çalışma zamanında üretilebilir. Çözüm olarak, gerekli nesnenin bir örneğini elde etmek için bir Dependency Injection Container kullanabiliriz.

Hatalar/İstisnalarla Başa Çıkmak

Exception nesnelerinin bir mimarisini oluşturabiliriz, böylece uygulama her bir özel soruna göre uygun şekilde tepki verebilir, ya mümkün olduğu zaman bu sorundan kurtulabilir ya da olmadığında kullanıcıya yardımcı bir hata mesajı gösterebilir ve genel olarak hata için hatayı günlüğe kaydedebilir. sorunu çözmek için yönetici. Ve kullanıcılarınızı her zaman beyaz ölüm ekranından koruyun: Tüm yakalanmayan Error s ve Exception s, ekranda korkutucu olmayan bir hata mesajı yazdırmak için set_exception_handler işlevi aracılığıyla engellenebilir.

Yapı Araçlarını Benimseyin

Derleme araçları, manuel olarak yürütülmesi çok sıkıcı olan görevleri otomatikleştirerek çok zaman kazandırabilir. WordPress herhangi bir özel yapım aracıyla entegrasyon sunmaz, bu nedenle bunları projeye dahil etme görevi tamamen geliştiriciye düşer.

Farklı amaçlara ulaşmak için farklı araçlar vardır. Örneğin, görüntüleri sıkıştırmak ve yeniden boyutlandırmak, JS ve CSS dosyalarını küçültmek ve Webpack, Grunt ve Gulp gibi bir yayın oluşturmak için dosyaları bir dizine kopyalamak için görevleri yürütmek için oluşturma araçları vardır; diğer araçlar, Yeoman gibi temalarımız veya eklentilerimiz için klasör yapısını oluşturmaya yardımcı olan bir projenin iskelesini oluşturmaya yardımcı olur. Gerçekten de, etrafta bu kadar çok araç varken, mevcut farklı araçları karşılaştıran makalelere göz atmak, ihtiyaçlarımız için en uygun olanı bulmanıza yardımcı olacaktır.

Ancak bazı durumlarda, projemizin ihtiyaç duyduğu şeyi tam olarak gerçekleştirebilecek hiçbir derleme aracı yoktur, bu nedenle kendi derleme aracımızı projenin kendisinin bir uzantısı olarak kodlamamız gerekebilir. Örneğin, bunu WordPress'te Service Workers için destek eklemek üzere service-worker.js dosyasını oluşturmak için yaptım.

Çözüm

PHP 5.2.4'e kadar genişletilen geriye dönük uyumluluğu korumaya yönelik güçlü vurgusu nedeniyle, WordPress, PHP'ye eklenen en son özelliklerden yararlanamadı ve bu gerçek, WordPress'i kodlamak için çok heyecan verici olmayan bir platform haline getirdi. birçok geliştirici arasında.

Neyse ki, bu kasvetli günler yakında sona erebilir ve WordPress bir kez daha kodlamak için parlak ve heyecan verici bir platform haline gelebilir: Aralık 2019'da başlayan PHP 7.0+ gereksinimi, geliştiricilerin daha güçlü ve daha performanslı yazılım Bu makalede, yeni kullanıma sunulan en önemli PHP özelliklerini ve bunlardan en iyi şekilde nasıl yararlanılacağını inceledik.

Gutenberg'in yakın zamanda piyasaya sürülmesi, gelecek güzel zamanların bir işareti olabilir: Gutenberg'in kendisi topluluk tarafından tam olarak kabul edilmemiş olsa bile, en azından en son teknolojileri (React ve Webpack gibi) çekirdeğe dahil etmeye istekli olduğunu gösteriyor. . Bu olaylar beni meraklandırıyor: Ön uç böyle bir makyaj alabilirse, neden arka uca genişletmiyorsunuz? WordPress en az PHP 7.0 gerektirdiğinde, modern araçlara ve metodolojilere yükseltme hızlanabilir: npm tercih edilen JavaScript paket yöneticisi haline geldiyse, neden Composer'ı resmi PHP bağımlılık yöneticisi yapmıyorsunuz? Bloklar ön uçta site oluşturmak için yeni birimse, neden arka uçta işlevleri birleştirmek için PHP bileşenlerini kullanmıyorsunuz? Ve son olarak, Gutenberg, WordPress'i değiştirilebilir bir arka uç CMS'si olarak ele alıyorsa, neden WordPress'in sitenin kendisi değil de bir site bağımlılığı olduğunu kabul etmiyorsunuz? Bu açık soruları üzerinde düşünmeniz ve üzerinde düşünmeniz için bırakacağım.