배경: nginx와 wordpress를 사용하여 rpi4에서 여러 웹사이트를 실행하고 있습니다. 개발 및 테스트를 위해 사이트 중 하나를 로컬 네트워크에 복사하고 싶습니다. 데이터베이스와 WordPress 파일을 복사하고 포트 8082에서 수신 대기하고 데이터베이스를 백업하도록 구성 파일을 설정했습니다. 원래 웹사이트는 안전하고 https 연결 인증서를 사용하지만 로컬 복사본은 그렇지 않은 것 같습니다.
네트워크 192.168.0.213:8082에서 웹사이트에 접속하면 홈페이지로 이동하지만, 시도하는 모든 링크가 내 라이브 웹사이트로 리디렉션되기 때문에 로그인 페이지에 접속할 수 없습니다. 그래서 mysql 문을 통해 사이트 URL과 홈 페이지 URL을 업데이트했고 로그인 페이지에 액세스할 수 있었고 이제 홈 페이지를 제외한 다른 모든 링크가 작동했습니다. 이제 홈 페이지는 다음으로 리디렉션됩니다.
192.168.0.213:8082/192.168.0.213:8082/
존재하지 않는 페이지입니다. 이것을 알아낼 수 있다면 내가 원하는 것을 달성하는 데 매우 가까워진 것 같습니다. nginx이므로 .htaccess 파일은 없지만 필요한 모든 것을 수정하고 무엇이든 할 수 있는 루트 액세스 권한을 갖게 되어 기쁩니다. 저는 SQL, 명령줄 등을 알고 있지만 이전에 이 작업을 수행한 적이 없어서 막혔습니다. PHP 파일에서 자체적으로 추가되지 않도록 변경하거나 조정하기 위해 무엇을 찾고 있는지 잘 모르겠습니다.
기본적으로 제가 했던 "http://"를 추가하여 여기에 있는 수정 사항을 시도했습니다. 나는 아직도 이것에 대해 멍청하고 내 로컬 호스트를 올바르게 참조하고 있지 않은지 궁금합니다.
네, 이곳은 "chadsmancave"라는 블로그 사이트이고 모든 내용은 chadsmancavebkp에서 복사되었습니다. 데이터베이스에 대한 변경 사항은 내가 게시한 버전이 아닌 로컬 버전에만 반영되므로 두 버전을 모두 호스팅하고 있음을 확인할 수 있습니다.
다음 스크린샷이 도움이 되기를 바랍니다.
나는 이 질문에 대답하고 있지만 Chris Haas가 말한 내용이 문제를 해결했기 때문에 그의 대답을 받아들입니다.
실제로 저는 Chrome을 사용하고 있는데 해당 리디렉션이 유지됩니다! f5가 아닙니다. 그렇지 않으면 전체 브라우저 데이터를 완전히 지울 때까지 모든 것이 진행됩니다.
브라우저와 크롬이라고 했더니 집에 있는 다른 기기로 가서 주소를 입력했는데 결과가 나오지 않더군요. 그때 나는 이 모든 작업을 수행하는 데 사용했던 브라우저가 그 이유라는 것을 알았습니다!
감사합니다. 내가 이것 때문에 얼마나 많은 시간을 낭비할지, 아니면 포기할지 누가 알겠는가. 게다가 5~6시간의 개발자 시간이 낭비되었습니다. XD
저는 거의 매일 웹사이트를 이동합니다.
먼저 이미 설치된 공식 WP CLI를 다운로드하여 설치하세요.
다음으로 이동하려는 사이트에서
으아아아cd
WordPress 루트 디렉터리로 이동하고 다음 명령을 사용하여 데이터베이스를 내보냅니다.해당 디렉터리에 SQL 덤프 파일이 생성됩니다. 파일을 WordPress 루트 디렉터리
으아아아cd
의 새 위치로 이동하고 다음 명령을 사용하여 가져옵니다(분명히 파일을 적절하게 교체):마지막으로 새 위치에 있는 동안 검색 및 바꾸기 명령을 실행하세요.
으아아아첫 번째 URL은 이전 URL이고 두 번째 URL은 새 URL입니다. 프로토콜(HTTP 대 HTTP), 도메인(www.example.com 대 example.com)을 포함하여 정확해야 합니다. com) 및 포트. 프로토콜 없이 실행하지 마십시오. 예상한 대로 작동할 수도 있고 그렇지 않을 수도 있습니다. 마찬가지로, 뒤에 슬래시(예: )를 붙여 실행하지 마세요
https://example.com/
. 이렇게 하면 다른 효과가 발생할 수 있습니다.다음 매개변수(
--recurse-objects
)는 CLI에 객체를 역직렬화하고 반복하도록 지시합니다. 이는 메타 및 옵션 테이블을 안전하게 업데이트하는 데 필요합니다.다음 매개변수(
--all-tables
)는 단순히 플러그인을 포함한 전체 데이터베이스를 순회한다는 의미입니다.마지막 매개변수(
--dry-run
)는 업데이트가 이루어지지 않음을 의미합니다. 오타가 없다고 확신할 때까지 항상 이 기능을 켠 상태로 실행한 다음 오타 없이 명령을 실행하세요.주의
또한 다음과 같은 경우를 대비하여 실행, 가져오기 또는 업데이트하기 전에 항상 데이터베이스 백업을 수행하세요.
으아아아추가 메모
search-replace 명령에는 초기 덤프를 건너뛰고 사용할 수 있는
--export
옵션도 있습니다. 하지만 저는 개인적으로 이렇게 하지 않습니다. 라이브에서 개발서버로 백업할 경우 라이브 서버에서 추가적인 CPU/IO가 발생하는 것을 원하지 않고, 나중에 개발서버에서 이러한 부담이 발생하기를 바라기 때문입니다. 조건부로 사용할 수도 있지만 어디에서나 사용할 수 있는 명령 세트가 있는 것이 좋습니다.한 가지 더
브라우저, 특히 Chrome은 적어도 일시적으로 리디렉션을 기억하는 경향이 있습니다. 따라서 이 동작이 실제로 작동하는지 테스트할 때 항상 비공개 탐색 창에서 테스트할 것을 강력히 권장합니다. 이로 인해 나와 다른 개발자들이 얼마나 많은 시간을 잃었는지 말할 수 없습니다. 업데이트가 확인되면 일반 브라우저로 돌아갈 수 있습니다.