WordPress Eklenti Seçimi ve Envanter Yönetimi: Teknik Değerlendirme

Bir eklentiyi kurmak birkaç saniye sürer. Çıkarmak ise çoğu zaman veri taşıma, şablon düzeltme ve veritabanı temizliği demektir. Sitenin bakım maliyetini, saldırı yüzeyini ve sayfa hızını en çok belirleyen kararlardan biri bu yüzden kurulum anında verilir. Aşağıda yeni bir eklenti kurulmadan önce bakılacak teknik ölçütler, mevcut envanterin nasıl tutulacağı ve gereksiz eklentinin iz bırakmadan nasıl kaldırılacağı adım adım anlatılıyor.

Eklenti sayısı değil eklenti kalitesi

“Kaç eklenti fazladır?” sorusunun teknik bir cevabı yok. Yalnız kendi işini yapan, dosyalarını yalnız gereken sayfada yükleyen on beş eklenti; her sayfaya script ekleyen ve autoload seçeneklerini megabaytlarca şişiren tek bir eklentiden daha hafif olabilir. Sayıya değil şu dört etkiye bakın:

• Çalışma zamanı maliyeti: Her istekte çalışan PHP kodu, veritabanı sorguları, dış HTTP istekleri.
• Ön yüz maliyeti: Sayfaya eklenen CSS ve JavaScript, fontlar, üçüncü taraf çağrılar.
• Güvenlik yüzeyi: Eklentinin açtığı AJAX ve REST uç noktaları, dosya yükleme işlevleri, yetki kontrolleri.
• Bakım bağımlılığı: Geliştiricinin sürekliliği, lisans yenileme, diğer eklentilerle sürüm uyumu.

Aynı bakış “tek işlev için eklenti mi, birkaç satır kod mu?” kararını da netleştirir. Bir yönetici menüsünü gizlemek veya bir başlık eklemek için eklenti kurmak yerine, sürüm kontrolündeki bir mu-plugin dosyasına birkaç satır yazmak çoğu zaman daha az risklidir. Tersi de doğru: ödeme veya çok dillilik gibi karmaşık işlevleri özel kodla yeniden yazmak, bakımı yapılan bir eklentiden daha büyük teknik borç üretir. Ölçü, işlevin karmaşıklığıdır.

Eklenti değerlendirme ölçütleri tablosu

Yeni bir eklenti önerildiğinde doldurulacak formun iskeleti aşağıda. Her satır “kabul”, “koşullu kabul” veya “ret” olarak işaretlenir. Tek bir ret satırı eklentiyi elemeye yetebilir.

Ölçüt	Nereden bakılır	Uyarı işareti
Bakım sıklığı	WordPress.org sayfası, değişiklik günlüğü	Uzun süredir sürüm yok, “Tested up to” eski
Destek davranışı	Destek forumu, sorun takipçisi	Güvenlik bildirimlerine yanıt yok
Güvenlik geçmişi	WPScan, Patchstack, Wordfence zafiyet veritabanları	Tekrarlayan ve geç kapatılan açıklar
Kod kalitesi	Kaynak kod incelemesi	Nonce ve yetki kontrolü eksikliği, ham SQL
Varlık yükleme	Tarayıcı ağ sekmesi	Her sayfada script ve stil yükleme
Veritabanı izi	Kurulum öncesi/sonrası karşılaştırma	Büyük autoload seçenekleri, sınırsız log tablosu
Lisans ve sürdürülebilirlik	Lisans koşulları, satıcı	Yıllık lisans bitince güncelleme kesilmesi
Çıkış maliyeti	Veri modeli ve kısa kodlar	İçeriğe gömülen özel kısa kodlar, kapalı veri biçimi

Kod incelemesinde birkaç somut noktaya bakmak çoğu zaman yeterli fikir verir: form ve AJAX işleyicilerinde check_ajax_referer() veya wp_verify_nonce() ile nonce kontrolü, current_user_can() ile yetki kontrolü, sorgularda $wpdb->prepare(), REST rotalarında boş bırakılmamış permission_callback, çıktılarda esc_html() ve esc_attr(). Bunlar WordPress Plugin Handbook’ta tanımlanan temel güvenlik pratikleridir. Yokluğu ciddi işarettir.

“Çıkış maliyeti” satırı en sık atlanan ve en pahalıya patlayan satırdır. İçeriğe yüzlerce kısa kod (shortcode) yerleştiren bir eklenti kaldırıldığında bu kodlar sayfalarda düz metin olarak görünür: [ornek_kisa_kod id="12"] yazan bir hizmet sayfası. Kurmadan önce “bunu iki yıl sonra çıkarmak istersek ne olur?” sorusunu yazılı cevaplayın.

Performans etkisini ölçmek

Eklentinin etkisi tahminle değil ölçümle belirlenir; ölçüm staging’de, gerçek içerikle yapılır. Üç katmana bakılır.

Sunucu tarafı: Query Monitor, sorguları ve PHP sürelerini hangi bileşenden geldiğine göre gruplar; staging’de geçici açılıp ölçüm sonrası kaldırılabilir. Komut satırında WP-CLI’ın ayrı paketi olan wp-cli/profile-command kullanılabilir:

# Profil komutunu kur (tek seferlik)
wp package install wp-cli/profile-command

# Yükleme aşamalarının süresi ve sorgu sayısı
wp profile stage --fields=stage,time,query_count

# En maliyetli kancalar
wp profile hook --all --spotlight --orderby=time

# Autoload seçeneklerinin toplam boyutu ve en büyükleri
wp db query "SELECT option_name, LENGTH(option_value) AS boyut
  FROM $(wp db prefix)options
  WHERE autoload IN ('yes','on','auto','auto-on')
  ORDER BY boyut DESC LIMIT 20;"

Son sorgudaki autoload değerleri bilerek geniş tutuldu: WordPress 6.6 ile birlikte yes/no yanında on, off, auto, auto-on ve auto-off değerleri de kullanılıyor. Her istekte belleğe yüklenen bu seçenekler bir eklentinin önbelleğini veya log verisini taşıyorsa her sayfa yüklemesi yavaşlar. Sahada en sık gördüğümüz tablo budur: sorun sayfada değil, wp_options içinde.

Ön yüz: Aynı sayfanın tarayıcı geliştirici araçlarındaki ağ sekmesi eklenti açıkken ve kapalıyken karşılaştırılır. İşlevin kullanılmadığı sayfalarda (form eklentisinin form içermeyen sayfalarda) dosya yüklenip yüklenmediğine özellikle bakın.

Veritabanı: Kurulumdan önce ve sonra wp db tables --all-tables-with-prefix, wp option list --fields=option_name ve wp cron event list çıktıları alınıp karşılaştırılır. Eklentinin oluşturduğu tablolar, seçenekler ve zamanlanmış görevler baştan envantere yazılır; kaldırırken neyin temizleneceği bellidir. Veritabanı katmanındaki genel ayarlar için PHP-FPM ve MariaDB performans rehberi tamamlayıcıdır.

Eklenti envanteri ve sorumluluk kaydı

Envanter eklenti listesinin kopyası değildir; her eklentinin neden orada olduğunu söyleyen kayıttır. Önerilen alanlar:

• Eklenti adı ve slug’ı, kaynak (WordPress.org, ticari satıcı, özel geliştirme)
• Sağladığı iş işlevi ve kullanıldığı sayfalar
• İş tarafındaki sahibi (işlevin gerekli olduğuna karar veren kişi)
• Teknik sorumlu, lisans bitiş tarihi ve lisans hesabının bağlı olduğu e-posta
• Kritiklik sınıfı ve otomatik güncelleme durumu
• Oluşturduğu tablolar, seçenekler, cron görevleri ve içerikte kullanılan kısa kodlar
• Son gözden geçirme tarihi

Lisans e-postası alanını boş geçmeyin. Ayrılmış bir çalışanın posta kutusuna bağlı lisans, yenileme uyarısının kimseye ulaşmaması demektir.

Teknik kısım WP-CLI ile düzenli üretilebilir. Multisite’ta ağ genelinde etkin eklentiler ile site bazında etkin eklentiler ayrı listelenmelidir:

# Tek site
wp plugin list --fields=name,status,version,update,auto_update --format=csv > envanter.csv

# Multisite: ağ genelinde etkin ve zorunlu (mu) eklentiler
wp plugin list --status=active-network --fields=name,version
wp plugin list --status=must-use --fields=name,version

# Multisite: belirli bir alt sitenin etkin eklentileri
wp plugin list --status=active --url=alt.ornek.com --fields=name,version

Çıktılar sürüm kontrolüne veya paylaşılan bir dokümana aktarılır; iş sahibi, lisans ve gerekçe alanlarını ise elle doldurmak gerekir. Kurumsal web sitelerinde envanteri üç ayda bir gözden geçirmek makul bir başlangıç ritmidir.

Terk edilmiş ve gereksiz eklentileri ayıklamak

Gözden geçirmede her eklentiye üç soru sorulur: Hâlâ bakımı yapılıyor mu? İşlevi hâlâ kullanılıyor mu? Başka bir eklenti aynı işi yapıyor mu?

Terk edilmiş eklenti işaretleri: WordPress.org’da eklenti sayfasının kapatılmış olması (dizin kapatma nedenini her zaman açıklamaz; güvenlik sorunu da olabilir), uzun süredir sürüm çıkmaması, “Tested up to” değerinin birkaç ana sürüm geride kalması, destek forumunda yanıtsız güvenlik soruları. Ticari tarafta satıcının ürünü sonlandırması veya lisansın dolması da aynı kategoriye girer. wp plugin list çıktısındaki update sütunu dizinde yeni sürüm olup olmadığını gösterir; ama eski bir eklentide “güncelleme yok” görmek güncel olduğunu değil, artık geliştirilmediğini gösterebilir. Bu ayrımı kaçırmayın.

İşlevi çakışan eklentiler: Sahada sık rastlananlar: iki ayrı önbellek eklentisi, sayfa oluşturucu ile ayrı bir addon paketindeki benzer widget’lar, SEO eklentisi varken ayrıca kurulmuş site haritası eklentisi, iki farklı SMTP eklentisi. Biri seçilir, diğerinin işlevleri taşınır, envanterden düşülür. İki önbellek eklentisi birlikte çalışmaz.

Kullanılmayan işlev: Bir kampanya için kurulup kampanya bitince unutulan eklentiler. İçerikteki kullanımı aramak için kısa kodlar ve blok adları veritabanında aranabilir; örneğin wp db search '[ornek_kisa_kod' --all-tables veya wp post list --post_type=any --s=ornek_kisa_kod --fields=ID,post_title. Kullanımı bulunmayan eklenti devre dışı bırakılıp bekletilmez; aşağıdaki adımlarla yedeklenip kaldırılır.

Eklentiyi güvenli kaldırma adımları

Kaldırma bir değişiklik kaydıyla ve staging’de başlar:

1. Yedek: wp db export ile veritabanı yedeği ve eklenti klasörünün arşivi alınır.
2. Bağımlılık kontrolü: İçerikteki kısa kodlar, bloklar, Elementor widget’ları ve tema tarafındaki fonksiyon çağrıları aranır. Tema kodu eklenti fonksiyonunu doğrudan çağırıyorsa, eklenti kaldırıldığında site ölümcül hatayla düşer.
3. Devre dışı bırakma ve gözlem: wp plugin deactivate <eklenti> ile kapatılır, staging’de ilgili sayfalar ve formlar test edilir. Kritik işlevlerde canlıda bir süre devre dışı bekletmek de seçenektir.
4. Kaldırma: wp plugin uninstall <eklenti> eklentinin kendi kaldırma rutinini (uninstall.php veya kaldırma kancası) çalıştırır ve dosyaları siler. Etkin bir eklentide hata verir; önce devre dışı bırakın ya da --deactivate seçeneğini kullanın. Kaldırma rutini her eklentide yoktur; olanların bir kısmı da veriyi yalnız ayarlarda “kaldırırken verileri sil” benzeri bir seçenek açıksa siler.
5. Artık temizliği: Kurulumda envantere yazılan tablolar, seçenekler ve cron görevleri kontrol edilir. Kalanlar önce listelenir, sonra tek tek silinir: wp option delete <secenek>, wp cron event delete <kanca>. Tablolar için wp db query "DROP TABLE ..." ancak tablonun başka bir eklentiye ait olmadığı doğrulandıktan sonra çalıştırılır.
6. Doğrulama: PHP hata günlüğü, önbellek temizliği ve ilgili sayfaların görsel kontrolü.

Multisite’ta eklenti tabloları alt site önekleriyle (örneğin wp_2_) her alt site için ayrı oluşturulmuş olabilir. Temizlik her alt sitede ayrı kontrol edilir; ana sitede bakıp bırakmak yarım iştir. Komut ayrıntıları wp plugin komut başvurusunda yer alır.

Süreci sürdürülebilir kılmak

Envanter, güncelleme sürecinin ön koşuludur: neyin neden kurulduğu bilinmeyen bir sitede güncelleme testi de eksik kalır. Bu yüzden envanter, WordPress güncelleme politikası içindeki kritik eklenti listesinin de kaynağı olmalı. Yıllar içinde biriken özel kod ve eklenti bağımlılıkları teknik borca dönüştüğünde teknik borç envanteri yaklaşımı daha geniş bir çerçeve verir. Envanter çıkarma ve sadeleştirmeyi bakım kapsamına almak isteyen ekipler WordPress güvenlik ve bakım hizmetine, özel kodla eklenti bağımlılığını azaltmak isteyenler WordPress ve Elementor geliştirme sayfasına bakabilir.

Sık sorulan sorular

Bir WordPress sitesinde kaç eklenti olmalı?

Doğru bir sayı yok. Belirleyici olan, eklentilerin her istekte çalıştırdığı kod, yüklediği dosyalar, veritabanına bıraktığı iz ve bakım durumudur. Kötü yazılmış birkaç eklenti, çok sayıda hafif eklentiden fazla sorun çıkarır.

Devre dışı bırakılmış eklentiyi silmeden tutmanın sakıncası nedir?

Dosyalar sunucuda durdukça bazı zafiyetler eklenti dosyalarına doğrudan istek atılarak istismar edilebilir. Devre dışı eklentilerin güncellemesi de pratikte ihmal edilir. Kullanılmayan eklentiyi yedekleyip silin.

wp plugin uninstall komutu eklentinin tüm verisini siler mi?

Her zaman değil. Komut eklentinin kendi kaldırma rutinini çalıştırır ve dosyaları siler; veritabanında neyin silineceğine eklenti karar verir. Birçok eklenti veriyi bilerek bırakır. Kalan tablolar, seçenekler ve cron görevleri ayrıca kontrol edilmelidir.

Ücretsiz bir eklentinin terk edildiğini nasıl anlarım?

WordPress.org sayfasının kapatılması, uzun süredir sürüm çıkmaması, test edildiği WordPress sürümünün birkaç ana sürüm geride kalması ve destek forumundaki güvenlik sorularının yanıtsız kalması güçlü işaretlerdir.