make-cacheの新バージョンを用意し、
旧バージョンと仕様構造を変更しました。
もしversion 0.4未満の場合は、最新バージョンを入れてください。
WordPressには、wp-cacheというものや、wp-super-cacheと呼ばれる優秀っぽいプラグインがありますが、
この２つとも、誰かがアクセスした時に、キャッシュを生成する。
という仕様だと思います。
しかし私のこのブログのように、ほとんどアクセスが無いサイトだと、キャッシュが生成されなくて本当に寂しいです。
もっとアグレッシブにキャッシュを作ってやりたい。と思い開発しました。
ページにアクセスがあった際などのキャッシュ生成ではありませんが、
MovableTypeの静的HTML生成に近い動きをします。
プラグインをインストールすると、『投稿』欄に『キャッシュ再構築』というリンクが現れ、クリックすると次の画面になります。
記事投稿して、トップページだけ書き換えたい時は『トップページのみ再構築』。
全体を再構築したい場合は『全てを再構築』
ボタンを押すとロード中の画面になります。
なおロード中はAjaxにより非同期通信を行いますので、静的HTML化が対象のファイルが多すぎる場合も、恐らくタイムアウトは起きないと思います。
もし起きたら、ブラウザ側ではなく、ＷＥＢサーバ側（ホスティング業者側）で制限をかけていると思います。
完了すると
これで、トップディレクトリ部分から静的HTMLが生成されているかと思います。
試しにディレクトリを見てみてください。
なおこの静的ＨＴＭＬ化・再構築プログラムですが、以下の点にご注意ください。
[1]
%postname%
%category%
などにおいて、日本語でURLを構成しているサイトには適用出来ない。
アルファベット化させているものは動くようです。
これは日本語のURLの後にindex.htmlを付けても認識しないからと思われます。
ビジネスシーンでの利用では日本語文字列のURLはあり得ないと思うので、
まあいいか。です。
[2]
コメントやトラックバックの情報は再構築しないと反映されない
全てのページが静的化されるため、コメントやトラックバックは再構築しない限り反映されません。
まあいまどき、コメントやトラックバックはスパムがひどいので、必ず目視チェックがあると思うのでいいか。と。
それに私のブログはコメントやトラックバックなんて一切こないのでノープレブレムです。私が。
[3]
記事を投稿、編集した際には、再構築をしないと反映されない
これまた、全てを静的HTML化しているためです。
[4]
.htaccessで恐らく
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
と書いていると思います。一つ目のRewriteCondの上に
RewriteRule .*\.html/.* /index.php [L]
を記述してください。
例）
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule .*\.html/.* /index.php [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
これは、.htmlでパーマリンクを作っているサイト（私のサイトのような）だと、
コメント投稿完了時の戻りで、４０４エラーになってしまうためです。
.html/comment～～
が、普通にindex.phpを呼び出すように、このような記述をします。
また、サーバの仕様によっては
トップページはindex.phpが優先されてしまう場合があります。
そんな時は・・・というか念のため、
.htaccessには
DirectoryIndex index.html index.php
を記述してください。
従って、出来上がるであろう最終的な.htaccess
！！！この通り記述せず、実際には
DirectoryIndex～～
という記述と
RewriteRule .*\.html/.* /index.php [L]
だけ追加してください！
--------------------------------------------------------
DirectoryIndex index.html index.php
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule .*\.html/.* /index.php [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
--------------------------------------------------------
です。
[5]
cacheディレクトリ
not_rewrite.txt
を、書き込み可能な権限にしてください。
[6]
ファイルの文字コードとmetaタグの文字コードがあっていないと文字化けする可能性があります
[7]
カテゴリ等で使用しているディレクトリで、すでに使っているものがある場合、
削除されてしまいますのでご注意ください。
例）
カテゴリ名としてtestというのが存在し、
/category/test/sample.html
というファイルをすでに作成
再構築をすると、
/category
というディレクトリを削除しにいくため、必然的にsample.htmlが削除されます。
上記のお話で、何の事か分からない場合は、
全てのファイルをバックアップしてから、プラグインを導入して試してみた方がよろしいかと思います。
特に、再構築時には元々のキャッシュファイル（静的HTML）はガンガン削除しにいきますので、
注意が必要です。on your risk!でお願いします。
初めて使う時はお願いですからバックアップしてから設定してみてください。
滅多にバックアップはしないですから、いい機会では無いでしょうか。
ちなみにデータベース側には影響を与えていないので、データベースのバックアップは不要です。
そんなプログラムはこちら
WordPressの静的HTML化・再構築機能プラグイン
もしアンインストールする必要がある場合は、申し訳無いですが
make-cache/make-cache.php内115行目付近の
------------------------------------------
//クローリング開始
crawl( $exists, $rooturl, $rooturl, MAKE_CACHE_CACHE_DIR );
//一時ディレクトリに保管されているファイルを全て移動
RenameFile( MAKE_CACHE_CACHE_DIR, MAKE_CACHE_SITEDIR );
------------------------------------------
を
------------------------------------------
//クローリング開始
//crawl( $exists, $rooturl, $rooturl, MAKE_CACHE_CACHE_DIR );
//一時ディレクトリに保管されているファイルを全て移動
//RenameFile( MAKE_CACHE_CACHE_DIR, MAKE_CACHE_SITEDIR );
------------------------------------------
にして、『全てを再構築』してくれれば、プログラムが生成した静的HTMLは削除してくれます。
この変更がよく分からなかったら、申し訳無いですがプラグインの利用は控えた方がいいかもしれません。
ちなみにプラグインをはずす時に、この処理は自動で行わせたいと思っていますが、今日は疲れました。
さらに情報として、Ktai Styleとの相性について。です。
wp-cacheやwp-super-cacheとKtai Styleの相性は、結構シビアだそうですが、
このプラグインでは、.htaccessにてUserAgentで携帯を指定し、
そのUserAgentだったら全部index.phpに流す。とやれば、
ほとんどKtai Styleには影響を与えずに済むでは無かろうか？というところです。
試してないですが、今度その.htaccessの書き方を書いてみます。今日は疲れました。
MTの再構築が嫌いでwordpressに逃げてきた人が泣いて喜びそうなプラグインですね;P
おお！コメント有り難うございます！このブログ初めてのコメントです！
早速、再構築しないとコメント投稿は反映されない。という本仕様にハマり、
「あれ？コメントが出てこないなあ・・・？あれ？」
とか自分でハマりました。
[...] WordPressの静的ＨＴＭＬ化・再構築機能を開発しました- 犬や猿に分かるわけないだろ！コンピュータ・プログラミングHowTo [...]
使用方法もシンプルで簡単！これはWordPressユーザーに重宝されるプラグインですぞぉ！
コメント有り難うございます！そう言って頂けると作っていてやりがいというか、ああ良かったと思えます。
Linuxを作ったLinusの気持ちが職業プログラマ10年目にして、ようやく分かりましたｗ
(^^)/ どもです。再構築が終わらない件ですが、テストサイトのファイル数は少ないです。記事数が５・６個ですので。通常は「全てを再構築ボタン」を押しても数秒かかる程度ですが、再構築しても終わらない事象が起きている時は、数分間待ってもダメでした。
ちなみに、現在のバージョンは0.75です（バージョンアップ予定ですが、もう少しいじってからにしてみます）。
体感的に終わらない回数が増えているな～とは思っていましたが、今日はログインしてから、ボタン押しても一度も再構築されません。(T_T)ので、少し調べてみました。
トップページのみ再構築は完了するので、動作は確認できていました。おかしいなと思って、いろいろいじってみたら、Ktai Style 対応をする、にチェックして変更を保存している状態だと、どうやら全再構築が終わらないようでした。チェックをなしにすると動いています。
トップページのみ再構築、新規投稿からの再構築などは、Ktai Style がオンでも問題なく再構築は完了し、キャッシュも生成されているようでした。（ケータイサイト用キャッシュの生成の有無については、よくわからないので未確認としておきます。）
質問なのですが、Ktai Style をオンにすると、Ktai Style用のキャッシュも生成されるということでよいのでしょうか？また、そのキャッシュはcacheフォルダ内に生成されるのでしょうか？
現在、Ktai Style の動きと、make-cacheのKtai Style周りの動きについて無知な状態なので、もすこし調べて、双方いじってみてから結果報告してみます。また、わからない点が出てきたら質問してみます。
とりあえず、報告まで。 (^_^)v
連投失礼します。http://pc.freeblo.com/554.html に 「携帯からのアクセスの場合、自動的にKtai Styleに流し込むようにしました。」とありましたね、失礼しました。
これは携帯からのアクセスが内部的に 「Ktai Style ＞PC用キャッシュ＞PC用動的生成ページ」という表示優先順序になっていて、アクセスした人はKtai Style の（携帯のキャッシュページではない）画面が表示される、ということで良いのでしょうか。
そして、携帯用のキャッシュ生成をmake-cacheはまだ実装していない、ということでよいんでしょうか。
質問ばかりですいませんです (^^;)
コメント遅れてしまい申し訳ございません！
取り急ぎKtai Styleの仕様はご推察の通りの順序となります。
最終的には、Ktai Styleが出力する情報もキャッシュしてしまえば、
携帯にこそスピードが速くなっていいのかな？と考えているのですが、
現時点では未実装です（技術的な課題はクリアしております）
私の方では、Ktai Styleの使用Onにしていても、全体再構築は行われるのですが、少々不思議ですね・・・！！
UserAgentをチェックして、携帯だったらKtai Styleに流す。というだけの仕様なのですがｗ
（しかし、これだけ簡易だとバグの入る余地が無くていいと個人的には思いますｗ）
もう少し全体再構築がうまくいかない件、監視させて頂いてもよろしいでしょうか。
さらにこの状況が続くようでしたら（Ktai Style ONの時は動かない）、
その旨を説明書に明記しようかと考えておりますので、
どうぞよろしくお願い致します。
お忙しいところ、お返事ありがとうございます。 m(_ _)m さて、再構築が終わらない件です。症状解決してませんが、進捗がありましたので書いてみます。
結論から書くと、cacheフォルダ内のwpフォルダ直下にループしているかのようなキャッシュ生成が見られましたので、再構築時間自体が伸びているのではないか？という説が出てきています。
まず質問から。
cache直下の第一層目に生成されるフォルダですが、ここにはどういう系統のフォルダが生成されるのでしょうか？
質問の経緯は以下になります。FTPソフトそのまま見せられると楽なんですが、ご勘弁を m(_ _)m 紙とペンなどあれば・・・。
その前にサイトの簡単な環境ですが、URLはhttp://huurai.com/wp/make-cache/ カテゴリーは１つ make-cache というものがあります。パーマリンク設定は /%category%/%year%/%monthnum%/%day%/%post_id%/ です。バージョンは最新版です（結局、インストールし直しました）。
現在、cacheフォルダ直下、第一層目には2010、about、category、help、make-cache、manual、wpという７つのフォルダがあります。正確には再構築が成功しなかったせいで出来たと思われる、tmpという謎のファイルがありますが・・・。
第一層目のフォルダですが、2010が年月日ページ、aboutがページのページ（初期設定の「紹介」というページ）、categoryがカテゴリー、などだと思うのですが、残りの４つのフォルダ help、make-cache（カテゴリー？）、manual、wp の属性が、「正確に」わからないフォルダが生成されていましたので。
で、本題はここから。問題はこのwpというフォルダなのですが、wpフォルダ直下の第二層目にはmake-cacheフォルダがあります。
この二層目make-cacheフォルダ直下には、（第三層目）aboutとmake-cacheとwpという３つのフォルダがあります。よって、二層目make-cacheフォルダは、直下の構造が第一層目make-cacheフォルダとは違うので、別物なのではと考えられます。（この辺が悪の権限くさいので、詳しく知りたいのです。）
で、生成された三層目aboutフォルダはおそらく第一層目のカテゴリー（category）フォルダと構造が同一だと思われます、中にindex.htmlがあります。三層目make-cacheフォルダも同様に、直下のフォルダ構造は第一層目と同じなので、第一層目のフォルダと同一だと思われ、枝分かれしたフォルダ達の底には各種index.htmlがあります。
三層目wpフォルダですが、中には（四層目）make-cacheフォルダがあります。その中には（５層目）make-cacheフォルダとwpフォルダがあります。５層目make-cacheフォルダは、直下が第一層目と同一構造なので同一だと思われます。５層目wpフォルダの中は、（６層目）make-cacheフォルダがあります。
（６層目）make-cacheフォルダの中には、（７層目）make-cacheフォルダ、wpフォルダがあります。
文字だとわかりにくいですが、wpフォルダだけを追った場合だけで見ると、
１→２→３→４→５→４→５→４→５・・・
という層のループになっているかのような構造になっていると思います。
おそらく、再構築のたびにここが増えてるんじゃないかなと思うのです。カテゴリー名や、サイトURL名が悪さしてるんじゃないかなと思ったり。あと、パーマリンク構造をカスタムしたのも原因なのかなって思ったり。%category%/ 使ってるので。
とりあえず、この現象に気付いて、パーマリンク構造をデフォルトに戻したり、カテゴリー名を変えてみたりしてみている所ですので、その後の報告はまだ先になります。
テーマやテンプレートなど、環境はデフォルトからほとんどいじっていないですが、もし私のほうの環境の記述で足りない部分があったら、教えてください。理解しえる範囲で書きます。
最後にもひとつ質問なのですが、ＭＴの再構築中のように、現在どの箇所を再構築しているのか、というのは表示する事ってできますかね？再構築時間は増えるかなと思うのですが、重いページやエラーの出ているページの把握にも役立つのかなって思ったり。あと、止まっているのか、時間がかかっているだけなのかわかると助かるかなぁと。
長文失礼しました。(^▽^;)
huuraiさん
詳しくはeuropa3さんのコメント待ちってことで・・・。
>cache直下の第一層目に生成されるフォルダですが、ここにはどういう系統のフォルダが生成されるのでしょうか？
パーマリンク設定によってできるフォルダは変わるはずです。
以前europa3さんと別件でやりとりした際に書きコメントがあります。
—抜粋—
私(europa3さん)の方では、パーマリンクとして記事は全て
/記事ID.html
としているため、記事詳細ページは全てcache/記事ID.htmlとして作られるのですが、
masaruさんの方では、記事詳細ページは
年月日
で出てくるのですね・・・。
—終わり—
実際に全てのカスタム設定は試せてない(無限にあるので)のであれですが、huuraiさんと同じパーマリンク設定にて確認してみました。
うちでは問題なく再構築が完了しました。
＃一応切り分けの為に確認
coreserver？で試してると思うのですがPHPがセーフモードで動作してると思うのでこの辺りがネックになってそうな感じも？
う～ん。PHPをセーフモードで動作する環境作ってテストするほうがよさそうかなぁ？
cacheフォルダ内ですが、categoryフォルダとは別にcache直下に個別でカテゴリー名のフォルダができます。
これはパーマリンク設定をデフォルトにしても作成されるのでWPのDBがこんな感じではいってりるのかもしれません。（推測
huuraiさん、詳細な情報有り難うございます。
またmasaruさん、フォロー有り難うございます！
取り急ぎはhelp、manual、wpというディレクトリが作成されるのが結構異常な感じがしますね・・・。
.htaccess
で/wp/make-cache/index.phpとなっていたりはしますでしょうか？（あまり関係無いかもしれませんが・・・）
あるいは、サイト上のどこかしらで
http://huurai.com/wp/make-cache/manual
というようなリンクが貼られていたり、などはあり得ませんでしょうか。
基本的にはキャッシュHTMLはパーマリンクが解釈された後の生成になりますので、manualやhelpというのが結構気になりますね・・・
wpは、何となく
huurai.com/wp
の
wpを取ってしまったのかな？という印象があるのですが。
この件、for CORESERVERのためには重要な情報な気がしますので、引き続き何かあれば情報を頂ければ、ピンとくるものがあるかもしれません。
ちなみに、『WordPressのアドレス』と『サイトのアドレス』はどのような値になっておりますでしょうか？
申し訳ございませんが、どうぞよろしくお願いします。
それからもう一つ、頂いた『再構築中のファイル情報』ですが、ぜひ実現させたい機能ですよね。
１回トライしたのですが、どうも使っているjQueryで再現するのがやや難しい気がしておりまして、
これを解決するためのひらめきを私自身待っているところだったりします。
しかし、
「あれ？止まってない？さぼってない？」
みたいな事象は、長い処理だとどうしても発生してしまう疑念だと思いますので（私自身も）、
ぜひ実装したいと考えております。
よろしくお願いします！
huuraiです。今はcoreserverサポートに削除依頼出してるとこです。
フォルダをどかせることもできないので、元の環境には戻せなくなってしまいました。残念！ちなみにこの状況は、このサイトのみなので、URLにmake-cacheと入ってる事が問題なのかな？ってのが強かったりします。
huurai.com/wp/wp/ というサイトも一応動かしていますが、make-cacheカテゴリを作っても同じ状況にはなりません。
サーバー状況のせいなのか不明ですが、ごくまれに削除できたんです。でも、ディレクトリの名前をいじったり、WPごとアンインストール試したりしてたら、完全に削除不可能なフォルダ群になってしまったので、削除依頼出しました。
また、カテゴリ名を変えたりしてみました。するとwp直下のカテゴリー構造が少し変わったのか、wp→○○→wp→○○ ・・・ という単純な数の層のループみたいな構造に変わっていました。wp直下にあるmake-cacheフォルダ達の正体は皆カテゴリーのmake-cache を取得していたのでしょうかね。URLのmake-cacheではなくて。
元の構造を今見られないのが心残りですが、 http://huurai.com/wp/make-cache/manual のリンクはサイト内に記述はなかったかと。作った覚えもないですし、記事でパーマリンクを指定したものもないですし、紹介ページや個別アップロードしたものでもないです。coreserverデータベース、もしくは、wordpress本体のどっかから出てきちゃったのかなぁ？わからんです。
helpファイルも同様に無いです。
WordPressのアドレスは、 http://huurai.com/wp/make-cache です。サイトのアドレスも同じく http://huurai.com/wp/make-cache です。
今はとりあえず、他のサイトでもエラー出てるんで、初期インストール方法、セーフモード関連をかたっぱしから読んでます。連投で別サイトのエラーについて書きます。
連投失礼します。遅れましたが、kenさん、europe3さん、返事どうもです！
追記。アップロードした.htaccessを確認した時は RewriteRule . /wp/make-cache/index.php [L] というような事になっていたように思いますが、ちょっと自信がないです。（ローカルにループした構造できるの恐くて、バックアップとってなかったので・・・）
さて、huurai.com/wp/wp/ で出ているエラーです。個別記事編集の投稿編集ページ内の更新を押した際の再構築でエラーが出ます。全再構築、キャッシュ削除は問題なくできていると思います。
Warning: fopen(/virtual/huurai/public_html/wp/wp/wp-content/plugins/make-cache/cache/customize/2010/03/05/180/index.html) [function.fopen]: failed to open stream: Permission denied in /virtual/huurai/public_html/wp/wp/wp-content/plugins/make-cache/make-cache.php on line 583
こんな感じに。他には fwrite()、fopen、fclose、mkdir()、Warning: Cannot modify header information – headers already sent by、とか色々出ますが、個別記事のindex.htmlの個別パーミッション644→646に変えたらエラーは出なくなりました。
同様にカテゴリーのほうもなんですが、個別カテゴリーの編集ページのカテゴリーを更新を押しての再構築でエラーが出ます。
ただ、こちらも、パーミッションを個別に変えさえすれば対応できるのかな？量が多いのでやってませんが、パーミッション変更でエラーが消えて、少なくなっているのは確認しています。
生成されるファイルのパーミッションって、プラグイン側で設定できるものなんですかね？セーフモードでこうなってるのか、はたまた.htaccessの設定を含め自分の環境なのか、知りたいです。
全再構築、キャッシュ削除が動いているので、とりあえずmake-cacheのアクティブにキャッシュを生成する（削除する）という環境はできているんですけどね。
huuraiさん、詳細な情報を記述して頂き誠に有り難うございます！
現在、本業の方が忙しくてなかなか手が回せない状況なのが恐縮なのですが、
頂いた情報をもとにソースコードを洗い出してみます。
権限系はhuuraiさんのおっしゃる通り、
プログラムがキャッシュを生成する際に、事前にセットすることは可能かと思いますので、
それをする事で解決なのかな・・・？という直感はありますが、
manualやhelpがドヨ～ンと出てきた事は、まだ何らかの閃きが無いと原因が特定出来ない感じです。
なんにせよ、ソースに戻る。といことで！ｗ頑張りたいと思います。
はじめまして、素晴らしいプラグインだと思い早速使わせていただこうと思ったのですが、なぜか上手く作動していないようで自分ではお手上げ状態でしてコメントを頂きたく質問させてもらいます。m(–)m
こちらに書いてあるインストール手順に沿ってプラグインをインストールして作動させ、全構築を行ったのですが、FTPでその後にディレクトリを見てみるとトップページのみはキャッシュができている（index.html）ようなのですが他の記事のキャッシュ（～.htmlができるはずですよね？）が全くできていませんでした。
キャッシュの削除機能は作動します。
「記事投稿、編集時の再構築」をはいにして記事を投稿してみるもやっぱりキャッシュが作成されません。
記事数は600ほどありまして、これが問題なのかと思い1記事にしてみたりもしましたが解決できませんでした。
テーマもデフォルトに戻してみたり、プラグインを全て止めてみたりもしましたが駄目でした。
make-cache内のcacheフォルダのパーミッションは777に設定しております。
ちなみに私がwordpressをインストールしてるのはこんな感じになっていて、
/public_html/wp/wp-content/plugins/make-cache/cache
cacheフォルダの中には「index.html」、「wp」、「&」というフォルダがありまして、そのフォルダの中には何もありません。
普通はキャッシュができるはずですよね？
試しに他のキャッシュプラグインを試してみると、そちらは正常に作動しました。
現在、私は000webhost.comという海外の無料レンタルサーバーを使用しています。
スペースの容量はまだ1Gほど残っているので容量オーバーでも無さそうです。
使用しているのはプラグインがバージョン：0.81で、wordpressが2.9.2です。
どこか非常に初歩的なとこでつまずいてると思うんですが、自分で思いつく限りこんなとこです＾＾；
はも。さん！お返事が遅くて大変申し訳ない限りです！
キャッシュ生成がされない。となると、以前から問題となり得る事が分かってきた
PHPのセーフモード
が原因なのかな・・・？という気がしております。
＃これ以外の理由も今まで考えていたせいで遅くなってしまいましたが、
＃やはりこれが大きな原因な気がします。
あるいは・・・ですが、サーバの設定が特殊で、
/public_html
以下にファイルを設置しているが、実はシンボリックリンクで他に飛ばされており、そのせいでうまくいっていない。などなど・・・（未確認ですが）。
試しによそのサーバにWordPressを移してみて、動かしてみるといかがでしょうか・・・？
はも。さん。
連投すみません。こっそりドメイン移転、サイト名変更とかしちゃったりしてますがお気になさらず。誰も見てないサイトだと思うので豪快にいきなり変更しました。
はも。さんの状況ですが、もしかしたら分かったかもしれません。
パーマリンクが
?
の初期設定ではありませんでしょうか？
make-cacheプラグインは、パーマリンクを仮想的なhtmlなど、少なくとも初期設定以外のものでないと正常に動作しませんが、
この問題ではございませんでしょうか？
よろしくお願いします。
管理人さん、コメントありがとうございます。
>パーマリンクが
>?
>の初期設定ではありませんでしょうか？
>make-cacheプラグインは、パーマリンクを仮想的なhtmlなど、少なくとも初期設定以外のも
>のでないと正常に動作しませんが、
>この問題ではございませんでしょうか？
まさに管理人さんのおっしゃるとおりでした。
自分はデフォルトのままだった為にキャッシュが作成されていなかったようです。
試しに他のパーマリンク設定で再構築を行ったところ、いとも簡単に全てのキャッシュが作成されました。FTPでも確認できました。
念のために他の無料サーバーでも設置して試してみましたが、それらも無事に問題無く作動しています。
自分はXREAのレンタルサーバーのアカウントも所持していて、そちらでも試しましたが上手くいったのでセーフモードでも大丈夫のようです。
あと、余計なお世話かも知れませんが、キャッシュ構築メニューのサイドバーのとこに
最後の行に
と書かれていますが、「!」が先頭に書かれてなくてそのまま書いちゃうとタグが表示されちゃいますねｗ
ご丁寧にありがとうございました。
タグそのまま書いちゃったので消えちゃいましたが、
＜– sidebar.php target for make-cache end –＞
となってます。ですね。申し訳ない。
はも。さん
ご連絡有り難うございます。原因が分かって良かったです！
&
頂いた情報はホームページに掲載させて頂きます！またこれで一つ、オレオレのみＯＫ仕様が減った（？）気分ですｗ
また!がはずれていた件はおっしゃる通りでした！
修正バージョンを再アップしておきました。こちらもご連絡有り難うございました！
お久しぶりです。実はPC壊れて、買い換えてました。（;_;）
php6ではセーフモード廃止、という記事を見て、じゃぁもう移行環境作ろう！と思って、やってる最中に壊れました。（まさか不具合の原因は、PC壊れてたからとかいうオチじゃないよね・・・）
http://www.coreserver.jp/help/
http://www.coreserver.jp/help/index.php/phpcgi/
coreserverなら、上記方法で部分的にオフできたりとかありますが、coreserverで悩んでいる人は速度を諦めて、セーフモードを窓から投げ捨てほうがいいかと。
「速度を捨てて」cgiモードにするのを恐れて、セーフモードの対策に「時間をかける」・・・。本末転倒じゃん！と思ったからです。まぁ人それぞれですが。
http://drupal.jp/drupal5/guide/tips/safemode
http://bowz.info/1746
カテゴリや記事ページからの更新・再構築の際、mkdir() copy() fopen() flose() とかエラーの羅列が出てたような記憶あります。やはりキャッシュフォルダを生成した時に権限がapacheになって、そっからの作業ができる権限がない、という事なのかな。
環境をセーフモードと共存する環境で！と思ってがんばってきたんですが、サーバー変えるか、cgiモードにするか、この２択になりそうです。正直、セーフモードってのをなめてた部分がありました。こんなにも厄介者だったんですね！それがわかっただけでも収穫でした。
cgi版php6ってのがあるみたいですが、遠慮しました。詳しいページが見当たらないのと、結局は移行問題を先送りしてるだけなんで。
あ、近況報告がてら、チラ裏。
新PC。Acerデスクトップに80G SSDを載せてもらって諸費用込み１１万位。読み込み時間？なにそれ美味しいの？ってくらい速い（無い）です。なんか速度追求の終着点見えてきましたよ。現時点で不自由しないですけど。
セーフモードに吸い上げられた時間を返してもらえそうです。SSDいらっしゃい！セーフモードさよなら！です。
では、またmake-cacheいじってきます。 ノシ
huuraiさん
コメント有り難うございます。近況の内容が面白くて思わず笑っちゃいました。
セーフモードは今後消えゆく存在なのですね。
とはいえシステム管理も仕事としてやっている身としては、
PHP5からPHP6に上がる際が戦々恐々としていますｗ
ようやく
PHP4はサポートが終了する。
対応出来ない環境が多い。
セキュリティに問題あり。
という『錦の御旗』のもと、
そろそろPHP4の息の根は止められそうだな？
と思っていますが、次はPHP6とPHP5の境い目で戦うハメになるのですねｗ
自分もメインのノートPCから自動的にSSDになって、爆速で恩恵を受けています。
やっぱり速い。って重要ですよね。
SSDは1年経っても2年経ってもディスクが汚れない（データの配置方法だか何だか？）ので、速度が落ちないんだとか。
そのため寿命はちょっと弱いらしいですが、普通のハードディスクでも簡単にクラッシュしてエロ画像を全て吹っ飛ばして床を叩いて泣き崩れた私としては、
どっちも変わらない。壊れる時はHDDだろうがSSDだろうが壊れる。という認識です。
とはいえ情報有り難うございます！
このセーフモードの情報、コメント欄に載せておくだけでは勿体ない非常に有意義な情報ですので、記事として紹介してもよろしいでしょうか？
はじめまして。
素晴らしいプラグインありがとうございます。
いままで、私用のWordPressにて問題なく稼動していたのですが、
先日、別のサーバにて運用したところ、キャッシュ自体は問題なく生成されているのですが、別のプラグインがうまく作動してくれません。
プラグインは、Really simple capchaです。
症状としては、更新をしてもキャプチャ画像が変わらないというものです。
make cacheを停止もしくは、キャッシュを削除すると、画像は更新されます。
サーバ側の設定なのかもしれませんが、何か推測される問題点がございましたら、是非ご教授いただければと思います。
宜しくお願い致します。
tstko33さん
コメント有り難うございます！Really simple capchaというのは便利そうなプラグインですね！
しかしこれは静的HTML生成プラグインとは上手くウマが合わないプラグインかもしれません。
恐らくキャプチャ画像がキャッシュ生成時に作られてしまうため、
以後それを使われて何の意味も無いものになってしまうようですね・・・
これが、ページ表示のたびにJavaScriptから自動生成されていれば、また話は別だったのですが、
恐らくこのプラグインは残念ながら動作しないと思われます。
このとても有り難いフィードバック、お知らせの方はサイトに出しておきたいと思います。有り難うございます！
huuraiさん
お返事ありがとうございます。
今までXREAとCORESERVERで何個かWordPressを導入したのですが、
そこでは、make-cacheとReally simple capchaを併用していても、どちらも問題なく動いているんですよね･･･。
サーバー側の何らかの設定が関係しているのか、原因がわからないもので･･･。
私の方でも、いろいろ試してみたいと思います。
また何か情報が御座いましたら、教えてください！
[...] WP Super Cache make-cache [...]