Eklenti Çakışması

Eklenti çakışması en sık gizli katil: “plugin conflict”, “eklenti çakışması”, “yükleyince site bozuldu” sorununu doğru sırayla teşhis ve kalıcı çözüm

WordPress dünyasında en çok zaman yakan, en çok para yaktıran ama en az “adı konan” sorun Eklenti çakışmasıdır. Kullanıcı “yükleyince site bozuldu” der, geliştirici “tema bozdu” sanar, ajans “hosting”e yüklenir. Oysa sahadaki gerçek çok nettir: Eklenti çakışması, en sık gizli katildir. Çünkü hata her zaman anında patlamaz; bazen sadece belirli sayfada, belirli rol ile, belirli tarayıcıda, belirli saatlerde ortaya çıkar. Bu yüzden bu işi doğru sırayla elemezsen, saatlerce yanlış yere kazma vurursun.

Şunu açık söyleyelim: eklenti ekosistemi, çekirdek kadar sıkı denetlenmez. Çekirdek daha oturmuş kurallarla ilerler, ama eklentiler çok farklı kalite seviyelerindedir. Aynı işi yapan iki eklenti bir arada çalıştırıldığında (cache + cache, SEO + SEO, güvenlik + güvenlik) çatışma ihtimali ciddi şekilde artar. Kötü kodlanmış uzantı ise tek başına bile siteyi devirebilir. Bu makale, Eklenti çakışmasını rastgele kurcalamayla değil, disiplinli bir “arıza protokolü” ile çözmek için hazırlandı.

Hedef basit: önce siteyi tekrar ayağa kaldıracağız, sonra çatışmayı hangi eklenti veya hangi kombinasyon tetikliyor netleştireceğiz, ardından kalıcı olarak çakışmayı bitireceğiz. Bu sırayı bozmadan ilerlersen, en kötü vakada bile kontrol sende olur. Bu sırayı bozarsan, her gün başka bir yerden patlayan bir sistemle yaşarsın.

Eklenti çakışması gerçekte nedir, neden bu kadar sinsi çalışır?

Eklenti çakışması, WordPress’in çalışması sırasında iki veya daha fazla eklentinin aynı veriyi, aynı hook’u, aynı dosyayı, aynı çıktıyı veya aynı tarayıcı kaynağını kontrol etmeye çalışmasıdır. WordPress’in mimarisi “hook” ve “filter” mantığına dayanır. Eklentiler aynı hook’a bağlanır ve sıra, öncelik, beklenen veri tipi, hata toleransı gibi detaylar devreye girer. İki eklenti aynı anda aynı şeye müdahale edince, hata bazen anında fatal olarak patlar, bazen sadece küçük bir davranış bozukluğu şeklinde kendini gösterir. Sinsilik burada başlar.

Örnek olarak düşün: bir eklenti HTML çıktısını tamponlayıp sıkıştırmak istiyor, diğeri aynı çıktıyı güvenlik amaçlı filtrelemek istiyor. Birinin beklediği çıktı diğerinin elinde değişince, sonuç saçma bir boş sayfa veya kırık bir layout olabilir. Ya da bir eklenti checkout alanlarını düzenliyor, diğeri de aynı alanları doğruluyor. Alan isimleri bir yerde değişince ödeme anında hata çıkar. Kullanıcı bunu “ödeme bozuldu” diye görür, ama asıl sebep iki eklentinin aynı noktaya basmasıdır.

Bir de JavaScript cephesi var. Eklentiler, admin ve ön yüzde script yükler. İki eklenti aynı global değişkeni kullanır, aynı kütüphanenin farklı sürümünü yükler, dosyaları yanlış sırada yükler. Sonuç: tarayıcı konsolunda hata, sayfada kırık davranış. Bu, “site açılıyor ama çalışmıyor” tipinin ana kaynağıdır.

Belirtiler: Eklenti çakışması kendini nasıl belli eder?

Site tamamen açılmıyor, beyaz sayfa veya 500 hatası

Bu genelde PHP tarafında fatal error demektir. En sık görülenler şunlardır: aynı sınıfın iki kez tanımlanması, çağrılan fonksiyonun bulunmaması, PHP sürüm uyumsuzluğu, beklenmeyen veri tipleri, yanlış dosya dahil etme. Bu tipte çatışma genellikle bir eklenti güncellemesi sonrası veya yeni eklenti kurulumu sonrası ortaya çıkar.

Admin açılıyor ama ön yüz bozuluyor veya tersine

Admin ve ön yüz farklı script setleri ve farklı akışlar kullanır. Bazı eklentiler sadece adminde çalışır, bazıları sadece ön yüzde. Çatışma sadece bir tarafta da çıkabilir. Bu yüzden “admin sağlam, ön yüz bozuk” diyerek temaya atlamak hata olur. Aynı şekilde “ön yüz sağlam, adminde medya yüklenmiyor” da Eklenti çakışması olabilir.

Belirli sayfa türlerinde bozulma: ödeme, üyelik, form, arama, medya

Çatışmaların en pahalı olanı, kritik sayfalarda çıkanıdır. Ödeme sayfası, üyelik sayfaları, form gönderimleri, medya yükleme ekranı, arama sonuçları, çok dilli geçişler. Bu bölgeler eklentilerin yoğunlaştığı yerlerdir. Bir eklenti “küçük bir ek özellik” diye girer ama kritik akışın üzerine basar. Bu yüzden belirtiyi “hangi sayfada” gördüğün altın değerindedir.

Performans düşüşü, CPU zıplaması, admin yavaşlığı

Her çatışma patlayarak kendini göstermez. Bazı çatışmalar sessizce siteyi yavaşlatır. İki cache eklentisi aynı anda çalışınca, iki ayrı çıktı tamponlama zinciri oluşur. İki güvenlik eklentisi aynı isteği iki kez tarar. İki SEO eklentisi aynı metayı iki kez hesaplar, aynı sitemap’i iki farklı şekilde üretir. Sonuç: ağırlaşan sistem, beklenmedik yük. Bu da bir çatışma türüdür; sadece “kırık” değil “şişmiş” davranış üretir.

Tipik nedenler: Aynı işi yapan birden fazla eklenti ve kötü kodlanmış uzantı

Eklenti çakışmasının en klasik nedeni, aynı işi yapan birden fazla eklentinin aynı anda aktif olmasıdır. Bu, çok sıradan görünür ama inanılmaz sık yaşanır. Siteyi hızlandırma hevesiyle iki cache eklentisi kurulur. SEO tarafında “biri meta yazsın biri redirect yönetsin” diye iki SEO eklentisi aynı anda aktif kalır. Güvenlikte “biri firewall, biri login koruma” diye iki güvenlik eklentisi çakıştırılır. Sonra da “neden bozuldu” denir.

İkinci büyük neden, kötü kodlanmış uzantıdır. Kötü kodlanmış eklenti derken şunu kastediyorum: WordPress kod standartlarını umursamayan, global değişkenleri hoyrat kullanan, çıktıyı filtrelemeden basan, doğru hook’ları kullanmayan, adminde yüklemesi gereken script’i tüm sitede yükleyen, PHP sürüm uyumluluğunu doğru yönetmeyen eklenti. Böyle bir uzantı tek başına bile siteyi bozar. Yanına bir de “agresif optimizasyon” eklentisi geldi mi çatışma kaçınılmaz olur.

Üçüncü neden, bağımlılık kırılmasıdır. Modern eklentiler bazen bir kütüphaneye bağımlıdır. Güncelleme gelir, kütüphane sürümü değişir, başka eklenti aynı kütüphanenin eski sürümünü zorla yükler. Sonuç: sınıf bulunamadı, fonksiyon yok, beklenmeyen davranış. Bu, özellikle e-ticaret ve builder ekosisteminde sık çıkar.

Doğru sıra: Eklenti çakışmasını çözmenin sağlam protokolü

Bu bölümde “nasıl” kısmını keskin şekilde anlatacağım. Eklenti çakışması çözümü, rastgele eklenti kapatıp açma oyunu değildir. Doğru sıra, sana hem hız kazandırır hem de tekrar eden problemi kalıcı olarak bitirir.

Adım 1: Sorunu yeniden üret ve koşulu sabitle

Önce şunu netleştir: sorun her zaman mı oluyor, yoksa belirli koşullarda mı? Hangi URL’de, hangi kullanıcı rolünde, hangi cihazda, hangi tarayıcıda? Örneğin “sadece mobilde” diyorsan JavaScript tarafı daha şüpheli olur. “Sadece ödeme sayfasında” diyorsan checkout’a dokunan eklentiler şüpheli olur. “Sadece giriş yapınca” diyorsan session, rol, cache varyasyonu şüpheli olur.

Koşulu sabitlemeden “düzeldi” demek kendini kandırmaktır. Çünkü çatışmaların çoğu, sen test ederken görünmez. Bu yüzden her adımda aynı testi yapabileceğin bir senaryo kur.

Adım 2: Log okumadan karar verme

Şüpheyle değil, kanıtla ilerle. PHP fatal varsa bunu log söyler. JavaScript patlıyorsa konsol söyler. HTTP hatası varsa network sekmesi söyler. Log okumadan “kesin şudur” diye konuşan, eninde sonunda geri döner.

Güvenli debug ayarı:

<?php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Bu şekilde /wp-content/debug.log içine düşen hataları yakalarsın. Hata hangi eklenti dosyasını işaret ediyorsa, suçlu ya odur ya da o dosyayı tetikleyen başka bir eklentidir. İkisini ayırmak için sıradaki adımlar devreye girer.

Adım 3: Önce siteyi ayağa kaldır, sonra suçluyu bul

Site çöktüyse, önce hizmeti geri getirmen gerekir. Çünkü canlıda saatlerce test yapmak hem risk hem itibar kaybıdır. Bu aşamada amaç “mükemmel teşhis” değil, “siteyi açmak”tır. Site açıldıktan sonra suçluyu daha rahat yakalarsın.

En klasik ve etkili yöntem, eklentileri topluca devre dışı bırakmaktır. Admin açılmıyorsa bile dosya sisteminden bunu yapabilirsin.

SSH ile plugins klasörünü geçici kapatma:

mv wp-content/plugins wp-content/plugins.disabled

Site açıldıktan sonra geri al:

mv wp-content/plugins.disabled wp-content/plugins

WP-CLI varsa daha temiz:

wp plugin deactivate --all

Bu hamle, eklenti kaynaklı arızalarda çoğu zaman siteyi anında ayağa kaldırır. Ayağa kalkmadıysa tema veya çekirdek tarafı da işin içinde olabilir. Ama Eklenti çakışması konuşuyorsak, genelde bu adım seni rahatlatır.

Adım 4: İkili arama mantığıyla suçluyu bul

Asıl ustalık burada. “Tek tek aç” yaklaşımı çalışır ama 30 eklentide vakit kaybıdır. Daha akıllı yöntem, ikili arama mantığıdır. Eklentileri yarı yarıya açarsın. Sorun geri geldiyse suçlu o yarıda. Gelmediyse diğer yarıda. Bu şekilde birkaç turda suçlu gruba inersin. Sonra o grup içinde daha küçük parçalara bölerek net eklentiyi yakalarsın.

Bu yöntem, özellikle “yükleyince site bozuldu” senaryosunda altın değerindedir. Çünkü bazen yeni eklenti tek başına değil, mevcut bir eklentiyle birlikte patlar. İkili arama, kombinasyonları daha hızlı yakalamanı sağlar.

Adım 5: Aynı işi yapan eklentileri asla birlikte çalıştırma

Teşhis sırasında özellikle aynı işi yapan eklentilere dikkat edeceksin. İki cache, iki SEO, iki güvenlik, iki minify, iki image optimizer, iki redirect yöneticisi, iki form eklentisi bile bazen aynı endpoint’e basar. Bu bir “tercih” meselesi değil, teknik risk meselesidir. Aynı işi yapan eklentilerden birini seç, diğerini kaldır. Devre dışı bırakmak yetmez; sistemde durması bile bazen risk üretir.

Adım 6: Tarayıcı konsolu ve network ile JS/CSS çatışmasını yakala

Eklenti çakışmasının önemli bir kısmı, tarayıcı tarafında gerçekleşir. Özellikle builder ekosisteminde, slider eklentilerinde, pop-up eklentilerinde, cookie banner eklentilerinde ve optimizasyon eklentilerinde bu çok olur. Console’da “Uncaught TypeError”, “undefined is not a function”, “Cannot read properties of undefined” gibi hatalar görürsün. Network’te CSS/JS dosyalarının 404 veya 403 dönmesi, yanlış MIME type dönmesi gibi sorunlar görürsün. Bunlar sana doğrudan “hangi dosya yüklenememiş” veya “hangi script çakışmış” bilgisini verir.

Bu aşamada agresif optimizasyonu kapatıp test etmek şarttır. Çünkü minify ve merge işlemi dosya sırasını bozar. Eklenti çakışması zannedersin, aslında optimizasyon katmanı çatışmayı görünür hale getiriyordur. Teşhis için önce bu katmanı sadeleştir.

Adım 7: Staging yaklaşımı olmadan bu işi sürekli yaşarsın

Eklenti çakışması çoğu zaman “canlıda güncelleme” sonucu patlar. En sağlam yöntem, staging’de testtir. Önce staging’de eklentiyi kur, test et, sorun yoksa canlıya al. Staging yoksa, her yeni eklenti kurulumu bir kumardır. Bu, eski usul gibi görünse de hâlâ en doğru yöntem budur.

Çatışma türleri: PHP tarafı mı, veri tarafı mı, tarayıcı tarafı mı?

Eklenti çakışmasını daha hızlı çözmek için çatışmanın türünü doğru sınıflandırmak gerekir. Bu sınıflandırma, seni doğru loga ve doğru teste yönlendirir.

PHP fatal ve backend çatışması

Bu tipte genelde site açılmaz veya belirli admin ekranları patlar. debug.log ve sunucu error log burada esastır. Sinyaller net olur. Hangi dosyada, hangi satırda, hangi fonksiyon patladı görebilirsin. Bir eklentinin dosyası işaret ediliyorsa, o eklenti ya suçludur ya da başka bir eklenti onun beklediği şeyi bozuyordur.

Veri çatışması: veritabanı, option, meta ve autoload şişmesi

Bazı çatışmalar veritabanı düzeyindedir. İki eklenti aynı option anahtarını kullanır, aynı meta alanına müdahale eder, aynı transient’i yanlış yönetir. Özellikle “autoload” şişmesi burada çıkar. Bir eklenti autoload’a devasa veri basar, diğeri de her istekte onu okumaya kalkar. Sonuç: yavaş site, zaman aşımı, admin çökmesi. Bu bazen doğrudan “çatışma” diye adlandırılmaz ama pratikte iki eklentinin yanlış etkileşimidir.

Tarayıcı çatışması: JS global çakışması, kütüphane sürüm savaşı

Bu tipte site açılır ama davranış bozulur. Menü çalışmaz, buton çalışmaz, modal açılmaz, slider bozulur, responsive kırılır. Console hatası genelde vardır. Çözüm, hangi script’in çakıştığını bulmak ve bir tarafı devre dışı bırakmak veya istisna tanımlamaktır. Bazen de iki eklenti aynı kütüphaneyi iki farklı sürümle yüklediği için olur. Birinin güncellenmesi sorunu çözer, bazen de birini değiştirmek gerekir.

Acil müdahale: Site bozulduysa 15 dakikalık kurtarma planı

Şimdi daha pratik, saha odaklı bir plan veriyorum. Bu bölüm, kriz anında “siteyi aç” bölümü. Ama bu planın da bir sırası var. Sıra bozulursa daha çok dağıtırsın.

1) Bakım moduna al, ardından eklentileri kapat

Site çöktüyse önce zarar büyümesin. Ardından eklentileri kapat. WP-CLI varsa topluca kapatmak hızlıdır.

wp plugin deactivate --all

WP-CLI yoksa klasör yöntemi.

mv wp-content/plugins wp-content/plugins.disabled

2) Site açıldı mı kontrol et, sonra tek tek geri getir

Site açıldıysa eklenti kaynaklı olduğu kesinleşir. Şimdi eklentileri bir anda değil, kontrollü şekilde geri getir. Önce en kritik olanlar: güvenlik, e-ticaret, üyelik gibi. Ama aynı işi yapan ikiliyi asla birlikte açma. Örneğin iki cache eklentisini aynı anda açmak, tanıyı bulandırır.

3) Hata geri geldiği an logu yakala

Hata geri geldiği an debug.log dosyasını kontrol et. Çünkü hata anında en net iz çıkar. “Sonra bakarım” dersen, bir sonraki hamlede hata değişebilir, iz kayar.

4) Suçlu eklentiyi tespit et, rollback uygula

Suçlu eklentiyi bulduysan en hızlı çözüm bir önceki stabil sürüme dönmektir. WP-CLI ile belirli sürümü kurmak mümkündür.

wp plugin install eklenti-slug --version=1.2.3 --force

Bu bir “kalıcı” çözüm değildir, ama hizmeti geri getirir. Sonra staging’de yeni sürümü test edip uyumluluk çözülünce güncellersin.

Kalıcı çözüm: Eklenti çakışmasını bir daha yaşatmayan sistem kurmak

Şimdi işin en önemli kısmına geldik. Çatışmayı “bugünlük” çözmek kolaydır. Asıl mesele, bir daha aynı bataklığa girmemektir. Bunun yolu prosedürdür.

Kural 1: Eklenti envanteri ve rol tanımı

Her eklentinin sitede bir görevi olmalı. “Belki lazım olur” diye eklenti tutulmaz. Pasif eklenti bile dosya sisteminde duruyorsa risk üretir. Gereksiz eklentiyi kaldır. Bu sadece güvenlik değil, çatışma riski açısından da temel prensiptir. Eklenti sayısı arttıkça çatışma ihtimali geometrik artar. Bu bir gerçek.

Kural 2: Aynı işi yapan eklentilerden birini seç, diğerini kaldır

Cache için bir tane, SEO için bir tane, güvenlik için bir tane. “İkisi birlikte daha iyi olur” fikri WordPress’te çoğu zaman yanlıştır. Biri diğerinin ayağına basar. Sonra “gizli katil” devreye girer.

Kural 3: Güncelleme sırası ve staging zorunluluğu

Canlı sitede toplu güncelleme yapma. Önce staging’de güncelle, test et, sonra canlıya al. Kritik eklentileri (ödeme, üyelik, cache, güvenlik, builder) aynı anda güncelleme. Sırayla ilerle. Her güncellemeden sonra kritik akışları test et. Bu işin doğru yöntemi yıllardır böyledir ve hâlâ böyledir.

Kural 4: Çatışma çıktığında “istisna” ile değil “doğru mimari” ile çöz

Bazı kişiler her çatışmayı küçük hack’lerle çözmeye çalışır. Bir eklentiyi belirli sayfada kapat, diğerini başka sayfada aç, script’i dequeque et, override ile yamala. Bu bazen kısa vadede işe yarar, ama uzun vadede bakım kabusudur. Kalıcı çözüm genelde şudur: çatışan eklentilerden birini değiştirmek veya aynı işi yapanı kaldırmak. Net ve temiz çözüm budur.

Teşhis araçları: WP-CLI, debug.log ve kontrollü test

Bu bölümde sahada işe yarayan birkaç teknik aracı düzgün kullanma mantığını anlatacağım. Buradaki amaç “aracı çoğaltmak” değil, doğru aracı doğru yerde kullanmaktır.

WP-CLI ile aktif eklentileri hızlı görmek ve yönetmek

wp plugin list

Belirli bir eklentiyi kapatmak:

wp plugin deactivate eklenti-slug

Belirli bir eklentiyi açmak:

wp plugin activate eklenti-slug

Bu komutlar, özellikle admin açılmıyorsa hayat kurtarır. FTP ile uğraşmadan yönetirsin.

Güvenli debug ve script debug

Frontend çatışmalarında script dosyalarının minify edilmiş hali teşhisi zorlaştırır. Teşhis için script debug açmak bazen işe yarar.

<?php
define('SCRIPT_DEBUG', true);

Bu ayar, mümkün olan yerde minified yerine normal dosyaları yüklemeye yardım eder. Teşhis biter bitmez kapatmak daha doğrudur.

İleri seviye ama pratik: Kritik sayfalarda belirli eklentiyi devre dışı bırakma yaklaşımı

Bazen bir eklenti tüm sitede gerekli değildir. Örneğin ağır bir optimizasyon eklentisi ödeme sayfasında sorun çıkarıyordur. Kalıcı çözüm yine “tek eklenti” disiplinidir, ama bazı projelerde geçiş sürecinde belirli eklentiyi belirli sayfalarda devre dışı bırakmak gerekir. Bunu gelişi güzel değil, kontrollü şekilde yapmak gerekir.

Aşağıdaki örnek, eklenti filtresi ile belirli koşullarda eklenti yüklemeyi engelleme mantığını gösterir. Bu yaklaşım ileri seviye olduğu için ne yaptığını bilmeden kullanma. Ama doğru kullanıldığında kritik sayfayı korur.

<?php
/*
  Bu kodu bir mu-plugin olarak kullanmak daha temizdir:
  wp-content/mu-plugins/conditional-plugin-block.php
*/

add_filter('option_active_plugins', function ($plugins) {
    if (function_exists('is_checkout') && is_checkout()) {
        $block = array(
            'ornek-problemli-eklenti/ornek-problemli-eklenti.php',
        );

        foreach ($plugins as $i => $plugin) {
            if (in_array($plugin, $block, true)) {
                unset($plugins[$i]);
            }
        }

        $plugins = array_values($plugins);
    }

    return $plugins;
}, 20);

Bu yaklaşım, ödeme sayfasında problem çıkaran bir eklentiyi geçici olarak devre dışı bırakabilir. Ama tekrar ediyorum: bu “kalıcı mimari” yerine geçmez. Kalıcı çözüm, çatışan eklentiyi doğru alternatifle değiştirmektir.

En sık çatışma senaryoları: Nerede aramalısın?

Bu bölümde “hangi kombinasyonlar en çok patlar” sorusunun pratik cevabını vereceğim. Liste formatında madde kullanmadan, net örneklerle anlatıyorum.

Cache + cache

İki cache eklentisi aynı anda çalıştığında çıktı tamponlama, sayfa cache yazma, minify ve geciktirme katmanları üst üste biner. Biri diğerinin ürettiği cache dosyasını yanlış yorumlar. Dinamik sayfalar (sepet, ödeme, hesap) yanlış cache’lenir. Sonuç bazen “site bozuldu” değil, “bazen bozuluyor” olur. Bu en sinsi tiptir. Çözüm nettir: tek cache sistemi, doğru istisnalar.

SEO + SEO

İki SEO eklentisi aynı anda title/meta yönetmeye çalışır. Canonical çakışır, robots meta farklı çıkar, sitemap iki farklı şekilde üretilir. Bazen görünürde sorun yoktur ama arama motoru tarafında karışıklık olur. Bazen de adminde meta kutuları üst üste biner ve edit ekranı bozulur. Çözüm: tek SEO eklentisi, tek kaynak.

Güvenlik + güvenlik

İki güvenlik eklentisi aynı isteği farklı şekilde filtreler. Birisi REST isteklerini kısar, diğeri AJAX çağrılarını şüpheli görür. Sonuç: form gitmez, medya yüklenmez, editor kaydetmez. Kullanıcı “WordPress mail göndermiyor” der, aslında güvenlik eklentisi admin-ajax’i kesiyordur. Çözüm: tek güvenlik sistemi, WAF ve eklenti görevleri net ayrılmış olmalı.

Builder + tema + optimizasyon üçgeni

Builder eklentisi kendi CSS/JS düzenini kurar. Tema kendi framework’ünü getirir. Optimizasyon eklentisi dosyaları birleştirir ve geciktirir. Üçü bir araya geldiğinde “responsive bozuk”, “CSS kırıldı”, “buton çalışmıyor” şikâyeti doğar. Çözüm: birleştirme ve geciktirme agresifse yumuşat, builder uyumlu tema kullan, gereksiz framework’leri azalt.

WooCommerce ekosistemi: ödeme, kargo, kupon, fiyat

WooCommerce üzerinde çok eklenti çalışıyorsa çatışma ihtimali ciddi yükselir. Ödeme eklentisi, kargo eklentisi, kupon eklentisi, dinamik fiyat, çoklu para birimi, fatura entegrasyonu. Bunların her biri checkout’a dokunur. Birinin alan isimlerini değiştirmesi diğerinin doğrulamasını bozar. Sonuç: ödeme başarısız, checkout error, sepet boşalıyor gibi pahalı belirtiler. Burada prosedür şart: kritik eklentileri tek tek devreye alıp test etmek.

Kalite kontrol: Eklenti kurmadan önce sorman gereken sorular

Eklenti çakışmasını azaltmanın en ucuz yolu, çatışmayı daha doğmadan engellemektir. Bunun için eklenti kurmadan önce birkaç basit ama sert soru soracaksın.

Birinci soru: Bu eklenti gerçekten gerekli mi? Aynı işi yapan bir eklentim var mı?

İkinci soru: Bu eklenti düzenli güncelleme alıyor mu? Uzun süredir güncellenmiyorsa uzak dur.

Üçüncü soru: Bu eklenti kritik akışlara dokunuyor mu? Dokunuyorsa staging’de test etmeden canlıya alma.

Dördüncü soru: Bu eklenti siteye gereksiz yük bindiriyor mu? Her sayfada script basıyorsa risk artar.

Beşinci soru: Bu eklentinin kaldırılması kolay mı? Bazı eklentiler veritabanını şişirir, kaldırınca iz bırakır.

Bu soruları sormadan eklenti kurmak, çatışma riskini bilinçli olarak büyütmektir.

Operasyonel disiplin: Eklenti çakışmasını bitiren rutin

Bu işi kalıcı olarak düzene sokmak için basit bir rutin kuracaksın. Bu rutin, yıllardır değişmeyen “doğru iş yapma” biçimidir. Modern araçlar değişir, prensip değişmez.

Her yeni eklenti kurulumunda önce staging’de kur, sonra aynı test senaryosunu çalıştır.

Kritik eklentileri aynı gün topluca güncelleme. Sırayla güncelle, her adımda test et.

Gereksiz eklentiyi kapatma, kaldır. Kapalı tutmak temizlik değildir.

Bir iş için bir eklenti kuralını uygula. Aynı işi iki eklentiye paylaştırma.

Log okuma alışkanlığını rutin hale getir. Sorun çıktığında değil, sorun çıkmadan iz bırak.

Bu rutin oturursa, “eklenti çakışması” artık bir kriz olmaktan çıkar, yönetilebilir bir olay olur.

Tek sayfada uygulama sırası: Eklenti çakışması çözüm protokolü

1) Sorunu koşuluyla birlikte yeniden üret ve sabitle.

2) Debug logu aç, ekrana basmadan loga yazdır.

3) Site çöktüyse eklentileri topluca devre dışı bırakıp siteyi ayağa kaldır.

4) Eklentileri ikili arama mantığıyla geri aç, suçlu grubu daralt.

5) Aynı işi yapan eklentilerden birini seç, diğerini kaldır.

6) Tarayıcı console ve network ile JS/CSS çakışmasını doğrula.

7) Suçlu eklenti bulununca rollback veya alternatif eklenti ile kalıcı çöz.

8) Staging ve güncelleme sırası prosedürünü kalıcı hale getir.

Bu sıra ile ilerlersen Eklenti çakışması artık “gizli katil” olmaktan çıkar. Kontrol sende olur. Aksi halde her yeni eklenti kurulumunda aynı filmi tekrar izlersin.

Bu makale bilerek sert ve nettir. WordPress’te Eklenti çakışması, duygusal yorumla değil, disiplinle yönetilir. Doğru prosedürü uygula, gerisi zaten gelir.