최근에 저는 흥미로운 작은 문제를 발견했습니다. 저는 책 전용 웹사이트에서 WordPress를 실행하고 있으며 당연히 도메인에 변경 사항이 도입되기 전에 모든 것이 제대로 작동하는지 확인하기 위해 수행해야 하는 테스트가 있습니다. 이러한 변경 사항 중 하나는 WordPress 5.2에 사이트 상태 검사 도구를 도입한 것입니다. 이 도구는 설정에 대한 중요한 문제와 권장 조치를 알려줍니다.
자체적으로는 괜찮지만 5.4로 업데이트하면 도메인에 갑자기 새로운 문제가 있음을 나타내는 몇 가지 치명적인 오류가 표시되는 것을 발견했습니다. 오류:REST API에 오류가 발생하여 사이트에서 루프백 요청을 완료할 수 없습니다. 이 두 가지에 대한 세부 정보는 다음과 같습니다. 오류:cURL 오류 28:0바이트 수신(http_request_failed)으로 10000밀리초 후에 작업 시간이 초과되었습니다. 기이한. 디버그합시다.
자세한 문제
중요한 문제는 경각심을 불러일으킵니다. 그러나 잠재적인 문제를 주의 깊게 살펴보고 실제 영향이 무엇인지 이해해야 합니다. 종종 회사는 버그와 문제를 처리하는 방법에 대해 지나치게 엄격합니다. 아무도 보안 합병증으로 이어질 수 있는 문제에 대해 너무 느슨하다는 비난을 받고 싶어하지 않기 때문입니다. 이제 상태 보고서를 살펴보겠습니다.
첫 번째 문제는 다음과 같습니다.
REST API에 오류가 발생했습니다.
REST API는 WordPress 및 기타 애플리케이션이 서버와 통신하는 한 가지 방법입니다. 한 가지 예는 게시물과 페이지를 표시하고 저장하는 데 의존하는 블록 편집기 화면입니다.
오류로 인해 REST API 요청에 실패했습니다.
오류:cURL 오류 28:수신된 바이트가 0인 상태에서 10001밀리초 후에 작업 시간 초과(http_request_failed)
두 번째 텍스트는 다음과 같습니다.
사이트에서 루프백 요청을 완료할 수 없습니다.
루프백 요청은 예약된 이벤트를 실행하는 데 사용되며 코드 안정성을 확인하기 위해 테마 및 플러그인용 내장 편집기에서도 사용됩니다.
귀하의 사이트에 대한 루프백 요청이 실패했습니다. 이는 루프백에 의존하는 기능이 현재 예상대로 작동하지 않음을 의미합니다.
오류:cURL 오류 28:수신된 바이트가 0인 상태에서 10001밀리초 후에 작업 시간 초과(http_request_failed)
첫 번째 오류는 WordPress가 서버와 통신하는 데 사용하는 한 가지 방법임을 알려줍니다. 이는 다른 방법이 있음을 의미합니다. 다양한 작업을 수행할 때 이것이 실제로 가능한 문제를 일으킬지 여부에 대한 오류는 명확하지 않습니다.
블록 편집기에 대해 구체적으로 언급합니다. 워드프레스 5.0에 도입된 완전히 새로운 구텐베르크 기능인데 저는 사용하지 않고 대신 멋진 클래식 편집기에 의존합니다. 따라서 이것은 처음부터 문제가 아닌 것일 수 있습니다. 그런 다음 실제 기능에 대한 질문이 있습니다. 언급된 기능 중 어느 것도 영향을 받지 않습니다. WordPress는 제대로 작동하고 모든 것을 수행합니다. 아마도 오탐일까요? 곧 뵙겠습니다.
두 번째 오류는 백그라운드 업데이트, 야간 작업 등과 같은 예약된 이벤트에 대해 설명합니다. 다시 말하지만 구성하지 않은 경우 이는 문제가 되지 않습니다. 그렇게 하고 올바르게 실행되면 문제가 영향을 미치지 않습니다. 오류는 "예상대로 작동 중"이라고 표시되지만 이것은 매우 결정적이고 정확한 설명이 아닙니다. 문제 해결이 더 어려워집니다.
문제 원인
그러나 이것이 실제로 실제 문제라고 잠시 가정해 봅시다. 문제는 문제의 원인을 어떻게 해결하느냐입니다. 쉬운 일이 아니며 올바른 방향으로 안내할 수 있는 실제 오류 메시지가 없습니다.
그래서 제가 해야 할 일은 기본이 아닌 모든 구성 요소를 하나씩 수동으로 끈 다음 상태 검사를 다시 실행하여 특정 요소에 문제가 있는지 확인하는 것이었습니다. 운 좋게도 여가 시간에 테스트할 수 있었지만 프로덕션 설정에 미치는 영향을 상상해 보세요.
이제 ... 얼마 후, 나는 내가 사용하고 있던 모든 단일 플러그인과 테마를 시도했지만 이들 중 어느 것도 결과에 영향을 미치지 않는 것 같습니다. WordPress는 계속 불평했습니다. 그런 다음 검색을 확장하기로 결정했습니다. 관리자 페이지에 대한 액세스 제어의 보조 계층으로 기본 인증 및 기타 몇 가지 유용한 세부 정보와 함께 .htaccess 파일을 사용하고 있습니다. Lo와 보라, 인증 부분을 제거하면 문제가 해결되었습니다. 더 이상 상태 확인 오류가 없습니다!
AuthType 기본
AuthName 제한됨
AuthUserFile /home/mastablasta/wp-admin/passwd
유효한 사용자 필요
그래서 그것은 보일 것입니다-WordPress Site Health는 .htaccess 파일을 좋아하지 않습니다. 나는 이것이 어떻게 수표를 통과하는지 정확히 조사하지 않았지만 그럴 필요가 없습니다. 하나, 문제의 원인이 무엇인지 압니다. 둘째, 오류는 내가 원하고 필요로 하는 기능에 영향을 주지 않으므로 문제가 되지 않습니다.
결론
Site Health의 문제는 내부적인 것이 분명합니다. 결국 WordPress 5.4로 이동하면서 문제가 발생하기 시작했습니다. 물론 일부 코드가 변경되었지만 본질적으로 핵심 제품 동작이 업데이트 직전과 갑자기 근본적으로 다르고 사이트 기능의 다른 요소에 큰 문제가 없다면 그것은 문제는 핵심 제품 업데이트에서 비롯된 것 같습니다.
사이트 문제를 한 눈에 볼 수 있는 이런 아이디어는 마음에 들지만, 오탐지나 오류로 인해 발생하는 거위 추적이 잠시라도 마음에 들지 않습니다. 오류는 의미가 있어야 합니다. 오류가 나타나는 방식에서 무엇이 잘못될 수 있는지 통찰력이 없다면 기술적인 세부 사항을 보여줄 필요가 없습니다. cURL 오류 28과 .htaccess는 너무 멀리 떨어져 있는 것 같습니다. 어쨌든, 여기 있습니다. 유사한 문제의 영향을 받는 경우 사이트 구성을 살펴보고 기본 인증을 사용하고 있는지 확인하고 동일한 버그로 인해 어려움을 겪고 있는지 확인하십시오. 여기까지 하겠습니다.
건배.