WordPress Revizyonları Temizleme ve Sınırlandırma Rehberi

WordPress revizyonları, bir yazı veya sayfa üzerinde kaydedilen önceki sürümlere dönmenizi sağlar. Yanlışlıkla silinen bir paragrafı bulmak, iki editörün yaptığı değişiklikleri karşılaştırmak veya yayımlanan metindeki bir hatayı geri almak için kullanılır. Birikmiş kayıtlar veritabanında yer tutabilir; ancak hepsini düşünmeden silmek, işe yarayan bir geri dönüş yolunu da ortadan kaldırır. En güvenli sıra, mevcut durumu ölçmek, geri yüklenebilir yedek almak, gelecekte kaç sürüm tutulacağını belirlemek ve eski kayıtları yalnızca ihtiyaç doğrulandıktan sonra temizlemektir.

Bu rehber, WordPress yönetim ekranında revizyonları incelemekten WP_POST_REVISIONS ayarına, otomatik kayıtla farkından toplu temizleme risklerine kadar uygulanabilir bir yol sunar. Ekran adları sürüme göre değişebilir; burada anlatılan kavramları kendi sürümünüzde doğrulayın. Özellikle birden fazla editörün çalıştığı veya düzenlemeleri sık yapılan sitelerde geri alma olanağının değeri, birkaç megabaytlık alan tasarrufundan daha yüksek olabilir.

WordPress revizyonu nedir?

Revizyon, WordPress’in içerik üzerindeki kaydedilmiş değişiklikleri ayrı bir geçmiş kaydı olarak tutmasıdır. Yazının bugün ziyaretçiye gösterilen sürümü ile önceki sürümler aynı şey değildir. Revizyon ekranında hangi metnin eklendiğini, değiştiğini veya kaldırıldığını inceleyebilir; uygun eski sürümü geri yükleyebilirsiniz. WordPress belgeleri revizyonların başlık, içerik, yazar ve özet gibi alanları izleyebildiğini açıklar. Eklentiye özgü her alanın otomatik olarak aynı şekilde saklandığını varsaymayın.

Örneğin bir editör teknik bir rehberin girişini sadeleştirirken önemli uyarıyı silebilir. Hata birkaç gün sonra fark edildiğinde eski sürümdeki paragraf bulunup değerlendirilebilir. Bazen tüm eski sürümü geri yüklemek yerine yalnızca eksik paragrafı elle geri almak daha doğru olur; çünkü daha sonraki başka düzeltmeleri kaybetmek istemezsiniz. Revizyon ekranı bu karar için karşılaştırma sağlar.

Revizyonlar, tam site yedeği değildir. Veritabanının bozulması, sitenin taşınması veya yanlışlıkla silinen medya dosyaları gibi durumlar için ayrı yedek gerekir. Ayrıca bir revizyonun varlığı, eski görsellerin sunucuda hâlâ bulunduğunu garanti etmez. Revizyon geçmişini içerik düzeyinde bir güvenlik ağı; yedeği ise daha geniş kurtarma aracı olarak düşünün.

Revizyon, otomatik kayıt ve taslak arasındaki fark

Bu terimler aynı sanıldığında yanlış kayıtlar silinebilir. Taslak, henüz yayımlanmamış ya da taslak durumundaki ana içeriktir. Revizyon, bir kaydetme sonrasında oluşan geçmiş sürümdür. Otomatik kayıt ise düzenleme sırasında olası bağlantı kopması veya tarayıcı kapanmasına karşı tutulan özel bir sürümdür. WordPress, otomatik kayıtları revizyon altyapısıyla ilişkilendirir; fakat işlevleri farklıdır.

Resmî WordPress belgesine göre her kullanıcı için bir içerikte en fazla bir otomatik kayıt tutulur ve yenisi eskisinin üzerine yazılır. Bu nedenle “her dakika yeni veritabanı satırı açılıyor” varsayımı doğru değildir. Birden çok editör varsa her kullanıcının otomatik kaydı olabilir. Otomatik kayıt yayımlanmış içeriği doğrudan değiştirmez. Kaydedilmemiş bir çalışma geri yüklenebilecekse düzenleyici bunu gösterebilir.

Çöp kutusundaki yazı, taslak ve revizyonu da ayırın. Bir makaleyi silmek başka, o makalenin eski sürümlerini temizlemek başkadır. Özellikle eklenti arayüzünde “posts”, “drafts”, “autosaves” ve “revisions” ayrı seçenekler olarak görünüyorsa yalnızca amaçladığınız kayıt tipini işaretleyin. İşleme başlamadan önce etkilenecek kayıt sayısını ve örneklerini görün.

Revizyon ekranı nasıl açılır?

WordPress yönetim panelinde ilgili yazıyı veya sayfayı düzenleyin. Ayarlar kenar çubuğunda Yazı ya da Sayfa sekmesine geçip “Sürümler” veya “Revisions” sayısına tıklayın. Bağlantı, henüz geçmiş sürüm oluşmamış bir içerikte görünmeyebilir. Sitenizde özel editör, farklı rol yetkileri veya eklenti varsa arayüz değişebilir.

WordPress 7.0 ve sonrası yeni bir revizyon ekranı sunar. Önceki sürümlerde klasik karşılaştırma ekranı bulunur; yeni sürümlerde de klasik görünüme geçiş seçeneği olabilir. Bizim temel hedefimiz ekranın renklerine bağlı kalmadan iki sürüm arasında hangi içerik değiştiğini anlamaktır. Kaydırıcı veya revizyon listesinden tarihleri seçin. Yeni eklenen ve kaldırılan bölümleri okuyun. “Geri Yükle” düğmesine basmadan önce hangi tarihteki içeriği seçtiğinizi tekrar kontrol edin.

Eski bir sürüm güvenle nasıl geri yüklenir?

Önce geri alma amacınızı tek cümlede yazın: silinmiş bölüm mü, bozulmuş başlık mı, yanlış yazar mı? Ardından revizyon listesinden değişikliğin öncesindeki ve sonrasındaki sürümleri karşılaştırın. Tam sürümü geri yüklediğinizde o tarihten sonra yapılan başka düzenlemelerin görünür içerikten çıkabileceğini unutmayın. Ortak çalışılan bir sitede ilgili editöre haber vermek ve güncel sürümün kopyasını almak mantıklıdır.

1. Canlı sayfayı ve düzenleyicideki güncel metni kontrol edin. Hangi sorunu düzelteceğinizi belirleyin.
2. Revizyon ekranında tarihe ve düzenleyen kişiye bakın. İki sürümün farkını satır satır inceleyin.
3. Yalnızca bir paragraf gerekiyorsa önce onu kopyalayıp güncel yazıya eklemeyi değerlendirin.
4. Tüm sürüme dönmeniz gerekiyorsa doğru kaydı seçin ve geri yükleme işlemini onaylayın.
5. Yazıyı yeniden açıp bağlantıları, görselleri, H1 başlığını, özetini ve SEO alanlarını gözden geçirin.
6. Canlı sayfada eski sürümün gerçekten görüntülendiğini ve önemli yeni düzeltmelerin kaybolmadığını doğrulayın.

Geri yükleme işlemi yeni bir kayıt oluşturabilir; WordPress’in mevcut sürümle nasıl çalıştığını kendi sitenizde test edin. İşlem, eklenti tarafından tutulan her özel meta alanını eski hâline getirmeyebilir. Bu yüzden özellikle SEO başlığı, açıklama, öne çıkan görsel ve blok eklentisi alanlarını canlı sayfadan ve düzenleyiciden ayrıca karşılaştırın. Yanlış bir sürüm seçtiyseniz tekrar revizyon ekranına dönüp düzeltme yapabilirsiniz; ancak kritik içerikte yedek yine de gereklidir.

Revizyon sayısını neden ölçmelisiniz?

“Çok revizyon var, site kesin yavaş” çıkarımı eksiktir. Revizyon kayıtları wp_posts tablosunda yer tutar, fakat sayfa açılış hızını yalnızca kayıt adedi belirlemez. Veritabanının toplam boyutu, sorgu planı, indeksler, önbellek, sunucu kapasitesi ve eklentilerin yaptığı sorgular birlikte değerlendirilir. Büyük bir içerik arşivinde fazla geçmiş bakım yükünü artırabilir; küçük bir sitede birkaç yüz sürümü temizlemek ziyaretçinin deneyiminde ölçülebilir fark yaratmayabilir.

İşe başlamadan önce toplam veritabanı boyutunu, içerik ve revizyon sayısını, en çok geçmişi olan yazıları ve düzenleme sıklığını not edin. Yönetim panelindeki Sağlık ekranı, barındırma paneli veya güvenilir bakım araçları size genel görünüm verebilir. Teknik erişiminiz varsa veritabanı yedeği üzerinde tablo boyutlarını inceleyin. Canlı veritabanında rastgele SQL silme sorgusu çalıştırmak, özel tabloları veya ilişkileri bozmaya değmez.

Bir test ortamında önce şu soruları yanıtlayın: Hangi yazılar sık güncelleniyor? Yazarlar eski sürümlere ne kadar geri dönüyor? Hangi tarih aralığındaki kayıtlar gerçekten gereksiz? Yedeği kaç dakikada geri yükleyebiliyorsunuz? Bunların cevabı, herkes için aynı “3 revizyon tut” kuralından daha kullanışlıdır. Haber odasında çok sürüm saklamak gerekebilir; nadiren değişen küçük bir tanıtım sitesinde daha düşük sınır yeterli olabilir.

WP_POST_REVISIONS ayarı nasıl yapılır?

WordPress’in wp-config.php dosyasındaki WP_POST_REVISIONS sabiti, gelecekte kaç normal revizyonun tutulacağını sınırlar. Örnek olarak aşağıdaki değer, içerik başına üç normal revizyon tutmayı amaçlar. Bu sayı evrensel öneri değildir; editoryal ihtiyaca göre belirlenmelidir. Dosyayı düzenlemeden önce yedekleyin, doğru ortama bağlı olduğunuzu doğrulayın ve erişimi olan yetkili kişiyle çalışın.

define( 'WP_POST_REVISIONS', 3 );

Bu satır wp-config.php içindeki yapılandırma bölümüne, WordPress’i yükleyen son satırdan önce yerleştirilmelidir. Aynı sabitin ikinci kez tanımlanıp tanımlanmadığını arayın; kopya tanımlar uyarıya ve beklenmedik davranışa yol açabilir. Dosyanın PHP sözdizimini ve kodlamasını bozmayın. Değişiklikten sonra yönetim panelini ve bir yazıyı açarak hata oluşmadığını kontrol edin.

WordPress belgesine göre true veya -1 sınırsız normal revizyon anlamına gelir; false veya 0 normal revizyonları kapatır, fakat kullanıcı başına otomatik kayıt davranışı ayrı kalır. Pozitif tam sayı o kadar normal revizyonu tutar. Yeni bir içerik güncellendiğinde sınırın uygulanması, geçmiş kayıtların ne zaman azaltılacağını etkileyebilir. Dolayısıyla ayarı kaydetmek, sitedeki tüm eski revizyonları anında topluca temizleyen bir işlem değildir.

Revizyonları tamamen kapatmak genellikle gereksiz bir risk yaratır. Hatalı yayını geri alma imkânını kaybedersiniz. Maliyet kaygısı varsa makul bir pozitif sınır, yedekleme düzeni ve gerçekten büyüyen kayıtların izlenmesi daha dengeli bir başlangıçtır. Ayrıca bazı geliştiriciler wp_revisions_to_keep filtresiyle yazı türüne göre ayrı sayı belirleyebilir; farklı içerik türlerinin gereksinimleri varsa bu seçenek düşünülür.

Eski revizyonlar nasıl temizlenir?

WordPress çekirdeği revizyonları görüntüleme ve geri yükleme arayüzü sunar; toplu silme için standart yönetim ekranında aynı kapsamda bir düğme bulunmayabilir. Bu nedenle birçok site bakım eklentisi veya WP-CLI kullanır. Hangi aracı seçerseniz seçin, silinecek içerik türünü ve sayısını işlemin öncesinde görün. “Veritabanını optimize et” düğmesinin arkasında hangi sorguların çalıştığını bilmiyorsanız önce aracın belgelerini ve geri alma yolunu inceleyin.

Bir bakım eklentisi kullanırken yalnızca revizyonları hedefleyin; otomatik kayıt, taslak, çöp kutusu, geçici veri ve yorum temizliği ayrı kararlar olmalıdır. Eklentinin bazı kayıtları koruma, tarih aralığı seçme veya önizleme imkânı varsa kullanın. Canlıda geniş kapsamlı temizliği ilk deneme olarak yapmayın. Test ortamında önce küçük bir yazı grubuyla sonucu doğrulayın. Ardından canlı veritabanının tam yedeğini alıp dosyanın geri yüklenebildiğini kontrol edin.

WP-CLI veya SQL ile işlem yapan teknik ekip için de ilke aynıdır: seçilecek revizyonları önce yalnızca listeleyen bir sorgu veya araçla kapsamı inceleyin, yedek alın, mümkünse işlem günlüğü tutun ve küçük örnekte deneyin. Bu rehberde kopyala yapıştır ile tüm revision kayıtlarını silecek genel bir SQL komutu vermiyoruz; tablo öneki, özel içerik türleri ve sitenin iş akışı farklı olabilir. Yanlış kapsam içerik geçmişini geri döndürülemez biçimde azaltır.

Temizlik öncesi geri yüklenebilir yedek

Yedek alma işleminin başarı mesajı tek başına yeterli değildir. Dosyanın nerede tutulduğunu, ne kadar süre saklandığını ve hangi veritabanı anına ait olduğunu kaydedin. Sitenin dosyalarıyla veritabanını birlikte geri yüklemeniz gereken bir senaryo da olabilir. Barındırma hizmetinin otomatik yedeği varsa erişim yetkilerini, saklama süresini ve geri yükleme adımlarını önceden kontrol edin.

Staging ortamı varsa üretimden alınan uygun bir kopyada geri yükleme prova edin. Kişisel veri içeren üretim yedeğini güvenli olmayan test ortamına açık biçimde taşımayın. Testte birkaç örnek yazının revizyon sayısını ve geri dönüş işlevini işlem öncesi ve sonrası karşılaştırın. Bir yedeğin değerini, ihtiyaç anında kullanılabilir olması belirler.

İşlem sırasında site yoğun biçimde yazı güncelliyorsa yedek ile temizlik arasında yeni değişiklikler oluşabilir. Büyük sitelerde bakım penceresi belirlemek ve editörleri bilgilendirmek tutarlılığı artırır. İşlem bittiğinde bir yazıyı düzenleyip yeni revizyon oluştuğunu ve geri alma ekranının çalıştığını test edin. “Temizlik tamamlandı” ile “site sağlıklı” farklı sonuçlardır.

Veritabanı boyutu küçüldü mü, hız arttı mı?

Silme sonrası veritabanının panelde görünen fiziksel dosya boyutu hemen azalmayabilir. Veritabanı motoru boşalan alanı yeniden kullanabilir; fiziksel yeniden düzenleme ayrıca bakım gerektirebilir. Bu konuda barındırma sağlayıcınızın yöntemini izleyin. Alan ölçümünü aynı araç ve yöntemle önce/sonra karşılaştırın. Tek bir sayıdan tüm performans değişimini çıkarmayın.

Sayfa hızını değerlendirmek için aynı URL’leri, benzer sunucu yükü ve önbellek durumunda karşılaştırın. Veritabanı bağlantı hatası, yavaş sorgular veya ağır eklentiler varsa yalnızca revizyon silmek kök nedeni çözmez. Sitede yaşanan performans sorunlarını ayrı bir tanı akışıyla ele alın; WordPress veritabanı optimizasyonu rehberinde farklı bakım adımlarını da inceleyebilirsiniz.

Çok yazarlı ve sık güncellenen siteler için politika

Tek yazarlı kişisel blog ile günlük haber yayını aynı geçmiş ihtiyacına sahip değildir. Çok yazarlı sitede editör onayı, düzeltme kayıtları ve olası hata incelemeleri için daha uzun geçmiş saklamak gerekebilir. Özellikle hukuki veya editoryal kayıt gereksinimleri varsa temizleme süresi kurumsal politikayla uyumlu olmalıdır. Sırf disk alanı için geçmişi kısa tutmak ileride düzeltmenin izini zorlaştırabilir.

Basit bir politika yazın: Hangi içerik türünde kaç sürüm tutulacak, yedek ne kadar saklanacak, temizliği kim başlatacak, geri yükleme talebini kim onaylayacak? Haftalık veya aylık otomatik temizlik düşünüyorsanız önce manuel sürecin sorunsuz çalıştığını kanıtlayın. Planlı görev bozulursa bildirim alabileceğiniz bir izleme mekanizması kurun. Otomasyonun amacı sürprizleri azaltmak olmalıdır.

Sık yapılan yanlışlar

• Revizyonları yedek sanmak: Sunucu veya medya kaybında tüm siteyi geri getirmezler.
• Hepsini kapatmak: Geri alma yolunu gereksiz yere kaldırır; önce makul bir sınır deneyin.
• Sayıyı anında temizleme sanmak: WP_POST_REVISIONS gelecekteki güncelleme davranışını düzenler; toplu silme düğmesi değildir.
• Otomatik kayıtları karıştırmak: Yeni çalışma kaybına karşı işlevini bilmeden temizlemeyin.
• Yalnızca dosya boyutuna bakmak: Performansın nedenini sorgu ve sunucu ölçümleriyle arayın.
• Test etmeden üretimde silmek: Geri alma ihtiyacı ortaya çıktığında hangi kaydın eksildiğini bulmak güç olabilir.

Uygulama senaryosu: 300 yazılık bir blog

Varsayalım bir blogda 300 yazı var ve bazı eski rehberler onlarca kez güncellenmiş. Yönetim panelinde yavaşlık hissediliyor, fakat ölçüm henüz yok. İlk adım, veritabanı ve sunucu kaynak kullanımını kaydetmektir. Sonra birkaç çok düzenlenen yazının revizyon ekranını açıp geçmişin editörler için gerçekten kullanılıp kullanılmadığını sorun. Gereksiz olduğu anlaşılan kayıtlar için tarih aralığı ve içerik türü bazında bir kapsam belirleyin.

İkinci adım, yedeği geri yüklemeyi staging kopyasında denemek ve seçilen bakım aracını küçük bir örnek üzerinde çalıştırmaktır. Üçüncü adım, canlıda uygun bakım zamanında sınırlı temizliği yapmak ve kaydedilen alanı ölçmektir. Son adım, yeni bir yazı güncellemesinden sonra normal revizyon ve otomatik kayıt davranışını doğrulamaktır. Eğer yönetim paneli hâlâ yavaşsa sıradaki inceleme yavaş sorgular, eklentiler ve sunucu kapasitesidir. Revizyonların fazla olması ile yavaşlık aynı anda görülebilir; bu tek başına nedensellik kanıtı değildir.

Yayımdan sonraki kontrol listesi

1. Seçtiğiniz revizyon sınırını ve nedenini ekip notuna yazın.
2. wp-config.php değişikliğinden sonra PHP uyarısı ve site erişim hatası olmadığını kontrol edin.
3. Bir test yazısında en az bir yeni sürüm kaydedip karşılaştırma ekranını açın.
4. Yedekleme dosyasının varlığını ve geri yükleme provasının sonucunu kaydedin.
5. Temizlikten önce ve sonra aynı ölçüm yöntemiyle kayıt sayısını ve alanı karşılaştırın.
6. Canlı makalelerde başlık, görsel ve SEO alanlarının beklenen biçimde kaldığını örnekleyin.
7. Beklenen kazanım görülmediyse performans sorununu başka bileşenlerde araştırın.

Sık sorulan sorular

Revizyonları silmek mevcut yazıları siler mi?

Doğru kapsamla çalışan bir araç yalnızca geçmiş sürüm kayıtlarını hedefler; güncel yayımlanmış yazı ana kayıt olarak kalır. Fakat yanlış seçilmiş içerik türü veya hatalı sorgu zarar verebilir. Bu yüzden canlıdan önce test, yedek ve örnek doğrulaması gerekir. “Sadece revizyon” seçeneğinin gerçekten hangi kayıtları kapsadığını aracın belgelerinden okuyun.

Revizyonları sınırlamak otomatik kaydı kapatır mı?

WordPress belgelerinde normal revizyon ile kullanıcı başına otomatik kayıt ayrı anlatılır. WP_POST_REVISIONS değerini sıfır yapmak, otomatik kaydın tamamen yok olacağı anlamına gelmez. Yine de üretim ortamındaki davranışı kullandığınız WordPress sürümü ve eklentilerle test edin. Kaydedilmemiş içerik için tek güvence olarak otomatik kayda bel bağlamayın; önemli uzun düzenlemeleri düzenli kaydedin.

Kaç revizyon tutmalıyım?

Tek bir doğru sayı yoktur. İçerik güncelleme sıklığı, editör sayısı, geri dönüş ihtiyacı, depolama bütçesi ve kurum politikası belirleyicidir. Üç veya on gibi değerler örnek ayarlardır. Önce geçmişe ne kadar sık dönüldüğünü ve saklamanın gerçek maliyetini görün. Sonra pozitif bir sınır seçip birkaç hafta izlemeniz, körlemesine sıfırlamaktan daha güvenlidir.

Revizyon temizliği SEO’yu doğrudan geliştirir mi?

Geçmiş kayıtları azaltmak kendi başına arama sıralaması vaadi değildir. Eğer veritabanı yükü gerçekten sayfa sunumunu etkiliyorsa teknik iyileştirmeye katkı verebilir; bunu ölçmeniz gerekir. Daha önemlisi, geri alma yeteneğini korumak yanlış yayımlanmış içeriği hızla düzeltmenize yardım eder. SEO bakımında canlı içeriğin doğruluğu ve erişilebilirliği önceliklidir.

Sonuç

WordPress revizyon geçmişi, içerik düzenleme sürecinin işe yarayan bir parçasıdır. Temizlik kararı verirken önce revizyonların nasıl kullanıldığını, otomatik kayıttan farkını ve yedeğin geri yüklenebilirliğini değerlendirin. WP_POST_REVISIONS ile ileriye dönük makul bir sınır koyun; eski kayıtları ise ölçüm ve testten sonra seçici biçimde temizleyin. Böylece alanı yönetirken editörlerin güvenli geri dönüş yolunu korursunuz.

Kaynaklar: WordPress: Revisions, WordPress geliştirici belgeleri: wp-config.php, WordPress: wp_revisions_to_keep.