WP-DBManager：自動実行機能の日付が過去に。実行できず
-
WP-DBManagerをインストールしました。
ところが、自動実行機能が機能してくれず困っております。
解決方法を教えていただけましたら幸いです。当方がトライしたのは以下です。
・本プラグインを停止して、再度有効化した
・本プラグインを削除して、再度インストルし、有効化した
・本プラグインを削除し、backup-dbフォルダも削除し、再度インストールし、有効化した
どれも設定情報が残っているようで、作業前の日付のままになっていました。
おそらくは、この過去の設定情報を削除すれば直らないかな？と想像したところでお手上げとなりました。済みませんんがご存知の方いらっしゃいましたら宜しくお願いします。
-
一部、情報をうまく伝えきれていない点ありまして追加致します。
WP-DBManagerのバージョン 2.63
Database OptionsのAutomatic Schedulingで自動でバックアップやリペア、修繕をおこなう周期を設定しますが、ここで1Hourというように時間ごとで設定したら、
Next backup date:
の欄が、登録した日時、つまり本日只今になり、その後一時間待ってもいくら待っても自動バックアップしたメールも届きませんし、実際にバックアップされていません。
1Hourを2Hour等に数字変更しても、何度やっても次のバックアップ時間が本日只今になってしまい、厳密に言うと「過ぎている」ようになってしまいます。
過ぎていても、指定した周期に自動バックアップが動いてくれればいいのですが、これまたなぜか動いてくれないのです。1dayに指定しようが、3dayであろうが、300Minutesであろうが、1Hourであろうが2Hourであろうが、動いてくれません。
いったいどうしたらまともに自動バックアップが動いてくれるんでしょうか？
ちなみに、手動バックアップ、つまり、Backup DBからおこなう分はふつうに動いてくれます。自動バックアップが動いてくれません。
また、なぜかわからないのですが、１サイトだけは自動バックアップが正常に作動してくれています。
その他の４サイトはすべてダメでこの現象が共通しておこっています。うまくいくサイトといかないサイト、どれもすべて同じレンタルサーバにおいています（マルチドメイン型のサーバ）。
調査中の進捗を掲載致します。
ひとつだけうまくいくサイトがあり、残りの４サイトは軒並みダメと記載していたのですが、
やはり状況変わりません。WP-dbmanagerのアンインストール方法が特殊だったことを知ったので、正しくアンインストールをおこない、改めてインストールして再度設定してみたのですが、やはりダメでした。
うまくいく唯一のサイトは、Automatic Schedulingのスケジュールを変更した直後、うまくいかないサイト群と同様の表示になりはします。本日只今の日時になるので、一見すると、ダメになったか！と思うのですが、しばらくして再読み込みすると、バックアップもオプティマイズも修復も、どれも軒並み未来の日時に勝手に切り替わってくれます。ここがうまくいかないサイト群との違いでした。
うまくいかないサイト群は、再読み込みしようが時間を空けてアクセスしようが、日時は最初のままであり、どんどん過去の遠い日時になっていくばかりです・・・・・このプラグインの手動でバックアップファイルを生成する方はどのサイトもできるのですが・・・
生成も可能ですし、e-mailで飛ばすのもできています。しかし自動スケジュール実行だけができません・・・どなたか解決策思い当たる方いらっしゃらないでしょうか？・・・・・
本スレを投稿してから約一か月・・・
ネットで調べても全く見当たらず・・・
そして相変わらず現象変わらずです・・・
誰か教えてください・・・こんにちは。
WP-DBManagerは、擬似cronを使ってスケジュールしているのだと思いますが、ダッシュボード上で、WordPressやプラグインの更新通知は表示されていますか？
これらも擬似cronによってスケジュールされているので、これが表示されないなら、そもそも擬似cronが機能していない可能性があります。
擬似cronのスケジュールは、データベースのoptionsデーブルのcronで確認できます。
デフォルトでスケジュールされるのは、「wp_version_check」、「wp_update_plugins」、「wp_update_themes」、「wp_scheduled_delete」かと思います。
擬似cronは、プラグインのWP-Cron Dashboardを使えば、管理画面からも確認、操作できますので、まず、WP-DBManagerがスケジュールされているか確認した方が良いと思います。
ちなみに擬似cronは、サイトにアクセスがあったタイミングで、スケジュールした時間を経過していたら実行するものなので、アクセスの少ないサイトでは正確に実行されませんので。
ありがとうございます。
補足ですが、レンタルサーバを借りていて、そこはマルチドメイン型で、サイトを10サイト前後入れています。
そのうち、１サイトだけは本件問題が出現せず、正常に定期的にバックアップされたデータがメールで送信されてきてくれます。
他のすべてのWPサイトについて本件問題が出現しております。
以上をまず補足しておきます。さて、本題ですが、WPやプラグインの更新通知はいつも出てきています。
「WordPress 3.3.1 が利用可能です ! 更新してください。」
がWordPress自体のcronで、「新バージョンの Akismet が利用できます。バージョン 2.5.5 の詳細を表示するか、自動アップグレードを行ってください。」
というのがプラグインのcronですよね？
サイドバーにもプラグインでひとつアップグレードがあれば「1」と出ていますし、
これを見るに、疑似cronというのですかね、これはONになっているようです。また、cronチェックのプラグインも入れてみました。以下の内容でした。
ひとつだけアクションフックというのに登録されていない、というのがありましたが何かおかしいでしょうか。
dbmanagerという項目が関係するのかと思いますが、それは全部登録されているようですが。————————————————————
予定されたタスク
タスク実行予定時刻: 2010 年 3 月 9 日 @5:37 PM
No.1: wp_update_plugins √ アクションフックに登録されています。
タスク実行予定時刻: 2011 年 10 月 25 日 @11:13 AM
No.2: wp_version_check √ アクションフックに登録されています。
No.3: wp_update_themes √ アクションフックに登録されています。
タスク実行予定時刻: 2011 年 10 月 25 日 @11:13 AM
No.4: wp_scheduled_delete √ アクションフックに登録されています。
タスク実行予定時刻: 2011 年 12 月 15 日 @5:22 AM
No.5: backwpup_cron X アクションフックに登録されていません。
タスク実行予定時刻: 2011 年 12 月 15 日 @5:34 AM
No.6: dbmanager_cron_backup √ アクションフックに登録されています。
No.7: dbmanager_cron_optimize √ アクションフックに登録されています。
No.8: dbmanager_cron_repair √ アクションフックに登録されています。
タスク実行予定時刻: 2011 年 12 月 26 日 @2:25 AM
No.9: do_pings √ アクションフックに登録されています。
タスク実行予定時刻: 2012 年 1 月 23 日 @8:27 AM
No.10: sm_build_cron √ アクションフックに登録されています。現在の時刻: 2012-01-25 10:41:15
————————————————————追記させていただきます。
phpmyadminにログインし、サイドバーのDBテーブルの中で、
「wpsite1_options」
というものがあったのでそれをクリックし、「cron」という文言で検索したところ、
「option_name」が「cron」という項目がひとつ出てきました。
「編集」をクリックすると、文字列の羅列が出たのでエディタにコピペしてご案内あった四つの名称を検索しましたところ、全部出てきました。
以下のように書かれてありました。内容は正常なのでしょうか、それともおかしいでしょうか。a:2:{s:16:”wp_version_check”;
a:1:{s:17:”wp_update_plugins”;
i:43200;}}s:16:”wp_update_themes”;
a:1:{s:19:”wp_scheduled_delete”;
何とか自動スケジュールを稼働させたいです。
大変お手数ですが何卒宜しくお願い申し上げます。見た限り、擬似cronにスケジュールはされていますね。
タスク実行予定時刻: 2011 年 12 月 15 日 @5:22 AM
No.5: backwpup_cron X アクションフックに登録されていません。は、おそらく過去にインストールされていたプラグインのものかと思います。
プラグイン削除時にスケジュールから削除されない仕様だったのでしょう。気になるのが、「タスク実行予定時刻」がどれも過去の日付である点です。
どれも正常に動いてない可能性もあるかと思います。更新通知に関しても、私の勘違いで擬似cron以外にも起動トリガーがあり、一見、正常なように見えるという可能性もありますし。
１つの可能性ですが、問題のサイトでベーシック認証を掛けていませんか？
本当にありがとうございます。
１つの可能性ですが、問題のサイトでベーシック認証を掛けていませんか？
おお、すごい。勉強になります。おっしゃるとおりです、かけております。
かけているのは、ログインURLに対してです。<Files ~ wp-login.php>
require user myidname
</Files>理由は、よりセキュアにするためにこうすると良いと本で読み、かつ、自分も納得できることだったからです。
しかも、ご指摘が鋭いかも、と思いましたのは、
本件問題が出ずに自動バックアップが成功している唯一のサイトだけ、設置を先延ばししていてhtaccessによるアクセス制限をかけていなかったからなんです。結論先にせず申し訳ありません。
書きながらチェックしておりました。
結果、成功いたしました。
プラグインのオプション設定の画面が未来の日付になってくれて、なおかつメールも届きました。
本当にありがとうございます。ただ、htaccessによるアクセス制限がかけられないのはこれまたいけませんので、両立したいのですが何か方策はないでしょうか。
お尋ねばかりで申し訳ありません。
htaccessの記載で、このプラグインに限らず、他でもこのようなことがあるのならば、このようなときにアクセス制限が障壁にならないような書き方ややり方はあるものでしょうか。多分間違い無いと思いますが、BASIC認証が障壁となってWordPress自身がwp-cron.phpにアクセスできないのだと思います。
cron.phpの中で
wp_remote_post()を使ってwp-cron.phpを読み込んでいるため、サーバー自身がURLでwp-cron.phpにアクセスできないと正常に機能しませんし、これはBASIC認証の制限にも引っかかります。BASIC認証と共存させるなら、サーバー自身のIPをベーシック認証から外すように記述すれば良いと思います。
アドバイス、助かっております。
承知しました。レンタルサーバ会社にIPアドレスが何なのか問い合わせ中です。
結果をまたご報告いたしますレンタルサーバ会社から回答ありました。
WebサーバのIPのことでいいのでしょうか？
と聞かれ、そのはずだと答えましたところ、そもそも共用サーバなのでIPアドレスは公開しておりません。
しかし調べようと思えば、コマンドプロンプトのnslookupで調べることはできます。
でも共用サーバなのでIPは変わりますので、IPアドレスを使った除外設定ではない方法をお探しいただき、
試してみてください。当社では本件はサポート対象外です。と言われました。
IPアドレス以外の方策というものがあるのかどうか、現在探し中です。BASIC認証には詳しくないので具体的な記述は書けませんが、何となく、認証が意図した動作になっていないように思います。（wp-login.php以外にも効いている？）
いずれにせよ、gapelさんのテストの結果からもBASIC認証が影響していることは間違いないでしょう。
これはサーバーからの参照ではないので、厳密なテストにはなりませんが、
http://neoinspire.net/status_check/
で、
http://WordPressのアドレス/wp-cron.php
※（自信はないですが、可能性として）これを行うとこのタイミングで、擬似cronが実行される可能性もあります。を入力して
status : 200
となるでしょうか？
「401」となるなら認証を求められていますので、「wp-cron.php」にも認証が効いています。
これが起こりえるか分かりませんが、「200」となる場合も、サーバー上ではどうなのか不明ですし。
本当に助かっております。ありがとうございます。
申し訳ありません。前回のアドバイスを受けての調べが足りておりませんでした。
htaccessに記述しているその他の箇所もよくみて考えるべきでした。
これにつきましてと、ご質問への回答の二つについて書き込ませていただきます。【htaccessに記載している内容】
————————————————————
htaccess内の他の箇所に
Filesについて deny from all の記述をしているファイルたちがあり、その中に、ご指摘のファイルである
wp-cron.php
も書いておりました。
おっしゃる通りだと気づきました。wp-cron.phpをブラウジングしようとすると拒否させる設定なので、これによって自動バックアップがなされていないということかな、と思い至りました。
実際に、このファイルの記述だけを削除したところ、自動バックアップが正常に稼働しました。以下にhtaccessの記述内容を記載します。
AuthUserFile /serverpass/.htpasswd_wp-login AuthGroupFile /dev/null AuthName "Please enter your ID and password" AuthType Basic <Files ~ wp-login.php> require user loginid </Files> <Files ~ "^.(htpasswd|htaccess)$"> deny from all </Files> <Files ~ wp-app.php|wp-blog-header.php|wp-config.php|wp-config-sample.php|wp-cron.php|wp-links-opml.php|wp-load.php|wp-mail.php|wp-pass.php|wp-register.php|wp-settings.php|wp-trackback.php|xmlrpc.php> deny from all </Files> ErrorDocument 400 http://mysite.com/error/400.html ErrorDocument 401 http://mysite.com/error/401.html ErrorDocument 402 http://mysite.com/error/402.html ErrorDocument 403 http://mysite.com/error/403.html ErrorDocument 404 http://mysite.com/error/404.html ErrorDocument 405 http://mysite.com/error/405.html ErrorDocument 406 http://mysite.com/error/406.html ErrorDocument 407 http://mysite.com/error/407.html ErrorDocument 408 http://mysite.com/error/408.html ErrorDocument 409 http://mysite.com/error/409.html # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPressただ、これについてもなのですが、deny from all によって拒否していたのは既報のとおり、wp-login.phpというログインページ以外の.phpページをブラウジングさせない方が良いということを本に書いてあったため、それによってwp-cron.phpも直接ファイルを開かせないようにしておりました。
よって、拒否設定からwp-cron.phpをなくしてしまってはいけないのでしょうから、
結局何かしらの例外記述をせねばならんのだろうかと感じております。
セキュリティについてよくわからないのですが、
http://www.mysite.com/wp-cron.php
をブラウジングしたら真っ白のページが開くだけですし、ブラウザの「ソースを開く」機能で開いてもソースも真っ白なので、もしかして拒否する必要性はないとかでしょうか。
————————————————————【ご質問への回答】
————————————————————
拒否設定からwp-cron.phpを解除する前は、
ステータスコード:302
となっていました。拒否設定から解除した後は、
ステータスコード:200
となっていました。
————————————————————拒否設定からwp-cron.phpを削除してもセキュリティ上何ら問題ないのであれば削除しただけでOKで、セキュリティ上問題があるのであれば、やはり何かの例外設定をおこなわないとならないのでしょうか。
何度もお付き合いさせてしまって申し訳ないです。そして本当にありがとうございます。ただ、これについてもなのですが、deny from all によって拒否していたのは既報のとおり、wp-login.phpというログインページ以外の.phpページをブラウジングさせない方が良いということを本に書いてあったため、それによってwp-cron.phpも直接ファイルを開かせないようにしておりました。
wp-cron.phpの場合は、アクセスされた時に予定日時を過ぎていたらスケジュールされた処理が実行されるだけのことで、そもそも擬似cronは、訪問者のアクセスがトリガーになっていますから、それがトップページであろうと、wp-cron.phpであろうと関係ないですし、神経質になる理由もないと思います。
WordPressを信頼できると考えれば必要性の薄い制限ですが、だからと言ってBASIC認証がダメというわけでもないと思います。
ただし、同様の理由で動作しない機能が出てくる可能性があると思いますし、問題が出れば、BASIC認証も疑うというやり方で問題を切り分ける運用になります。私の場合は、WordPressを信頼して、そのような制限を掛けるつもりはありませんし、今回もそうですが、問題が出た際の切り分けも大変ですので、時間の節約という意味合いもあります。
個人的には、サイトで提供する機能やインストールするテーマやプラグインの吟味に時間を使った方が、セキュアなサイトになるように思います。おっしゃる通り、問題が出たときに簡単に解決させるためにもなるべくシンプルにする、ということは大切ですね。
私もBASIC認証をしたいわけではなかったわけですが、必要なのであればそれも仕方ないと思うだけでありました。wp-cron.phpなどの他の.phpファイルをアクセス制限なしで設置しているだけですと、URLが想定されてしまうので、そのURLに対して何かしらされるから本で推薦されていたのだと思っておりました。
ベーシック認証を外し、deny from allも外すことも考えたいと思います。
このたびは本当に有難う御座いました。ずっと解決できなかったので助かりました。
- トピック「WP-DBManager：自動実行機能の日付が過去に。実行できず」には新たに返信することはできません。