Alan grubunu güvenle değiştirme

Her alan bir sütundur; bu yüzden kayıtlı bir alan grubunu düzenlemek gerçek bir veritabanı tablosunu değiştirir. Eklenti bunu, değerleri yanlışlıkla kaybetmemeniz için birkaç güvenlik kuralıyla yapar.

Güvenlik kuralları

Her değişikliğin etkisi

Kayıttan sonra eklenti ne yaptığını bildirir. Yeniden adlandırma renamed, tür değişikliği type: text→number olarak görünür; yedekler ise migration_backups altında listelenir. Örneğin name adlı bir Text alanı Number'a dönüştürüldüğünde editör şunu gösterir: A type change could lose data, so the old values were copied to: name__bak. Check the converted values, then delete the backup columns under Table health.

Alanı yeniden adlandırma

1. Alanın Field key (SQL column name) ayarını değiştirin. Satır şu uyarıyı gösterir: Key rename will run SQL RENAME COLUMN.
2. Kaydedin. Değerler korunur.
3. Eski anahtarı kullanan şablonları, kısa kodları ve kodu güncelleyin.

REST API'de yeniden adlandırma, aynı uid ile yeni bir key göndermektir (bkz. Alan grubu oluşturma).

Alan türünü değiştirme

Riskli değişikliklerde This type change can lose data iletişim kutusu görünür. Neyi kaybedebileceğiniz yöne bağlıdır:

Üç seçeneğiniz var:

1. Cancel: hiçbir şey değişmez.
2. Convert with a backup: önce eski değerler {key}__bak sütununa gider. Kayıttan sonra dönüştürülen değerleri kontrol edin. Memnun kaldığınızda yedek sütunu Table health › Leftover columns › Remove from DB altından silin.
3. Create a new field instead: yeni türde ikinci bir alan ekler ve eski sütuna dokunmaz. Değerleri kendi kurallarınızla taşımak istediğinizde önerilen yol budur (bir betikle kopyalayın, ardından eski alanı kaldırın).

Bu adda bir yedek sütun zaten varsa, sonraki {key}__bak_2, {key}__bak_3 şeklinde adlandırılır.

Yedek sütunları nasıl inceleyip kaldıracağınız için Table health bölümüne bakın.

Dizinli bir alanın türünü değiştirmek, yeni tür dizinlenemiyorsa dizini de temizler. REST API ile kaydediyorsanız bu durumda "indexed": false değerini kendiniz gönderin; aksi halde veritabanı reddeder (BLOB/TEXT column ... used in key specification without a key length) ve hiçbir şey değişmez.

Alanı kaldırma

Alan editörden ve düzenleme ekranlarından çıkar; sütunu değerlerini korur. Sütun, Table health içinde Leftover columns altında (Table differences paneli) ve REST şema yanıtında orphan_columns olarak görünür.

Buradan şunları yapabilirsiniz:

Kaldırılmış bir alanın adını yeniden kullanma

Anahtarı bir leftover sütunla aynı olan yeni bir alan eklerseniz, kayıt önce şu iletişim kutusuyla durur: These names hold saved values:

Daha önce kaldırdığınız bir alan aynı adı kullanıyordu ve değerleri hâlâ veritabanında. Yeni alanın bu değerlerle ne yapacağını seçin.

Seçiminizi uygulamak için iletişim kutusunda Save changes düğmesine tıklayın veya geri dönmek için Cancel seçin. (REST: kayıt, 409 durumu, wpmcf_orphan_columns kodu ve bir sütun listesiyle yanıt verir; isteği "orphan_columns": { "key": "reclaim" } veya "fresh" ile yeniden gönderin.)

Büyük tablolar

Çok satırlı bir tabloyu değiştirmek bir web isteğinden uzun sürebilir. Tabloda yaklaşık 100.000 satır veya daha fazlası olduğunda (bir tahmin), değişiklik kuyruğa alınır ve Action Scheduler aracılığıyla arka planda çalışır. Saklanan Group veya Repeater değerlerini yeniden yazan değişiklikler, bu iş PHP'de satır satır yürüdüğü için daha erken, yaklaşık 5.000 satırdan itibaren başlar. Geliştiriciler ilk eşiği wpmcf/fields/schema_background_rows filtresiyle değiştirebilir.

Bir değişiklik kuyruktayken veya çalışırken:

• Editör Applying database changes başlığını ve şu mesajı gösterir: This table is large, so the changes run in the background. The site uses the previous version until they finish. You can leave this page. Kartta ise Updating rozeti görünür. Bittiğinde: The database changes are done.
• Site, değişiklik tamamlanana kadar önceki tanımı kullanmaya devam eder.
• Bu sırada kaydedilen değerler korunur ve değişiklik tamamlandığında yazılır (yeniden adlandırılan alanlar yeni sütunlarına eşlenir).
• Save changes devre dışı kalır ve API 409 (wpmcf_schema_busy) ile şu mesajı döndürür: Database changes for this field group are still being applied. Save again when they are done.
• Kuyruğa alınmış bir değişikliği (çalışan bir değişikliği değil) DELETE /wpmcf/v1/field-groups/{key}/schema-job ile iptal edebilirsiniz; başarısız bir değişiklik de aynı yolla kapatılabilir (Dismiss düğmesi).

İş başarısız olursa editör, veritabanı mesajıyla birlikte The last changes could not be applied ve The site still uses the previous version of this field group. mesajlarını gösterir. 15 dakika sonra hâlâ “çalışıyor” görünen bir iş kesintiye uğramış sayılır: The database change was interrupted before it finished. Review Table health in the field group, then save again. Action Scheduler'ın çalışabilmesi gerekir (WP-Cron veya gerçek bir cron); bkz. Sorun giderme.

Kayıtta görebileceğiniz uyarılar

Sorun giderme