WordPress Search and Replace

WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…

WordPress는 데이터베이스의 수십 개 테이블에 절대 URL을 저장하므로, 도메인 변경이나 SSL 이동 시 이전 주소들이 게시물, 옵션 및 플러그인 설정 전체에 흩어집니다. 검색 및 바꾸기는 이를 안전하게 정리하는 방법입니다. 이 가이드에서는 KPanel에서 지원되는 두 가지 방법, 일반적인 세 번째 방법이 데이터를 손상시키는 이유, 그리고 결과를 검증하는 방법을 다룹니다.

필요한 경우

SSL을 활성화한 후 http://에서 https://로 이동합니다.
예를 들어 old-brand.co.nz에서 new-brand.co.nz로 도메인을 변경합니다.
스테이징을 프로덕션으로 푸시한 후, 스테이징 호스트명이 데이터베이스에 여전히 포함되어 있을 때입니다.
이전 자산 호스트를 중단하고 모든 이미지 URL을 한 번에 재지정합니다.
이전 전화번호나 단종된 제품명 등 많은 게시물에 걸친 대량 오타를 수정합니다.

검색 및 바꾸기는 모든 테이블의 행을 한 번에 다시 쓰며, 행별 실행 취소가 없습니다. 사소해 보이는 변경이라도 매번 백업을 시작하기 전에 작업합니다. KPanel은 아래에 설명된 기본 제공 도구를 사용할 때 자동으로 하나를 생성하지만, 명령을 직접 실행하는 경우 백업은 사용자의 책임입니다. 백업 생성을 참조하세요.

일반 SQL REPLACE를 실행할 수 없는 이유

이것은 WordPress 데이터베이스 작업에서 가장 심각한 실수이므로, 방법을 선택하기 전에 이해할 가치가 있습니다.

WordPress는 플러그인 설정, 테마 옵션 및 위젯 데이터를 PHP 직렬화 문자열로 저장합니다. 직렬화 문자열은 내부의 모든 값의 길이를 기록합니다. 예:

a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}

s:26는 URL이 26자라는 것을 나타냅니다. 일반 SQL REPLACE()을 사용하여 http://을 https://로 바꾸면 텍스트는 27자가 되지만 저장된 길이는 여전히 26자를 주장합니다. 그러면 PHP는 전체 옵션을 직렬화 해제하기를 거부하고, 설정은 조용히 비어 있는 상태로 돌아갑니다. 테마 커스터마이저 설정이 사라지고, 슬라이더가 슬라이드를 잃고, 플러그인 라이선스가 등록 해제됩니다.

KPanel이 실행하는 WP-CLI 검색 및 바꾸기는 각 값을 직렬화 해제하고, 내부에서 바꾸고, 수정된 길이로 다시 직렬화합니다. 이것이 여기서 유일하게 문서화된 방법인 이유입니다.

WordPress 데이터베이스에 대해 UPDATE wp_options SET option_value = REPLACE(...) 또는 phpMyAdmin의 동등한 작업을 실행하지 마세요. 작동하는 것처럼 보이고, 영향을 받은 행을 보고하지만, 터치한 모든 직렬화 설정을 조용히 파괴합니다. 백업 복원 외에 다른 복구 방법이 없습니다.

방법 1: 검색 및 바꾸기 카드

거의 모든 사용자에게 올바른 선택입니다. 모든 WordPress 계획에서 사용할 수 있습니다.

KPanel에 로그인하여 왼쪽 사이드바에서 웹사이트를 클릭합니다.
사이트를 클릭합니다.
WordPress 탭을 연 후 빠른 작업 섹션을 엽니다.
검색 및 바꾸기 카드를 찾고 구성을 클릭합니다.
**찾기(이전 값)**에 기존 텍스트를 입력합니다.
바꾸기에 새 텍스트를 입력합니다.
**드라이 런(미리보기만, 변경 없음)**을 선택된 상태로 두고 미리보기를 클릭합니다.

드라이 런은 몇 개의 바꾸기가 수행될 것인지 보고하고 테이블과 열별로 개수를 나누므로, 커밋하기 전에 변경이 정확히 어디에 도달할지 볼 수 있습니다.

미리보기가 올바르게 보이면:

드라이 런을 선택 해제합니다.
실행을 클릭합니다.
대화상자를 확인합니다.

전체 백업이 자동으로 생성되고 바꾸기가 시작되며, 실행은 플러그인이 만든 테이블을 포함한 모든 테이블을 포함합니다.

가장 구체적인 문자열을 검색합니다. old-domain.co.nz을 바꾸면 mail.old-domain.co.nz 및 staging.old-domain.co.nz도 다시 쓰며, 이는 거의 필요한 것이 아닙니다. https://old-domain.co.nz처럼 스킴을 포함하면 일치가 더 정확해집니다.

방법 2: 콘솔에서 WP-CLI

콘솔은 플래그를 더 제어할 수 있는 동일한 엔진을 제공합니다. 관리형 계획에 표시되는 섹션 중 하나입니다. 다른 계획에서는 탭 스트립에 +8 Managed에서 링크가 대신 표시됩니다.

사이트를 열고, WordPress를 연 후 콘솔을 엽니다. 프롬프트는 이미 wp으로 시작하므로 나머지 명령만 입력합니다.

먼저 미리보기:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run

그 다음 실제로 실행:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables

콘솔은 사용자를 위해 백업을 생성하지 않습니다. 자동 사전 실행 백업은 방법 1에서 검색 및 바꾸기 카드를 사용할 때만 발생합니다. 여기서 명령을 실행하는 경우, 사이트의 백업 탭에서 직접 백업을 먼저 수행합니다.

유용한 플래그:

플래그	수행하는 작업
`--all-tables`	핵심 WordPress 테이블뿐만 아니라 플러그인이 만든 사용자 정의 테이블을 포함합니다
`--dry-run`	변경될 내용을 보고하고 아무것도 작성하지 않습니다
`--precise`	바꾸기에 SQL이 아닌 PHP를 사용합니다. 느리지만 어려운 직렬화 구조를 처리합니다
`--skip-columns=guid`	게시물 GUID를 그대로 둡니다(아래 참조)
`--report-changed-only`	출력을 실제로 변경된 테이블로 제한합니다

GUID에 대한 참고

모든 WordPress 게시물에는 guid 열이 있습니다. URL처럼 보이지만 링크가 아닌 식별자이며, 피드 리더는 이를 사용하여 이미 본 항목인지 판단합니다. 다시 작성하면 피드의 모든 게시물이 새 항목으로 다시 나타날 수 있습니다.

도메인을 영구적으로 변경하고 새로 시작할 때 GUID를 다시 작성합니다. 같은 도메인에서 HTTP에서 HTTPS로만 이동할 때는 --skip-columns=guid으로 건너뜁니다.

도메인 변경: 대신 사이트 URL 카드 사용

전체 목적이 사이트를 새 도메인으로 이동하는 것이라면 검색 및 바꾸기로 시작하지 마세요. 같은 빠른 작업 섹션에 있는 사이트 URL 변경 카드는 siteurl 및 home 옵션을 업데이트하고 한 번에 올바른 순서로 모든 테이블에 걸쳐 바꾸기를 실행합니다. 다른 방식으로 하면 WordPress가 자체 관리자를 로드할 수 없게 될 수 있습니다.

바꾼 후

작업을 완료하기 전에 이 목록을 살펴봅니다.

캐시를 비웁니다. 빠른 작업 섹션에서 캐시 비우기를 실행합니다. 사이트에서 전체 페이지 캐시를 사용하는 경우, WordPress에서 캐싱으로 이동하여 비웁니다.
다시 작성 규칙을 비웁니다. 같은 섹션에서 다시 작성 비우기를 실행하거나, wp-admin에서 설정을 열고 고유주소를 클릭한 후 아무것도 변경하지 않고 변경사항 저장을 클릭합니다.
사이트가 사용 중인 경우 CDN을 비웁니다 - 성능에서 Kapsule CDN으로 이동합니다. CDN 캐시 비우기를 참조하세요.
private 창에서 사이트를 로드하여 브라우저 캐시가 오도하지 않도록 합니다.
자물쇠를 확인합니다. SSL 이동 후 자물쇠가 없거나 경고가 표시되는 것은 URL이 남겨졌음을 의미합니다. 혼합 콘텐츠 경고 수정을 참조하세요.
까다로운 페이지를 클릭하여 확인합니다. 홈페이지 슬라이더, 헤더 로고, 페이지 빌더로 만든 모든 페이지, 그리고 스토어의 체크아웃. 이들은 직렬화 옵션에 살아있는 URL을 보유합니다.
캐싱 플러그인을 비웁니다 - 자체 설정 화면에서.

문제 해결

드라이 런이 0개의 바꾸기를 보고합니다. 문자열이 정확한 형식으로 데이터베이스에 없습니다. 후행 슬래시, www. 접두사 또는 스킴을 확인합니다. 먼저 호스트명만 검색하여 그곳에 있는지 확인해봅니다.

도메인 변경 후 이미지가 손상되었습니다. 미디어 URL은 wp_posts 및 wp_postmeta에 있으며 --all-tables에 의해 선택됩니다. 그러나 CDN이나 이미지 최적화 플러그인이 자체 다시 쓴 복사본을 캐시할 수 있습니다. CDN과 플러그인의 캐시를 비운 후 다시 로드합니다.

바꾼 후 설정이 사라졌습니다. 이것은 직렬화 문제이며, 원본 SQL이 아닌 여기의 도구를 통해 변경이 수행되었음을 의미합니다. 실행 전에 생성한 백업을 복원합니다. 백업에서 복원을 참조하세요.

스테이징 URL이 계속 나타납니다. 무언가 그들을 다시 채우고 있으며, 보통 예약된 푸시나 캐시된 옵션입니다. 스테이징 사용: 푸시 및 풀의 워크플로우를 확인하고 푸시할 때 URL 다시 작성이 선택되어 있는지 확인합니다.

WordPress 데이터베이스에서 검색 및 바꾸기 실행하기