WordPress White Screen of Death: 복구 가이드

WordPress는 MacOS 및 현재 Windows와 마찬가지로 악명 높은 "죽음의 흰색 화면"또는 간단히 "WSOD"를 가지고 있습니다. 무언가 잘못되었을 때 WSOD가 나타납니다. 알 수 없는 이유로 비어 있거나 대부분 비어 있는 흰색 화면이 나타납니다. 이제 뭐?

워드프레스 WSOD(White Screen of Death)란 무엇입니까?

정상적인 조건에서는 WordPress 사이트에서 "죽음의 흰색 화면"(WSOD)이 발생하지 않을 것입니다. 워드프레스 사이트의 공용 프런트엔드 또는 백엔드 인터페이스 대신 나타나는 빈 흰색 화면일 뿐입니다. 이는 WordPress가 충돌하여 제대로 로드되지 않음을 의미합니다.

왜요? 무엇이 잘못되었나요?

2019년 5월 WordPress 5.2가 출시된 이후 WordPress에는 WSOD로부터 사용자를 보호하기 위한 복구 모드가 있습니다. 복구 모드가 없으면 호환성 문제로 인해 많은 WSOD가 생성되고 WordPress 사용자가 좌절하게 됩니다. 서버가 설치 중인 플러그인, 테마 또는 확장에서 지원하지 않는 PHP 또는 MySQL 버전을 사용하는 경우 사이트를 손상시키는 대신 복구 모드를 사용할 수 있습니다. 오늘날 PHP 메모리 부족(OOM) 오류는 아마도 WSOD 보호를 우회하여 완전히 빈 화면을 남기는 가장 일반적인 시나리오일 것입니다.

WordPress 핵심 기여자 Marius Jensen과 함께 오늘날 진정한 WSOD를 유발할 수 있는 다른 원인을 확인했습니다. Marius는 사이트 상태(현재 상태 확인 및 문제 해결) 플러그인의 작성자이며 개념과 기능이 결국 WordPress 코어에 포함되었습니다. (그래서 복구 모드 및 기타 보호 기능을 사용할 수 있습니다.) Marius는 완전히 빈 화면으로 WordPress를 충돌시키는 유일한 방법은 치명적인 오류 처리기가 제대로 작동하지 않도록 PHP의 실행 흐름을 중단하는 것이라고 확인했습니다. PHP와 HTTP 서버 간의 연결을 끊으면 이를 달성할 수 있습니다. 화면상의 문제 해결 피드백은 표시되지 않습니다. 실망스러울 수 있지만 단순히 WordPress 내부에서 작업하고 플러그인을 설치 및 구성하는 경우에는 이런 일이 발생하지 않을 것입니다.

죽음의 흰색 화면은 WordPress가 해킹되었음을 의미합니까?

아니요, WSOD가 있다고 해서 악당이 당신을 잡았다는 의미는 아닙니다. 그러나 드물게 보안 위반의 부작용이 될 수 있습니다. 해커가 사이트를 해킹했다고 생각되면 Kathy Zant의 가이드인 해킹된 WordPress 사이트를 정리하는 방법으로 이동하세요.

PHP 코딩 오류, 둘 이상의 플러그인 간의 충돌 또는 서버 환경의 문제가 WSOD의 가장 큰 원인입니다. 다행히도 이것은 재앙이 아닙니다! 귀하의 사이트와 그 콘텐츠는 손실되지 않았습니다. 원하는 경우 WSOD를 직접 수정할 수 있습니다.

이 기사에서는 WSOD에 대한 가능한 진단 및 치료법 목록을 살펴보겠습니다. WordPress 사이트를 다시 활성화하는 방법을 배웁니다. 또한 WordPress가 더 깊은 수준에서 작동하는 방식을 배우게 됩니다.

미리보기 보기

워드프레스 죽음의 하얀 화면: 내가 그랬어?

예. 죽음의 하얀 화면은 아마도 무언가의 결과일 것입니다. 당신은 당신의 WordPress 사이트를 만들었습니다.

WSOD의 원인은 일반적으로 방금 설치하고 활성화한 WordPress 플러그인에서 찾을 수 있습니다. 또는 최근 업데이트의 결과일 수 있습니다. 새로 추가되거나 업데이트된 플러그인이 다른 플러그인과 충돌할 수 있습니다. 이 시나리오에서 하나의 플러그인은 다른 플러그인과 동일한 작업을 수행하려고 하거나 모순된 목적으로 작동합니다.

플러그인, 테마 또는 오작동하는 PHP 코드 스니펫으로 인해 치명적인 오류가 발생하는 경우 WSOD가 발생할 수 있습니다. 사용 중인 PHP 버전과 호환되지 않는 구문 오류, 버그 또는 코드가 포함될 수 있습니다. 귀하 또는 귀하의 호스트가 방금 PHP 버전을 업그레이드했다면 — 좋은 일입니다! — 호환되지 않는 플러그인은 오류를 발생시키기 시작하고 WSOD로 사이트를 중단시킬 수 있습니다. WordPress 5.2 이상을 사용하는 경우 비호환성 문제로 인해 실제 WSOD보다 훨씬 유용한 복구 모드가 활성화됩니다.

일반적으로 범인은 플러그인, 테마 또는 사용자 정의 코드로 방금 변경된 모든 것입니다.

WSOD는 종종 사이트의 기능에 영향을 미치는 마지막(또는 아주 최근) 변경 사항에 대한 응답이기 때문입니다. 모든 최근 변경 사항을 검토합니다. 문제를 일으킬 가능성이 가장 높은 변경 사항에 집중하십시오. 방금 새 플러그인을 설치했거나 일부 테마 코드를 수정한 경우 무엇이 잘못되었는지 확인하는 첫 번째 위치입니다.

WordPress가 대부분 죽었을 때

모든 WSOD는 동일하지 않으며 일부는 진정한 WSOD가 아닙니다.

완전히 흰색 화면이 아닌 일종의 오류 메시지가 표시될 수 있습니다. HTTP 500 오류 또는 데이터베이스 연결 끊김에 대한 서버 오류 메시지일 수 있습니다. WordPress의 중요한 오류 메시지일 수 있습니다. 또는 방문자에게는 사이트가 정상적으로 로드되지만 로그인을 시도하면 흰색 사망 화면이 표시될 수 있습니다. 다른 경우에는 그 반대일 수 있습니다. WordPress 대시보드에 로그인할 수 있지만 사이트의 공개 프런트 엔드는 모든 사람에게 빈 화면을 제공합니다.

귀하의 WSOD 경험이 이러한 설명 중 하나라도 해당된다면 희소식입니다! 귀하의 사이트는 거의 죽었습니다. 그것을 되살리는 것은 어렵지 않을 것입니다.

WordPress 사이트를 방문하거나 로그인을 시도할 때 완전히 빈 흰색 화면이 표시되는 경우 이것이 진정한 WSOD입니다. 원인을 파악하려면 조금 더 깊이 파헤쳐야 합니다.

WordPress 복구 모드 및 죽음의 흰색 화면

다행스럽게도 WSOD에 직면한 사람에게는 복구 모드가 워드프레스 5.2에 도입되어 이를 제거합니다. 복구 모드는 많은 치명적인 오류를 포착하고 수정하는 데 도움이 됩니다. 최신 주요 WordPress 코어 릴리스를 사용하지 않는 경우 여기에서 시작하십시오. 최신 정보를 얻으세요!

WordPress의 복구 모드 덕분에 문제가 발생했을 때 완전히 비어 있는 흰색 화면이 표시되는 경우는 드뭅니다. WordPress 6.1부터 다음 메시지와 함께 회색 화면 위에 흰색 창이 더 자주 표시됩니다.

이전 버전의 WordPress에서는 "사이트에 기술적인 문제가 발생했습니다."와 같은 유사한 메시지가 표시됩니다.

백엔드 /wp-admin URL로 이동하면 관리자 이메일 계정에서 추가 정보를 확인하라는 알림도 표시됩니다.

다른 경우에는 사이트 복구를 위한 일종의 설명 및 지침과 함께 "내부 서버 오류"를 설명하는 굵은 텍스트가 있는 흰색 화면이 표시될 수 있습니다.

복구에 오신 것을 환영합니다

복구 모드입니다. WordPress는 사용자가 다시 일어서도록 도울 수 있도록 노력하고 있습니다.

가장 먼저 할 일은 WordPress 관리자 계정과 연결된 이메일 주소를 확인하는 것입니다. WordPress는 실행 중인 모든 코드에서 치명적인 PHP 오류를 식별하려고 시도합니다.

가능한 경우 WordPress는 오작동하는 플러그인 또는 기타 코드를 "일시 중지"합니다. WordPress는 잘못된 코드가 실행되지 않도록 합니다. 그런 다음 이메일로 관리자에게 세부 정보를 보고합니다.

복구 모드 이메일에는 복구 모드에서 WordPress에 로그인하기 위한 지침과 임시 링크가 있습니다. (이 링크는 24시간 동안 유효합니다. 그 후에도 사이트에 심각한 오류가 발생하면 새 링크가 전송됩니다.)

프로 팁: 복구 모드 이메일을 받지 못한 경우 관리자로 로그인할 때 기본 사이트 URL에 다음 주소를 추가하여 복구 모드에서 WordPress에 로그인할 수 있습니다. /wp-login.php?action=entered_recovery_mode .

더 자세히 조사할 수 있는 기회입니다. 복구 모드가 특정 플러그인을 WSOD의 원인으로 식별한 경우 비활성화하십시오. 이렇게 하면 모두를 위해 사이트가 다시 표시됩니다. 그런 다음 이 플러그인에 대해 알려진 문제를 조사할 수 있습니다. 업데이트가 있는지 확인하십시오. 유지 관리를 담당하는 사람들에게 연락하십시오.

죽음의 모든 흰색 화면이 WordPress에서 동일하지는 않습니다.

몇 가지 예외적인 경우에 WordPress 또는 서버 환경의 다른 곳에서 문제가 발생했습니다. 업데이트 또는 설치 프로세스가 중단되어 사이트가 유지 관리 모드에 멈춘 상태일 수 있습니다. 귀하, 귀하의 호스팅 제공업체 또는 귀하가 설치한 플러그인이 예기치 않은 결과로 php.ini 또는 .htaccess 파일을 수정했을 수 있습니다. 기존 환경이 새로 설치된 플러그인의 요구 사항을 지원하지 않을 수 있습니다.

WordPress 복구 모드는 이러한 상황에 대처할 수 없지만 흰색 화면에 눈에 보이는 오류 메시지를 생성합니다. 사이트의 프런트 엔드에 액세스할 수 없지만 관리자 로그인 화면과 백엔드 인터페이스는 정상적으로 작동할 수 있습니다.

이것은 진정한 WSOD 상황이 아니지만 성가신 일입니다. 일반적으로 다음 조건 중 하나로 인해 발생합니다.

1. 유지 관리 모드에 갇혀 있습니다.

WordPress 코어, 플러그인 또는 테마를 업데이트하는 동안 WordPress는 "유지 관리 모드"로 들어갑니다. 사이트의 어느 부분을 탐색하면 다음과 같은 흰색 메시지 창이 있는 회색 화면이 표시됩니다.

때때로 이 문제는 1분 안에 해결되지 않지만 품질이 관리되는 WordPress 호스팅은 자동화된 프로세스로 이 문제를 인식하고 수정합니다. 아무 변화 없이 몇 분을 기다린 경우 WordPress가 설치된 웹/응용 프로그램 루트 폴더에서 .maintenance 파일을 삭제하여 유지 관리 모드에서 벗어날 수 있습니다. (이를 보려면 파일 이름에 마침표가 있는 "보이지 않는" 파일 보기를 활성화해야 할 수 있습니다.)

.maintenance 파일이 없으면 사이트가 예상대로 로드됩니다.

2. 파일 업로드 또는 게시물 크기 제한에 도달했습니다.

너무 많은 데이터를 전송하기 때문에 업로드, 게시 후 또는 양식 제출 프로세스에서 사이트가 흰색 화면으로 시간 초과될 수 있습니다.

해결 방법: wp-config.php 에서 게시물 콘텐츠 제한을 늘립니다.

 ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

해결 방법: php.ini 에서 파일 업로드 및 게시 크기 제한을 늘립니다.

 upload_max_filesize = 256M
post_max_size = 256M

게시물 또는 양식 제출 시간이 초과되기 전에 시간(초)을 연장하는 것도 도움이 될 수 있습니다. PHP가 스크립트를 실행하고 입력을 구문 분석하는 시간을 늘리는 것도 가능합니다. 또한 양식 제출에 허용되는 변수의 수를 늘릴 수 있습니다. 마지막으로 PHP가 제출된 데이터를 쓰레기로 처리하는 시간 제한을 지정할 수 있습니다.

 max_execution_time = 300
max_input_time = 300
max_input_vars = 1000
session.gc_maxlifetime = 1000

또는 .htaccess , httpd.conf 또는 virtualhost 에서:

 php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value 세션.gc_maxlifetime 1000

또는 WordPress용 사용자 지정 코드 스니펫 또는 테마 functions.php 파일에서:

 @ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000' );

이러한 매개 변수의 메모리 및 시간 값은 권장 사항일 뿐입니다. 작동하는지 확인하고 현재 값을 확인하려면 WordPress 관리 인터페이스에서 사이트 상태 도구를 사용하십시오.

복구 모드와 함께 WordPress 5.2는 사이트 상태 도구를 도입했습니다. 문제를 진단하고 사이트 설정 및 서버 환경에 대한 기술 정보를 얻는 데 매우 유용합니다. 도구 > 사이트 상태 아래의 관리자 메뉴에서 찾으십시오. WordPress용 상태 점검 및 문제 해결 플러그인의 확장 기능을 활용할 수도 있습니다.

3. PHP 메모리 부족

PHP는 WordPress 코어의 기반이 되는 서버 측 스크립팅 언어입니다. PHP가 WordPress 및 활성 플러그인을 실행할 메모리가 충분하지 않으면 WSOD가 나타납니다. 오류 메시지 또는 로그에 표시된 것을 볼 수 있습니다.

호스팅 계획에 따라 서버의 모든 애플리케이션 또는 WordPress의 특정 인스턴스에 대한 PHP 메모리 제한을 늘릴 수 있습니다. 어떻게 해야 할지 잘 모르겠으면 호스트의 기술 지원 팀에 도움을 요청하십시오.

wp-config.php

일반적으로 WordPress 폴더의 wp-config.php 파일에 다음 설정을 추가하면 이 예에서 WordPress의 프런트 엔드 메모리 제한이 256MB로 설정됩니다.

 define('WP_MEMORY_LIMIT', '256M');

128~256MB가 적당합니다. 또한 다음 줄을 wp-config.php 에 추가하여 PHP에 할당된 최대 또는 백엔드 메모리(다음 예제에서도 256MB)를 정의할 수 있습니다.

 정의('WP_MAX_MEMORY_LIMIT', '256M');

두 번째 숫자는 PHP가 자체적으로 사용할 수 있는 총 메모리를 정의하는 최대 메모리 제한입니다. 첫 번째 숫자는 더 큰 PHP 제한 내에서 실행되는 WordPress의 메모리입니다. 최대 PHP 메모리 제한은 WordPress 애플리케이션 메모리 제한과 같거나 높아야 합니다.

php.ini

PHP 최대 메모리 제한을 정의하는 또 다른 방법은 WordPress 폴더에 있는 php.ini 파일의 설정을 사용하는 것입니다.

 memory_limit = 256M

줄의 시작 부분에 세미콜론이 없는지 확인하십시오! 그리고 php.ini 는 php.ini 파일이 있는 폴더 또는 그 아래에서 실행되는 WordPress(또는 다른 모든 PHP 응용 프로그램) 인스턴스에만 영향을 미칩니다. 서버 또는 웹 루트에 액세스할 수 있는 경우 php.ini 는 다른 조건을 지정하는 자체 php.ini 파일이 없는 한 모든 PHP 응용 프로그램에 대한 환경 설정을 관리하는 것은 거기에 있는 php.ini 파일입니다.

.htaccess

PHP 메모리 제한을 정의하는 세 번째 방법은 Apache 또는 Litespeed를 HTTP 서버로 사용하는 경우 WordPress 폴더의 .htaccess 파일을 사용하는 것입니다. 위의 예와 같이 .htaccess에는 최대 PHP 제한을 256MB로 설정하기 위해 다음과 같이 주석 처리되지 않은 행이 있어야 합니다.

 php_value memory_limit 256M

wp-config.php , php.ini 및 .htaccess 의 응용 프로그램 및 서버 설정 구문 오류로 인해 WSOD가 발생할 수도 있습니다. 사이트를 손상시키는 경우 수동으로 수정하거나 원래 기본값으로 바꿔야 할 수 있습니다. Apache 또는 Litespeed 웹 서버를 사용하는 경우 작동 방식을 제어하는 .htaccess 파일은 많은 WordPress 플러그인에서 변경할 수 있습니다. 이러한 파일에 오류가 발생하면 WSOD가 발생하고 사이트가 다운될 수 있습니다.

4. HTTP 서버가 충돌합니다

HTTP(또는 암호화된 보안 형식 HTTPS)는 웹 서버를 웹 서버로 만드는 하이퍼텍스트 전송 프로토콜입니다. 요청 시 서버가 클라이언트(예: 브라우저)에 웹 페이지(HTTP 문서)를 제공하는 방식입니다.

WordPress 사이트에 일반적으로 사용되는 HTTP 서버는 Apache, Litespeed 및 NGINX입니다. 오류 화면은 약간 다르게 보이고 브라우저에 표시되는 방식이 다를 수 있지만 모두 동일한 HTTP 오류 코드를 보고합니다.

내부 서버 오류라고도 하는 HTTP 500 오류는 HTTP 요청을 이행하지 못하게 하는 예기치 않은 문제가 HTTP 서버에 있음을 나타냅니다. 다른 5xx 서버 오류 코드, 특히 502(잘못된 게이트웨이), 503(사용할 수 없는 서비스) 및 504(게이트웨이 시간 초과)는 서버가 과부하되었거나 액세스할 수 없음을 나타냅니다. 500 내부 오류는 요청된 페이지/문서를 반환하지 못하게 하는 서버의 고장에 대한 포괄적인 오류입니다.

귀하의 브라우저는 HTTP 오류 화면에 대한 고유한 테이크를 제공할 수 있으며 고유한 특수 오류 코드를 표시할 수 있습니다. Google Chrome(및 기타 Chromium 기반 브라우저)은 Chrome을 사용하는 동안 주소 표시줄에서 chrome://network-errors/ 로 이동하는 경우 내부적으로 자체 오류 코드를 모두 나열하고 설명합니다.

서버 측 문제

WordPress 사이트에 일반적으로 사용되는 HTTP 서버 소프트웨어에는 Apache, Litespeed 및 NGINX가 포함됩니다. 많은 WordPress 호스트는 성능을 최대화하기 위해 캐싱과 함께 사용합니다.

브라우저를 강제로 새로 고치거나 브라우저 쿠키 및 캐시를 지워도 500 오류 화면이 제거되지 않으면 잘못된 서버 측 캐시 파일을 선택할 수 있습니다. 서버 측 캐싱은 잘 안 될 때 많은 혼선을 일으킬 수 있으니 이것도 클리어 해보시길 바랍니다. 호스팅 제어판 또는 WordPress 관리 인터페이스에 캐시 지우기 컨트롤이 있을 수 있습니다.

HTTP 500 오류의 일반적인 원인에는 다음과 같은 서버 측 조건이 포함될 수 있습니다.

1. PHP 메모리 제한이 초과되었습니다.
2. PHP가 오류를 표시하도록 설정되지 않은 경우 기타 PHP 오류.
3. 서버 파일 및 폴더에 대한 액세스 권한이 부족합니다.
4. .htaccess 구성 파일의 구문 오류.

우리는 이미 PHP 메모리 제한과 이를 늘리는 방법을 다루었습니다. 아래의 다음 섹션에서 PHP 디버깅에 대해 자세히 살펴보겠습니다.

최신 관리 WordPress 호스팅에서는 잘못된 권한이 발생하지 않아야 하지만 기존 공유 호스팅에서는 일반적입니다. 파일은 664 또는 644로, 폴더는 775 또는 755로, wp-config.php는 660, 600 또는 644로 설정해야 합니다. WordPress.org에서 파일 권한 변경에 대해 자세히 알아보세요.

.htaccess 파일을 변경했거나 파일을 변경하는 플러그인(종종 또는 캐싱)을 사용하는 경우 오류를 검토하거나 복원하거나 작동하는 새 .htaccess 파일을 다시 만들어야 할 수 있습니다. WordPress.org에서 .htaccess 에 대해 자세히 알아보세요.

클라이언트 측 문제

HTTP 500 오류는 다른 조건으로 인해 클라이언트 측(브라우저)에서 발생할 수도 있습니다.

5. 잘못된 브라우저 설정.
6. 손상된 캐시.
7. 브라우저에서 실행되는 손상된 JavaScript 파일.
8. 인터넷 연결 문제.

다른 브라우저에서 사이트를 로드하여 문제인 현재 브라우저를 제거해 보십시오. 브라우저 문제가 있는 경우 기본 설정으로 재설정해 보십시오. 설치한 브라우저 확장 프로그램이나 플러그인을 비활성화하여 사이트와 제대로 상호 작용하지 않는지 확인하세요.

문제가 잘못된 캐시 파일과 관련된 경우 캐시되지 않은 WordPress 관리 영역에 계속 액세스할 수 있습니다. 여전히 WordPress 관리 인터페이스에 로그인할 수 있는 경우 거기에서 캐시 지우기 스위치를 사용하거나 아래에 설명된 추가 문제 해결 단계를 시도할 수 있습니다.

데이터베이스 문제, WordPress 사이트의 플러그인 또는 테마 문제 또는 WordPress 자체 문제로 인해 HTTP 500 오류가 발생할 수도 있습니다.

HTTP 500 오류 문제를 해결하려면 HTTP 서버와 PHP에 대한 오류 로깅을 켜야 합니다. 그런 다음 둘 다에 어떤 오류가 나타나는지 확인하십시오. 또한 PHP 메모리 제한을 확인하고 잠재적으로 늘리고, 플러그인을 비활성화하고, 기본 테마로 전환하여 이러한 조치로 인해 사이트가 다시 작동하는지 확인할 수 있습니다.

아래에서 이러한 단계에 대해 자세히 살펴보겠습니다. 이를 수행해도 500 오류가 해결되지 않으면 웹 호스트의 지원 팀에 문의하여 추가 지원을 받으십시오.

WordPress가 정말로 죽었을 때

오류 피드백이 전혀 표시되지 않고 WordPress 사이트의 모든 프런트 및 백엔드 페이지에 완전히 흰색 화면이 나타나는 경우 이것이 완전한 WSOD 경험입니다. PHP 오류 로그 및 HTTP 서버 로그에 액세스하는 방법을 알고 있으면 일부 오류 메시지 및 진단 정보를 얻을 수 있습니다. WordPress에 대한 PHP 디버깅을 켜는 것은 또 다른 옵션입니다. 호스트에는 디버깅에 보다 쉽게 ​​액세스할 수 있는 몇 가지 도구가 있을 수 있습니다. 그러나 그렇지 않은 경우 솔루션을 찾을 때까지 일반적인 WSOD에 대한 이 치료법 목록을 간단히 살펴볼 수 있습니다.

WordPress의 죽음의 흰색 화면 문제 해결 및 수정을 위한 마스터 체크리스트

WordPress White Screen of Death를 수정하려면 다음 단계를 수행하면 해결책을 찾을 수 있습니다. 내가 경험한 대로 가장 일반적인 WSOD 원인의 순서대로 구성되어 있지만 어떤 순서로든 시도해 볼 수 있습니다.

특정 상황에 가장 관련이 있는 것으로 보이는 솔루션의 우선 순위를 지정하는 것이 가장 합리적입니다.

오류 로깅 및 디버깅 단계(#2)는 가장 기술적이지만 철저하며 항상 WordPress를 종료시키는 원인을 알려줍니다.

유용한 진단 및 복구 도구가 될 수 있는 몇 가지 무료 플러그인에 대한 링크를 제공했습니다. 또한 iThemes Security가 특히 데이터베이스 스캔 및 복구 기능과 파일 변경 감지에 유용하다는 것을 알 수 있습니다. 서버 설정 및 기능을 자세히 살펴볼 수 있는 서버 도구도 있습니다.

최후의 수단으로 좋은 최신 백업을 통해 사이트를 마지막으로 알려진 양호한 상태로 온라인 상태로 되돌릴 수 있습니다. Backup Buddy는 이 역할에 가장 적합한 플러그인입니다.

브라우저 캐시 및 쿠키 지우기

브라우저와 서버에 있는 사이트의 캐시된 페이지는 실제로 발생하는 것과 다른 것을 보여줄 수 있습니다. WordPress가 귀하의 사이트에 새로운 방문자를 표시하는 것을 보고 있는지 확인하십시오.

먼저 브라우저의 캐시와 쿠키를 지웁니다. 이렇게 하면 WordPress 또는 다른 사이트에 로그인한 경우 사용자 세션이 종료되므로 다른 방문자처럼 볼 수 있습니다.

그런 다음 호스팅 패널과 WordPress 관리자(사용 가능한 경우)를 사용하여 호스트 및 WordPress 캐시 플러그인이 생성하는 모든 서버 측 캐싱을 지웁니다. 모든 사이트와 서버 캐싱을 끄십시오. 브라우저에서 강제 새로 고침을 수행합니다. 문제가 해결되면 시스템에서 작동하지 않는 캐시 설정이 활성화된 것이 문제일 수 있습니다. 제거 프로세스를 통해 작동하는 것과 작동하지 않는 것을 식별할 수 있습니다.

2. PHP 오류 찾기

WordPress 코어, 테마 또는 플러그인의 PHP 코드는 WordPress가 White Screen of Death로 유령을 포기하게 만드는 치명적인 오류를 생성할 수 있습니다.

치명적인 PHP 오류와 그 원인에 대한 자세한 정보를 얻으려면 PHP 오류 보고를 켜고 화면, 로그 파일 또는 둘 다로 보낼 수 있습니다. 치명적인 오류는 WSOD의 소스를 가리킬 수 있습니다.

PHP 기반 웹 애플리케이션인 WordPress에는 PHP의 오류 로깅 기능을 활용하는 데 도움이 되는 디버깅을 위한 자체 진단 보고 시스템이 있습니다. 켜고 제어하려면 wp-config.php 에 다음과 같은 줄이 있는지 확인하십시오.

 정의('WP_DEBUG', true);

이를 추가하거나 값을 false에서 true로 변경해야 할 수 있습니다. 이는 WordPress에 PHP 디버깅을 켜도록 지시합니다.

WP Debugging 플러그인을 설치하고 활성화하여 바로 가기를 사용할 수도 있습니다. wp-config.php 를 직접 수정하지 않고도 WordPress에 대한 PHP 디버깅을 켭니다.

아래 표시된 추가 wp-config.php 매개변수는 디버깅 출력을 HTML 및 기본적으로 "error_log"라는 파일로 화면에 인쇄합니다.

 정의( 'WP_DEBUG_DISPLAY', 참 );
정의( 'WP_DEBUG_LOG', 참 );

또한 WordPress가 문제를 일으킬 가능성이 있는 경우 최적화되지 않은 버전의 CSS 및 JavaScript 종속성을 사용하도록 하는 것이 도움이 될 수 있습니다.

 정의( 'SCRIPT_DEBUG', true );

Debug Bar 플러그인은 유용한 추가 보완 도구입니다. 멋진 인터페이스에서 디버깅 데이터를 보여줍니다.

이를 위해서는 php.ini 에 error_reporting = E_ALL 과 같이 NONE 이외의 값을 error_reporting 상수에 제공하는 줄이 있어야 합니다. 이 줄에는 세미콜론이 없어야 합니다. 활성 설정이 아닌 주석이 됩니다. E_ALL 을 사용하면 모든 PHP 오류, 경고 및 알림이 표시됩니다. E_ERROR 와 같은 다른 값을 사용하여 WordPress 충돌을 유발하는 치명적인 런타임 오류만 기록합니다.

3. 테마 및 플러그인 충돌 확인

이전 단계에서 설명한 대로 PHP 오류에 대한 디버깅은 WSOD의 소스로 명확한 테마 또는 플러그인 파일을 가리켜야 합니다. 덜 기술적 인 제거 프로세스 접근 방식으로 닫을 수도 있습니다.

테마 문제 해결

White Screen of Death는 종종 WordPress 테마 및/또는 플러그인 간의 충돌로 인해 발생합니다. 충돌 소스를 식별하려면 모든 플러그인을 비활성화하고 Twenty Twenty-Three와 같은 WordPress 코어를 사용하여 수정되지 않은 현재 기본 테마 패키지로 전환해 볼 수 있습니다.

테스트하기 가장 간단한 테마로 시작합니다. 활성 테마를 정상으로 알려진 수정되지 않은 기본 테마로 전환하면 사이트가 다시 온라인 상태가 된다면 사용하던 테마에 문제가 있는 것입니다.

테마의 functions.php 파일이 있는 경우 해당 파일을 살펴보십시오. 최근에 변경한 경우 문제의 원인일 수 있습니다. functions.php 파일은 활성화될 때 테마와 함께 사용하기 위해 사용자 정의 기능 코드가 추가되는 곳입니다. 여기서 잘못된 코드 및 구문 오류는 WSOD를 제공합니다.

플러그인 문제 해결

일시적으로 플러그인 폴더를 /wp-content/plugins/ 폴더 밖으로 이동하여 명령줄/SSH 또는 SFTP를 통해 WordPress 관리자에 액세스 하지 않고도 플러그인을 비활성화할 수 있습니다. 내 연습은 "A"라는 플러그인 하위 폴더를 만들어서 알파벳순으로 정렬된 /plugins 디렉토리에 먼저 나타나도록 하는 것입니다. 그런 다음 다른 모든 플러그인 폴더를 "A"로 이동합니다.

이 작업을 완료하면 사이트를 새로고침하세요. WordPress는 플러그인이 모두 사라진 것처럼 작동합니다. 여전히 설치되어 있지만 비활성화되어 있습니다. White Screen of Death가 사라지면 플러그인과 테마를 하나씩 다시 활성화하고 매번 홈 페이지를 새로 고쳐 어떤 것이 사이트 충돌을 일으키는지 확인할 수 있습니다.

Meks Quick Plugin Disabler는 모든 활성 플러그인을 빠르게 비활성화한 다음 명령에 따라 WordPress 관리자 내부에서 다시 활성화하는 편리한 도구입니다.

4. 손상된 코어 파일 복구

WSOD는 손상된 핵심 WordPress 파일의 결과일 수 있습니다. 그럴 가능성은 낮지만 WordPress 대시보드 업데이트 영역에서 클릭 한 번으로 최신 버전의 WordPress를 빠르게 다시 설치하는 것은 간단합니다. 이것은 플러그인, 테마 또는 기존 콘텐츠에 해를 끼치지 않으므로 핵심 파일이 정상인지 확인하는 좋은 방법입니다.

위의 단계 중 어느 것도 도움이 되지 않는 경우 WSOD는 사용자가 도달할 수 없는 서버 환경 문제로 인해 발생할 수 있습니다. 이 경우 호스팅 제공업체에 도움을 요청해야 할 수 있습니다. 최후의 수단으로 백업을 복원하여 사이트를 "마지막으로 성공한" 상태로 롤백할 수도 있습니다.

WSOD를 방지하는 방법 — WordPress 사이트 소유자 및 빌더를 위한 조언

WordPress는 제대로 작동하고 있었는데 갑자기 White Screen of Death가 생겼습니다!

WordPress의 기능에 중요한 것을 변경했기 때문일 수 있습니다.

Liquid Web 또는 Nexcess와 함께 견고한 관리형 WordPress 호스팅 계정을 사용하는 경우 수행 중인 작업에 대한 충분한 리소스로 적절하게 구성되어 WSOD로 WordPress를 손상시킬 수 있는 방법의 99%를 피할 수 있습니다.

문제는 사이트 소유자가 이러한 관행을 피하지 않는다는 것입니다!

하지 말아야 할 것

1. 카우보이 코딩. SFTP, 명령줄 또는 WordPress 관리자 내부의 코드 편집기 및 스크립트 삽입기를 통해 라이브 사이트에서 기능 코드를 추가하거나 편집합니다. 하나의 작은 실수로 사이트가 다운됩니다. .htaccess 및 wp-config.php 와 같은 구성 파일을 변경하면 사이트가 다운될 수도 있습니다. 대신 로컬 테스트 또는 라이브(공용 아님) 스테이징 사이트에서 작업합니다.
2. 모호한 테마, 플러그인 및 확장 설치. 라이브 사이트에 저품질 또는 무효화된 소프트웨어를 설치하는 것은 문제를 불러일으키는 것입니다. 한 번에 너무 많은 것을 추가하는 것만으로도 최종적으로 브레이킹 체인지가 무엇인지 결정하기 어려울 수 있습니다. 카우보이 코딩과 유사하게 새 코드 제품을 라이브 사이트에 설치하는 것은 위험합니다. 개인 로컬 또는 준비 사이트에서 먼저 잘 테스트하십시오.
3. 복잡한 캐싱. 모든 캐싱 및 성능 최적화 플러그인과 제대로 작동하지 않을 수 있는 여러 종류의 서버측 캐싱이 호스트에서 제공될 수 있습니다. 새로운 캐싱 방법이나 설정을 구현하는 경우 라이브 사이트에 대한 변경 사항을 구현하기 전에 로컬 및 스테이징 환경에서 신중하게 테스트하십시오.
4. 한 번에 모든 것을 업데이트합니다. 여러 테마와 플러그인을 한 번에 일괄 업데이트할 수 있습니다. 일반적으로 이것은 작동하지만 서버 시간이 초과되면 유지 관리 모드에서 멈출 수 있습니다. 또한 새로 업데이트된 코드로 인해 새로운 버그, 충돌 또는 호환성 문제가 발생할 수 있습니다. 이런 일이 발생하여 사이트가 다운되면 문제의 원인을 파악하기가 더 어려워집니다. 여러 테마, 플러그인 및 확장 프로그램을 한 번에 모두 업데이트한 경우 여러 항목이 될 수 있습니다. 업데이트된 코드는 기본 공개 사이트에 배포하기 전에 로컬 및 라이브 스테이징 사이트에서 테스트할 수 있습니다.

WSOD가 없는 삶을 위한 팁

WSOD는 모든 WordPress 사이트에서 발생할 수 있지만 경보의 원인이 되어서는 안 됩니다. 이 가이드의 팁을 따르면 사이트 방문자가 알아차리기 전에 문제를 식별하고 신속하게 해결할 수 있습니다.

WordPress 사이트의 문제는 적절한 유지 관리 및 관리의 중요성을 강조합니다. WSOD에 반응하는 것보다 방문자가 오류 메시지와 빈 화면에 노출되지 않는 방식으로 WordPress에서 작업하는 방법을 배울 수 있습니다.

신중하고 신중하게 변경하십시오. 로컬 테스트 또는 스테이징 환경에서 잠재적인 WSOD를 처리합니다. 이들은 오늘날 대부분의 관리되는 WordPress 호스트를 위한 표준 도구 및 기능입니다. 이러한 기본 모범 사례를 따르면 WordPress White Screen of Death에 대해 걱정할 필요가 없습니다.

WordPress 보안 및 보호를 위한 최고의 WordPress 보안 플러그인

WordPress는 현재 모든 웹사이트의 40% 이상을 지원하므로 악의적인 의도를 가진 해커의 손쉬운 표적이 되었습니다. iThemes Security Pro 플러그인은 WordPress 보안에서 추측을 제거하여 WordPress 웹사이트를 쉽게 보호하고 보호할 수 있도록 합니다. WordPress 사이트를 지속적으로 모니터링하고 보호하는 상근 보안 전문가가 있는 것과 같습니다.

iThemes 보안 프로 받기

댄 크나우스

Dan Knauss는 StellarWP의 기술 콘텐츠 제너럴리스트입니다. 그는 1990년대 후반부터 오픈 소스에서 일하고 2004년부터 WordPress에서 일하는 작가, 교사 및 프리랜서였습니다.