요  며칠 사이에  호스트 이전(site migration)을 몇 번이나 했는지 셀 수가  없는 것 같다.   이전 과정에서 겪은 몇 가지 사항들에 대해 나중을 위하여 기록으로 남긴다.

이전의 유형 :  새로운 호스팅 서버로 이전하지만  루트 도메인의 주소는 변경 하지 않는 방법이다. 결과적으로 황씨 닷컴의 분류기준으로는 1번 에 해당하지만 과정 상의 구체적인 방법에서는 많은 차이가 있다.

전체 이전의 형태를 보면

A1–> A0 –> A1  –> B0  이렇게 총 세번의 이삿짐을 꾸렸다.

      처음의 이전은 A0 사이트의 메뉴 바가 무슨 이유에선지 permalnk 역할을 하지 못하고 ‘ 404 에러메시지‘ 가 나오는 것을 뒤늦게 발견했기 때문에 이것을 수정하기 위한 응급적인 것이었다.   (뒤늦게 생각해보니 이것의 원인은 글 가져오기 실행이 중단되는 일이 벌어져서 실행 버튼을 여러 번 누른 것 때문에 벌어진 일이라고 생각된다.  이때 글과의 연결이 깨진 중복된 메뉴항목 (카테고리와 연결된) 들이 있는 것을 모르고  확인도 하지않은 채 여러 중복된 메뉴들을 지우고 아무 항목이나 하나만 남겨 두는 과정에서 링크가 깨진 것 같다.  유사한 현상을 feedwordpress 플러그인에 관한 글에서 이미 언급한 바 있다. )

        A0는 A1과 동일한 업체의 호스트이지만 밴드 허용량이 차이가 나기 때문에 응급적으로 만 사용할 수 밖에 없었고 다시 A1으로 복귀해야했다.  마지막의 이사는 A1 호스트가 저장용량의 한계치에 도달해서 더 이상은 호스트로서의 역할을 수행할 수 없는 지경에 이르렀기 때문이었다.  이참에 아예 용량 제한이 훨씬 더 큰  호스팅 업체(B)로 다시 이전했다.   다행인 것은 최근에 루트도메인을 확보해서 고유주소가 바뀌지 않게 되었다는 것이다.

1. A1 –> A0 이전에 관하여

1) DB의 이상 현상인가?

A1 서버는  메뉴 바의 링크가 연결되지 않는 문제가 있다 는 것 이외에도

     아래 그림처럼 워드프레스 자동 업데이트에 문제가 있었다. 다시 시도해도 이 메시지가 지워지지 않는 상태였다.

다행인 것은  A0사이트는 예전에 설치한 상태의 DB구조를 그대로 유지하고 있었고 이후에 A1에서는 한 두개의 post만이 업데이트 되어있는 상태였으므로 A1 에서 업데이트 된 포스트만 잘 갈무리해서 A0 사이트로 옮겨놓는다면 일단은 성공… 이후에 A1사이트의 메뉴 바를 수리하고 다시 옮겨오면 될 일이다.

그래도 모르는 일이므로 A1사이트의 글들을 Advanced Export 플러그인으로 월별로 백업받았다.  이후에 ‘새로 업데이트된 post’만 남겨놓고 모두 삭제

다 시 그 글들만 백업받고 모두 다 삭제 이번에는 A0사이트에서 월별로 백업받은 post를 월별로 가져오기 실시… 그런데 오류가 발생 A1에서 글을 모두 완전히 지우지 않고 휴지통에 남겨놓은 상태(DB에 남겨 놓은 상태)였기 때문에 가져오기 방법에서는 가져오기 할 수 없다고 나온다. 할 수 없이  ‘새로 업데이트된 post’  최근 글 몇개 만 남겨 놓고 나시 휴지통 비우기 진행..

이제야 가져오기가 제대로 된다. …

아차… 사이트 메인터넌스 공지를 하면 더 좋겠는데…

열심히 구글링해서 쓸만한 플러그인을 찾아 설치.. (일명 ‘Ultimate Maintenance Mode ‘  설치에 대해서는 별도로 글을 쓴다.)

2)  A0사이트의 포스트 업데이트와 도메인 주소 이전

     A1사이트에서 가장 최근 글 만으로구성된  백업파일을 A0사이트에 가져오기한 후에 메뉴항목이 제대로 연결되는지도 확인 이제  도메인 네임서버의 이전만 하면 된다.

     도메인 등록업체 사이트로 가서…. 아니고 이 경우에는 호스팅 업체가 동일해서 네임서버가 동일 하므로 네임서버의 변경은 불 필요하다 단지  A1사이트에 연결된 도메인을 삭제하고 A0사이트에서 새롭게 도메인을 연결하면 된다.

( domain parking 이라고도 부른다. 하지만 업체에 따라서는 domain parking을 아직 사이트를 생상하지 않고 도메인만 등록한 경우에 이주소로 찾아오는 손님들을 위해  ‘사이트를 준비 중입니다’ 혹은 ‘under construction’ 이런 메시지나 이미지를 서비스를 domain parking이라고 부르고 나의 루트 도메인네임을 호스트에 연결해준다는 뜻으로 ‘도메인 연결‘ 이라고 부르기도 한다. )

처음 도메인 등록할 때 보다는 시간이 많이 걸리지만 (약 15분 정도 ?) 호스팅 업체를 변경하는 때(서너 시간 이상… 어떨 때는 하룻밤이 지나야 하고  밤사이에 정상 연결되었다가 아침에 다시 연결이 않되고 한 두시간 지나야 다시 정상연결되기도 한다. )  보다는 정상적인 연결에 그리 시간이 많이 걸리지는 않았다. (한 두 시간정도)

3) A1사이트의 메뉴바  수리

일단 새로 가져온 글과 함께 가져오기 된 메뉴항목, 카테고리, 태그 이런 것들에 연결된 링크가 제대로 작동하는지 테스트 …. 일단은 성공이다.  A0사이트의 메뉴와  비교해 가면서 동일한 메뉴 바를 완성…

휴~~ 이제 다시 도메인 주소만 이전하면 된다.

이제는 이 과정에서 새롭게 알게된 몇가지 사항들에 관해 기록한다.

일반적으로는 사이트를 이전하면 과거 사이트는 삭제해버리기때문에 크게 분제되지 않지만 필자의 경우에는 임시로이전해 갔다가 다시 돌아와야하는 것이기 때문에 문제가 복잡해 졌다 .또한 이전사이트를 백업용으로 그대로 살려두고 싶을 때에도 유사한 문제가 발생할 것이다.

4) 주소 이전에 관계된사항들 …

일반적으로 사이트 이전은 아래와 같이 하라고들 추천한다.

1. DB는 그대로 옮기고.. wp_options에 있는 home_url, site_url 옵션의 주소를 변경
2. wp_posts 및 테마에서 사용하는 URL들 재설정 (이때 상대경로가 아닌 절대경로로 사용된 내용들은 보통 에러가납니다)
3. 실제 사이트 구동 확인 (inspector 켜고 URL 경로 에러나는 것들이 있는지 하나씩 확인 과정을 거칩니다)

home_url, site_url 의 경우에는 아래 그림과 같이 데쉬보드에서도 수정이 가능하다.

home_url 은 워드프레스 주소와 같고 , site_url 은 사이트 주소이다.

     이것을 변경하기 전에 반드시 해야할 일이 있다. 과거 사이트에서는 이와는 반대로 이주소를 호스팅 업체가 제공하는 원래의 서브 도메인 주소로 복귀시켜야한다. 그렇게 하지않으면 나중에 다시 접속하는 것에 애를 먹는다 . (여기서는 A1 –>A0 이전 후에 A1사이트의 메뉴 복구를 위해 접속ㄹ하는데서 분제가 발생했다.  물론 나중에 phpMyadmin 으로 접속해서  옵션 항목에 찾아 들어가서 URL을 수정하면 접속가능하다.

     과거 사이트에서는 DB에 흔적을 남기는 프러그인들을 필히 꺼두어야 한다. 필자의 경우에  수리를 위해서 대부분의 글들을 지워버리자 auto redirest plugin의 경우에 404 error 가  말썽을 부렸다.  사이트를 수정하는 동안 구글 검색기가 예전의 접속을 시도하여 404 error가 발생하자 아래 그림과 같이 이것을 DB에 기록해 놓은 것이다.

  이렇게 되면 나중에 사이트를 다시 복구한 뒤에도 사이트 내의 거의 모든 링크 항목들을 클릭해도 홈 화면으로 되돌아가는 현상이 발생한다.  다행이 하나 남겨 두었던 글에서 만 정상적으로 작동하는 것을 보고 힌트를 얻어서  DB에 접속해서 이것들을 모두 지워버림으로써 복구할 수 있었다.

5) Disqus 댓글의 링크 주소 변경

이것에 관해서는 일전에도 잠시 기록한 내용들이 있다.   하지만 디스커스가 제공하는 자동이전 기능을 이용하기 에는 시간이 촉박해서 (과거 기억으로는 일반적으로 하룻밤 정도 걸린다. ) 수동으로 일일이 주소변경을 해야했다.

       A1 사이트든 A0사이트든 모두 사이트 주소가 www.example.com 이므로 별도로 손을 댈 이유가 없는 것이 었지만 이번에 확인해보니 올바르지 않는 URL들이 많이 남아 있었다.

( 원칙적으로는 처음에 고유 도메인을 등록하면서 거쳤어야 할 절차이지만 마부리 확인을 하지않아서 과거의 url (A1)들이 그대로 남아있는 것도 있고 경우에 따라서는 A0사이트로 남아 있는 것들도 있어서 그냥 둘 수는 없다.

 

6) Facebook 에 관련된 것

메뉴항목을 모두 수리항 이후에 무심코 페이스북 좋아요 버튼을 눌렀더니 이런 메시지가 뜬다.

 

또는 이런 경우도 있다.

어라? 이거 어디서 많이 본듯한 느낌인데….

내친 김에 페북 고객센터의 도움말 검색창에서 ‘ 차단된 게시물’이라고 넣어보니 ‘내 게시물이 차단되 이유’라는 항목이 뜬다.        당장에 클릭…

음… 결국 동일한 내용을 여러번 다른위치에 게시하는 걸 악성 게시물이라고 간주하는 모양이다.  (원래의 주소로 공유, 좋아요 누른 게시물이있는데 동일한 내용을 담고 있는  다른 사이트를 또 공유, 좋아요 누르려고 하니 악성이라고 보는 것이다.   과거에 내가 공유한 게시물을 클릭한 경우에 스팸가능성에 대한 경우를 준 이유를 이제야 이해하게 된다.

내가 만났던 대표적인 스팸 경고이다.

 당장에 페이스북 계정에 접속해서 ‘활동로그’를 열었다.  과거에 공유했지만 이제는 사용하지않는 모든 사이트들의 공유(또는 좋아요)를 삭제 (또는 취소)했다.

  도메인 이전이 활성화되어’ example.com’ 주소로 접속이 가능해지고  home_url (워드프레스 주소)와 site_url(사이트 주소) 를 수정한 이후에는  공유, 좋아요 버튼을 누르는 경우에도 이런 현상이 나타나지 않는다.

(그렇다면 과거에 ‘숙제‘로 남겨 두었던 이상한 현상과 Sinsweibo에서의 공유 거부 현상도 같은 이유 때문인지도 모른다)

 addthis 플러그인에서도  예전 사이트에서의 공유 기록들이 그대로 반영되어 숫자가 표시된다.

   [update :2014.03.27.]  하지만  facebook플러그인의 경우에는 app ID 까지 등록하는 것이기 때문에 도메인 이전이 활성화 된 후라도 예전 사이트에서 플러그인이 활성화되어 있다면 충돌이 발생하여 (이것은 충돌이라기 보다는 facebook이 중복된 post에 대해서 공유를 거부하는 정책을 기술로 구현해 놓은 것이라고 생각된다 .  ) 신규 사이트에서 플러그인을 활성화 해 놓는다고 해도 recommend bar가 정상 작동을 하지 않는다.  recommend bar플러그인은  예전 호스트 사이트에서 활성화 되어있는한 절대 신규 사이트에서 활성화되지않는다 (단, 중복되는 post에 국한해서 나타나는 현상이므로 신규 호스트 사이트에서 새로운 post를 밸행하면 여기에서는 recommend bar가 작동한다.  이런 내용을 자꾸 잊어버리고 그 동안 한 참을 왜 이런 현상이 나타나는지 고민해왔었다.

참고 : Addthis의 경우에는 조금 다르다.

      사이트 주소를 등록하지 않고 사용자 계정만 등록한 상태에서 다른 SNS계정들의 공유 기록과 그 공유를 클릭한 횟수 들만을  기록으로 남길 뿐 사이트이 고유 주소와 그 내용에는 관심이 없는 일종의 공유 중계자 이기 때문에 내용이 스팸인저 여부는 관심이없다. 사이트 주소가 바뀌면 바뀐대로 공유 기록을 남길 뿐이다.

6) 기타

일반적으로는 content 디렉토리를 덥어쓰기 하는 방식으로 사이트 이전을 하는것이 원칙이지만 내 경우에는 원래 의 사이트에 DB가 망가진 것일 수있다고 판단되었기 때문에 일일이 플러그인을 새로 설치해야 했다.

글이 너무 길다.. 나중에라도 잘라야할 지도 모르겠다.

마친다.