WordPress'te Profesyonelliğe Giden Yol: Yıllarca Çıkardığımız Dersler

Bugüne kadar sayısını unutacağımız kadar çok WordPress tabanlı site geliştirdik; bir o kadarını da başka firmaların geliştirdiği işleri devraldık. Bu süreçte WordPress’e dair birikimimiz ve gözlemimiz katlanarak arttı: neyi yapmak gerektiğini, neyden uzak durmak gerektiğini tek tek deneyerek öğrendik.

Aşağıdaki notları, WordPress tabanlı site işine yeni başlayanlarla paylaşmak istedik. Hepsi sahadan, gerçek projelerden çıkmış pratiklerdir.

1. Tema seçimi: sizi rezil de eder, vezir de

Piyasada “her şeyi yapan” kapsamlı temalar var. Bunlardan birini tercih ettiğinizde, aslında WordPress kullanmaktan çok o temanın kendi kurallarını kullanmaya başlarsınız. Tema kötü kodlanmışsa siteniz yavaşlar ve ne yaparsanız yapın tam bir çözüm bulamazsınız. Ya da tema, ayarlarını o kadar kendine özgü bir mantığa oturtur ki, yılların WordPress kullanıcısı olsanız bile “bu değişiklik hangi menüden, nasıl yapılıyor?” diye saatlerce uğraşırsınız.

Yani tema seçimi göründüğünden çok daha kritik bir karardır. Biz genelde Astra tarzı sade bir tema seçip onu kendimiz şekillendirmeyi tercih ediyoruz. Evet, bu yaklaşım kodlama tarafında daha fazla emek ister; ama karşılığında size çok daha fazla hâkimiyet ve çok daha temiz bir sonuç verir.

2. Mutlaka child tema kullanın

Bugüne kadar devraldığımız işlerin neredeyse hiçbirinde child tema kullanıldığını görmedik. Oysa WordPress’te uzmanlaşmanın en temel adımlarından biri budur.

Senaryoyu düşünün: Sitede bir değişiklik gerekiyor, ana temanın header.php veya footer.php dosyasına iki satırlık bir müdahale yapıyorsunuz. Ne kadar basit, değil mi? Peki altı ay sonra o temanın yeni bir sürümü çıktığında ne olacak?

• Neyi nerede değiştirdiğinizi not aldınız mı?
• Güncel temayı eskisinin üzerine yazarsanız, yaptığınız tüm değişiklikler uçar.
• Güncellemeyi yapmazsanız, güvenlik açığıyla baş başa kalırsınız.
• Diyelim ki her şeyi titizce not aldınız, bu sefer de aynı değişiklikleri tek tek yeniden yapma zahmeti sizi bekler.

Oysa WordPress bu sorunu yıllar önce çözmüş durumda.* Ana tema üzerinde yapacağınız tüm override’ları child tema üzerinde uygularsanız, güncellemeler değişikliklerinize hiç dokunmaz. Olsun, bitsin.

İnsan olarak unutkanlıkla malulüz; üstelik altı ay sonra kendi yazdığımız koda bile yabancılaşıyoruz. Bu yüzden child temada yaptığınız her değişikliği iyi dokümante edin. Yorum satırları tam da bunun için var.

* Child tema desteği WordPress 2.7 ile (Aralık 2008) geldi. Yani bu, yeni bir özellik değil, onlarca yıllık, kanıtlanmış bir pratik.

3. Eklentiler: less is more

Siteye eklenen her satır kod, aslında bir teknik borçtur (technical debt). Bu yüzden “siteye olabildiğince az kod eklemek” temel ilke olmalıdır.

Her işi yapan kapsamlı eklentiler çoğu zaman çekici görünür; ama çoğu durumda tam tersine, sade ve tek işe odaklı olanları tercih etmek çok daha sağlıklıdır. Hatta mümkünse eklenti hiç kullanmayıp, ihtiyacınız olan işi functions.php içine eklenecek kısa kodlarla çözmek en temiz yoldur.

Örneğin şu işler için koca bir eklenti kurmaya gerek yok; birkaç satır kod fazlasıyla yeter:

• Sayfaya “yukarı çık” butonu eklemek,
• body etiketine duruma göre özel bir CSS sınıfı eklemek,
• Kullanmadığınız WordPress emoji ve embed script’lerini kapatıp sayfayı hafifletmek,
• Yönetim panelindeki gereksiz menüleri veya widget’ları gizlemek.

Her biri için ayrı bir eklenti, beraberinde kendi güncellemelerini, olası uyumsuzluklarını ve güvenlik yüzeyini getirir. Oysa aynı işi yapan küçük bir kod parçası, tamamen sizin kontrolünüzdedir.

4. functions.php’yi düzenli kullanın

Her yiğidin yoğurt yiyişi farklıdır; bizim usulümüz şöyle. Child temanın functions.php dosyasını bir “her şeyin tıkıştırıldığı karmaşa” değil, bir içindekiler listesi gibi kullanıyoruz:

<?php
// xyz işini yapan kod
include '01-xyz-isini-yapan-kod.php';

// abc işini yapan kod
include '02-abc-isini-yapan-kod.php';

// qwe işini yapan kod
include '03-qwe-isini-yapan-kod.php';

Her işlevi ayrı, numaralandırılmış bir dosyaya bölmek; kodu okunabilir, bakımı kolay ve sorun çıktığında tek tek devre dışı bırakılabilir hale getirir.

Bir adım ötesi: bu child tema klasörünü bir Git reposu olarak takip edin. Böylece hangi değişikliği ne zaman ve neden yaptığınız kayıt altında kalır; geri almak da, ekipçe çalışmak da çok kolaylaşır.

5. İçerik modelleme: Custom Post Type, ACF, Meta Box, Pods

Peki nedir bu araçlar? ACF (Advanced Custom Fields), Meta Box, Pods ve benzerleri; WordPress’in standart “yazı” ve “sayfa” kalıplarının ötesine geçip kendi içerik tiplerinizi ve bunlara ait özel alanları (custom fields) tanımlamanızı sağlayan eklentilerdir. Topluca bunlara içerik modelleme ya da özel alan araçları diyebiliriz. Üçü de aynı işi farklı yaklaşımlarla yapar; hangisini seçeceğiniz projeye ve alışkanlığınıza kalmış, birini diğerine üstün kılan tek bir doğru cevap yoktur.

Bu araçları kullanmaya başladığınız an, WordPress ile ilişkinizin profesyonel seviyeye çıktığını gösterir. Artık WordPress’i hazır bir bloga sıkışmış bir araç olarak değil, oyun hamuru gibi istediğiniz şekle sokabildiğiniz esnek bir altyapı olarak kullanıyorsunuz demektir.

Özel içerik tipleri ve özel alanlar sayesinde içeriğinizi kendi veri modelinize göre yapılandırır; editörlere dağınık bir metin kutusu yerine, net ve hatasız bir giriş deneyimi sunarsınız.

Somut bir örnek verelim: bir emlak sitesindeki “ilan”ı, bir etkinlik sitesindeki “etkinlik”i ya da kurumsal bir sitedeki “referans”ı; standart yazı veya sayfaya tıka basa sığdırmak yerine, kendi alanlarıyla (fiyat, konum, tarih, harita…) ayrı bir içerik tipi olarak tanımlarsınız. Üstelik bu araçların sunduğu ilişki alanları (relationship fields) sayesinde tipleri birbirine bağlayabilirsiniz; örneğin bir “proje” kaydını ilgili “müşteri” ve “hizmet” kayıtlarıyla ilişkilendirebilirsiniz. Böylece içerik, dağınık bir metin yığını olmaktan çıkıp üzerine güvenle site kurabileceğiniz tutarlı bir veriye dönüşür.

Bu yaklaşımın gerçek bir örneğini merak ederseniz: şair Behçet Necatigil’in binlerce belgelik dijital arşivini, tam da bu yöntemle (ACF ve projeye özel kodlamayla) kendi veri modeline oturttuk. Nasıl kurguladığımızı Necatigil’in Odası başarı hikâyemizde okuyabilirsiniz.

6. Headless: WordPress’i sadece “motor” olarak kullanın

Kafamıza kazınmış bir varsayım var: WordPress kurduk mu, siteyi de onun temasıyla, onun kurallarıyla yayınlamak zorundayız sanıyoruz. Oysa hiç de öyle değil.

WordPress’i kafanızda ikiye ayırın: içeriğin girildiği, yönetildiği arka taraf (backend) ve ziyaretçinin gördüğü ön taraf (frontend). Editörler yıllardır alıştıkları o pratik panelde içeriğini girmeye devam etsin; ama o içeriği ziyaretçiye sunan ön yüzü, tamamen kendi seçtiğiniz bir teknolojiyle yazın. İşte buna headless (başsız) kullanım deniyor.

Peki frontend’i neyle yazarsınız? Tamamen size kalmış: Next.js, Laravel, .NET, hatta sade bir statik site üreteci… WordPress, içeriği size REST API veya GraphQL üzerinden veri olarak teslim eder; gerisi sizin dünyanız. Üstelik Bölüm 5’te konuştuğumuz gibi içeriğinizi düzgün bir veri modeline oturttuysanız, headless’a geçiş de bir o kadar kolaylaşır.

Peki bunun nesi güzel?

• Editörler için hiçbir şey değişmez; sevdikleri, bildikleri panel olduğu yerde durur.
• Frontend tarafında temanın kısıtlarından, ağır eklenti yığınından ve “bu ayar hangi menüde” derdinden tamamen kurtulursunuz.
• Performans, güvenlik ve tasarım üzerinde tam hakimiyet sizdedir. Bu yazı boyunca anlattığımız “hakimiyet” meselesinin zirvesi diyebiliriz.

Tabii her güzel şeyin bir bedeli var. Headless kurulum, klasik bir WordPress sitesine göre daha fazla emek ve geliştirici ister; hazır temaların ve frontend eklentilerinin kolaylığından da vazgeçersiniz. Yani her projenin harcı değil. Ama içeriğin yoğun, trafiğin yüksek ya da arayüz beklentisinin “sıra dışı” olduğu projelerde; WordPress’in olgun içerik yönetimini modern bir frontend’in hız ve esnekliğiyle birleştirmek, çoğu zaman en akıllıca yol oluyor.

7. Güvenlik ve güncelleme: az kod, az risk

Buraya kadar saydığımız her ilke aslında güvenliğe de hizmet eder. WordPress dünyasında saldırıların büyük çoğunluğu, güncellenmemiş çekirdek ve eklentilerdeki bilinen açıklardan gelir. Bu yüzden:

• Çekirdeği ve eklentileri düzenli güncelleyin. Burada kritik olan “düzenli” kelimesidir. Güncellemeleri belirli aralıklarla yapmaz, biriktirirseniz, bir süre sonra güncellemeye korkar hale gelirsiniz. Çekirdek, tema ve eklentilerde aynı anda devasa sürüm sıçramaları yapmak; “kesin bir şeyler arıza verecek” dedirten, riskli bir işe dönüşür. Oysa küçük adımlarla ilerleyen düzenli bir yedekle-güncelle döngüsü, her güncellemeyi zararsız bir rutine çevirir. Child tema sayesinde de bunu, yaptığınız özelleştirmeleri kaybetme korkusu olmadan rahatça yapabilirsiniz.
• Az eklenti, az saldırı yüzeyi demektir. “less is more” ilkesi sadece performans değil, güvenlik için de geçerlidir.
• Düzenli yedek alın ve yedeği zaman zaman geri yükleyerek çalıştığından emin olun.
• Değişiklikleri önce yerel veya staging ortamda deneyin; doğrudan canlı sitede düzenleme yapmaktan kaçının.

Bu konuyu daha derinlemesine ele aldığımız Kurumsal Web Sitesi Bakımı Neden Şart? yazımıza da göz atabilirsiniz.

Devraldığımız bir siteye önce neye bakarız?

Başka bir firmanın geliştirdiği bir siteyi devraldığımızda, koda dalmadan önce hızlı bir sağlık kontrolü yaparız. Genellikle ilk baktığımız şeyler şunlardır:

• Child tema var mı? Yoksa, değişiklikler doğrudan ana temaya yapılmış demektir; güncelleme riskini en baştan değerlendiririz.
• Kaç eklenti yüklü ve hangileri gerçekten kullanılıyor? Çoğu sitede yıllar içinde birikmiş, artık işlevsiz ama hâlâ yük getiren eklentiler buluruz.
• Çekirdek, tema ve eklentiler güncel mi? Birikmiş güncellemeler, çoğu zaman devraldığımız sitenin en acil sorunudur.
• Özelleştirmeler nasıl ve nereye yazılmış? functions.php mi şişmiş, yoksa kod düzenli dosyalara mı bölünmüş; bu, devralma sürecinin ne kadar zorlu geçeceğini gösterir.

Sonuç

WordPress’i profesyonelce kullanmak; sade bir tema seçmek, child tema ile güvenli çalışmak, eklenti bağımlılığını en aza indirmek, kodu düzenli tutmak, özel veri yapılarını doğru kurmak ve gerektiğinde headless gibi farklı mimarilere açık olmaktan geçer. Bunların hiçbiri sihirli bir kısayol değil; ama hepsi, yıllar içinde defalarca işe yaradığını gördüğümüz disiplinlerdir.

WordPress tabanlı bir projede takıldığınız bir konu mu var, yoksa mevcut bir siteyi daha sağlam bir temele mi taşımak istiyorsunuz? Bizimle iletişime geçin.