WordPress Eklenti Nasıl Yapılır? Eklenti Geliştirme Rehberi

WordPress eklentisi yazmak, sanıldığı kadar karmaşık değildir; zor olan, eklentiyi güvenli, hızlı ve güncellemelere dayanıklı yazmaktır. Bu rehberde bir eklentinin temel anatomisini, hook mantığını, güvenlik kurallarını ve yayın öncesi kontrol listesini anlatıyoruz. Anlattıklarımız, lisanslı ürünler geliştirirken günlük işimizde uyguladığımız pratiklerdir.

Eklenti nedir ve ne zaman yazılmalı?

Eklenti, WordPress çekirdeğine dokunmadan yeni işlev ekleyen PHP paketidir. Tema değiştirdiğinizde kaybolmaması gereken her şey, yani özel yazı tipleri, formlar, entegrasyonlar ve iş kuralları, temaya değil eklentiye aittir. Yalnızca birkaç satırlık bir ihtiyaç için bile hazır eklenti yığmak yerine küçük bir özel eklenti yazmak çoğu zaman daha hafif ve daha güvenlidir. Bu karşılaştırmayı hazır yazılım mı özel yazılım mı yazımızda daha geniş ele aldık.

Burada sık karıştırılan bir ayrım var: işlevselliği temanın functions.php dosyasına koymak hızlı çözüm gibi görünür ama tema değiştiğinde bütün özellikler kaybolur. Her zaman çalışması gereken işlevler için must-use (mu-plugins) klasörü bir seçenektir; ancak güncelleme mekanizması olmadığı için ürün geliştirirken normal eklenti yapısı daha uygundur. Karar kuralı şudur: içerik ve sunum temaya, işlev ve veri eklentiye aittir.

Minimum eklenti yapısı

wp-content/plugins altında bir klasör oluşturun ve içine ana PHP dosyasını koyun. Dosyanın en üstündeki yorum bloğu eklentiyi WordPress'e tanıtır: Plugin Name, Description, Version, Author, Text Domain ve Requires PHP gibi alanlar burada yer alır. Bu başlık varsa eklenti yönetim panelinde görünür ve etkinleştirilebilir.

Küçük bir eklenti tek dosyayla başlayabilir; ancak büyüdükçe şu yapıyı öneririz:

• includes/ altında sınıflar: her sınıf tek bir sorumluluk taşısın ve namespace kullansın
• admin/ altında ayar sayfaları ve yönetim ekranı kodu
• assets/ altında CSS ve JS dosyaları; yalnızca gereken sayfalarda yüklenmeli
• languages/ altında çeviri dosyaları
• uninstall.php: eklenti silindiğinde seçenekleri ve tabloları temizleyen dosya

Sınıf yapısında pratik bir yaklaşım, ana dosyayı olabildiğince ince tutmaktır: ana dosya yalnızca sabitleri tanımlar, otomatik yükleyiciyi çağırır ve eklentinin ana sınıfını başlatır; her şey bu sınıftan hook'lara bağlanır. Böylece kodunuz test edilebilir kalır, ekibe yeni biri katıldığında nereden başlayacağını hemen görür. Fonksiyon ve sınıf adlarına benzersiz bir önek ya da namespace vermeyi ihmal etmeyin; çünkü WordPress'te tüm eklentiler aynı global alanı paylaşır ve çakışma, canlı sitede beyaz ekranla sonuçlanabilir.

Hook mantığı: eylemler ve filtreler

WordPress eklentilerinin kalbi hook sistemidir. add_action ile WordPress belirli bir noktaya geldiğinde kodunuzu çalıştırırsınız; add_filter ile bir değeri döndürülmeden önce değiştirirsiniz. Çekirdek dosyayı düzenlemek yerine hook kullanmak, her güncellemede kodunuzun yerinde kalmasını sağlar. Hook türleri ve örnekleri için resmi eklenti geliştirici el kitabındaki hook bölümüne bakın.

Kural basit: sayfa her yüklendiğinde ağır iş yapmayın. Veritabanı sorgusunu yalnızca ihtiyaç duyulan hook'ta çalıştırın, sonuçları transient veya object cache ile saklayın ve script dosyalarını yalnızca ilgili ekranda sıraya alın.

wp_enqueue_script ve wp_enqueue_style ile dosyalarınızı sıraya alın; doğrudan head içine script yazmayın. Böylece bağımlılıklar (jQuery gibi) doğru sırada yüklenir, sürüm parametresiyle tarayıcı önbelleği güncellenir ve diğer eklentilerle çakışma azalır. Yönetim paneli ve ön yüz için ayrı hook'ları kullanın: admin_enqueue_scripts yalnızca yönetim ekranlarında, wp_enqueue_scripts ise ziyaretçi tarafında çalışır. Dosyayı gerekmeyen sayfalarda hiç yüklememek için is_singular gibi koşul kontrollerinden yararlanın.

Güvenlik: eklentilerin en sık düştüğü yer

WordPress açıklarının büyük kısmı çekirdekten değil, eklentilerden gelir. Dört alışkanlık riskin çoğunu ortadan kaldırır:

1. Girdiyi temizleyin: Kullanıcıdan gelen her veriyi sanitize_text_field gibi fonksiyonlarla temizleyin ve doğrulayın.
2. Çıktıyı kaçırın: Ekrana yazdığınız her değeri esc_html, esc_attr veya esc_url ile kaçırın.
3. Nonce kullanın: Form ve AJAX isteklerinde nonce doğrulaması yaparak CSRF saldırılarını engelleyin.
4. Yetkiyi kontrol edin: İşlem yapmadan önce current_user_can ile kullanıcının yetkisini sorgulayın; veritabanında özel sorgu yazıyorsanız prepare kullanın.

Resmi eklenti güvenliği rehberi bu konuları örnekleriyle anlatıyor ve her eklenti geliştiricisinin baştan sona okuması gereken bir kaynak.

REST API uç noktaları (register_rest_route) ve admin-ajax kullanıyorsanız, her uç noktaya permission_callback tanımlamayı unutmayın; yetkisiz erişime açık uç nokta, eklentilerde en sık görülen açıklardan biridir. Dosya yükleme ve dosya sistemi işlemlerinde ek özen gösterin; kullanıcıdan gelen yolu asla doğrudan include veya okuma işlemine vermeyin. Composer paketlerini güncel tutun, kullanılmayan kodu silin ve API anahtarı gibi hassas bilgileri kaynak koda gömmeyin.

Ayarlar, çeviri ve sürüm yönetimi

Ayarlarınızı Settings API ile kaydedin; böylece doğrulama ve temizleme için standart bir yolunuz olur. Veritabanına yazılan seçeneklerin autoload değerine dikkat edin: her sayfada yüklenmesi gerekmeyen büyük veriyi autoload dışında tutmak hızı doğrudan etkiler. Metinlerinizi baştan çeviriye hazır yazın: Türkçe kullanıcılar için Text Domain ve __() fonksiyonlarını kullanmak, ilerde yeni dil eklemeyi kolaylaştırır.

Yönetim ekranını sade tutun: ayarları gruplayın, her seçeneğin altına kısa bir açıklama yazın ve varsayılan değerleri çoğu kullanıcının işini görecek şekilde belirleyin. Kullanıcının hiçbir şey yapmadan çalışan bir eklenti kurması, ürün kalitesinin en güçlü göstergesidir.

Sürümlemede Semantic Versioning (ana.alt.yama) benimseyin ve veritabanı yapısını değiştiren her sürümde bir geçiş (migration) rutini yazın. Eklenti etkinleştirilirken tablo oluşturuyorsanız, sürüm numarasını option olarak saklayıp güncellemelerde karşılaştırın.

Eklentinin kaldırma davranışı da profesyonelliğin işaretidir. Müşteri eklentiyi sildiğinde ayarların ve özel tabloların ne olacağını önceden kararlaştırın: varsayılan olarak veriyi koruyup isteğe bağlı bir “silerken verileri temizle” seçeneği sunmak kazara veri kaybını önler. Çok siteli (multisite) kurulumlarda eklentinin her sitede ayrı çalışabilmesi için ayarların site bazında saklanması gerekir. Son olarak hata kaydını (error_log) ve debug çıktısını kontrol altında tutun; müşterinin log dosyasını gereksiz bilgiyle doldurmayın.

Test konusunda otomasyon, tek kişilik projelerde bile değer katar: PHPUnit ile iş mantığını, WordPress'in test altyapısıyla hook davranışlarını test edebilirsiniz. Kodlama standardı için PHP_CodeSniffer ve WordPress Coding Standards kuralları, sorunları daha kod yazılırken yakalar. Ayrıca eklentinin ilk kurulumunu temiz bir WordPress ortamında, başka eklentiler etkinken ve etkin değilken denemek, çakışma sorunlarını yayından önce ortaya çıkarır. Temel yapıyı ise resmi eklenti temelleri bölümünde bulabilirsiniz.

Yayından önce kontrol listesi

• WP_DEBUG açıkken hata veya uyarı çıkmıyor
• Eklenti etkinleştirme, devre dışı bırakma ve silme senaryoları temiz çalışıyor
• Elementor, Gutenberg ve WooCommerce gibi sık kullanılan araçlarla uyum test edildi
• Desteklediğiniz en düşük PHP ve WordPress sürümü başlıkta belirtildi
• Ücretli ürünse lisans ve güncelleme akışı hazır; bu konuyu lisans sistemi yazımızda anlattık

Kendiniz mi yazmalı, ekibe mi vermelisiniz?

Basit bir ihtiyaç için kendiniz yazabilirsiniz; ancak ödeme, lisans veya müşteri verisi gibi hassas alanlara dokunan eklentilerde deneyimli bir ekip, hem güvenlik hem bakım açısından kendini amorti eder. WordPress eklenti geliştirme hizmetimizle ihtiyaç belirtiminden yayına, dokümantasyon ve bakıma kadar süreci üstleniyoruz. Kendi ürünümüz AYM Multilingual, bu yaşam döngüsünün canlı bir örneğidir.

Paylaş:XLinkedInWhatsApp