Misafir Yazı Sürümleri: WordPress Revizyon Kaydı

WordPress revizyon sistemi, her kaydedilen taslağın ve yayınlanmış güncellemenin bir kaydını tutar; hangi cümlenin eklendiğini, çıkarıldığını ya da değiştiğini gösterir ve eski bir sürüme dönmenizi sağlar. Misafir yazı kabul eden bir blogun editörü için bu, ücretsiz ve hazır bir değişiklik defteridir. Ama defterin sınırları vardır: revizyon sayısı sınırlanabilir, onay notları ve rel kararları revizyona girmez, silme için arayüz yoktur. Bu yüzden revizyonu tek başına kayıt sistemi saymayın; onay notunuzu ve link kararlarınızı tutan dış bir kayıtla birlikte kullanın.

Kısa karar: Revizyonları açık tutun, editör ve yazar için ayrı kullanıcı hesabı kullanın, her onayda revizyon sürümünü onay notuna yazın ve revizyon sınırı koyacaksanız sınırı yazının geçeceği tüm düzeltme turlarını kapsayacak kadar yüksek seçin. Aşağıdaki bölümler bu kararın dayandığı belge ifadelerini ve uygulama önerilerini ayırır.

Revizyon sistemi ne saklar

Belgenin tarifi

WordPress'in revizyonlar belgesi (yeni sekmede açılır), sistemi her kaydedilen taslak ya da yayınlanmış güncellemenin kaydını tutan bir yapı olarak tarif eder. Kaydırıcıyı sürükleyerek her revizyonda neyin değiştiğini görebilirsiniz; ekran neyin eklendiğini, neyin aynı kaldığını ve neyin çıkarıldığını gösterir. Eklenen ya da çıkarılan satırlar vurgulanır, tek tek karakter değişiklikleri ek vurguyla gösterilir. Geri yüklemek için Restore düğmesi kullanılır. Menü adları arayüz diline göre değişebilir; Türkçe arayüzde karşılıkları farklı görünebilir.

Hangi alanlar izlenir?

Belgeye göre WordPress varsayılan olarak başlık, yazar, içerik ve özet alanlarındaki değişiklikleri izler. Belge başka alanlardan (kategori, etiket, öne çıkan görsel, özel alanlar) söz etmez; bu alanların hiçbiri belgede güvenceye alınmış değildir. Misafir yazıda rel kararı, bir bağlantının hedefi ve kategori seçimi gibi bilgiler önemliyse, bunların izlendiğini varsaymayın; kendi kurulumunuzda deneyerek kontrol edin.

Revizyonlar nerede durur?

Belge, revizyonların yazıların bulunduğu tabloda saklandığını söyler: revizyonlar ilişkili yazının alt kayıtları olarak tutulur, durumları "inherit", türleri "revision" olarak yazılır. Bu ayrıntı editörü ilgilendirmez, ama bir şeyi gösterir: revizyonlar sitenin veritabanındadır ve veritabanı yedeğiyle birlikte taşınır. Yedek almıyorsanız ya da yedek politikanız revizyonları dışarıda bırakıyorsa, editör değişiklik defterinin de yedeği yoktur.

Revizyonları karşılaştırma

Revizyon ekranına ulaşmak

Belge revizyonları görmek için Ayarlar kenar çubuğunu açıp Sayfa ya da Yazı sekmesinden Revisions yanındaki sayıya tıklamanızı söyler. Belgeye göre WordPress 7.0'dan itibaren bu tıklama yeni revizyon ekranını açar; WordPress 6.9 ve öncesinde klasik revizyon ekranı açılır. Belgedeki sürüm bilgileri değişebilir; uygulamadan önce kendi sitenizdeki sürümü ve belgenin güncel hâlini kontrol edin.

Yeni ekranda renkler

Belge, yeni ekranda kaydırma çubuğunun yanındaki renkli işaretleri tarif eder: eklenen bloklar düz yeşil, çıkarılan bloklar kırmızı ve ileri eğimli çapraz çizgili, değiştirilen bloklar sarı ve geri eğimli çapraz çizgilidir. İşarete tıklayarak değişikliğe atlayabilirsiniz. Soldaki Show changes simgesi renkli vurguyu açıp kapatır. Renk tek başına anlam taşımaz; çizgi desenleri renk ayrımı yapamayan okuyucular için de farkı gösterir.

Klasik ekran ve iki revizyonu karşılaştırma

Klasik ekran, içeriğin HTML hâlini yan yana karşılaştırır. Belge, bu ekranda iki ucu olan bir kaydırıcı bulunan "Compare any two revisions" modunun, karşılaştırılacak iki revizyonu seçmeye izin verdiğini söyler. Editör için bu mod, ilk onaylanan sürüm ile yayın sonrası değişen sürüm arasındaki farkı tek ekranda görmenin yoludur. Karşılaştırma farkları metin ya da HTML görünümünde çizilir; belgeye göre işlenmiş (rendered) bir karşılaştırma şimdilik yoktur.

Otomatik kayıt ve revizyon sınırı

Otomatik kayıt

Belge, bir yazı için kullanıcı başına en fazla bir otomatik kayıt bulunduğunu, yeni otomatik kaydın eskisinin üzerine yazıldığını ve çok kullanıcılı ortamlarda her kullanıcı için ayrı otomatik kayıt tutulduğunu söyler. Otomatik kayıtlar yayınlanmış içeriğin üzerine yazmaz; özel bir revizyon türü olarak saklanır ve revizyon zaman çizelgesinde Autosave etiketiyle işaretlenir. Tarayıcı çökerse ya da bağlantı kesilirse, yazıyı yeniden açtığınızda WordPress bir yedek bulunduğunu söyleyip geri yükleme bağlantısı sunar.

Editör açısından sonuç şudur: Autosave satırları bir onay kararı değildir. Bir kullanıcının otomatik kaydı kendi üzerine yazıldığı için, çok sık kaydedilen ara hâller revizyon listesinde birikmez ama sonraki bir otomatik kayıt önceki ara hâlin yerine geçer. Onaylanan sürümü, açıkça kaydedilmiş bir revizyonla işaretleyin.

Revizyon sayısını sınırlamak

Belge, saklanacak revizyon sayısını sınırlamanın iki yolunu verir: geliştiricilerin kullandığı wp_revisions_to_keep filtresi ve wp-config.php içinde WP_POST_REVISIONS tanımı. WP_POST_REVISIONS için değerler şöyledir: true (varsayılan) ya da -1 her revizyonu saklar; false ya da 0 hiçbir revizyon saklamaz (yazı başına bir otomatik kayıt dışında); sıfırdan büyük bir tamsayı ise o kadar revizyonu (artı kullanıcı başına bir otomatik kayıt) saklar. Belge, yazı yeniden güncellendiğinde eski revizyonların otomatik silindiğini de yazar.

Bu son cümle editör için önemlidir: sınır koyarsanız, ilk sürümler yayın sonrası düzeltmeler biriktikçe kaybolur. İlk onaylanan sürümü sonradan karşılaştırma ihtiyacınız varsa, bu sürüm artık revizyon listesinde bulunmayabilir.

Karar kuralı: revizyon sınırı koymalı mıyım?

Uygulama önerisi: Veritabanı boyutu gerçek bir sorun değilse sınır koymayın. Koyacaksanız, bir misafir yazının geçeceği düzeltme turlarını (yazar taslağı, editör düzeltmesi, yazar yanıtı, son onay, yayın sonrası düzeltmeler) kapsayacak kadar yüksek bir sayı seçin ve bu sayıyı yazılı politikaya yazın. Sınır ne olursa olsun, onaylanan sürümün kopyasını ve onay notunu dış bir kayıtta saklayın. Belgede önerilen bir sayı yoktur; bu bir uygulama kararıdır.

Yazar ve editör değişikliğini ayrıştırma

Ayrı hesap, ayrı iz

Belge, varsayılan olarak yazar alanındaki değişikliklerin de izlendiğini söyler, ama bir revizyonda hangi kullanıcının kaydettiğinin nasıl gösterileceğini anlatmaz. Bu yüzden iz bırakmanın en sağlam yolu, her kişinin kendi hesabıyla çalışmasıdır. Editör ve yayıncı ortak bir "editor" hesabı kullanıyorsa, hangi değişikliği kimin yaptığı revizyondan okunamaz. Misafir yazarın siteye kullanıcı olarak eklenip eklenmeyeceği politikanıza bağlıdır; eklenmiyorsa, yazarın taslağı editör hesabıyla yüklenir ve bu durum onay notunda belirtilmelidir.

Hangi değişikliğin kimden geldiğini kaydetmek

Revizyon, değişikliğin nedenini kaydetmez. "Bu cümle neden çıkarıldı?" sorusunun cevabı onay notunda ya da değişiklik kaydında olmalıdır. Uygulama önerisi: her editör düzeltme turunun sonunda, revizyonun yanında bir not satırı bırakın: tur numarası, değişikliği isteyen taraf ve gerekçe. Böylece revizyon "ne değişti"yi, not "neden değişti"yi taşır.

Dış kayıt gerektiren durumlar

Revizyonun yetmediği yerler

Revizyon bir metin defteridir; karar defteri değildir. Şu durumlarda dış bir kayıt gerekir: onay notları, rel kararları ve gerekçeleri, yazarla yazışma, talep ve itiraz geçmişi, ve revizyon sınırı yüzünden kaybolmuş eski sürümler. Ayrıca belgeye göre revizyon silme için bir arayüz yoktur; bu, kaydın yanlışlıkla silinmesine karşı bir koruma gibi görünse de, toplu temizlik gereksinimi doğduğunda bir geliştirici işi gerektirir.

Taslak ile canlı sürümün aynı olduğunu doğrulamak için sponsorlu içerik taslak ve yayın sürümü karşılaştırması yazısındaki adımlar, revizyon ekranıyla birlikte kullanılabilir. Revizyon, hangi sürümün canlıya çıktığını söylemez; canlı sayfayı onaylanan sürümle siz karşılaştırırsınız.

Tarihler ve revizyonlar

Revizyon sürüm tarihi ile sayfadaki dateModified aynı şey değildir. Google'ın Article yapılandırılmış veri sayfası (yeni sekmede açılır) dateModified'ı makalenin en son değiştirildiği tarih ve saat olarak ISO 8601 biçiminde tanımlar ve saat dilimi bilgisi vermenizi önerir; WordPress revizyon belgesi ise revizyonların bu alanı nasıl etkilediğini anlatmaz. Sitenizin temasının ya da eklentinizin dateModified değerini revizyon kaydından mı türettiğini kendi kurulumunuzda doğrulayın. Revizyon kaydı yalnızca sayfadaki tarih alanını destekleyen bir iç kanıttır.

Editoryal takvimle bağlantı

Revizyon sayısı yüksek bir yazı, editoryal takvimde risk işaretidir: çok sayıda düzeltme turu, yazının yayın tarihini kaydırabilir. Takvim ve konu sahipliği tablosu için editoryal takvim ve konu sahipliği tablosu yazısı kullanılabilir; tabloya "tur sayısı" sütunu eklemek revizyon sayısını yönetilebilir kılar.

Bu kayıtların hiçbiri revizyon sayısına bağlı değildir; bir yazı üç revizyonla da yirmi revizyonla da aynı kayıt disiplinine tabidir.

Politika ve kayıt cümleleri

• Tüm kullanıcılar kendi hesabıyla çalışır; ortak editör hesabı kullanılmaz.
• Her onay turu, revizyon sürümüne atıf yapan bir onay notuyla kapanır.
• Revizyon sınırı varsa, değeri ve gerekçesi yazılı politikada yer alır.
• Onaylanan sürümün kopyası dış kayıtta saklanır.
• Yayın sonrası her değişiklik, değişiklik kaydında nedeniyle birlikte yer alır.

Bu cümlelerin yerleşeceği bütün çerçeve için misafir yazı politikası sayfası yazısına bakabilirsiniz.

Revizyon geri yükleme riskleri

Geri yüklemek, seçilen sürümü yeni bir kayıt olarak yazar; ama eski bir sürüme dönmek, o sürümden sonra yapılan bütün düzeltmeleri geri almak demektir. Misafir yazıda bu iki risk doğurur. Birincisi, yayın sonrası bir olgu düzeltmesi geri alınabilir. İkincisi, rel değeri verilmiş bir link geri yüklenen sürümde bulunmayabilir ve değer kaybolur. Uygulama önerisi: geri yükleme yapmadan önce kayıt tablosuna bakın, geri yüklemeden sonra link tablosunu yeniden kontrol edin ve işlemi değişiklik kaydına yazın.

Tur tur kayıt akışı

Bir misafir yazı birkaç düzeltme turundan geçebilir ve her turun bir revizyon karşılığı olmalıdır. Uygulama önerisi: revizyonu bir karar defterine bağlamanın en basit biçimi aşağıdaki akıştır.

1. Yazar taslağı gelir. Editör taslağı kaydeder ve ilk revizyonun oluştuğunu kontrol eder. Onay notuna "Tur 0: yazar taslağı" yazılır.
2. Editör kontrol listesini uygular. Çıkarılan ya da değiştirilen cümleler kaydedilir. Not: "Tur 1: iki olgu cümlesi çıkarıldı, gerekçe ve kaynak ekte."
3. Yazar yanıtı gelir. Düzeltilmiş metin kaydedilir. Not: "Tur 2: yazar yanıtı işlendi."
4. Link kararı verilir ve linkler işaretlenir. Not: "Tur 3: rel değerleri uygulandı, link tablosu güncellendi."
5. Son onayda editör revizyon zaman çizelgesindeki son kaydı seçer ve onay notuna sürümü yazar. Not: "Onaylanan sürüm: son kayıt, tarih ve saat."
6. Yayın sonrası her değişiklik yeni bir not satırı alır; değişikliğin nedeni ve isteyeni yazılır.

Bu akışta revizyon ekranı "ne değişti" sorusunu, notlar ise "neden ve kim" sorusunu cevaplar. Revizyon sayısı sınırlandığında bile notlar yerinde kalır.

Onay notu şablonu

Revizyon ekranı belirli bir kaydı gösterir ama "bu kayıt onaylanan kayıttır" bilgisini taşımaz. Not bu açığı kapatır. Aşağıdaki alanlar tek satırda doldurulabilir.

• Yazı başlığı ve yazar adı.
• Onaylanan revizyonun kaydedildiği tarih ve saat ve kaydeden hesap.
• Toplam düzeltme turu sayısı.
• Çıkarılan ya da değiştirilen önemli cümlelerin kısa listesi.
• Link tablosunun yeri ve son güncelleme tarihi.
• Ticari bağ beyanının yeri.
• Onaylayan editör ve onay tarihi.

Sürüme ad vermek

Revizyonların kendi adı yoktur; yalnız tarih ve saatle ayırt edilirler. Onay notunda bir sürümü anmak için tarih ve saati ve kaydeden hesabı yazın. Sürümü "son hâli" gibi göreli bir ifadeyle anmayın; bir hafta sonra "son" artık başka bir kayıt olabilir. Gerekiyorsa onaylanan metnin bir kopyasını dış kayıtta saklayın ve kopyanın adına tarihi ekleyin.

Kullanıcı hesabı kararı: yazar siteye eklensin mi?

Misafir yazarı sitenin kullanıcısı yapmak, revizyon izini zenginleştirir ama güvenlik ve yönetim yükü getirir. Belgeler bu konuda bir öneri vermez. Aşağıdaki tablo iki yolu karşılaştırır.

Uygulama önerisi: yetki sınırını yazılı tutun. Yazarın hesabı varsa yalnızca kendi taslağına erişebilmeli ve yayınlama yetkisi bulunmamalıdır. Hesap yoksa yükleme sırasında yazarın adını ve gönderim tarihini nota yazın.

Revizyon ayarları kontrol listesi

• Revizyonlar açık mı? WP_POST_REVISIONS false ya da 0 değil mi?
• Sınır varsa değeri düzeltme turu sayısını karşılıyor mu?
• Her editör kendi hesabıyla mı çalışıyor?
• Revizyon ekranına erişim, yalnızca yetkili editörlerde mi?
• Veritabanı yedeği revizyonları kapsıyor mu?
• Onay notunda revizyon tarihi ve saati yazılıyor mu?
• Link kararları ayrı bir kayıt tablosunda mı?
• Yayın sonrası değişiklikler değişiklik kaydına işleniyor mu?

Yedek ve saklama

Revizyonlar veritabanında durduğundan, yedek planı revizyonları da kapsar. Belgede yedek konusunda bir ifade yok; bu, sitenizin yedek ayarlarının işidir. Editör açısından önemli olan, yazı silinirse ya da eski sürüme dönülürse hangi kaydın hâlâ geri getirilebileceğini bilmektir. Kişisel veri içeren yazıların saklama süresi ayrı bir politika konusudur ve bu konunun dışındadır.

Revizyon kaydı ile sürüm karşılaştırması arasındaki fark

İki kavram birbirine karışır. Revizyon kaydı, sitedeki yazının düzenleme tarihçesidir. Sürüm karşılaştırması ise onaylanan metinle canlıdaki metnin aynı olup olmadığının kontrolüdür. Revizyon kaydı "içeride ne oldu"yu gösterir; karşılaştırma "dışarıda ne var"ı. Biri diğerinin yerine geçmez: revizyon listesi eksiksiz olsa bile canlı sayfa bir eklenti ya da önbellek yüzünden onaylanan metinden farklı görünebilir. Bu nedenle onay akışında iki adım ayrı yazılır: revizyon sürümünün kaydı ve canlı sayfa karşılaştırması.

Kendi kurulumunuzda doğrulama denemesi

Belge varsayılan davranışı anlatır; sitenizdeki tema, eklenti ve sürüm farklı sonuç verebilir. Aşağıdaki deneme, bir test yazısında on dakikada yapılabilir ve hangi bilginin revizyonda izlendiğini gösterir. Denemeyi canlı bir misafir yazıda değil, bu iş için açılmış bir taslakta yapın.

1. Bir test yazısı açın ve metne iki paragraf yazın; kaydedin.
2. Başlığı değiştirin ve kaydedin. Revizyon ekranında başlık farkının göründüğünü doğrulayın.
3. Bir paragrafa link ekleyin ve rel değerini sponsored yapın; kaydedin. Revizyonda link ve özniteliğin görünüp görünmediğine bakın.
4. Kategori ve öne çıkan görseli değiştirin; kaydedin. Bu değişikliklerin revizyonda görünüp görünmediğine bakın. Belge bu alanlar için güvence vermez.
5. İki revizyonu karşılaştırma modunda yan yana açın.
6. Bir revizyonu geri yükleyin ve link özniteliğinin geri yüklenen sürümde durduğunu doğrulayın.
7. Deneme sonuçlarını kayıt politikanıza yazın: hangi alan revizyonla izleniyor, hangisi için dış kayıt gerekiyor.

Deneme sonucunu yazılı tutmak, yeni bir editör işe başladığında "revizyon neyi kapsıyor?" sorusunu cevaplar. Sonuç, sürüm yükseltmelerinden sonra yeniden denenmelidir, çünkü belge sürüme göre ekran değişikliklerini kaydeder.

Revizyon, görünür tarih ve okuyucu

Okuyucu revizyon listesini görmez; yalnız sayfadaki tarihi ve varsa güncelleme notunu görür. Bu yüzden revizyon sayısı ile okuyucuya gösterilen "güncellendi" bilgisi arasında bir politika kararı bulunmalıdır. Her kayıtta tarih değişirse, tarih anlamını yitirir. Her kayıtta değişmezse, önemli bir düzeltme okuyucuya hiç yansımaz. Uygulama önerisi: tarih kararını revizyona değil, değişikliğin içeriğe etkisine bağlayın ve kararı değişiklik kaydında tutun. Google'ın Article sayfası dateModified için güncelleme eşiği vermez, bu yüzden eşik yayıncının politikasındadır.

Geri alma sonrası tarih

Bir revizyonu geri yüklediğinizde sayfadaki değişiklik tarihi de değişmiş olabilir; temanız ya da eklentiniz tarihi nasıl ürettiğine bağlıdır ve belge bunu anlatmaz. Geri yüklemeden sonra görünür tarihi ve yapılandırılmış veriyi kontrol edin; tarih içeriğin gerçek durumuyla uyuşmuyorsa düzeltin.

Revizyonun sınırlarını ekibe anlatmak

Editör ekibinde herkes revizyonun ne yapıp ne yapmadığını aynı biçimde bilmelidir. Sık duyulan yanlış anlamalar kısa bir tabloyla düzeltilebilir. Tablo, eğitim ya da yeni editör için bir sayfalık bilgi notu olarak kullanılabilir.

Örnek senaryo: bir ev dekorasyonu blogu

Örnek senaryo: Bir ev dekorasyonu blogu, bir boya markasının danışmanından "küçük salonlar için renk seçimi" yazısı kabul eder. Yazar taslağı editörün hesabıyla yükler ve onay notunda bunu belirtir. Editör ilk turda iki olgu cümlesini çıkarır, ikinci turda yazarın yanıtını işler ve üçüncü turda marka linkine sponsored verir. Her turun sonunda onay notuna revizyon sürümünü yazar. Sitede revizyon sınırı olarak beş değeri seçilmiştir; yayın sonrası iki düzeltme daha geldiğinde ilk sürüm revizyon listesinde görünmez olur, ama onay notundaki kopya ve dış kayıttaki metin yeterli kanıt sağlar. Yayın sonrası bir geri yükleme gerekirse, editör önce kayıt tablosuna bakar ve sponsored değerinin geri yüklenen sürümde durduğunu doğrular.

Aynı blogda iki ay sonra başka bir editör, yazının ilk sürümünü görmek ister. Revizyon listesinde ilk kayıt yoktur, çünkü sınır nedeniyle silinmiştir. Editör dış kayıttaki metne ve onay notuna bakar, onaylanan sürümün tarihini ve saatini oradan okur ve geçmişi eksiksiz anlatır. Bu durum, sınır koyma kararının yazılı politikada neden gerekçesiyle yer alması gerektiğini gösterir: kayıp bir sürüm, planlanmış bir sonuçtur ve dış kayıt onun için hazırlanmıştır.

Uygulama önerisi: karar defterindeki her satıra revizyon numarasını, yazara gönderilen notun tarihini ve kapanış tarihini yazın; böylece hangi tur hangi isteği karşıladı sorusu sonradan tek bakışta cevaplanır.

Sık Sorulan Sorular

WordPress revizyonları misafir yazı için yeterli bir değişiklik kaydı mı?

Metin farkı için yeterlidir; değişikliğin nedenini, rel kararını ya da onay notunu taşımaz. Belge varsayılan olarak başlık, yazar, içerik ve özet alanlarının izlendiğini söyler. Karar kayıtları için dış bir kayıt gerekir.

Revizyon sayısını sınırlarsam ne olur?

Belgeye göre sıfırdan büyük bir tamsayı tanımlarsanız o kadar revizyon (artı kullanıcı başına bir otomatik kayıt) saklanır ve yazı yeniden güncellendiğinde eski revizyonlar otomatik silinir. İlk onaylanan sürüm kaybolabilir.

Otomatik kayıt yayınlanmış içeriği değiştirir mi?

Belgeye göre otomatik kayıtlar yayınlanmış içeriğin üzerine yazmaz; özel bir revizyon türü olarak saklanır ve kullanıcı başına yazı başına en fazla bir tane bulunur.

Revizyonları arayüzden silebilir miyim?

Belge, revizyon silmek için bir API işlevi olduğunu ancak arayüz bulunmadığını söyler. Toplu temizlik bir geliştirici işi olabilir; yapmadan önce yedek alın.

İki revizyonu karşılaştırmak mümkün mü?

Belgeye göre klasik revizyon ekranında iki uçlu kaydırıcıyla çalışan Compare any two revisions modu iki seçili revizyonu karşılaştırır. WordPress 7.0'dan itibaren yeni ekran açılır; klasik ekrana oradan geçilir. Sürüm bilgisi değişebilir.

Revizyon tarihi dateModified'ı belirler mi?

WordPress revizyon belgesi bu konuda bir ifade içermez. Google'ın Article sayfası dateModified'ı en son değiştirilme tarihi ve saati olarak tanımlar. Temanız ya da eklentiniz değeri nasıl üretiyorsa onu kendi kurulumunuzda doğrulayın.

Sonuç

Revizyonları açık tutun, herkes kendi hesabıyla çalışsın, her onay turu bir revizyon sürümüne ve onay notuna bağlansın. Revizyon sınırı koyacaksanız ilk onaylanan sürümü kaybetmeyecek bir sayı seçin ve metin dışındaki kararları (neden, rel, onay) dış bir kayıtta tutun.

Yayın tarafında bir yerleştirme ya da misafir yazı akışı kurmak istiyorsanız, tanıtım yazısı hizmet sayfasında seçenekleri ve yayın koşullarını görebilirsiniz.