WordPress Multisite’de ACF Pro ve Öğrenme Yönetim Sistemi Kurulumu

WordPress Multisite ortamında çalışan bir proje, beklenmedik bir veritabanı mimarisi sorunuyla karşılaştığında, aslında kodlama değil stratejiyle ilgili bir dersle karşı karşıya kalmış olabilirsiniz. eCoach adlı bir projede, müşterinin gereksinimlerini karşılamak için Advanced Custom Fields (ACF) Pro’nun Özel Tablolar özelliğini kullanmak zorunda kaldık. Ancak, projenin temelinde yatan "öğrenme verilerinin ağ düzeyinde paylaşılması" gereği, varsayılan WordPress Multisite yapısının ötesine geçmemizi gerektirdi.

Proje, farklı web sitelerinin aynı öğrenme verilerini kullanmasını gerektiren bir öğrenci yönetim sistemiydi. Oysa ACF Pro’nun varsayılan davranışı, her siteye özel tablo oluşturmak üzerine kuruludur — örneğin, wp_1_learner ve wp_2_learner gibi. Oysa bizim ihtiyacımız, tüm sitelerin aynı veriye erişebildiği tek bir wp_learner tablosuydu.

Verinin Sahipliği: WordPress Multisite’nin Temel Sorusu

WordPress Multisite projelerinde karşılaşılan en kritik soru, "Hangi tablo adı kullanılmalı?" değil, "Bu veriyi kim sahipleniyor?" olmalıdır. Veri, tek bir siteye mi ait, yoksa tüm ağa mı ait? Bu karar, mimarinin her yönünü etkiler.

• Siteye özel veriler: Sayfalar, gönderiler, site ayarları, tema seçenekleri ve yerel içerikler. Bu veriler her sitede ayrı tutulmalıdır.
• Ağ düzeyindeki veriler: Ortak öğrenenler, küresel raporlar, ağ genelindeki kayıtlar ve site çapındaki ilişkiler. Bu veriler, tek bir yerde saklanmalıdır.

Bizim durumumuzda, öğrenenler tüm ağa ait olduğundan, her site için ayrı kayıt oluşturmak hem veri çoğaltımına hem de senkronizasyon sorunlarına yol açacaktı. Doğru mimari, verinin sahipliğini doğru şekilde tanımlamaktan geçiyordu: ağ düzeyinde bir `wp_learner` tablosu.

WordPress Multisite’nin Veritabanı Önekleri: Kritik Ayrıntı

Bu sorunun kökeninde, WordPress’in veritabanı öneklerini nasıl yönettiği yatıyor. $wpdb nesnesi aracılığıyla erişilebilen iki önemli değer bulunur:

• `$wpdb->prefix`: Mevcut siteye ait veritabanı öneki. Örneğin, Site ID 1 için wp_1_ gibi.
• `$wpdb->base_prefix`: Ağın temel öneki. Örneğin, varsayılan wp_ gibi.

ACF Pro’nun Özel Tablolar özelliği, varsayılan olarak $wpdb->prefix kullanır ve bu da her siteye özel tablo oluşturmasına neden olur. Oysa bizim ihtiyacımız, tüm sitelerin aynı tablodan veri okumasıydı. Bu noktada, tablo adını belirlerken hangi önekin kullanılacağı kritik hale geldi.

ACF Pro’nun Sınırlamaları ve İş Akışı Uyuşmazlığı

ACF Pro’nun Özel Tablolar özelliği, alan verilerini wp_postmeta yerine özel tablolarda saklamayı sağlar. Bu, büyük projelerde performansı artırabilir. Ancak Multisite ortamında, ACF’nin varsayılan davranışı, verinin siteye özel olmasını gerektirir.

Projemizde, ACF’nin varsayılan davranışını değiştirmek için çeşitli yaklaşımlar denedik:

• Özel eklenti kancaları kullanmak: ACF’nin tablo oluşturma davranışını değiştirmek için acf/include_fields veya acf/init gibi kancaları araştırdık. Ancak sonuç, sadece yüzeysel bir değişiklikti; verinin sahipliğiyle ilgili temel sorunu çözmüyordu.
• ACF’nin kodunu değiştirmek: $wpdb->prefix yerine $wpdb->base_prefix kullanarak ACF’nin iç kodunu değiştirmek teknik olarak mümkündü. Ancak bu, eklenti güncellemeleriyle uyumsuzluk yaratacak ve uzun vadeli bakım sorunlarına yol açacaktı.

Sonuçta, ACF’nin varsayılan davranışını değiştirmek yerine, onun sunduğu arayüzü kullanıp veriyi farklı bir katmanda saklamanın daha sürdürülebilir bir çözüm olduğunu anladık.

ACF’yi Arayüz Olarak Kullanmak, Veriyi ise Özel Katmanda Saklamak

En etkili çözüm, ACF’yi sadece bir arayüz olarak kullanmak ve veriyi kendi özel tablolarımızda saklamaktı. Bu yaklaşımda:

• ACF, müşteriye sunulan kullanıcı dostu alan yönetimi arayüzünü sağlamaya devam ediyor.
• Özel bir eklenti, wp_learner ve wp_learner_meta tablolarını wp_learner şeklinde oluşturuyor — tüm sitelerin erişebileceği şekilde.
• ACF’nin acf/load_value ve acf/save_post gibi kancaları kullanılarak, verinin okunması ve kaydedilmesi, özel tablolara yönlendiriliyor.

Bu mimariyle, müşteri alan gruplarını ACF üzerinden yönetmeye devam ederken, verilerin ağ genelinde tutarlı ve tek bir noktada saklanması sağlanıyor. Aynı zamanda, performans ve veri bütünlüğü de korunmuş oluyor.

Sonuç: Mimariyi Gereksinimlere Uyarlamak

Bu proje, WordPress Multisite projelerinde verinin sahipliği ve mimarisi hakkında önemli bir ders verdi. ACF Pro’nun sunduğu kolaylıkları kullanırken, onun varsayılan davranışının projelerin gereksinimlerine uygun olmadığı durumlarda, veriyi farklı bir katmanda yönetmek gerektiğini gösterdi.

Gelecekteki projelerde, verinin kim tarafından kullanılacağı ve nasıl depolanacağına dair kararlar, mimarinin temelini oluşturmalıdır. ACF gibi güçlü araçlar, esneklikleriyle projelerin ihtiyaçlarına uyum sağlayabilir — ancak bazen bu uyumu sağlamak için, varsayılan akışı yeniden düşünmek gerekebilir.