WordPress Verilənlər Bazasında URL-i Serializasiya Olunmuş Məlumatı Sındırmadan Dəyişmək

WordPress verilənlər bazasında adi UPDATE ... SET column = REPLACE(column, 'oldurl', 'newurl') əmrini işlətməyin. O, mətni düzgün dəyişəcək və eyni anda tənzimləmələrinizi məhv edəcək, çünki WordPress massivləri və obyektləri PHP-serializasiya olunmuş sətirlər kimi saxlayır və bu format daxilindəki hər sətrin bayt uzunluğunu qeyd edir. Xam SQL əvəzləməsi mətni yenidən yazır, amma qeyd olunmuş uzunluğa toxunmur və dəyər oxunmaz hala düşür.

Bunun əvəzinə serializasiyanı başa düşən alət istifadə edin. Əmr sətrində bu, wp search-replace əmridir. Əvvəlcə verilənlər bazasının ehtiyat nüsxəsini götürün, sonra quru rejimdə işlədin, sonra isə əsl əməliyyatı aparın.

Əslində nə sınır

PHP-serializasiya olunmuş sətir belə görünür:

s:18:"http://example.com"

Buradakı 18 ondan sonra gələn mətnin bayt uzunluğudur. Sayın — http://example.com tam olaraq 18 simvoldur.

İndi saxlanılmış bir mövzu tənzimləməsini təsəvvür edin:

a:1:{s:4:"logo";s:18:"http://example.com";}

http:// ifadəsini https:// ilə adi SQL əvəzləməsi ilə dəyişəndə belə alınmalıdır:

a:1:{s:4:"logo";s:19:"https://example.com";}

Ancaq belə alınmır. Nəticə budur:

a:1:{s:4:"logo";s:18:"https://example.com";}

Sətir artıq 19 baytdır, amma hələ də 18 olduğunu iddia edir. PHP elan olunmuş uzunluğu oxuyur, 18 bayt irəli gedir, gözlədiyi yerdə bağlayan dırnaq və nöqtəli vergül tapmır və əl çəkir. Bütün massiv unserialize olunmur.

Nə üçün səssizcə uğursuz olur

Bu səhvi belə bahalı edən məhz həmin hissədir. WordPress xəta atıb dayanmır. Parametri oxuyanda dəyəri öz unserialize köməkçisindən keçirir, PHP yararsız məlumat üçün false qaytarır və WordPress kodunuza elə bir dəyər verir ki, sanki parametr heç vaxt təyin edilməyib. Plagin və ya mövzu isə öz standart dəyərinə qayıdır.

Yəni əlamət xəta səhifəsi deyil. Əlamətlər bunlardır:

• Vidjetlər yan panellərdən yox olur
• Fərdiləşdirmə tənzimləmələri mövzunun standart dəyərlərinə qayıdır
• Səhifə qurucusunun maket məlumatı boş qayıdır və səhifə boş açılır
• Plagin tənzimləmə səhifələri təzəcə quraşdırılmış kimi görünür
• Menyular təyin olunduqları yerləri itirir

İdarə panelində heç nə bir problemin olduğunu bildirmir. Sətir hələ də verilənlər bazasındadır və düzgün görünən mətnlə doludur. Sadəcə uzunluq prefiksi bir-iki bayt fərqlidir. Serializasiya açılmayanda PHP bildiriş verir, amma xətaların göstərilməsi söndürülmüş canlı saytda bunu heç kim görmür. WP_DEBUG sabitini WP_DEBUG_LOG ilə birlikdə aktiv edib WP_DEBUG_DISPLAY dəyərini false etsəniz, həmin bildirişlər oxuya biləcəyiniz jurnal faylına düşəcək.

Zərər də bərabər paylanmır. Sadə skalyar dəyərlər — siteurl, home, adi yazı mətni, öz sütununda duran URL — sadəlövh əvəzləmədən problemsiz çıxır. Yalnız serializasiya olunmuş dəyərlər sınır. Səhv əvəzləmənin ilk baxışdan işləmiş kimi görünməsinin səbəbi də budur.

Heç nəyə toxunmadan əvvəl wp-config.php faylını yoxlayın

wp-config.php faylında WP_HOME və ya WP_SITEURL təyin olunubsa, bu sabitlər verilənlər bazasındakı hər şeydən üstündür. wp_options cədvəlini dəyişmək tamamilə təsirsiz görünəcək. Problemin verilənlər bazasında olduğu qənaətinə gəlməzdən əvvəl bu sətirləri axtarın:

define( 'WP_HOME', 'http://example.com' );
define( 'WP_SITEURL', 'http://example.com' );

Ya onları yeni URL-ə uyğunlaşdırın, ya da silin və idarəni verilənlər bazasına buraxın.

Əvvəlcə ehtiyat nüsxə — həqiqətən

Serializasiya sınığını geri qaytarmaq həmişə asan olmur. Uzunluq prefiksi ilə məzmun bir-birinə uyğun gəlmədikdə orijinal dəyəri sınmış dəyərdən bərpa etmək mümkün deyil — ilkin sətri bilmədən düzgün uzunluğun nə olduğunu bilmək olmaz. Yeganə real geri qaytarma yolu ehtiyat nüsxədir.

wp db export backup-before-replace.sql

WP-CLI yoxdursa, mysqldump ilə:

mysqldump -u USER -p DBNAME > backup-before-replace.sql

Mümkünsə, faylı serverdən kənarda saxlayın. Sayt kökündə duran ehtiyat nüsxə həm bərpa nöqtəsi, həm də təhlükəsizlik problemidir.

Təhlükəsiz əmr

WP-CLI-nin search-replace əmri hər dəyəri açır, dekodlanmış strukturu gəzir, onun içində əvəzləmə aparır və düzgün uzunluqlarla yenidən serializasiya edir. Əvvəlcə quru rejim:

wp search-replace 'http://example.com' 'https://example.com' --dry-run --all-tables --skip-columns=guid

Hesabatı oxuyun. Orada hər cədvəl və sütun üzrə neçə əvəzləmə olacağı yazılır. Cədvəl siyahısı qəribə görünürsə və ya tanımadığınız cədvəldə minlərlə uyğunluq varsa, dayanın və əsl əməliyyatdan əvvəl baxın.

Sonra işə salın:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --report-changed-only

Parametrlər haqqında dürüst qeydlər:

• --all-tables WordPress-in özünün qeydiyyatdan keçirmədiyi cədvəlləri də əhatə edir və plagin məlumatları çox vaxt məhz orada olur. Bu parametr olmadan bəzi plagin cədvəlləri tamamilə kənarda qalır.
• --skip-columns=guid vacibdir. guid canlı URL yox, lent oxucuları üçün daimi identifikatordur. Onu yenidən yazmaq abunəçilərin bütün arxivinizi yeni yazı kimi görməsinə səbəb ola bilər.
• Sonda kəsik xətt olmadan və toxunmaq istəmədiyiniz protokol variantları olmadan axtarın. Sadəcə example.com yazsanız, e-poçt ünvanlarına və yazı mətnindəki hər qeydə də toxunacaqsınız.

Əmr sətrindən istifadə edə bilmirsinizsə, serializasiyanı başa düşən köçürmə plaginləri eyni dekodlaşdırma işini idarə panelindən görür. Axtardığınız davranış açıq şəkildə “serializasiya olunmuş məlumatı emal edir” kimi təsvir olunmalıdır; alət bunu yazmırsa, etmədiyini fərz edin.

Hansı cədvəllər və sütunlar iştirak edir

Cədvəl	Sütun	Serializasiya riski
wp_options	option_value	Yüksək — vidjetlər, mövzu tənzimləmələri, tranzientlər, plagin parametrlərinin çoxu
wp_postmeta	meta_value	Yüksək — səhifə qurucusu maketləri, xüsusi sahə massivləri
wp_usermeta	meta_value	Yüksək — səlahiyyətlər, ekran və idarə paneli üstünlükləri
wp_termmeta	meta_value	Orta — plaginlərdən asılıdır
wp_posts	post_content, guid	Məzmun üçün aşağı, amma qısakod atributları və blok kodu URL daşıyır
wp_comments	comment_content, comment_author_url	Aşağı
wp_links	link_url, link_image	Aşağı və çox vaxt istifadə olunmur

Multisaytda bunlara wp_blogs, wp_site, wp_sitemeta və hər sayt üçün wp_2_options, wp_3_options və s. əlavə olunur. Multisaytda URL dəyişikliyinin adi axtar-əvəzlə əməliyyatından kənar əlavə qaydaları var — onu ayrıca iş kimi qəbul edin.

search-replace əmrinin tam həll etmədiyi hallar

Məhdudiyyətlər barədə dürüst danışaq:

Verilənlər bazasında saxlanılan JSON. Bəzi səhifə qurucuları maket məlumatını kəsik xətləri qaçış simvolu ilə yazılmış JSON kimi saxlayır, yəni URL-iniz https://example.com yox, https:\/\/example.com şəklində görünür. Normal formanın axtarışı onu tapmayacaq. Qaçış simvollu variant üçün ikinci keçid lazım ola bilər. Nüsxə üzərində sınayın.

Base64 ilə kodlanmış dəyərlər. Plagin tənzimləmələri saxlamazdan əvvəl kodlayırsa, mətnə əsaslanan heç bir əvəzləmə URL-i ümumiyyətlə görə bilmir. Belə tənzimləmələri adətən plaginin öz ekranından yenidən daxil etmək lazım gəlir.

Fayllara sabit yazılmış URL-lər. functions.php faylına, uşaq mövzu şablonuna və ya sabit resurs yoluna yazılmış hər şey verilənlər bazasında deyil və ona toxunulmayacaq. Mövzu qovluğunu ayrıca grep edin.

Keşlənmiş və hazırlanmış nəticə. Obyekt keşi, səhifə keşi və CDN nüsxələri düzgün əvəzləmədən sonra da köhnə URL-ləri verməyə davam edir. Onları təmizləyin, sonra əvəzləmənin uğursuz olduğunu düşünməzdən əvvəl yenidən yoxlayın.

Səhv sorğunu artıq işlətmisinizsə

Ehtiyat nüsxəni bərpa edin. Cavab budur və çox vaxt işləməyən təmir prosedurunu təklif etmək əvəzinə bunu açıq demək daha düzgündür.

Ehtiyat nüsxə yoxdursa, bərpa yolu dardır: heç vaxt serializasiya olunmamış dəyərlər salamatdır, sınmış serializasiya dəyərlərini isə ya əllə yenidən qurmaq, ya da müvafiq tənzimləmə səhifəsini yenidən yadda saxlamaqla sıfırlamaq lazımdır. Vidjet sahəsini yenidən yadda saxlamaq, menyu yerini yenidən seçmək və ya plaginin parametrlərini yenidən daxil etmək sınmış dəyərin üzərinə təzə və düzgün serializasiya olunmuş dəyər yazır. Yorucudur, amma işləyir və zədəli sətirləri yerində qoyub sayta növbəti dəfə baxacaq adamı çaşdırmaqdan yaxşıdır.

Əmrləri işə salmazdan əvvəl onları hazırlamaq üçün WordPress axtar və əvəz et SQL alətindən istifadə edin — orada hansı sütunlara adi SQL ilə toxunmağın təhlükəsiz olduğu, hansılarının isə serializasiyanı başa düşən emal tələb etdiyi görünür, beləliklə əmrə keçməzdən əvvəl bölgünü görə bilirsiniz.