WooCommerce HPOS Nedir? Yüksek Performanslı Sipariş Depolamaya Güvenli Geçiş

Mağazanızın yönetim panelinde WooCommerce → Ayarlar → Gelişmiş → Özellikler sekmesini açtığınızda iki radyo düğmesi görürsünüz: "WordPress gönderi depolama (eski)" ve "Yüksek performanslı sipariş depolama". İkincisinin hemen altında da genellikle kırmızı bir uyarı vardır: "3 eklenti bu özellikle uyumlu değil." Tıklamak istersiniz ama hangi eklentinin ne kadar sorun çıkaracağını bilmediğiniz için elinizi geri çekersiniz. Bu yazı tam olarak o anı çözmek için yazıldı.

Karar vermeyi zorlaştıran şey, HPOS'un görünürde tek bir onay kutusu olması ama arkasında bir veritabanı mimarisi değişikliği durmasıdır. Siparişleriniz yıllardır wp_posts tablosunda blog yazılarıyla aynı yerde duruyordu; HPOS bunları kendilerine ait tablolara taşır. Değişiklik gerçek ve kalıcıdır, dolayısıyla "aç bakalım ne olacak" yaklaşımı canlı bir mağazada kabul edilebilir değildir.

Aşağıda önce bu değişimin somut olarak neyi hızlandırdığını, sonra da riski en aza indiren geçiş yöntemini anlatıyorum: uyumluluk ekranını doğru okumak, senkronizasyon modunda iki depoyu paralel çalıştırmak, önce/sonra ölçüm almak ve gerektiğinde tek komutla geri dönmek. Mağazanızın genel hız tablosunu iyileştirmek istiyorsanız bu yazıyı WooCommerce performans rehberimizle birlikte okumanızı öneririm.

Siparişleriniz Şimdiye Kadar Tam Olarak Nerede Duruyordu?#

WooCommerce, WordPress'in üzerine inşa edildiği için başlangıçta hazır olan veri yapısını kullandı: custom post type. Bir sipariş, wp_posts tablosunda post_type = 'shop_order' değerine sahip bir satırdı. Siparişin tüm ayrıntıları — müşteri adı, fatura adresi, kargo adresi, toplam tutar, ödeme yöntemi, para birimi, sipariş anahtarı — wp_postmeta tablosuna anahtar/değer çiftleri hâlinde yazıldı.

Bunun ne anlama geldiğini bir örnekle görelim. Tek bir siparişi eksiksiz okumak için veritabanının yapması gereken iş şudur:

-- Tek bir siparisin meta verileri kac satira dagilmis?
SELECT COUNT(*) AS meta_satir_sayisi
FROM wp_postmeta
WHERE post_id = 12345;

Tipik bir mağazada bu sayı 40 ile 120 arasında değişir. Yani ekranda gördüğünüz bir sipariş, veritabanında onlarca satırın birleştirilmesiyle oluşur. Üstelik wp_postmeta, sitenizdeki her şeyin meta verisini tutar: ürünler, yazılar, sayfalar, medya dosyaları, eklenti ayarları. Beş bin siparişi olan bir mağazada bu tablo rahatlıkla bir milyon satıra çıkar.

İkinci sorun indekslemedir. wp_postmeta tablosunun meta_value sütunu longtext tipindedir ve bu sütun üzerinde işe yarar bir indeks kurulamaz. "Ödeme yöntemi havale olan siparişleri listele" gibi bir sorgu, MySQL'i çok sayıda satırı taramaya zorlar. Sipariş listesi ekranının büyüyen mağazalarda giderek yavaşlamasının temel nedeni budur.

Üçüncüsü de meşguliyettir. Ürün güncellemesi, yeni sipariş, ödeme bildirimi, kargo takip numarası yazımı — hepsi aynı iki tabloya yazar. Yoğun bir kampanya gününde bu tablolar sürekli çalışır durumdadır ve yazma işlemleri birbirini bekletir.

HPOS Tam Olarak Neyi Değiştiriyor?#

High-Performance Order Storage (Yüksek Performanslı Sipariş Depolama), siparişleri genel amaçlı tablolardan çıkarıp yalnızca siparişler için tasarlanmış dört tabloya taşır:

Kritik fark şu: artık her alan gerçek bir sütun. status, total_amount, payment_method, date_created_gmt gibi alanlar kendi sütunlarında ve üzerlerinde indeks var. "Son 30 günün ödeme bekleyen siparişleri" sorgusu artık geniş bir tarama değil, indeks okuması.

-- HPOS oncesi: postmeta uzerinden JOIN zinciri
SELECT p.ID, pm.meta_value AS total
FROM wp_posts p
JOIN wp_postmeta pm ON pm.post_id = p.ID AND pm.meta_key = '_order_total'
WHERE p.post_type = 'shop_order' AND p.post_status = 'wc-processing';

-- HPOS sonrasi: tek tablo, indeksli sutunlar
SELECT id, total_amount
FROM wp_wc_orders
WHERE status = 'wc-processing';

Bir not: wp_wc_order_stats tablosunu HPOS ile karıştırmayın. O tablo WooCommerce Analytics'e aittir ve HPOS'tan önce de vardı; raporlar için özet veri tutar, siparişin kendisini değil.

HPOS, WooCommerce 8.2 sürümüyle kararlı hâle geldi ve o tarihten sonraki yeni kurulumlarda varsayılan depolama biçimi oldu. Yani yeni bir mağaza kurduysanız muhtemelen zaten HPOS kullanıyorsunuz. Konu, yıllardır çalışan eski mağazaların geçişi.

HPOS Geçişi Sizin Mağazanızda Fark Yaratır mı?#

Her mağaza aynı kazancı görmez ve bunu geçiş yapmadan önce tahmin edebilirsiniz. Belirleyici olan sipariş sayısı ve wp_postmeta tablosunun büyüklüğüdür.

-- Kac siparisiniz var?
SELECT post_status, COUNT(*) AS adet
FROM wp_posts
WHERE post_type IN ('shop_order', 'shop_order_refund')
GROUP BY post_status;

-- Tablolarin gercek boyutu (MB)
SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS boyut_mb,
       table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
  AND table_name IN ('wp_posts', 'wp_postmeta')
ORDER BY boyut_mb DESC;

Kabaca bir yön tayini:

• 1.000 siparişin altında: Ölçülebilir bir hız farkı büyük ihtimalle görmezsiniz. Yine de geçmek mantıklıdır, çünkü mağaza küçükken geçiş yapmak en risksiz zamandır.
• 5.000 – 50.000 sipariş: Yönetim panelindeki sipariş listesi, arama ve filtreleme belirgin biçimde hızlanır. En sık olumlu geri bildirim alınan aralık budur.
• 50.000 sipariş üzeri: Fark dramatik olabilir. On saniyeyi aşan sipariş ekranlarının bir saniyenin altına indiği durumlar sıradan.

Ölçümü inandırıcı yapmak için geçişten önce somut sayılar alın. Tarayıcının geliştirici araçlarındaki Ağ sekmesinde sipariş listesi isteğinin süresini not edin. Sipariş arama kutusuna bir müşteri e-postası yazıp süreyi ölçün. Aynı ölçümleri geçişten sonra tekrarlayın; kararınızı hissiyata değil rakama dayandırmış olursunuz.

"Bu Eklenti Uyumlu Değil" Uyarısını Doğru Okumak#

Özellikler ekranında WooCommerce eklentilerinizi üç gruba ayırır ve bu ayrımı anlamak geçişin en önemli adımıdır.

Uyumlu eklentiler. Geliştirici, eklentinin ana dosyasında açıkça "ben HPOS ile çalışırım" beyanında bulunmuştur. Bu beyan tek bir kod parçasıdır:

add_action( 'before_woocommerce_init', function () {
    if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
        \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
            'custom_order_tables',
            __FILE__,
            true
        );
    }
} );

Uyumsuz olarak işaretlenenler. Geliştirici açıkça "uyumsuzum" demiştir. Bunlar gerçek risktir; siparişe yazdıkları veri kaybolabilir veya eklenti hata verebilir.

Belirsiz (uncertain) eklentiler. Burada dikkat: WooCommerce bu listeye, hiçbir beyanda bulunmayan eklentileri koyar. Bu, "uyumsuz" demek değildir — "bilmiyorum" demektir. Uzun süredir güncellenmeyen ama siparişlere hiç dokunmayan bir galeri eklentisi de bu listede çıkar. Yani listenin uzunluğuna bakıp paniklemek yerine, her satırı şu soruyla değerlendirin: bu eklenti siparişi okuyor ya da siparişe veri yazıyor mu?

Pratikte gerçekten inceleme gerektirenler şunlardır: ödeme altyapıları, kargo entegrasyonları, fatura ve e-arşiv eklentileri, muhasebe senkronizasyonları, sipariş dışa aktarma araçları, sipariş durumu bildiren SMS/e-posta eklentileri ve pazaryeri entegrasyonları. Bir kaydırıcı ya da iletişim formu eklentisi listede görünse bile geçişi ilgilendirmez.

Uyumsuz bir eklenti bulduğunuzda üç yolunuz var: geliştiriciden güncelleme istemek, uyumlu bir alternatife geçmek veya o eklentiyi kaldırmak. Dördüncü bir yol daha var ve genellikle en pratik olanı: senkronizasyon modunda kalmak. Bunu birazdan açıklıyorum.

Eklentilerin birbiriyle etkileşiminden doğan sorunları teşhis etmek için WordPress eklenti çakışması yazımızdaki ikili arama yöntemi burada da işinize yarar.

Senkronizasyon Modu: İki Depoyu Paralel Çalıştırmak#

HPOS ekranındaki en değerli seçenek radyo düğmeleri değil, altındaki onay kutusudur: "Uyumluluk modunu etkinleştir (siparişleri gönderi tablosuyla senkronize eder)."

Bu mod açıkken WooCommerce her siparişi hem yeni HPOS tablolarına hem de eski wp_posts / wp_postmeta yapısına yazar. Okuma işlemi seçtiğiniz yetkili depodan yapılır, ama diğeri de güncel kalır. Sonuç şudur: HPOS'u kullanmaya başlarsınız, ama eski yapıya doğrudan erişen bir eklenti veya özel kodunuz varsa o da çalışmaya devam eder.

Bunun bedeli her sipariş için çift yazma işlemidir; yani yazma tarafında bir miktar ek yük. Buna karşılık geri dönüş maliyetini neredeyse sıfıra indirir. Canlı bir mağazada doğru sıralama şudur:

1. Senkronizasyon modunu açık tutarak HPOS'a geçin.
2. Birkaç hafta gerçek trafikle çalıştırın; tüm sipariş akışını (ödeme, iade, kargo, fatura) gözlemleyin.
3. Hiçbir sorun çıkmadığından emin olduktan sonra senkronizasyonu kapatın.
4. Uzun bir süre daha sorun görmezseniz eski verileri temizleyin.

Aceleci davranmayın; senkronizasyon modunda geçirilen birkaç hafta, geri dönüşü olmayan bir sürprizden çok daha ucuzdur.

Adım Adım Güvenli Geçiş#

1. Tam yedek alın. Dosya değil, veritabanı yedeği kritik. Konsola erişiminiz varsa:

# Gecis oncesi tam veritabani yedegi
mysqldump -u kullanici -p --single-transaction --quick veritabani_adi \
  | gzip > hpos-oncesi.sql.gz

# Yedegin gercekten okunabilir oldugunu dogrulayin
gunzip -t hpos-oncesi.sql.gz && echo "Yedek saglam"

Yedekleme stratejisini bir düzene oturtmadıysanız WordPress yedekleme yazımız başlangıç için yeterli.

2. Önce hazırlık ortamında deneyin. Canlı mağazanın bir kopyasını alıp geçişi orada yapın. Gerçek siparişlerle test etmek, boş bir kurulumda test etmekten kat kat değerlidir. Kurulum için staging ortamı yazımıza bakabilirsiniz.

3. WooCommerce ve eklentileri güncelleyin. Geçişten önceki hafta yapılacak en verimli iş budur; birçok "uyumsuz" etiketi tek bir güncellemeyle kalkar.

4. Uyumluluk listesini temizleyin. Yukarıdaki soruyu — siparişe dokunuyor mu? — her eklentiye uygulayın, gerçek riskleri çözün.

5. Senkronizasyonu açıp bekleyin. Ayarlar ekranından uyumluluk modu kutusunu işaretleyip kaydedin. WooCommerce mevcut siparişleri arka planda toplu işlerle yeni tablolara aktarmaya başlar. Sipariş sayınıza göre bu birkaç dakikadan birkaç saate kadar sürebilir.

6. Aktarımın bittiğini doğrulayın. Senkronizasyon tamamlanmadan yetkili depoyu değiştirmeyin.

7. HPOS'u yetkili depo yapın. Radyo düğmesini "Yüksek performanslı sipariş depolama" olarak seçin ve kaydedin. Senkronizasyon kutusu hâlâ işaretli kalsın.

8. Sipariş akışının tamamını test edin. Kendi kartınızla küçük tutarlı gerçek bir sipariş verin ve şunları tek tek kontrol edin: ödeme alındı mı, sipariş listesinde göründü mü, bilgilendirme e-postaları gitti mi, fatura eklentisi belgeyi kesti mi, kargo entegrasyonu takip numarasını yazdı mı, iade akışı çalışıyor mu, müşteri hesabındaki sipariş geçmişi doğru mu? Bu kontrolleri yapmadan geçişi tamamlanmış saymayın.

WP-CLI ile Geçiş: Büyük Mağazalar İçin#

On binlerce siparişi olan mağazalarda tarayıcıdan tetiklenen arka plan işleri yavaş ilerleyebilir ve ilerlemeyi görmek zordur. SSH erişiminiz varsa komut satırı hem daha hızlı hem de şeffaftır. Komutlar wp wc hpos altında toplanmıştır; WP-CLI kullanımına yeniyseniz önce oraya göz atın.

Tipik bir geçiş oturumu şöyle işler:

# 1. Mevcut durum
wp wc hpos status

# 2. Kac siparis aktarilmayi bekliyor?
wp wc hpos count_unmigrated

# 3. Senkronizasyonu calistir, bekleyen sayisi sifira inene kadar tekrarla
wp wc hpos sync

# 4. Iki depodaki veri ayni mi?
wp wc hpos verify_data

# 5. Fark bulunan siparislerde tam olarak ne farkli?
wp wc hpos diff 12345

# 6. Her sey temizse HPOS'u uyumluluk moduyla birlikte ac
wp wc hpos enable --with-sync

verify_data komutunun raporladığı farklar genellikle zararsızdır (biçim farklılıkları, boş değerler), ama sipariş toplamı veya durumu gibi bir alanda fark görürseniz diff ile o siparişe bakın ve nedenini anlamadan devam etmeyin.

Geçişten Sonra Karşılaşılan Tipik Sorunlar#

Belirti: Fatura eklentisi çalışıyor ama sipariş üzerindeki özel alan (TCKN, vergi dairesi gibi) boş geliyor. Sebep: Eklenti veriyi get_post_meta( $order_id, '_alan', true ) ile okuyor. HPOS'ta sipariş artık bir gönderi olmadığı için o kimlik wp_postmeta tablosunda karşılık bulmuyor. Çözüm: Kod sizin kontrolünüzdeyse sipariş nesnesi üzerinden okuyun. Değilse senkronizasyon modunu açık bırakın; eski tablo da yazıldığı için eklenti çalışmaya devam eder.

// HPOS oncesi yazilmis kod
$vkn = get_post_meta( $order_id, '_vergi_no', true );

// HPOS uyumlu dogru kullanim
$order = wc_get_order( $order_id );
$vkn   = $order ? $order->get_meta( '_vergi_no' ) : '';

// Yazma tarafi da nesne uzerinden olmali
$order->update_meta_data( '_vergi_no', '1234567890' );
$order->save();

Belirti: Özel bir rapor sayfası veya tema fonksiyonu boş liste döndürüyor. Sebep: Kodda WP_Query ile post_type => 'shop_order' sorgusu yapılıyor. HPOS'ta o gönderi tipinde kayıt kalmaz. Çözüm: Sipariş sorgularını wc_get_orders() üzerinden yapın; bu fonksiyon hangi depo aktifse ona göre doğru sorguyu üretir.

$siparisler = wc_get_orders( array(
    'status'       => array( 'wc-processing', 'wc-completed' ),
    'date_created' => '>' . ( time() - 30 * DAY_IN_SECONDS ),
    'limit'        => 50,
) );

// Kodunuzun hangi depoda calistigini ogrenmek isterseniz:
$hpos_aktif = \Automattic\WooCommerce\Utilities\OrderUtil::custom_orders_table_usage_is_enabled();

Belirti: Doğrudan SQL yazan bir raporlama aracı sıfır satır döndürüyor. Sebep: Sorgu hâlâ wp_posts tablosuna bakıyor. Çözüm: Sorguyu wp_wc_orders tablosuna taşıyın. Aracı değiştiremiyorsanız senkronizasyon modu tek çıkış yolunuzdur.

Belirti: Sipariş numaralarının değiştiğinden şüpheleniliyor. Sebep: Aslında değişmez. HPOS, wp_wc_orders.id sütununda aynı kimliği korur; müşterilerinize bildirdiğiniz sipariş numaraları geçiş sonrası da geçerlidir.

Geri Dönüş: Kapıyı Açık Bırakmak#

Senkronizasyon modunda çalışıyorsanız geri dönüş gerçekten kolaydır. Ayarlar ekranından depolama biçimini "WordPress gönderi depolama (eski)" olarak seçmeniz yeterli — çünkü eski tablolar zaten güncel tutuluyordu.

# Once bekleyen senkronizasyon kalmadigindan emin olun
wp wc hpos count_unmigrated

# Sonra eski depoya donun
wp wc hpos disable

Komut, bekleyen senkronizasyon varsa geri dönüşe izin vermez. Bu bir engel değil, koruma: yarısı aktarılmış bir veriyle geri dönmek, iki depoda birbirini tutmayan siparişler demektir.

Senkronizasyonu kapattıktan sonra ise durum değişir. Eski tablolar artık güncellenmediği için, kapatma tarihinden sonraki siparişler wp_posts tarafında bulunmaz; geri dönüş için önce wp wc hpos sync ile ters yönde senkronizasyon yapmanız gerekir. Bu yüzden senkronizasyonu kapatma kararını, gerçekten emin olduğunuz bir noktada verin.

Son adım olarak wp wc hpos cleanup komutu eski tablolardaki artık sipariş verisini siler ve wp_postmeta tablonuzu hissedilir ölçüde küçültür. Bunu geri dönüşü olmayan bir işlem olarak görün: yalnızca aylardır sorunsuz çalışan, yedeği alınmış bir kurulumda çalıştırın. Veritabanı bakımının genel prensipleri için MySQL performans optimizasyonu yazımıza bakabilirsiniz.

Sıkça Sorulan Sorular#

HPOS geçişi siparişlerimi siler mi ya da bozar mı?#

Hayır. Geçiş bir kopyalama işlemidir: siparişler eski tablolardan okunup yeni tablolara yazılır, eski veri olduğu yerde durur. Senkronizasyon modunda ise iki depo aynı anda güncel tutulur. Yine de geçişten önce mutlaka tam veritabanı yedeği alın; asıl risk verinin silinmesi değil, uyumsuz bir eklentinin yeni yapıya yazamaması ve bunun fark edilmemesidir.

Uyumluluk listesinde çıkan her eklentiyi kaldırmam gerekir mi?#

Gerekmez. Bu listenin büyük bölümü "uyumsuz" değil, "beyan vermemiş" eklentilerden oluşur. Yalnızca siparişi okuyan veya siparişe veri yazan eklentiler gerçekten önemlidir: ödeme, kargo, fatura, muhasebe ve pazaryeri entegrasyonları. Bir galeri ya da form eklentisi listede görünse bile geçişi etkilemez.

Uyumsuz bir eklentim var ama vazgeçemiyorum, ne yapmalıyım?#

Senkronizasyon modunu açık bırakın. Bu modda WooCommerce hem yeni hem eski tabloları güncel tuttuğu için, eski yapıya doğrudan erişen eklenti çalışmaya devam eder ve siz yine de HPOS'un okuma hızından faydalanırsınız. Bedeli her siparişte çift yazma işlemidir; çoğu mağaza için kabul edilebilir bir maliyettir.

Küçük bir mağazam var, geçiş yapmam şart mı?#

Şu an için zorunlu değil ama ertelemenin bir faydası da yok. Aksine, mağaza küçükken geçiş yapmak en risksiz zamandır: az sipariş, az entegrasyon, kısa senkronizasyon süresi. HPOS yeni kurulumlarda zaten varsayılan olduğu için eklenti ekosistemi de bu yöne doğru ilerliyor.

Geçiş sonrası sipariş numaralarım değişir mi?#

Değişmez. Siparişin kimliği yeni tabloda da aynı sayı olarak korunur, dolayısıyla müşterilerinize daha önce bildirdiğiniz sipariş numaraları geçerliliğini sürdürür. Aynı şekilde sipariş anahtarları, fatura kayıtları ve müşteri hesabındaki sipariş geçmişi de olduğu gibi kalır.

Geçiş ne kadar sürer, mağazamı kapatmam gerekir mi?#

Kapatmanız gerekmez; senkronizasyon arka planda çalışır ve mağaza bu sırada sipariş almaya devam eder. Süre sipariş sayısına ve sunucu gücüne bağlıdır: birkaç bin sipariş dakikalar içinde, yüz binlerce sipariş birkaç saatte aktarılır. WP-CLI kullanmak hem süreyi kısaltır hem de ilerlemeyi adım adım görmenizi sağlar.

HPOS açıkken veritabanım küçülür mü?#

Hemen küçülmez, hatta senkronizasyon modunda bir süre büyür; çünkü aynı veri iki yerde tutulur. Asıl küçülme, senkronizasyonu kapatıp wp wc hpos cleanup komutunu çalıştırdığınızda gelir. O aşamada wp_postmeta tablosundan on binlerce satır silinir ve tablo boyutu belirgin biçimde düşer. Bu adımı ancak geri dönmeyeceğinizden emin olduğunuzda atın.