답변:
그것은 당신이 ALTERNATE_WP_CRON
정의한 표시입니다wp-config.php
예약 된 게시물 게시와 같은 일부 백그라운드 처리를 수행하기 위해 WordPress에서 ?doing_wp_cron
추가 된 URL로 리디렉션합니다 .
이 문제에 대한 많은 게시물을 보았지만 실제 해결책을 찾는 데 성공한 사람은 거의 없습니다. 나를 위해이 문제를 해결하는 것은 .htaccess 파일에서 리디렉션을 관리하는 것이 었습니다.
다음은 .htaccess 파일에 다음 줄을 추가하여 URL을 리디렉션하는 방법에 대한 예입니다.
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron= [NC]
RewriteRule (.*) /$1? [R=301,L]
</IfModule>
이것이 도움이되기를 바랍니다!
참고 :이 팁은 이 포럼 에서 가져옵니다.
@scribu BackupBuddy는 백업 절차의 일부로 WordPress 작업 예약을 사용하여 백업 일정의 일부로 작업을 예약한다고 생각합니다-사이트에 루프백이 비활성화되어 있으면 유일한 솔루션 (일부 맞춤형 외부 솔루션 제외)과 내가 확신하는 특정 대체 솔루션 아시다시피, WordPress에 통합되어 있으며 대체 cron 수정입니다. 따라서 호스트에 루프백이 비활성화 된 경우에만 "필수"입니다. 이 경우라면 아니오 라는 것을 명심하십시오.예약 된 작업 (표준 WordPress 예약 된 작업 또는 다른 플러그인과 관련된 작업)이 작동합니다. 사실은 사용자가 BackupBuddy를 시도 할 때까지 호스트가 WordPress 설치를 방해했다는 사실을 사용자가 알지 못하는 것입니다. 그 이유는 그 시점까지는 보이지 않았기보다는 문제가 분명하기 때문입니다.
crontab 유형 접근 방식을 사용하는 것은 고정 된 석고 일뿐입니다. 왜냐하면 WordPress cron 처리를 매우 자주 "핑 (ping)"하지 않으면 일정 유형의 예약 된 작업에서만 작동하는 것이기 때문입니다.
물론 사용자가 대체 wp cron 픽스를 원하지 않거나 사용할 수없는 경우 루프백을 허용하고 적절한 crontab 기반 기능을 설정할 수있을만큼 충분히 알 수없는 호스트로 이동하지 않으려는 경우 BackupBuddy는 작동하는 수동 백업 모드를 제공하지만 일정을 사용할 수있을 때 사용할 수있는 기능의 유연성이 부족합니다.
이 문제의 원인은 대체 cron입니다. 이 문제를 해결하려면 액세스 권한이 있으면 실제 cron 프로세스를 활성화하고 (호스팅에서 허용 할 경우) wp-config.php에서 ALTERNATE_WP_CRON을 비활성화 할 수 있습니다.
ALTERNATE_WP_CRON
같이 정의하는 것false
입니다wp-config.php
.