Veritabanım neden metin widget verilerini kaybediyor?

Geliştirme makinemizde WordPress'te bir site oluşturdum. Kullandığımız temada metni görüntülemek için çok sayıda widget bölgesi vardır (kenar çubuğu ve ön sayfa). Ekran bilgilerimizi koymak için tüm bu bölgelerde basit Metin widget'ları kullandım.

Siteyi üretime geçirdiğimde, veritabanının anlık görüntüsünü almak için WP-DB-Backup eklentisini kullandım. Ardından, .sql dosyasını, tüm dosya yollarını ve URL referanslarını güncellemek için üretim sitemize yönlendirmek üzere düzenledim.

Veritabanını, web sitesini oluşturup tüm dosyaları üretim sitesine kopyaladıktan sonra, verileri yeni veritabanına almak için .sql dosyasını mysql komut isteminden çalıştırın.

Ancak, üretim sitesine gittiğimde, bazı metinler ortaya çıkıyor ve bazıları görünmüyor. Sitenin pencere araçları bölümüne baktığımda, pencere araçları bölümlerinden bazılarında pencere araçları eksik. Metin widget'leri "Aktif Değil Widget" bölgesinde bile görünmüyor, sadece orada değiller.

BackWPup eklentisini kullanarak işlemi tekrarlamaya çalıştım, veritabanını dökerken SQL sözdiziminin farklı olduğunu fark ettim.

İçeri aktarma sırasında neden metin widget verilerini kaybediyorum?

Sorununuz burası:

Ardından, .sql dosyasını, tüm dosya yollarını ve URL referanslarını güncellemek için üretim sitemize yönlendirmek üzere düzenledim.

Bunu yapamazsın. WordPress, birçok şeyin hem dizelerin içeriğini hem de uzunluklarını içeren "serileştirilmiş veri" olarak saklar . URL'yi değiştirdiğinizde ve uzunluk değiştiğinde, seri hale getirilmiş veriler artık doğru olmaz ve PHP bunu reddeder.

Uzun vadeli sorun şudur, temelde yanlış yapıyorsunuz. Verilerinin taşınmasını sağlayacak bir geliştirme sitesi kuruyorsanız, başlamak için üretim sitenizle aynı URL’ye sahip olması gerekir. HOSTS dosyanızı, üretim alanına (example.com gibi) farklı bir IP adresi (127.0.0.1 gibi) vermek için el ile düzenleyebilirsiniz; böylece "üretim" URL'si yalnızca sizin için geliştirme sitesi haline gelir. Daha sonra bu üretim URL'sini kullanarak verilerinizi ve bağlantılarınızı ve diğer her şeyi oluşturabilirsiniz ve verileri taşıdığınızda, bununla ilgili hiçbir şeyin değiştirilmesi gerekmez.

Ancak kısa vadede, SQL dosyasında basit bir metin arama / değiştirme kullanmayın. Keşfettiğiniz gibi, bu işleri kırar.

Ve bunu önermek için tereddüt ederken, bu bozuk serileştirmeleri işlemek için WordPress çekirdek kodunu değiştirmenin bir yolu var. Wp-include / functions.php dosyasını değiştirmelisiniz ve maybe_unserialize () işlevini şuna değiştirmelisiniz:

function maybe_unserialize( $original ) {
    if ( is_serialized( $original ) ) {
        $fixed = preg_replace_callback(
            '!(?<=^|;)s:(\d+)(?=:"(.*?)";(?:}|a:|s:|b:|i:|o:|N;))!s',
            'serialize_fix_callback',
            $original );
        return @unserialize( $fixed );
    }
    return $original;
}
function serialize_fix_callback($match) { return 's:' . strlen($match[2]); }  

Bu uygulanabilir bir uzun vadeli çözüm DEĞİLDİR. Sadece sizi şimdi çalışmaya ve çalışmaya teşvik etmek için kullanılmalıdır. Uzun vadede, geliştirme sürecinizi düzeltmeniz gerekir, böylece başlamak için bu tür bir URL munging yapmak zorunda kalmazsınız.

Bu konuyla başa çıkmak için her zaman burada sağlanan WordPress Seri Arama ve Değiştirme aracını kullanıyorum. Herhangi bir konuda mükemmel çalışıyor. Bunu tüm site taşıma gereksinimlerimde uzun zamandır kullanıyorum. Bu gerçekten kalkınma veritabanını üretime geçirmekle ilgili sorunların çaresine bakıyor.

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Otto'nun cevabı tam anlamıyla açıktır. Bunu zor yoldan da keşfettim.

Ancak, http://spectacu.la/search-and-replace-for-wordpress-databases/ adresinde havalı bir komut dosyası kullanarak bunun üzerinde çalışmayı başardım.

WordPress'inizi ve yeni bir url / domain adına geçirmek için aşağıdakileri yapın:

1. Mevcut wordpressin DB dökümünü (örneğin phpmyadmin kullanarak) alın.
2. Dökümü olduğu gibi geri yükleyin (değişiklik yapılmasına gerek yoktur) yeni konumunuza
3. Komut dosyasını spectacu.la adresinden wordpress ana klasörünüze çıkartın (bu bir eklenti değil ...)
4. Komut dosyasını yeni sitenizde tarayıcınızı işaretleyerek çalıştırın, örneğin http: //new-website.url/searchreplacedb.php
5. Komut dosyasını yeni wordpress ana sayfanızdan silmeyi unutmayın

OP, veritabanı dışa aktarma dosyasında arama ve değiştirme yaparken çok kısaydı ve bazı serileştirilmiş verilerin içinde "wp_" oluşumunu değiştirdi. Çözüm, düzenli ifadenin içindeki backtick'i ekleyerek ve sonra içe aktardıktan sonra veritabanında kalan anahtarları elle güncelleyerek arama ve değiştirme işleminde daha öncelikli olacaktır.

Öneki taşıyorsanız ve değiştiriyorsanız ve daha manuel bir yaklaşım gibi, aşağıdakini yapın (bu yalnızca OP’lerin kaygılarını giderir ve site URL’sinin güncellenmesiyle ilgilenmez)

1. Veritabanınızı yedekleyin ve dışarı aktarın SQL dosyasını yeni ortama taşıyın (örneğim, backup_YYYY-MM-DD.sql dosyasının adını alır)
2. Yeni ön ekinizi kullanmak için tablo adlarını değiştirmek için SQL dosyasında bir toplu arama ve değiştirme yapın (SQL dosyanızı içe aktarırken PRIOR!). Bunu yapmanın bir yolu bir Perl gibi bir liner kullanmak olacaktır: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-AA-GG.sql
3. SQL verilerinizi veritabanına alın
4. Sabit kodlanmış öneki içeren _options içindeki tüm anahtarları güncelleyin: myprefix_options kümesini güncelle seçenek_adı = concat ('myprefix _', substr (seçenek_adı, 4)) burada seçenek_adı 'wp_%'
5. _User_meta içindeki kodlanmış öneki içeren anahtarları güncelle: güncelleme myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) burada meta_key 'wp_%'

WP Migrate eklentisini kullandım , cadı http ve klasör yamalarını değiştirdi. İçe aktarırken tek bir sorunla karşılaştım, ancak aşağıdaki satırları oluşturulan sql'nin en üstüne koyarak çözdüm:

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

Ayrıca @Yoav tarafından yanıtlanan Ara ve Değiştir aracıyla (v2.1) da denedim, ancak yine de serileştirilmiş verilerimi bozuyor.