個人サーバーで人気のロリポップ！サーバーですが、プランにもよりますが意外とPHP負荷への判定が厳しいです。
個人向けプランで最上位プランの「チカッパ」プランでも、1日のアクセスが3000くらいのWordPressサイトを2つくらい動かすと、制限をかけられてしまう場合があります。

そんな時は、おなじみWP Super Cacheで負荷を軽減してやり過ごしてみましょう……あれ？
なんか動かない。

There’s been an error posting your Twitter status! Visit your WP to Twitter settings page to get more information and to clear this error message.

警告! Could not update /home/users/1/weblogy/web/public_html/wp-config.php! WPCACHEHOME must be set in config file.

警告! /home/users/1/weblogy/web/public_html/wp-content/advanced-cache.php がないか、更新できません。

• 1. もしこのファイルがすでにあれば、まず最初にこのファイルを削除してください
• 2. ftp やサーバーソフトウェアで chmod コマンドを使用して /home/users/1/weblogy/web/public_html/wp-content を書き込み可能にし、(chmod 777 /home/users/1/weblogy/web/public_html/wp-content) このページを再読込みします。これは一時的な処置で、この後、読み込みのみに再度する必要があります。(前述のコマンドで 777 を 755 に変更します)
• 3. /home/users/1/weblogy/web/public_html/wp-content/advanced-cache.php を更新するためにこのページを再読込みします

もし動作しなければ /home/users/1/weblogy/web/public_html/wp-content/advanced-cache.php ファイルが存在するか確認してください:

1. 1. テキストエディターで /home/users/1/weblogy/web/public_html/wp-content/plugins/wp-super-cache/advanced-cache.php$wp_cache_file を開きます
2. 2. テキスト CACHEHOME を /home/users/1/weblogy/web/public_html/wp-content/plugins/wp-super-cache/ に変更します
3. 3. ファイルを保存し、/home/users/1/weblogy/web/public_html/wp-content/advanced-cache.php へコピーしてこのページを再読込みします

継続できません…前の問題を修正して再度お試しください。

案内の通り、wp-contentのパーミッションを777にしたのですが解決しない。advnced-cache.phpを見てみたりしたのですが、なんか説明と話が噛み合わない。

しばらく考えた結果、ロリポップ！の仕様でwp-config.phpのパーミッションが書き換えられていることを思い出しました。

wp-config.phpを書き込み可能にする

ロリポップ！は、昨年2013年に大規模なWordPressへのアタックを受けて、ユーザーサイトが改竄された経緯から、wp-config.phpを書き込み不可にする仕様になっています。

なるほど、400になっています。
これを

で一時的にパーミッションを変更し、上記WP Super Cacheの設定画面を再読み込みすると、WP Super Cacheがwp-config.phpを書き換え、wp-contentの中にキャッシュ用ディレクトリを作成し、インストールが完了します。それから、wp-config.phpとwp-contentのパーミッションを元に戻せばOKです。

私は運営するサービスでTwitter連携（WordPressに投稿したら自動的にTweetされるように）する時に、WP to Twitterというプラグインを使っています。Jetpackにもこの機能はあるんですけど、短縮URLが選べたり、ハッシュタグを付けられたりする自由度の高さでこちらを使用しています。

が、先日からうまく連携できなくなり、このようなエラーが表示されるようになりました。

認証エラーではなく、クエリの失敗でもない

認証エラーではなさそうです。エラーメッセージを読んでみると、コードなし、「Twitterからは認識できるレスポンスコードが帰ってきませんでした」というエラーメッセージでした。

少し調べてみると、結構前にプラグイン作者のJoe Dolson氏がフォーラムで回答しているのを発見しました。

Joe Dolson
Member
Plugin Author
Posted 2 years ago #

Are either of you on Bluehost? Bluehost has a known issue with Twitter blocking some of their shared IP blocks at the moment. “Code 0″ means that the query isn’t successfully reaching Twitter, so Twitter is not returning any response — this is a common issue if your host is being blocked by Twitter.
WordPress › Support » [Plugin: WP to Twitter] Response code “0””

意訳：君たち、Bluehostを使ってない？ Bluehostが共有IPがたまにTwitterからブロックされる既知の問題があるんだよ。「コード：0」は「クエリーがTwitterに到達しなかった」という意味ではなくて、「Twitterから何のレスポンスも帰ってこなかった」という意味なんだ。（これはホストサーバーがTwitterにブロックされた時の一般的な挙動だね）

共用サーバーがブロックされてしまったら

Bluehostというのはアメリカのメジャーなレンタルサーバーサービスです。つまり、共用サーバーでイタズラな使い方をしたユーザーがいて、TwitterからIPごとブロックされてしまった場合に起こるエラーということですね。
ホスティング会社が察知して、何らかの対応をとってTwitterのブロックが解除されるのを待つしかないようです。

制限解除まではJetpackを使うことにしましょう。
JetpackはAutomaticのサーバーから発信されるので、WordPressを動かしているサーバーの制約を受けないというのはこういう場合利点ですね。

昨日（8月28日頃）から、日本の個人サイト界隈で大変な騒動になっています。

発端は、WordPressのフォーラムに投稿されたこんな質問。

サイトが急に文字化けになり、困っております；；
Hacked by Krad Xinと黒の上部ツールバーにあり、サイトが改ざんされてしまったのでしょうか？
WordPress › フォーラム » サイト改ざん？”

【ここまでのまとめ】

アドミンバーに犯行声明つきって、それってひょっとしなくても改竄されてますよね！
(さらに…)

WordPressの「投稿」画面を使わないで、別のシステムから直接SQL文を発行して記事をぶっこむ仕様のWebアプリを製作中。

本題の前に、WordPressの主な記事ステータスについてご説明します。

WordPressの記事ステータス

記事ステータスとはつまりその記事がどのような状態で保存されているか、ということです。
主なものを紹介すると、

• 下書き(draft)
• 公開中(publish)
• 予約投稿(future)
• ゴミ箱（trash）

が代表的なところです。
他には

• レビュー待ち（pending）
• 自動保存（auto-draft）
• 非公開（private）
• リビジョン（inherit）

があります。

さて、今回開発していたWebアプリでは、あえてpublishedではなく、futureで記事を登録していました。
なぜかというと記事の公開時にTwitter連携をしていたのですが、最初からpublishedで登録すると、Twitter連携アプリが作動する「記事公開時フック」を通らないので、Twitterに記事が配信されなかったからです。
そこでわざと予約投稿にして、公開はWordPress側にさせることでフックを通そう、という算段です。

しかし、予約登録まではうまくいくものの、公開予定時間になってもwp-cronが作動せず、「予約投稿の失敗」になってしまう。

WordPressの予約投稿のメカニズム

未来の日付で記事が投稿された場合、WordPressの記事ステータスが「future」になります。
この状態で公開日時以降にそのWordPressのどこかにアクセスが有った場合、wp-cronが作動して記事の公開処理が行われます。
cronと言ってもサーバーで時限処理をするcronと違って、WordPressにアクセスされた時に日時を持って公開判定をするので、擬似的なcronといえるでしょう。

しかし、予約投稿には
・記事の日付
・記事のステータス

以外にも、DB上では情報の更新がありました。
今回WordPress上から投稿した時と何が違うのか調べてみると、単純に記事の投稿時刻とステータスだけではなく、wp_optionsの中の「cron」というテーブルに予約動作に関する情報が登録されていたのでした。

wp-optionsのcronを調べてみる

中をのぞいてみると、このレコードは記事予約の他にはakismetのスパム削除スケジュールなど、WordPressが扱う予約動作全般の情報を保存しておくものでした。
で、今回の予約記事に関しては

i:1368027884;
a:1:{s:19:”publish_future_post”;
a:1:{s:32:”2b1da4ca66a51f7e26369cbe52edd54f”;
a:2:{s:8:”schedule”;
b:0;
s:4:”args”;
a:1:{i:0;
i:567;

という情報が増えていました。
publish_future_postはこの予約動作の種類を、最後のi:567は記事IDを示している、といった程度は分かるのですが、「2b1da4ca66a51f7e26369cbe52edd54f」などはどうもWordPressが乱数を発生させて割り当てているようで、これを解析して再現するのは骨が折れそうです。

その労力を考えると、素直にWordPressのXML-RPC投稿を利用したり、Twitterの投稿アプリを追加開発したりしたほうが良さそうな気がします…。

普通に予約投稿が失敗する場合

こういうなにか特別なことをしてるわけではなく、普通に運用しているはずのWordPressで予約投稿がうまくいかない場合は、こちらの記事が参考になるかと思います。
WordPressの予約投稿が失敗する件の解決方法

WordPressで、用意されているWordPress関数でなくオリジナルな挙動をする関数を自作するとき、便利なのが$wpdbクラスですね。
query、insert、get_resultsなど各メソッドの引数にSQL文を入れることによって、WordPressのMySQLデータベースから自由自在に結果を出し入れすることができます。

…と思ったら、あれっ？
フェイタルエラーが出てしまった！

Fatal error: Call to a member function get_results() on a non-object….
Fatal error: Call to a member function query() on a non-object….
Fatal error: Call to a member function insert() on a non-object….

はい。functions.phpの中の関数などにコードを余所からコピーしてきた場合など、上記のエラーが出て困った人も多いのではないでしょうか。

このエラーは「メンバー関数（メソッド）をオブジェクトでない場所で使おうとしてますよ」という意味です。

こんな時は慌てず

global $wpdb;

のグローバル宣言をそれより前に挿入します。
WordPress で DB にアクセスするには wpdb クラスを使います。グローバル変数 $wpdb でアクセスすることが可能です。
PHPでは、グローバル変数を関数の内部で使用する場合、関数の内部でグローバルとして宣言しておく必要があります。

上記はWordPressの例ですが、他のPHPフレームワークでも共通する原則なので、「困ったらグローバル宣言！」を忘れないようにしましょう！