데이터베이스 가져 오기에서 텍스트 위젯 데이터가 손실되는 이유는 무엇입니까?

개발 시스템에서 WordPress에 사이트를 만들었습니다. 우리가 사용하는 테마에는 (사이드 바 및 프론트 페이지)에 텍스트를 표시하기위한 수많은 위젯 영역이 있습니다. 이 모든 영역에서 간단한 텍스트 위젯을 사용하여 디스플레이 정보를 넣었습니다.

사이트를 프로덕션으로 마이그레이션 할 때 WP-DB-Backup 플러그인을 사용하여 데이터베이스의 스냅 샷을 만들었습니다. 그런 다음 결과 .sql 파일을 편집하여 프로덕션 사이트를 가리 키도록 모든 파일 경로와 URL 참조를 업데이트했습니다.

데이터베이스, 웹 사이트를 만들고 모든 파일을 프로덕션 사이트로 복사 한 후 mysql 명령 프롬프트에서 .sql 파일을 실행하여 데이터를 새 데이터베이스로 가져옵니다.

그러나 프로덕션 사이트로 이동하면 일부 텍스트가 표시되고 일부는 표시되지 않습니다. 사이트의 위젯 섹션을 살펴보면 일부 위젯 영역에서 텍스트 위젯이 누락되었습니다. 텍스트 위젯은 "비활성 위젯"영역에서도 보이지 않으며 단순히 존재하지 않습니다.

BackWPup 플러그인을 사용하여 프로세스를 반복하려고 시도했지만 데이터베이스를 덤프 할 때 SQL 구문이 다릅니다.

가져 오는 동안 텍스트 위젯 데이터가 손실되는 이유는 무엇입니까?

문제가있는 곳 :

그런 다음 결과 .sql 파일을 편집하여 프로덕션 사이트를 가리 키도록 모든 파일 경로와 URL 참조를 업데이트했습니다.

당신은 그렇게 할 수 없습니다. 워드 프레스는 많은 옵션을 "직렬화 된 데이터"로 저장하는데, 여기에는 사물의 문자열 내용 과 길이 가 모두 포함 됩니다. 따라서 URL을 수정하고 길이가 변경되면 직렬화 된 데이터가 더 이상 정확하지 않으며 PHP는이를 거부합니다.

장기적인 문제는 기본적으로 잘못하고 있다는 것입니다. 데이터를 마이그레이션 할 개발 사이트를 설정하는 경우 프로덕션 사이트와 정확히 동일한 URL이 있어야합니다. HOSTS 파일을 수동으로 편집하여 프로덕션 도메인 (example.com과 같은)에 다른 IP 주소 (예 : 127.0.0.1)를 부여하면 "프로덕션"URL이 개발 사이트가됩니다. 그런 다음 해당 프로덕션 URL을 사용하여 데이터와 링크 및 기타 모든 것을 생성 할 수 있으며 데이터를 마이그레이션 할 때 데이터를 변경할 필요가 없습니다.

그러나 단기적으로는 SQL 파일에서 간단한 텍스트 검색 / 대체를 사용하지 마십시오. 아시다시피, 이로 인해 문제가 발생합니다.

그리고 그것을 제안하는 것을 망설이는 동안, 이러한 깨진 직렬화를 처리하기 위해 WordPress 핵심 코드를 변경하는 방법이 있습니다. wp-includes / functions.php 파일을 수정하고 maybe_unserialize () 함수를 다음과 같이 변경해야합니다.

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]); }  

이것은 가능한 장기적인 해결책이 아닙니다. 지금 당장 일하고 일하는 데만 사용해야합니다. 장기적으로 개발 프로세스를 수정하여 이러한 종류의 URL 뭉치를 시작할 필요가 없도록해야합니다.

이 문제를 해결하기 위해 항상 여기에 제공된 WordPress Serialized Search & Replace 도구를 사용합니다. 문제없이 완벽하게 작동합니다. 모든 사이트 마이그레이션 요구 사항에서 오랫동안 이것을 사용해 왔습니다. 이것은 개발 데이터베이스를 프로덕션으로 마이그레이션하는 문제를 실제로 처리합니다.

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

오토의 대답은 현장에있다. 나는 또한 이것을 어려운 방법으로 발견했다.

그러나 http://spectacu.la/search-and-replace-for-wordpress-databases/ 의 멋진 스크립트를 사용 하여이 문제를 해결할 수있었습니다 .

워드 프레스 및 새 URL / 도메인 이름으로 마이그레이션하려면 다음을 수행하십시오.

1. 기존 워드 프레스의 DB 덤프 (예 : phpmyadmin 사용)를 가져옵니다.
2. 덤프를있는 그대로 (수정할 필요없이) 새 위치로 복원
3. spectacu.la에서 워드 프레스 홈 폴더로 스크립트 압축을 풉니 다 (플러그인이 아닙니다 ...)
4. 브라우저를 가리켜 서 새 사이트에서 스크립트를 실행하십시오 (예 : http : //new-website.url/searchreplacedb.php).
5. 새로운 워드 프레스 홈에서 스크립트를 삭제하는 것을 잊지 마십시오

데이터베이스 내보내기 파일에서 검색 및 바꾸기를 수행 할 때 OP가 열악 해졌으며 일부 직렬화 된 데이터 내에서 "wp_"발생이 변경되었습니다. 해결 방법은 정규식에 백틱을 포함시킨 다음 가져 오기 후에 데이터베이스에 남아있는 키를 수동으로 업데이트하여 검색 및 교체에서 더욱 포용 적입니다.

접두사를 마이그레이션하고 변경하고보다 수동적 인 접근 방식과 같이 다음을 수행하십시오 (이는 OP 문제 만 해결하고 사이트 URL 업데이트를 처리하지 않습니다)

1. 백업 및 데이터베이스 내보내기 SQL 파일을 새 환경으로 이동 (이 예에서는 파일 이름이 backup_YYYY-MM-DD.sql이라고 가정)
2. SQL 파일에서 대량 검색 및 교체를 수행하여 새 접두어를 사용하도록 테이블 이름을 변경하십시오 (SQL 파일을 가져 오기 전에). 이를 수행하는 한 가지 방법은 다음과 같은 Perl one-liner를 사용하는 것입니다 : perl -p -i.bak -e "s /`wp_ /`myprefix_ / g"backup_YYYY-MM-DD.sql
3. SQL 데이터를 데이터베이스로 가져 오기
4. 접두사가 하드 코딩 된 접 두부를 포함하는 _options 내의 키를 업데이트하십시오. update myprefix_options set option_name = concat ( 'myprefix _', substr (option_name, 4)) 여기서 option_name은 'wp_ %'
5. 하드 코딩 된 접두어를 포함하는 _user_meta 내의 키를 업데이트하십시오. update myprefix_usermeta set meta_key = concat ( 'myprefix _', substr (meta_key, 4)) 여기서 meta_key는 'wp_ %'

내가 사용 WP 마이그레이션 플러그인, 마녀을 대체 HTTP 및 폴더 패치를. 가져올 때 단일 문제가 발생했지만 생성 된 SQL의 맨 위에 다음 줄을 넣는 문제가 해결되었습니다.

/*!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 */;

@Yoav가 응답 한 Search And Replace 도구 (v2.1)를 사용해 보았지만 여전히 직렬화 된 데이터가 손상됩니다.