WordPress Revizyon Temizleme: Güvenli Yöntemler

WordPress revizyonları neden birikir?

Bir WordPress yazısını her kaydettiğinizde önceki sürüm tamamen kaybolmaz. WordPress, düzenleme sırasında oluşan sürümleri veritabanında tutar; böylece yanlış bir paragrafı, silinen bir görseli veya eski bir başlığı birkaç tıklamayla geri getirebilirsiniz. Bu özellik işe yarar. Yıllarca düzenlenen sitelerde revizyon sayısı ise sessizce büyür.

Çok yazarlı bloglarda, WooCommerce ürün kataloglarında ve Gutenberg editöründe sık sık taslak kaydedilen sitelerde aynı içerik için onlarca, hatta yüzlerce revizyon oluşabilir. Her revizyon wp_posts tablosunda ayrı bir kayıt olarak tutulur. Bazı eklentiler de kendi verilerini wp_postmeta tablosuna ekleyebilir.

Kritik nokta şu: Revizyon temizlemek, WordPress’i hızlandıran sihirli bir düğme değildir. Gereksiz kayıtları azaltır; yedek boyutuna, bazı yönetim paneli ekranlarına ve sorgulara olumlu etki edebilir. Sitenin asıl yavaşlığı kötü bir sorgudan, fazla eklentiden veya yetersiz PHP kaynaklarından geliyorsa yalnızca revizyon silmek sorunu çözmez.

Ben bu kontrolü genellikle disk ya da veritabanı kullanımı beklenmedik biçimde büyüdüğünde yaparım. Bir taşıma sırasında müşterinin “Yedeğimiz var” dediği klasörü açtığımda içeride yalnızca boş bir dizin bulmuştum. Revizyon temizliğine geçmeden önce geri dönüş planını doğrulamanın neden şart olduğunu o gün tekrar gördüm. Boş klasör yedek değildir.

Önce neyi temizlediğinizi görün

Temizlik işlemine doğrudan silme komutuyla başlamayın. Önce mevcut durumu ölçün. Yönetici hesabıyla WordPress panelinde bir yazıyı açıp “Revizyonlar” bölümünü kontrol edebilirsiniz. Bu yöntem birkaç içerik için yeterli olur; yüzlerce yazının durumunu görmek için WP-CLI veya SQL daha sağlıklı sonuç verir.

WP-CLI ile revizyon sayısını bulma

SSH bağlantısında WordPress dizinine geçin. Uzun süren komutları çalıştırırken ben doğrudan kabuk yerine tmux kullanırım; bağlantı kopsa da işlem yarıda kalmaz.

cd /var/www/html
tmux new -s wp-maintenance
wp db export before-revision-cleanup.sql
wp db query "SELECT COUNT(*) AS revision_count FROM wp_posts WHERE post_type = 'revision';"

Burada tmux komutundaki görünmez karakter sorun yaratabileceğinden gerçek komut şu olmalıdır:

tmux new -s wp-maintenance

İlk komut WordPress dizinine geçer, ikinci komut kopmalara karşı bir oturum açar. wp db export veritabanının temizlik öncesi yedeğini alır. Son sorgu da wp_posts tablosundaki revizyonları sayar. Tablo önekiniz wp_ olmayabilir; gerçek öneki wp-config.php içindeki $table_prefix değerinden kontrol edin.

Çıktıda birkaç yüz kayıt görüyorsanız temizlikten bekleyeceğiniz kazanç sınırlı olabilir. Binlerce veya on binlerce kayıt, özellikle düşük kaynaklı hosting paketlerinde, daha yakından incelenmeye değerdir. Yalnızca toplam sayıya bakmayın; hangi içeriklerin bu kayıtları ürettiğini de bulun.

wp db query "SELECT post_parent, COUNT(*) AS revision_count
FROM wp_posts
WHERE post_type = 'revision'
GROUP BY post_parent
ORDER BY revision_count DESC
LIMIT 20;"

post_parent değeri, revizyonun bağlı olduğu yazı, sayfa veya ürünün kimliğidir. Bir içerikte olağan dışı sayıda kayıt varsa düzenleme alışkanlığını, otomatik kaydetme davranışını ve kullanılan eklentiyi araştırın.

Veritabanı tablolarını doğrudan incelemek

phpMyAdmin veya MySQL istemcisi kullanıyorsanız aynı sorguları çalıştırabilirsiniz. Ben önce wp db export ile yedek almayı tercih ederim. Panelden alınan yedek de kullanılabilir, fakat geri dönüş adımlarını test etmediyseniz dosyanın varlığı tek başına güvence değildir.

Revizyonları kontrol etmek için temel sorgu şöyledir:

SELECT ID, post_parent, post_date, post_title
FROM wp_posts
WHERE post_type = 'revision'
ORDER BY post_date DESC
LIMIT 20;

Çıktıda başlıkların çoğu “Revision” benzeri görünür. post_parent alanı sıfır olan veya silinmiş içeriklere bağlı kalan kayıtlar ayrıca incelenebilir. Bunları topluca silmeden önce sitenin kullandığı özel içerik tiplerini tanıdığınızdan emin olun.

WordPress revizyon temizleme yöntemleri

Tek bir doğru yöntem yok. Sitenin boyutu, erişim seviyeniz ve geri dönüş planınız hangi seçeneğin uygun olduğunu belirler.

Panel üzerinden seçili revizyonları silmek

Az sayıda içerik için en kontrollü yöntem WordPress editöründeki revizyon ekranıdır. Yazıyı açın, “Revizyonlar” alanına girin ve ihtiyacınız olmayan eski sürümleri yönetin. WordPress’in kendi arayüzü burada içerik ile revizyon arasındaki ilişkiyi görmenizi sağlar.

Bu yöntem veritabanını topluca küçültmek için yavaştır. Bir yazının yanlışlıkla değiştirildiği, son sürümün hatalı olduğu veya editörün aynı içeriği iki kişi tarafından kullandığı durumlarda anlaşılır bir kontrol noktasıdır.

Az kayıt varsa en güvenli tercih genellikle budur. Acele etmeyin.

WP-CLI ile tüm revizyonları kaldırmak

Revizyonların tamamını silmek istiyorsanız önce yedeği doğrulayın. Küçük ve orta boy sitelerde aşağıdaki yaklaşım kullanılabilir:

wp post list --post_type=revision --format=ids
wp post delete $(wp post list --post_type=revision --format=ids) --force

İlk satır silinecek kayıtların kimliklerini listeler. İkinci satır bu kayıtları kalıcı olarak kaldırır. Çok büyük listelerde kabuğun komut uzunluğu sınırına takılabilirsiniz; binlerce kimlik varsa işlemi partilere bölmek daha güvenlidir.

İlk komutun çıktısı boşsa ikinci komutu çalıştırmayın. Büyük bir listede önce sayıyı kontrol etmek için şu biçimi kullanabilirsiniz:

wp post list --post_type=revision --format=ids | wc -w

Silmeden önce yalnızca sayıyı değil, örnek kayıtları da kontrol edin. Yanlış tablo öneki veya yanlış WordPress dizini seçimi her zaman mümkündür. “Nasıl olsa sadece revizyon” düşüncesi burada gereksiz risk yaratır.

SQL ile doğrudan silme

Doğrudan SQL kullanmak hızlıdır, hata payı da yüksektir. Bu yolu ancak veritabanı yedeğiniz, geri yükleme erişiminiz ve tablo yapısı hakkında net bilginiz varsa tercih edin.

DELETE FROM wp_posts
WHERE post_type = 'revision';

Bu sorgu bütün revizyon kayıtlarını siler. İçeriklerin kendisini silmez; normal yazı, sayfa veya ürün kayıtlarına dokunmaz. Eklentilerin revizyonlara bağlı meta verileri kalabilir. Büyük temizlikten sonra yetim meta kayıtlarını ayrıca analiz etmek gerekir; rastgele SQL ile wp_postmeta silmek, ihtiyaç duyulan özel verileri de yok edebilir.

Ben doğrudan SQL kullanacaksam önce işlem kapsamını transaction destekleyen bir ortamda test ederim veya etkilenecek kayıtları dışa aktarırım. Canlı sunucuda phpMyAdmin ekranına yapıştırıp düşünmeden çalıştırmak, birkaç dakikalık işi geri dönüşü zor bir kazaya çevirebilir.

Eski revizyonları koruyup yenilerini sınırlamak

Tüm revizyonları silmek yerine içerik başına belirli sayıda son sürümü saklamak çoğu site için daha dengeli bir yaklaşımdır. wp-config.php dosyasına, “That’s all, stop editing!” satırından önce şu tanımı ekleyebilirsiniz:

define( 'WP_POST_REVISIONS', 10 );

Bu ayar içerik başına en fazla 10 revizyon tutulmasını sağlar. Mevcut eski revizyonları geriye dönük olarak silmez; bundan sonra oluşacak kayıtları sınırlar. Geçmiş birikim için ayrıca temizlik planı gerekir.

Değeri false yaparak revizyonları kapatmak teknik olarak mümkündür:

define( 'WP_POST_REVISIONS', false );

Ben bunu genel bir çözüm olarak önermem. Bir yazarın metni yanlışlıkla silmesi veya ürün fiyatını hatalı değiştirmesi halinde geri dönüş noktası bırakmazsınız. İçerik başına 5, 10 veya editoryal iş akışınıza uyan başka bir sınır belirlemek daha makuldür.

Bu ayarı eklerken dosyanın PHP sözdizimini bozmayın. Başında veya sonunda gereksiz karakter bulunan bir wp-config.php dosyası, revizyon temizliğinden bağımsız olarak sitenin açılmamasına yol açabilir. Değişiklikten önce dosyanın kopyasını almak iyi bir alışkanlıktır.

Eklentiyle temizlik yaparken nelere bakarım?

Panelden işlem yapmak isteyen kullanıcılar için revizyon temizleme eklentileri pratik olabilir. Eklenti seçerken yalnızca kaç tabloyu temizlediğine bakmayın. Güncelleme tarihi, kullandığınız WordPress sürümüyle uyumluluk, geri alma seçeneği ve otomatik zamanlama desteği daha anlamlı göstergelerdir.

Bir eklenti revizyonların yanında çöp yazıları, spam yorumları, geçici seçenekleri veya yetim meta kayıtlarını da temizlemek isteyebilir. Hepsini aynı anda seçmek cazip görünür. Peki neden temkinli davranıyorum? Çünkü geçici seçenek gibi görünen bir kayıt bazı eklentiler için yapılandırma veya önbellek bilgisi olabilir.

İlk çalıştırmayı canlı sitede değil, staging kopyasında yapın. Ardından ana sayfa, birkaç yazı, iletişim formu, giriş ekranı ve WooCommerce kullanıyorsanız sepet ile ödeme adımlarını test edin. Temizliğin hemen ardından sorun görülmezse bile yedek dosyasını bir süre saklayın.

Eklenti kullanmanız veritabanı yedeği almanıza engel değil. Temizlik öncesi ve sonrası tablo boyutlarını karşılaştırmak için şu sorgu fikir verebilir:

SELECT table_name, ROUND(data_length / 1024 / 1024, 2) AS data_mb,
ROUND(index_length / 1024 / 1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
AND table_name IN ('wp_posts', 'wp_postmeta');

Tablo adlarını kendi önekinize göre değiştirin. data_mb veri alanını, index_mb ise indeks alanını gösterir. Revizyonlar silinse bile tablo dosyasının işletim sistemi seviyesinde hemen küçülmemesi normaldir; MySQL tabloyu yeniden düzenlemeden disk kullanımı aynı kalabilir.

Temizlikten sonra veritabanı neden hâlâ büyük görünüyor?

Bu soru destek biletlerinde sık karşıma çıkıyor. DELETE satırları kaldırır, fakat InnoDB tablosunun fiziksel dosyası her zaman işletim sistemine hemen alan iade etmez. Bu, silme işleminin çalışmadığı anlamına gelmez.

Hosting panelindeki disk kullanımı değişmediyse önce kayıt sayısını tekrar ölçün:

wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';"

Sayı düşmüşse temizlik gerçekleşmiştir. Tabloyu yeniden düzenlemek için OPTIMIZE TABLE kullanılabilir; bu işlem büyük tablolarda geçici ek disk alanı ve tablo kilidi gerektirebilir. Canlı WooCommerce sitesinde yoğun saatlerde çalıştırmak yerine bakım penceresi planlayın.

Veritabanı bağlantı sorunları veya bozuk tablolar görürseniz WordPress Veritabanı Bağlantı Hatası: 5 Çözüm başlıklı yazıdaki kontrol sırasını kullanabilirsiniz. Revizyon temizliği sırasında bağlantı bilgilerini değiştirmek gerekmez; konu dışı bir DB_HOST veya parola değişikliği eklemek teşhisi zorlaştırır.

Otomatik temizlik için güvenli bir plan

Otomatik görev kuracaksanız sırayı koruyun: önce yedek, sonra temizlik, en son izleme. Cron görevi sessizce başarısız olabilir. Ben evdeki Raspberry Pi üzerinde çalışan Uptime Kuma ile kendi cron işlerimi bile izliyorum; izlemediğiniz cron, çalışmayan cron’dur.

Basit bir plan şöyle kurulabilir:

Her gün veya hafta veritabanı yedeği alın.
Son yedek dosyasının oluştuğunu ve makul bir boyuta sahip olduğunu kontrol edin.
Belirlediğiniz sınırın üzerindeki eski revizyonları temizleyin.
Ayda bir yedeği ayrı bir ortamda geri yükleyerek gerçekten kullanılabildiğini doğrulayın.

Yedeği aynı sunucunun aynı diskinde tutmayın. Disk arızası veya yanlış bir SQL komutu hem canlı veriyi hem de yedeği aynı anda erişilemez hale getirebilir. RPO ve RTO hedeflerini belirlerken KOBİ’ler İçin RPO/RTO ve Felaket Kurtarma Planı: Hosting Tarafında Gerçekçi Hedefler yazısındaki yaklaşım operasyon tarafını netleştirir.

Otomatik görev için WP-CLI kullanan bir script yazabilirsiniz. Sabit ve kontrolsüz bir wp post delete komutunu üretim ortamına bırakmayın. Önce kayıt sayısını loglayın, eşik değer belirleyin ve beklenmeyen artışta işlemi durdurun. Silme komutunun çıktısını log dosyasına yazmak, cron’un gerçekten çalışıp çalışmadığını anlamayı kolaylaştırır.

Revizyon temizliği performansı ne kadar etkiler?

Etki, veritabanının boyutuna ve sitenin çalışma biçimine göre değişir. Revizyon sayısı azsa ölçülebilir bir fark görmeyebilirsiniz. Çok sayıda eski kayıt ve gereksiz meta verisi varsa yedek süresi, bazı veritabanı sorguları ve yönetim paneli işlemleri rahatlayabilir.

Site yavaşlığı için ilk teşhisim yine revizyon sayısı değildir. Yavaş sorguları, PHP-FPM süreçlerini, disk beklemelerini ve eklenti davranışlarını da kontrol ederim. WordPress ve WooCommerce sitelerinde rapor eklentileri, filtrelenmemiş sorgular ve ağır dış API çağrıları çoğu zaman daha büyük etki yaratır.

Hosting ve SEO İlişkisi: Gerçekler ve Efsaneler yazısında da belirttiğim gibi, temiz bir veritabanı tek başına iyi sıralama garantisi vermez. Kullanıcı deneyimi; sunucu yanıtı, önbellek, tema, eklentiler, içerik kalitesi ve ağ koşullarının birlikte oluşturduğu bir tablodur. Revizyonları temizleyin, performans ölçümünü yalnızca bu işleme bağlamayın.

Bakım öncesi ve sonrası ölçüm alın. Ana sayfanın yanıt süresini, yönetim panelinde yazı kaydetme süresini, veritabanı boyutunu ve yedek süresini not edin. Böylece yaptığınız değişikliğin faydasını tahminle değil, kendi sitenizin verisiyle görürsünüz.

Sık Sorulan Sorular

WordPress revizyonlarını tamamen silmek güvenli mi?

Yedek aldıysanız ve revizyonlara geri dönme ihtiyacınız yoksa silmek genellikle güvenlidir. Yine de önce staging ortamında deneyin. Editoryal süreçte eski sürümlere ihtiyaç duyuyorsanız tümünü silmek yerine belirli sayıda revizyon saklayın.

WordPress revizyon temizleme işlemi yazılarımı siler mi?

Doğru filtreyle yalnızca post_type = 'revision' kayıtlarını silersiniz; yayımlanmış yazılar, sayfalar ve ürünler yerinde kalır. Yanlış tablo veya sorgu kullanımı riskli olduğundan komutu çalıştırmadan önce kayıt sayısını ve veritabanı önekini kontrol edin.

Revizyon sınırı kaç olmalı?

Çoğu site için içerik başına 5 veya 10 revizyon makul bir başlangıçtır. Birden fazla editörün çalıştığı, sıkı onay süreci olan sitelerde daha yüksek bir sınır gerekebilir. Sınırı ekledikten sonra geçmiş kayıtları ayrıca temizlemeyi unutmayın.

Revizyonları sildim ama disk alanı neden artmadı?

MySQL satırları silmiş olsa bile InnoDB tablo dosyası fiziksel alanı hemen geri vermeyebilir. Kayıt sayısını doğruladıktan sonra uygun bir bakım penceresinde tablo optimizasyonu planlayın ve işlem öncesi yeterli boş disk alanı bırakın.

Benim bakım sıram basit: yedeği alırım, yedeği açabildiğimi doğrularım, sonra küçük bir örnek üzerinde temizlik yaparım. WordPress revizyonları faydalı bir güvenlik ağıdır; yalnızca bu ağın yıllarca birikip veritabanını gereksiz yere şişirmesine izin vermemek gerekir.

Post Views: 32