WordPress一覧

CORESERVER + WordPress で BackWPup The Final

これまでイロイロと手を加えることでなんとか動作させてきた「BackWPup」ですが、今回の Coreserver アップデートによりすんなり動作するようになったようです。

・ウェブサーバーのバージョンアップ(Apache2.2系へ変更)
・標準のPHPのバージョンアップ(PHP5.2系 → PHP5.3系へ変更)
・CGI版PHP5.2、5.3、5.4、5.5の最新版へのアップデート
・FastCGI版PHP5.3、5.4、5.5の提供
・セーフモードの解除
・お客様サイト内のユーザー所有者「apache」のファイルをユーザー様へ変更

コアサーバーApache/PHPのバージョンアップ から引用

PHP5.2系 → PHP5.3系に変更されたと同時にセーフモードが解除された為だと思われます。
(セーフモードはPHP5.3で非奨励、PHP5.4で廃止)
続きを読む


CORESERVER + WordPress で Quick Cache

ちょいと気が向いたのでキャッシュまわりをいじってみたのでその備忘録。

負荷を気にするほどPVないだろ!という声は聞こえない。聞こえない。

ググってチョイスした WordPress のプラグインはこれ。

Quick Cache

導入方法や設定は詳しく解説されているサイト様があるので割愛w

プラグインを有効にした後、早速速度を計測してみる。

が、、、全然変化なし。

Chrome のデベロッパーツールでも、Firefox の Firebug でも、Internet Explorer の開発者ツールでも変わらない・・・
続きを読む


CORESERVER + WordPress で BackWPup Part.4

(BackWPupの新しい記事はこちら

面倒なので WordPress をすべてCGIモードで動かした前回から約一ヶ月。

BackWPup でバックアップはとられているものの、何故かログがエラーや警告だらけ。。
「やはり横着はいかん」というコトで、ちゃんと設定してみました(^ ^;

インストールディレクトリの.htaccess

まずはインストールディレクトリの .htaccess を整理する。

今まで書いていた AddHandler をFilesディレクティブも含めすべて削除。
通常ならパーマリンクを変更している場合のみ rewrite の記述が残るはず。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

続きを読む


CORESERVER + WordPress で BackWPup Part.3

(BackWPupの新しい記事はこちら

BackWPupのバージョン3以降、CORESERVERでうまく動作しなかった件を再検証してみる。

とりあえず今日現在最新であるバージョン3.0.6にアップデート。

そして前回の追記と同じくWordPress全体をCGIモードで動作させてテスしてみると、問題なくバックアップが完了してDropboxにも保存された。

バージョン3.0.4の時のように異常に遅いというコトもなく、所要時間は今までと同じくらい。

ただし、バージョン2.1.17で登録したJob設定を開くとWarningが出まくるので、削除⇒再作成するか、一旦保存⇒再設定⇒保存する必要がある。(Jobsの画面にもforeachのWarningがあるけど無視)

さて、.htaccessを元に戻しセーフモードでの動作を確認。
続きを読む


WordPress3.5でprepare関数のWarning

WordPressの3.5にアップデートした時に何やら Warning がでる場合があるらしい。

ウチもテーマのフッター部分で、コピーライトの年数を取得する部分で発生を確認。

Warning: Missing argument 2 for wpdb::prepare()

ちなみにmono-labさんのmonochrome旧バージョン3.3です。
(テーマの最新版はウィジェット使用時にスタイルシートでサイドバーの余白に難があったので様子見。。)

調べてみるとバージョン3.5からprepare関数の第二引数が必須になったらしい。

WordPress3.5 にしたら prepare でエラーが出た 場合

上記サイト様にとりあえずの対処方が。

でも、コアファイル(Wordpress本体のプログラム)をいじるのは何となく嫌。。。

幸いにも(!?)monochromeのテーマはprepare関数でプレースホルダーを使っておらず決め打ちのSQLだった!

というワケで、子テーマにfooter.phpをコピーして、prepare関数の第二引数にNULLを指定することで回避しました。

prepare("SQL文");

prepare("SQL文",null);

にするだけー。

プラグインやテーマでプレースホルダーを使っていない場合は、とりあえず回避できます。


スポンサーリンク