그게 바로 지금 쓰고 있는 스킨이다. 전의 스킨에 비해서 상당히 허접해진 것 같은데, 이건 어쩔 수 없다. 내 HTML 실력이 영 안 좋아서 말이다. 이것을 하기 위해서 미디어위키의 페이지를 하나 얻어 온 다음 그것을 무작정 태터의 기본 스킨에 합쳐 버렸다. 그리고 위키와 블로그가 서로 다른 개념을 가지고 접근하기 때문에 이것을 해결해야만 했다.
위키는 한 페이지에 하나의 글이 있다는 것을 전제로 하고, 아무나 수정할 수 있기 때문에 수정이 쉬워야 하며 하나의 글을 기준으로 작성해도 된다. 그러나 블로그는 한 페이지에 여러 개의 글이 올 수 있으며 주인장 말고는 편집할 수 있는 사람이 없다. 이를 극복하기 위하여 미디어위키의 스타일을 대부분 뜯어고쳤다.
한편 미디어위키의 모노북 CSS 파일에도 블로그로 쓰기는 부적합한 부분이 몇 군데 있는데 그 중 하나가 왼쪽 사이드바이다. 사이드바의 넓이를 더 넓혀야 했으며 display 속성이 block으로 되어 있는 부분을 inline으로 되돌려야 했다. 그래서 br 태그가 없는데도 불구하고 링크들이 각 줄에 하나씩만 표현되는 이상한 현상이 계속 나타났다.
당분간 이 스킨은 블로그 메인으로 쓰일 예정이다. 그와 함께 더더욱 업그레이드 될 것이다.
Tag Archives: 미디어위키
데이터베이스와 함께한 오전
뷁키백과는 데이터베이스 엔진으로 미디어위키를 쓴다. 그런데, 뷁키백과 데이터베이스를 흔드는 과정에서 미디어위키 데이터베이스에 너무 많은 글이 들어가서 글 개수 통계가 섞이는 등 만행이 일어났기 때문에 이런 특단의 조치로 전체 리비전을 지웠다.
- 우선 리비전을 지울 글을 클릭해서 “편집”을 누른다.
- 그 다음, 명령줄에서
"php -cli nukePages.php [페이지_제목]"을 입력한다. - 다 되면 저장을 누른다.
그런데 이 과정에서 ㅅㄱㅎ 문서가 제대로 복구되지 않아서 옛 버전으로 남아있었다는 것을 망각했던 채
php -cli nukePages.php ㅅㄱㅎ이 명령을… 때렸다! 처참한 결과만 남아서 울고 있었다. 위키백과의 특정 버전 삭제와는 다르게 이 명령은 데이터베이스 자체적으로 모든 것을 지우기 때문에, undo가 가능한 특정 버전 삭제와는 달리 동작은 한 방향이다. 이럴 때 쓸 수 있는 말이 OTL이지.
그러나 하늘이 무너져도 희망은 있는 법. 윈도우 서버 RWAPM이라는 것이 떠올라서 그 녀석을 통해서 전에 받아 두었던 DB 전체 백업을 다시 올렸다. 그리고 phpMyAdmin으로 들어가서 페이지를 찾아야 했다. 그렇지만 미디어위키의 너무 철저한 리비전 때문에 한 문서를 가르키는 테이블이 총 3종류 있다. 그 셋은 [prefix]_page, _text, _revision이다. 이제 이 세 테이블을 따라가 보자. [prefix] 값은 적절한 것을 찾으면 되고 여기서는 brw_이다.
우선, brw_page 테이블에서 page_title을 기준으로 ㅅㄱㅎ를 검색한다. 그러면 그에 대응하는 page_id와 page_latest 값을 찾을 수 있다. page_id 값과 page_latest 값을 기억한 다음, brw_revision에서 rev_id 기준으로 아까 찾은 값을 대입해서 검색한다. 그러면 rev_page 값과 page_id 값이 같으면 빙고라는 뜻을 이야기한다. 그 다음 brw_text로 간다.
그런데 이 녀석이 BLOB으로 기록되어 있다? 그래서 phpMyAdmin은 보여 주기를 거부하고 있다. 그것 때문에 MySQL을 직접 건드려도 봤으나 별 소득이 없었다. 그러다가 내 눈에 들어온 것이…
Export였다! 즉, CSV 파일로 내보낸 다음에 검색하면 된다는 뜻이다. 이것을 몰라서 오늘 오전 내내 허공에다가 삽질하고 있었다. CSV 파일에서 검색은 page_latest 값을 기준으로 검색하면 내용이 나온다. 그러나, 다행히도 내용의 일부를 기억하고 있기 때문에 그것을 기준으로 검색을 해서 결국 문서를 살렸다.
오늘의 결론.
- 백업과 복원을 생활화하자.
- 무엇이든지 원리와 구조를 알고 논리적으로 접근하자.
- 경희누나 미안.