Eklentim için bir API nasıl oluşturulur?

WordPress için eklentiler geliştiriyorum, geliştirdiğim çoğu eklenti iki veya üç sınıf kullanıyor, bu nedenle Buddypress veya WooCommerce kadar büyük değil.

Diğer geliştiricilerin işlevleri özelleştirebileceği ve sistemin Buddypress ve WooCommerce ile aynı olması gereken bir tür karmaşık sistemi (şu anda ayrıntıları paylaşamıyorum, daha sonra geliştirme sırasında) sunmak için iki açık kaynak eklentisi geliştirmeyi planlıyorum. .

Bu eklenti dosyalarını kontrol ettiğimde ve geliştiricilerin ihtiyaca göre değiştirebilecekleri kendi eylemlerini ve filtrelerini kaydettiklerini fark ettik. Ancak, benim sorun tamamen anlayamıyorum, nasıl diğerleri eklenti işlevleri geçersiz kılmak ve kendi eklemek için esnekliğe sahip bir eklenti yazmak gerekir.

Kesin bir cevap vermenin zor olduğunu biliyorum, ancak doğru yönde gidebilmem için bir başlangıç ​​kılavuzuna ihtiyacım var. Kendi eylemlerimi ve filtrelerimi kaydetmem gerekiyor mu? Evet ise nasıl? değilse, seçeneklerim nelerdir?

Tavsiyen bana çok yardımcı olacak ... Teşekkürler

Bir eklenti veya temada sunduğunuz API, söz konusu kodun mantığına bağlıdır. Muhtemelen tüm durumlar için geçerli bir rehber yoktur.

API'lerle birden fazla eklenti için katkıda bulunuyorum ve şu ana kadar öğrendiğim şey:

1. Kullanıcıların kodunuzu nasıl kullandıklarını gerçekten bilmeden API sunmayın.

   İlk iki veya üç sürümü API olmadan yayınlayın. Mümkünse özel eylemler veya filtreler, genel yöntemler veya işlevler (ve hiçbir zaman global değişkenler) yoktur. Kullanıcılarınızdan gelen istekleri bekleyin, ancak iç kod yapınızın uzun vadede çalışacağını bilmeden kodu eklemeyin.

   Bir API'nin geriye dönük uyumluluğunu korumak zordur . Başka yerlerde gerekli iyileştirmeleri engelleyebilir. WordPress'in günümüzde kaldıramayacağı tüm global değişkenleri düşünün. Bu kötü bir API ve yıllarca takılı kalıyoruz, çünkü insanlar zaten kullanıyor .

2. API'nızı kodun geri kalanından ayırmayı düşünün (bir fikir için önceki bağlantıya bakın).
   API'nız yalnızca üçüncü taraf geliştiriciler için değil, sizin için de yararlı olmalıdır. Gerekmiyorsa kendiniz için kısıtlama eklemeyin.

3. Kendi köpek mamasını yiyin.
   Özel kancalar sunuyorsanız, bunları kodunuzda kullanın. Bu, diğer geliştiricilere faydalı örnekler verecektir ve olası kusurları yakında görebilirsiniz.
   WordPress çekirdeği, Ayarlar API'si olarak adlandırılan dahili olarak kullanırsa, bugün bu karmaşa olmazdı. Olabilir.

4. Örnek olun.
   Eklentinizde WordPress çekirdek API'sinin iyi kısımlarını kullanın. Anonim nesnelerden , sabitlerden, global değişkenlerden ve her türlü öngörülemeyen koddan kaçının .

5. Tutarlı bir adlandırma düzeni kullandığınızdan emin olun ( böyle bir karmaşa değil ) ve her şeyi kendi ad alanınızın altına koyun.

6. Önce belgeleri yazın. Daha sonra yeni (bir) API'sı yayınlayın.
   Her şey için faydalı örnekler oluşturun. Kaç tane delik ve fazlalık bulacağınızı görünce şaşıracaksınız.

7. Geri arama cehenneminden kaçının.
   İşler gerektiği gibi çalışmadığında (küçültülmüş komut dosyaları ve stil sayfaları dahil değil) API'nızın hatalarını ayıklamak için özel araçlar sunun. AJAX'ın hatalarını ayıklamak için , sadece burada ne kadar yaratıcı olabileceğinizi göstermek için bir örnek yazdım . Yine, bu araçlar yayınlanmadan önce belgelerinizde açıklanmalıdır.

8. WordPress'in geri arama paradigmasına bir alternatif, Gözlemci deseni olabilir . Bu, üçüncü taraf geliştiriciler için bariyeri artıracaktır, ancak her iki tarafta da daha iyi kodla sonuçlanabilir.