WordPress VIP Sandbox’ın Bir Ajansa Öğrettiği Dört Şey

Bir platformun satış sunumunda yaptığı ile çalışan bir repoda yaptığı arasındaki fark, ajansın niye var olduğunun bütün cevabıdır. Birinin oturup test yapılandırmasını kurması, kenar davranışlarını zorlaması, dokümantasyonun atladığı yerleri yazması gerekir. Bir kurumun ileri yıllarını üstüne bina edeceği bir WordPress kararını veriyorsan, soru şu değil: ajansın bu platformun adını duymuş mu? Soru şu: platformla, direndiği yerleri bulacak kadar oturmuş mu?

Bu yaz ekibimizi bir WordPress VIP ajans ortaklık başvurusundan geçirdim. Amaç bir temayı deploy ettiğimi kanıtlamak değildi, onu bir GitHub hesabı olan herkes yapar. Amaç, ancak sandbox’ı gerçekten çalıştırınca öğrendiğimiz şeyleri bulup kayda almaktı: dokümantasyonun açık okumasıyla çelişen varsayılanlar, hoş geldin turunun bir adım dışında riske dönüşen kolaylıklar, bir platform özelliğinin birinci günden kurduğumuz koca bir eklenti kategorisini emekliye ayırdığı yerler.

Bu bulguların dördü yazıya değer, çünkü her biri bir alıcıya sözleşme öncesi söylediğimiz şeyi değiştiriyor. Hiçbiri satış materyallerinde yok, çoğu da kamuya açık dokümanlarda bizim karşılaştığımız biçimiyle durmuyor.

Platform neyi değiştiremeyeceğine kendisi karar veriyor, hem de erken

İlk denememiz dümdüzdü: bir sandbox hazırla, kendi temamızı deploy et, içeriği içeri taşı. Hepsi yürüdü, GitHub’dan production ortamına ilk deploy kırk sekiz saniyede bitti. Bir kurumsal içerik yayınını WAF, CDN ve bir cache katmanının içinden geçirmiş biriysen, kırk sekiz saniye akılda kalan bir cümle oluyor.

Daha az beklediğim şey, bu kolaylığın altındaki yapısal katılıktı. Bu sandbox uygulamasını repo içinden multisite ağına çevirmenin mümkün olup olmadığını kanıtlamak istedim, çünkü yönetilen hostingde bize tanıdık gelen desen bu. Standart WP_ALLOW_MULTISITE sabitini VIP yapılandırma dosyasına ekledim, production dalına push ettim, deploy’un bittiğini bekledim, sabitin yerinde olduğunu doğruladım, wp-admin/network.php‘yi açtım. Ekran bizi geri çevirdi ve sabitin tanımlı olmadığını söyledi.

Sabit tanımlıydı. Olan şu: VIP’in kendi platform kodu bu sabiti bizim yapılandırma dosyamız okunmadan önce kendisi tanımlıyor, bizimki hiçbir şey yapmayan bir satıra dönüşüyor. Dokümantasyon bunu, dönüşüm için VIP Destek ile iletişime geçin diyerek üstü kapalı söylüyor. Pratikte bu satır bir nezaket gibi okunuyor. Sandbox’ta ise sert bir ray gibi davranıyor: uygulama tipi provizyon anında sabitleniyor ve tek siteli bir uygulamayı multisite’a çevirmek, vip-config dosyası ne derse desin, müşterinin kendi başına yapamayacağı bir platform operasyonu.

Alıcı tarafı için bu bilgi iki yönlü işe yarıyor. Katılık, platformun savunulabilir olmasının sebebi: ekibinin ya da bir satıcının yanlışlıkla yapamayacağı bir değişiklik sınıfı var. Aynı katılık, tek site ile multisite ağ kararının uygulama provizyon edilmeden önce, usulüne göre, alınması gerektiğinin de sebebi. Düğmeye basmayı hiç denememiş bir ajans, denemenin bu sorunun yerleştiği son yer olduğunu bilmiyor olabilir.

Özel alan adı bağlandığı an sandbox’ın kendi koruması sessizce kalkıyor

Yazıya girmeyi beklemediğim bulgu bu, çünkü bir yapılandırma detayı gibi görünüyor ve gerçek bir risk olarak çıkıyor. Her VIP uygulaması hayatına bir go-vip.net ana makine adı üzerinde başlıyor. O ana makinede platform otomatik olarak robots.txt‘de Disallow: / yayınlıyor ve X-Robots-Tag: noindex, nofollow başlığını ekliyor. Bir sandbox’tan tam da beklediğin davranış, ve sessizce çok iş görüyor.

Uygulamaya kendi özel alan adını bağladığın an, ki launch sihirbazı bunu ilk davet ettiği şeylerden biri, o otomatik koruma duruyor. Özel ana makine artık sitenin kendi robots.txt‘sini sunuyor, enjekte edilen başlık yok, ve yirmi dakika önce Google için görünmez olan sandbox şimdi senin alan adının altında tamamen taranabilir durumda. Sandbox’ımızda bunu bakarak keşfettik: go-vip.net ana makinesi doğru sinyalleri dönüyordu, bizim özel ana makinemiz hiçbirini dönmüyordu, ve test için içeri alınmış içerik, bir müşterinin arama sonuçlarında görmekten mutlu olmayacağı türdendi.

Düzeltme veritabanında tek satır (blog_public‘i 0‘a çek, edge cache purge et), ve asıl ders düzeltme değil. Asıl ders şu: tek tıkla özel alan adı kolaylığı, güvendiğin bir korumayı sana haber vermeden kapatıyor. Bunu VIP’teki irtibatımıza, bayrak dikilmesi gereken kısa bir davranış listesinin bir kalemi olarak ilettik. Platformdaki Node uygulamaları aynı boşluğu biraz farklı bir şekilde taşıyor, yani ayrışık bir ön yüzde soru tersinden geliyor: başlıkları kim ekliyor? Bir ajansın platform ustalığını değerlendiren bir alıcı için bu, sormadan gündeme gelmesi gereken türde bir mevzu, çünkü bir sandbox’ın Google’a düşmesinden toparlanma hoş olmuyor ve güven bedeli kalıcı.

Yerleşik görsel servisi, yerine koyduğu eklentilerin çoğundan daha değerli

Üçüncü bulgu, arkasında gerçek sayı olan bulgu, çünkü bilerek yürüttüğüm bir testti. VIP, medyayı tek bir eklenti dahi gerektirmeden dönüştürüp sunan yerleşik bir görsel servisiyle geliyor, ve alıştığım üçüncü parti yığını önermeyi bırakmadan önce bunun gerçekten neye değdiğini bilmek istedim. VIP dokümantasyonu düz bir cümleyle söylüyor: “bütün görseller otomatik olarak dönüştürülüp, uyumlu tarayıcılara .webp dahil yeni nesil formatlarda sunulur.” Doğru iddia, ve gerçek dosyalara karşı test etmeye değer.

Sandbox’a temsili bir görsel setinin yüklemesini yaptık: bir broşür görseli, iki arayüz render’ı, bir stok portre. Bunlar gerçek bir editöryal akışta gördüğün boyutlar, eklenti kıyaslamalarının kullandığı budanmış küçük görseller değil. Modern bir tarayıcının Accept: image/webp başlığı ile belirli dosyalarda ölçtüğümüz sonuçlar:

• 4.101 KB’lık bir broşür görseli 740 KB WebP olarak sunuldu, yaklaşık yüzde 82 azalma.
• 3.671 KB’lık bir arayüz render’ı 843 KB olarak sunuldu, yaklaşık yüzde 77.
• 2.831 KB’lık bir ürün ekranı 325 KB olarak sunuldu, yaklaşık yüzde 89.

Önemli bir çekincesi var. Çok büyük orijinaller kendi URL’lerinde dokunulmadan geçiriliyor, yani 4,95 MB’lık bir kamera dosyası tam boyutta istenirse 4,95 MB JPEG kalıyor. Dönüşüm, URL’de bir genişlik parametresi görür görmez devreye giriyor, zaten WordPress’in srcset ürettiği yol da bu. Normal tema çıktısında ziyaretçinin vurduğu yol tam burası, bu yüzden yukarıdaki ölçüm gerçek senaryoyu adil yansıtıyor.

Ticari karşılığı: koca bir görsel optimizasyon eklenti şeridi, birinci günden yığından çıkıyor. Önceden Smush, Optimole veya ShortPixel taşıyan, bunların ücretli katmanlarının maliyetini herhangi bir ciddi görsel hacminde cebine yazan bir build’de, bu iş artık bir platform özelliği. Binlerce ürün fotoğrafı taşıyan bir markanın tarafında bu küçük bir kazanç değil: faturadan bir satıcı eksik, güncellenecek bir eklenti eksik, performans olayında değişken sayısı bir azalmış demek.

“Kutudan çıktığı gibi çalışan” entegrasyon, kimsenin söylemediği bir ayara bağlı

Son bulgu, ajansı üçüncü ayda yakalaması en muhtemel olan: hata gibi görünüyor, aslında bağımlılık. VIP, platformu ve WordPress sitesini yapay zekâ ajanlarına tek bir denetlenebilir uç nokta üzerinden açan Secure MCP entegrasyonuyla geliyor. Dokümantasyon iki araç setini listeliyor, biri platform işlemleri biri site içeriği için, ve yetkilendirme çoğu kurumsal MCP uygulamasından daha temiz: tek satır istemci kaydı, standartlara uyan OAuth, elle çevrilecek istemci sırrı yok.

İki araç setini de açtık, bir ajanı sandbox’ımıza karşı yetkilendirdik, platform araç seti hemen çalıştı. WordPress araç seti bağlanmayı reddetti, hata belirsiz biçimde WordPress MCP sunucusunu işaret ediyordu. Üç deneme, aynı sonuç, görünen bir sebep yok. Sitedeki REST indeksi WordPress MCP ad alanının kayıtlı olduğunu doğruluyordu. Rota oradaydı. İstek, HTML’ye bir yönlendirme döndürüyordu.

Site, varsayılan “Plain” kalıcı bağlantı yapısıyla çalışıyordu, bu da /wp-json/ yolunun arkasında bir URL yeniden yazması olmadığı ve WordPress’in API yerine ana sayfayı döndürdüğü anlamına geliyor. Herhangi bir pretty permalink yapısına geç, cache’i purge et, WordPress araç seti bağlanıyor. Secure MCP kurulum talimatlarında bu geçmiyor, çünkü gerçek her WordPress kurulumunda pretty permalinks açık, kimse neredeyse hiç açık bırakılmayan bir varsayılana bağımlılığı yazmayı akıl etmiyor. Sandbox’ta, varsayılanların açık bırakıldığı yerde, izole etmek bir saat sürdü.

İzlemeye değer asıl desen şu: yapay zekâ entegrasyonları belirli bir WordPress kurulum şekli varsayıyor, ve o şekil sarsıldığı anda “çalışmıyor” diyorlar, “bu sitede X eksik” demiyorlar. Ajansın işi, bu varsayımları Cuma öğleden sonra bir müşteri biletine düşmeden önce görmek.

Gerçek bir build’de ne demek, ve brief’e ne yazılır

Yukarıdaki dört bulgunun hiçbiri tek başına bir karar vermez. Bir arada, değerlendirmeyi yapan ajansın gerçekte nasıl çalıştığını, ve bir WordPress VIP ajansına ya da benzer bir yönetilen kurumsal platform ortağına imza atmadan önce brief’te görmen gereken şeyi anlatıyor. Bir WordPress veya WooCommerce kurulumunda bu, dört ayrı yere düşüyor.

Multisite bulgusu, keşif fazının şeklini değiştiriyor. Bir kurum iki ülke sitesi işletiyor ve seneye bir üçüncüyü eklemeyi düşünüyorsa, bu karar uygulama provizyon edilmeden önce alınır, ilk launch’tan sonra değil. Brief’te ajansın önümüzdeki yirmi dört ayda uygulama haritasının ne olacağını yazılı söylemesi istenmeli, ve her birinin ne olduğu. Bedeli proje açılışında bir konuşma; yanlış yapmanın bedeli bir replatform.

Özel alan adı dizinlenme boşluğu küçük ve pahalı. Gerçek bir build’de bu, cutover’da tek bir kontrol listesi maddesi: production olmayan ortama bir özel ana makine bağlanmadan önce, sitenin Ayarlar’da halka açık olmadığından emin ol, ve platformun kendisinin kapsamadığı herhangi bir ön yüz servisi için başlıkların edge’de ayarlandığından emin ol. Node runtime üzerindeki bir ayrışık ticaret ön yüzü için o başlık, deploy yapılandırmanın içinde olmak zorunda, backend’den varsayılamaz. Yirmi dakikalık bir ön hazırlık; alternatifi, bir staging ortamının Google’ın cache’inde ne işi olduğunu bir hukuk ekibine anlatmak.

Görsel CDN bulgusu, sayıya dökmesi en kolay olan. Binlerce ürün görseli taşıyan bir WooCommerce katalog build’inde satıcı bütçesinden çıkarılacak doğru satır, herhangi bir üçüncü parti görsel optimizasyon servisi, tabii ki seçtiğin platformda yerleşik karşılığı varsa. Kazanç sadece lisans ücreti değil: güncellemede kırılabilecek bir eklenti eksik, yönetilecek bir kimlik seti eksik, performans olayında bir değişken daha az.

MCP bulgusu önümüzdeki on iki ayda en çok konuşulacak olanı, ve ajan trafiği kabul etmeye niyetli her WordPress kurulumunda zaten geçerli. Pratik istek sade: production ana makinenin /wp-json/‘u 200 yanıt ve JSON içerik tipiyle sunduğunu doğrula, pretty permalinks’in açık olduğunu doğrula, edge cache’in entegrasyonun güvendiği sinyalleri soyup almadığını doğrula. Ajana hazır WordPress’in geri kalanı bu üç kontrolün üzerine oturuyor, biz de bunları WordPress VIP ajans işimizin standart launch öncesi kontrol listesine koyduk.

Ajans konuşmasında nereye otururum

Bir WordPress VIP build’ini yürütecek ajansı seçmek, dışarıdan sorgulanması zor yüzeylere karşı verilen bir karardır. Sunum platformun ne yaptığını söyler. Satın alma ekibi aynı dokümantasyonu okuyabilir. Bulması daha zor olan, ve uzun bir angajmanda en kıymetli olan şey, ajansın platformun kendi kenarlarından geçip sana daha kısa bir sürpriz listesiyle dönüp dönmediğidir.

Alıcı tarafında olsam, her şeyden önce bir soru sorardım. Bu platformda son yapmaya çalıştığın ve platformun izin vermediği şey neydi, ondan ne öğrendin? Sandbox’ı dürüst yapmış ajans buna tek cümlede, somut bir örnekle cevap verir. Yapmamış olan, broşüre uzanır. Burada anlattığım türde saha çalışmasının bütün değeri, bir sonraki müşteri sorduğunda o tek cümlelik cevabı tekrar tekrar üretebilmesidir. Bu konuşmayı sürdürmek istersen, bizi tr-tr.thewpclan.com/wordpress-vip-ajansi adresinde bulursun.