WordPress 업데이트 실패 및 게시 실패 오류를 수정하는 방법

WordPress 사이트에서 콘텐츠를 업데이트하려고 할 때 "업데이트 실패" 또는 "게시 실패" 오류가 발생합니까? 당신은 바로 이곳에 왔습니다. 이러한 문제의 근본 원인을 식별하고 해결할 수 있는 방법을 살펴보겠습니다.

WordPress 업데이트 및 게시 실패 오류의 원인은 무엇입니까?

WordPress 인스턴스가 WordPress REST API(WordPress 블록 편집 경험에 의존)와 통신하지 못하는 경우 WordPress에서 "게시 실패" 또는 "업데이트 실패" 오류가 발생할 수 있습니다.

이런 일이 발생하는 데는 여러 가지 이유가 있지만 가장 분명한 이유는 가장 간단합니다. 인터넷 연결이 끊어졌습니다.

연결이 끊긴 경우 게시 실패 오류가 발생할 수 있습니다. 이런 일이 발생할 수 있는 또 다른 이유는 다음과 같습니다.

• 사이트 URL의 최근 변경 사항
• API 호출을 방지하는 모든 타사 서비스
• 오작동하는 플러그인

대부분의 경우 이것은 쉽게 해결할 수 있습니다.

1단계 – 인터넷 연결 확인 및 영구 링크 설정 저장

틀림없이 이 오류가 발생하는 가장 일반적인 이유는 인터넷 연결이 끊어졌을 때입니다. 블로그 게시물을 업데이트하는 동안 예기치 않게 연결이 끊어지면 WordPress에서 이 오류를 반환할 수 있습니다. 인터넷에 연결되어 있는지 확인한 경우 새 탭의 편집 보기에서 게시물이나 페이지를 열고(또는 페이지에서 다른 곳으로 이동하기 전에 변경 사항을 복사/저장해야 함) 콘텐츠 업데이트를 다시 시도합니다.

또 다른 일반적인 해결 방법은 사이트의 영구 링크 설정을 다시 저장하는 것입니다(일반적으로 호스팅 구성 변경으로 인해 손실됨). 이를 수행하는 두 가지 매우 간단한 방법이 있습니다. 우리가 제안하는 첫 번째 방법은 WP CLI를 사용하는 것입니다.

WP CLI로 영구 링크 설정 새로 고침

SSH를 통해 호스팅 환경에 액세스할 수 있는 경우 영구 링크 설정을 새로 고치는 가장 쉬운 방법은 다음과 같습니다.

1 – 서버에 SSH 접속

2 – WordPress 설치의 루트 디렉토리로 이동합니다.

3 – 다음을 실행하여 기존 영구 링크 구조를 플러시합니다.

 wp 다시 쓰기 플러시

4 – 다음과 같이 이전에 사용했던 영구 링크 구조를 다시 업데이트합니다.

 wp 재작성 구조 '/%postname%'

참고: 프로덕션 환경에서 이러한 명령을 실행하는 경우 영구 링크 설정을 다른 구조로 변경하면(사용하던 동일한 구조로 다시 변경하지 않고) 트래픽 손실이 발생하므로 주의하여 진행하십시오.

WordPress 관리 영역에서 영구 링크 설정 새로 고침

또는 아래와 같이 설정 > 영구 링크에서 액세스할 수 있는 영구 링크 설정의 WordPress 관리 영역에서 직접 변경할 수도 있습니다.

2단계 – REST API가 차단되고 있는지 확인

위에서 언급했듯이 WordPress 게시 실패 오류가 발생할 수 있는 또 다른 일반적인 이유는 REST API가 비활성화되었거나 차단된 경우입니다. 고맙게도 WordPress에는 REST API 상태를 확인하는 데 사용할 수 있는 멋진 도구가 있습니다.

도구 로 이동한 다음 사이트 상태를 선택하기만 하면 됩니다. 여기에서 WP 설치와 관련된 많은 오류를 볼 수 있습니다. REST API가 제대로 작동하지 않으면 다음 오류가 표시됩니다.

"REST API에 예기치 않은 결과가 발생했습니다."

또한 사이트 상태 보고서는 사이트에 설치 및 활성화한 특정 플러그인에 의해 REST API가 차단되는 경우와 같은 문제 해결 방법에 대한 몇 가지 팁을 제공합니다.

즉, 사이트의 특정 원인을 디버그하는 가장 좋은 방법은 다음 행을 따라 무언가를 표시할 수 있는 브라우저의 콘솔 로그를 확인하는 것입니다.

위의 경우 정확한 오류 메시지는 " ERROR 업데이트에 실패했습니다. 오류 메시지: 응답이 유효한 JSON 응답이 아닙니다. "이고 오류의 원인은 Cloudflare의 방화벽이 사용자의 IP가 WP JSON에 액세스하는 것을 차단했기 때문입니다.

따라서 문제가 WP JSON 또는 REST API 오류에서 403(금지됨) 상태 코드를 받는 것 같다면 현재 보유하고 있는 보안 조치(예: 웹 애플리케이션 방화벽, 다음에 설명)가 다음과 같은지 확인하십시오. 사용자가 WordPress 웹 사이트에 콘텐츠를 게시하거나 업데이트할 수 없도록 하는 이러한 디렉토리에 대한 액세스를 의도치 않게 차단하지 마십시오.

3단계 – 웹 응용 프로그램 방화벽 서비스 확인

Cloudflare는 콘텐츠 전송 네트워크(CDN) 서비스, DDoS 보호, 인터넷 보안 및 DNS 서비스를 제공하는 세계 최대의 공급업체입니다.

우리는 Servebolt에서 Cloudflare의 열렬한 팬입니다. Cloudflare 최적화 파트너로서 Servebolt와 Cloudflare 간의 더 나은 네트워킹 연결을 제공합니다. 우리는 Servebolt CDN 및 Accelerated Domains 서비스를 포함하여 인프라의 다양한 부분에 Cloudflare Enterprise를 사용합니다.

사이트에서 Cloudflare를 사용하는 경우 서비스에서 REST API 호출을 차단할 수 있습니다. 방화벽 필터가 트리거되고 Cloudflare가 IP 주소를 의심스러운 것으로 간주하면 WordPress 관리 영역에서 "업데이트 실패" 또는 "게시 실패" 오류가 발생할 수 있는 모든 REST API 요청을 즉시 차단합니다.

이 경우 IP 주소를 빠른 수정으로 화이트리스트에 추가하기 전에 IP가 자체 WAF에 의해 차단된 이유를 식별하려면 웹 애플리케이션 방화벽의 분석을 확인하여 어떤 방화벽 규칙이 트리거되었는지 확인하십시오.

4단계 – PHP 오류 로그 검토 및 WordPress에서 디버깅 모드 활성화

WP 디버그를 활성화하고 WordPress의 자체 디버그 시스템을 사용하기 전에 Servebolt를 사용하는 사용자는 PHP 오류 로그에 쉽게 액세스할 수 있습니다.

기본적으로 Servebolt Cloud에서 실행되는 모든 사이트는 ErrorLog 및 AccessLog 의 두 가지 로그를 생성합니다. 이것들은 모두 /logs 폴더에 있는 사이트 루트에 있을 수 있습니다(즉, /public 디렉토리와 동일한 수준에 있음).

ErrorLog 파일에는 런타임 오류를 생성하는 사이트에서 실행 중인 모든 코드에 대한 정보가 포함됩니다(여기에는 사이트를 손상시키지 않고 백그라운드에서 계속 자동으로 실패하지만 가끔 발생하는 오류가 포함됨).

그리고 이것이 오류의 원인이 무엇인지에 대한 추가 정보를 제공하지 않는 경우 WordPress에서 디버깅 모드를 활성화할 수 있습니다. 디버깅 모드에 들어가면 WordPress는 debug.log 라는 새 파일에 수신된 모든 PHP 응답을 자동으로 기록합니다.

이 새 파일은 wp-content 디렉토리에 나타나므로 문제를 일으킬 수 있는 서버 측 응답을 확인하기 위해 살펴봐야 합니다.

디버깅 모드로 들어가려면 wp-config.php 파일을 열고 마지막 줄 바로 앞에 다음 줄을 추가하세요.

 // WP_DEBUG 모드 활성화
정의( 'WP_DEBUG', true );

// /wp-content/debug.log 파일에 디버그 로깅 활성화
정의( 'WP_DEBUG_LOG', true );

// 프로덕션 사이트에서 공개적으로 오류를 표시하지 않도록 합니다(선언하지 않은 경우 기본값은 true). 

정의( 'WP_DEBUG_DISPLAY', false );

debug.log 파일을 검토한 후 wp-config.php 파일에서 이 코드를 제거하여 디버깅 모드를 종료할 수 있습니다.

Servebolt를 사용하면 기본적으로 ErrorLog 및 AccessLog를 포함한 PHP 오류 로그에 액세스할 수 있습니다. 요청 시 지원 팀에 문의하여 사용할 수 있는 느린 쿼리 로그 외에도. 그러나 WordPress의 자체 디버깅 시스템은 오류를 식별하는 데 탁월하므로 코드베이스를 제어할 수 있도록 빡빡하게 실행할 수 있습니다.

이것은 말할 필요도 없지만 wp-config.php 파일을 변경할 때 주의해서 진행하십시오. 그러면 사이트를 백업하는 데 도움이 됩니다. Servebolt Cloud에서 실행되는 웹사이트는 하루에 두 번 백업됩니다. 우리는 주간 백업(3일 동안 저장)과 야간 백업(30일 동안 저장)을 실행합니다.

WordPress 사이트를 직접 백업할 수도 있습니다. 백업을 복원하려면 지원 팀에 문의하기만 하면 추가 비용 없이 가장 최근 백업을 복원해 드립니다.

5단계 – 모든 WordPress 플러그인 비활성화 및 다시 확인

사이트의 WordPress 플러그인으로 인해 오류가 발생했다고 의심되는 경우 한 가지 옵션은 모든 플러그인을 비활성화하고 문제가 해결되는지 확인하는 것입니다.

이렇게 하려면 플러그인 으로 이동한 다음 설치된 플러그인을 선택하기만 하면 됩니다. 그런 다음 모든 플러그인을 선택하고 일괄 작업 드롭다운을 사용하여 한 번에 비활성화합니다.

그런 다음 화면으로 돌아가 WordPress 업데이트 또는 게시 실패 오류가 여전히 지속되는지 확인합니다. 그렇지 않은 경우 이제 사이트에서 실행 중인 플러그인이 오류의 원인임을 알게 될 것입니다. 이 단계에서 식별하는 brute force 방법은 플러그인을 하나씩 다시 활성화하고 오류가 발생하면 다시 확인하는 것입니다. 그리고 제거 과정을 통해 결함이 있는 플러그인을 식별할 수 있습니다.

문제를 찾으면 플러그인 작성자에게 연락하여 디버깅에 필요한 정보를 제공하고 귀하(및 다른 모든 사용자)를 위해 제품을 개선하는 데 도움이 되므로 플러그인 작성자에게 알려주는 것이 좋습니다. 이것은 분명히 매우 지루하고 시간이 많이 걸리는 것을 감안할 때 디버깅과 관련하여 첫 번째 선택이 아닐 것입니다.

임시 해결 방법: Classic Editor 플러그인 설치(솔루션 아님)

WordPress 버전 5.0의 도입은 Gutenberg 편집기, 즉 오늘날 우리 모두가 블록 이라고 널리 참조하는 개념의 도입을 의미합니다.

이것은 일시적인 해결 방법일 뿐이지만 구텐베르크 편집기에서 클래식 편집기로 전환하면 게시물을 저장하고 업데이트할 수 있습니다.

참고: 이것은 분명히 해결책이 아니므로 임시 해결 방법으로만 사용해야 합니다.

구텐베르크에서 클래식 편집기로 전환하려면 클래식 편집기 플러그인을 다운로드하고 사이트에서 활성화하면 됩니다. 활성화되면 편집하고 있던 게시물(또는 페이지)로 돌아가서 평소처럼 다시 업데이트하거나 게시할 수 있습니다.

7단계 – 지원 팀에 연락

위의 어느 것도 귀하의 경우에 해결되지 않고 Servebolt Cloud에서 WordPress 사이트를 호스팅하기로 현명한 결정을 내린 경우 언제든지 지원 팀에 연락하십시오. 채팅과 이메일을 통해 연락을 주시면 저희 팀에서 이 문제의 원인이 무엇인지 기꺼이 조사해 드리겠습니다.

결론

특히 작업을 저장하지 못하게 하거나 작업 중인 새 콘텐츠에 게시를 누르지 못하게 하는 오류가 발생하는 것은 누구도 원하지 않는 일입니다. 따라서 자주 찾을 수 있는 간단한 수정 사항과 임시 솔루션이 있지만 문제의 원인을 식별하여 문제가 다시 발생하지 않도록 조치를 취하는 것이 좋습니다.

경험적으로 더 빠른 관리 호스팅에 관심이 있으십니까? Servebolt 방식을 시도하십시오:

• 확장성: 실제 사용자 워크로드 테스트에서 Servebolt는 65ms의 평균 응답 시간을 제공했으며, 이는 두 번째로 좋은 것보다 4.9배 빠른 응답 시간입니다.
• 가장 빠른 글로벌 로드 시간: 1.26초의 평균 페이지 로드 시간으로 글로벌 WebPageTest 결과 목록의 맨 위에 올랐습니다.
• 가장 빠른 컴퓨팅 속도: Servebolt 서버는 이전에 볼 수 없었던 데이터베이스 속도를 제공하여 평균보다 초당 2.44배 더 많은 쿼리를 처리하고 두 번째 최고보다 PHP를 2.6배 더 빠르게 실행합니다!
• 완벽한 보안 및 가동 시간: 모든 모니터에서 100% 가동 시간과 SSL 구현에 대한 A+ 등급을 통해 귀하의 사이트가 온라인 상태이고 안전하다는 것을 확신할 수 있습니다.

우리의 전문가 팀이 모두 지원합니다. 오늘 무료 테스트 Bolt 에 대해 Servebolt를 사용할 준비가 되셨습니까?