워드프레스 5.2 에러 복구 기능 스터디

들어가며

워드프레스 5.2에 들어오면서 여러 개선점이 있었습니다. 릴리즈 노트에 나열된 사항 중 단연 사이트 상태 점검(Site Health Check), 치명적인 에러에서 코어 동작을 보호하는 기능 (PHP Error Protection) 이 눈에 띕니다.

사이트 동작 체크는 도구 > Site Health 에서 확인할 수 있으며, 기능 자체는 Health Check & Troubleshooting에서 많은 것을 가져온 것으로 보입니다. 코어 버전과 플러그인 버전의 차이는 문제 진단 기능(troubleshooting)의 유무로 보입니다. 이 기능에 대해서는 별도로 정리하기로 하지요. 지금까지 여러 플러그인들이 시스템 정보 수집 페이지를 각자 개발했었습니다. 이제 앞으로 이런 시스템 정보는 코어에서 잘 통합될 것으로 보입니다.

Site Health Check 페이지. 기능의 Look & Feel이 Health Check & Troubleshooting에서 많이 가져온 것이 보입니다.
코어에 새로 추가된 사이트 정보 화면

업데이트 이후 갑자기 서버가 죽는 일. 워드프레스를 장기적으로 운영할 때 가장 골치아픈 문제일 겁니다. 코어가 아무리 안정적으로 발전한다 하더라도, 세상에 완벽은 없습니다. 언제 어디서든 잘못된 코드를 작성할 위험은 도사리고 있습니다. 어느 순간 업데이트를 끝마치고 페이지를 재접속했더니 텅 빈 화면만 나온다고 생각해 보세요. 영어권에서는 이것을 WSOD라고 부르더군요. White Screen of Death.

그렇다고 그게 무서워 업데이트를 마냥 미뤄 놓을 수는 없습니다. 아주 가끔 실수가 있다고는 하지만, 전반적으로는 업데이트란 모든 플러그인과 테마가 지금보다 더욱 편하고 좋은 환경을 만들기 위해 노력한 결과물입니다. 보안상 중요한 문제가 일어날 수도 있어 외면해서는 절대 안 되겠죠.

각설하고, 이번 워드프레스 코어 개발진이 이에 적극적으로 대응하기로 결정했나 봅니다. 5.2부터는 PHP 코드에 의도치 않은 치명적인 에러가 발생하도 무조건 WSOD 상태로 빠지지 않도록 동작합니다. 사용자에게도, 개발자에게도 매우 환영할 만한 기능입니다. 이 포스트를 통해 이 기능이 어떻게 동작하는지, 또 어떻게 에러로부터 사용자를 보호하는지 기록해 보려 합니다.

에러 보호 기능

PHP 에러 보호 기능의 핵심 중의 핵심은 아래 두 PHP 함수라고 볼 수 있습니다.

register_shutdown_function() 은 PHP가 완전히 종료하기 전에 특정 기능을 실행할 수 있도록 하는 함수입니다. 그리고 error_get_last() 함수는 PHP 실행 중 현재 시점에서 가장 마지막에 발생한 에러를 조회하는 함수입니다.

코어는 이 두 함수를 이용해 다음 과정을 실행할 것입니다.

  1. register_shutdown_function() 함수를 이용해 스크립트 종료 직전 에러 핸들러를 등록합니다.
  2. 스크립트 종료 직전 에러 핸들러가 error_get_last() 함수를 이용해 스크립트 실행 중 심각한 에러가 발생했는지 아닌지 점검합니다. 만약 별다른 에러가 없다면 임무는 여기까지입니다.
  3. 그러나 어떤 에러를 발견하였다면 에러 대응을 시도합니다.

아주 간략하게 3단계로 축약한 기본 개념입니다. 이 부분을 구현한 코드는 wp-includes/error-protection.php 파일의 wp_register_fatal_error_handler() 함수를 참고하시면 됩니다.

코어의 구체적인 에러 복구

에러를 만나게 되면 이 에러가 난 위치를 파악하여 테마면 테마 에러로, 플러그인 에러면 플러그인 에러로 DB 옵션 테이블에 기록합니다. 관리자에겐 복구 모드를 접근할 수 있는 링크를 이메일로 전달합니다.

복구 모드는 쿠키로 구워진 토큰값을 통해 인식됩니다. 복구 모드를 통해 관리자 패널에 접속하면 해당 사용자는 에러가 난 테마나 플러그인을 중단시킨 상태에서 접속하게 됩니다. 복구 모드에서는 그림처럼 어드민 바 상단 우측에 어드민 바임을 알리는 띠가 붙습니다. 브라우저 제목도 ‘Recovery Mode’라고 나오지요.

복구 모드에 대한 설명 'Exit Recovery Mode' 띠가 둘러져 있습니다.
복구 모드 중인 관리자 화면

이 모드에서 관리자는 테마 혹은 플러그인의 에러를 확인할 수 있습니다.

테마 에러 진단. Themes 페이지 (wp-admin/themes.php)의 밑바닥에서 출력됩니다.
플러그인의 에러 진단. Plugins 페이지 (wp-admin/plugins.php)의 플러그인 목록에서 발견됩니다.

테마는 에러 메시지가 조금 불친절하군요. 반면 플러그인은 파일 몇 번째 줄에서 어떤 에러가 나오는지까지 나오네요. 테마 메시지는 좀 더 개선되어야 할 필요가 있어 보입니다.

여기서 관리자는 해당 오류를 수정하여 ‘resume’을 선택하든지, 아니면 ‘deactivate’를 선택하여 해당 플러그인 기능을 비활성화하더라도 전체 사이트가 마비되는 것을 막든지 선택할 수 있습니다.

어떻게 복구 모드로 진입하는가?

관리자 페이지에서도 심각한 에러를 만나게 되면, 코어는 관리자에게 이메일을 보내어 사이트의 에러 상태, 그리고 복구를 위한 링크를 전달합니다. 이메일은 아래 그림과 유사합니다.

에러 탐지가 되면 이런 메일이 날아옵니다

메일 중간에 있는 임시 URL로 접근하면 복구 모드로 동작할 수 있는 로그인 페이지를 만나게 됩니다. 이 페이지로 로그인을 하면 로그인 세션 토큰 외 특별한 토큰을 쿠키로 전달받게 됩니다.

워드프레스 로그인 세션 쿠키

wordpress_rec_로 시작하는 것이 바로 복구 모드를 위해 발급된 쿠키입니다. 이 쿠키값이 올바르면 사용자는 복구 모드로 동작하는 것입니다.

또한 쿠키 값은 특별한 규칙이 있고, 이 규칙대로 잘 디코딩하면 세션 ID라는 것이 있습니다. 에러가 나면 에러 내용을 DB 옵션 테이블에 기록하는데, 옵션 테이블 이름은 이 세션 ID에 의해 조금씩 달라집니다. 세션 ID는 보통 난수적으로 선택됩니다. 실험을 위해 일부러 에러를 내고 복구모드에 들어왔을 때 옵션 테이블에는 아래와 같은 에러 내용이 기록된 것을 확인했습니다.

option name: 3a3f3bd482a7a6f2fc2a4480a7c1d8da3a6002e3_paused_extensions
option value: array(2) {
   'theme' =>
   array(1) {
     'twentyseventeen' =>
     array(4) {
       'type' =>
       int(256)
       'message' =>
       string(17) "Error on purpose."
       'file' =>
       string(90) "/home/changwoo/develop/wordpress/wp-contents/wp.local/themes/twentyseventeen/functions.php"
       'line' =>
       int(11)
     }
   }
   'plugin' =>
   array(1) {
     'wsod-test' =>
     array(4) {
       'type' =>
       int(256)
       'message' =>
       string(17) "Error on purpose."
       'file' =>
       string(85) "/home/changwoo/develop/wordpress/wp-contents/wp.local/plugins/wsod-test/wsod-test.php"
       'line' =>
       int(6)
     }
   }
 }
(옵션값은 unserialize 시켰습니다.)

에러 탐지 및 복구 모드와 관련된 설정값

에러 탐지와 복구 모드에 대한 설명이 어느 정도 된 것 같네요. 이제 이와 관련된 define 상수나 설정값을 메모하면서 포스팅을 마치기로 합니다.

  • WP_DISABLE_FATAL_ERROR_HANDLER: 참일 때는 아예 에러 보호 기능이 동작하지 않습니다. 개발 중에는 유용하게 쓸 수 있겠네요.
  • RECOVERY_MODE_EMAIL: 에러가 생길 때 복구 모드 안내를 위한 메일 주소를 설정하는데 쓰입니다. 선언되지 않으면 워드프레스 관리자 이메일입니다.
  • WP_RECOVERY_MODE_SESSION_ID: 난수로 발생되는 세션 ID를 고정할 수 있습니다.
  • wp-content/php-error.php 파일: 기본 에러 화면을 변경할 수 있는 템플릿 파일로 사용할 수 있습니다. 원한다면 WP_Fatal_Error_Handler::display_default_error_template() 메소드를 참고하여 사이트 고유의 에러 화면으로 만들 수 있습니다.
  • wp-content/fatal-error-handler.php 파일: WP_Fatal_Error_Handler 가 아닌 다른 에러 핸들러 클래스를 정의할 수 있습니다. 반드시 ‘handle()’이라는 퍼블릭 메소드가 정의되어 있어야 합니다.

워드프레스에서 PHP 세션은 독이 될 수 있습니다.

워드프레스 플러그인 제작시 PHP의 세션(session) 사용은 자제하시기를 권고드립니다.

이전에 잠시 쓴 포스트의 검증을 위한 작업을 했습니다. 두 포스트를 통해 저는 PHP 세션(session)은 어지간하면 사용하지 말기를 권고드리며, 다른 방법을 사용하시기를 조언드립니다. 세션 사용시 사이트의 성능 저하가 발생할 수 있기 때문입니다.

더 보기 “워드프레스에서 PHP 세션은 독이 될 수 있습니다.”

기본 권한과 메타 권한

워드프레스의 역할과 권한, 그리고 기본 권한과 메타 권한에 대해 포스팅해 보았습니다. 워드프레스의 강력한 권한 체계에 대해 알아보세요.

이전 포스트에서 예고한 대로 이번에는 기본 권한과 메타 권한에 대해 포스팅해 보고자 합니다.

구 워드프레스에는 회원들의 권한을 구분하기 위해 ‘레벨’이라는 개념을 사용했습니다. 예전 제로보드4 에서도 볼 수 있었던 개념입니다. 레벨 1부터 숫자가 높을 수록 권한이 낮아지는 방식의 권한 테이블 방식으로, 방법은 간단하나 썩 훌륭한 방법은 아니었습니다. 왜냐면 한 회원은 반드시 어떤 레벨에 종속되어 버리는 문제가 있고, 또 실제 운영에 있어서 권한의 높낮이보다 각기 회원의 세밀한 권한 설정도 중요할 때가 많은데, 이를 확장할 방법이 부족한 것이었죠.

워드프레스 2.0버전부터 새로운 개념인 역할과 권한(roles and capabilities)이 생겼습니다. 이 달라진 권한 개념은 레벨이라는 개념을 완전히 버리고 새롭게 디자인된 권한 설정입니다. 그럼 역할과 권한이 어떤 특성을 가졌는지부터 간단하게 설명해 보도록 할께요.

더 보기 “기본 권한과 메타 권한”

워드프레스 권한 실습 – 포스트 권한 집중 탐구

한때, 워드프레스는 사람들이 무료이고 쓰기 쉬워서 찾는 거지, 구식 개발이고 소스 코드도 알아보기 어렵고… 아무튼 이건 진짜 별로다. 이렇게 생각한 적이 있었습니다. 그러다가 생각이 바뀌게 된 계기가 있는데, 바로 역할과 권한(Role and Capability, 줄여서 RC) 체계를 접하게 된 것이었죠. 이후 워드프레스에 대한 평가가 긍정적으로 변했죠. 특히나 RC의 풍부한 표현은 정말 마음에 듭니다. 조금 어렵기는 해도, 사용자 레벨 같은 거와는 비교할 바가 아닙니다.

워드프레스는 CMS입니다. 단연코 콘텐츠의 관리와 유통에 있어 전문가입니다. 잘 뜯어보면 세심하게 배려한 부분이 정말 많습니다. 개발자 입장에서 볼 때 어떤 콘텐츠를 잘 관리하고 전파할 목적이라면, 어설프게 만들지 말고 워드프레스 써라고 충고하고 싶습니다. 10여년간 그들이 쌓아 올린 콘텐츠 관리에 대한 노하우는 만만한 것이 아닙니다.

사실 그동안 역할과 권한은 잘 쓰면 굉장히 멋진 것이 될 거라 생각은 해 왔습니다. 그러나 그 잘 쓰는 법을 여전히 잘 터득하지 못한 것 같았습니다. 물론 코덱스를 잘 읽으면 어지간한 정보는 습득할 수는 있지만 이것저것 만져보면서 직접 경험해보는 해킹(hacking)이 필요했습니다. 직접 좌충우돌하는 경험을 하고 싶었습니다. 그리고 이 포스트는 그 경험을 기록하기 위해 작성하는 것입니다. 

더 보기 “워드프레스 권한 실습 – 포스트 권한 집중 탐구”