更新しなくなったWordPressサイトを静的にしておく

WordPressはPHPで動的にサイトを出してます。
当然サーバーのCPUパワーを食うので、更新しなくなったサイトは静的に変換して置いておきたい。
StaticPress等のプラグインを入れて出力させるのが常套手段なのですが、現段階の最新版Wordpress4.7.2に入れたらエラーが出たりして(使っているテーマ、環境にもよると思います)。

ならば無理矢理クロールして取ってしまえ!ということでwget
$ wget -nc -x -r http://example.com

出来上がったファイルは拡張子がhtmlじゃないものも多いので、
設置先サーバーのほうでMIME-typeをいじります。

今回はnginx上に置いたので

server {
    server_name example.com;
    location / {
        default_type text/html;
    }
}


これだけ。
たぶんApacheでもDefaultType text/htmlとか書いておけば拡張子ナシでもhtmlとして出してくれるでしょう(未確認)

あとはアクセスしてみて、微妙にリンク先が無かったりするものは個別に手直し。
Wordpressに限らず動的サイトを静的にするのに使えるなぁ。

WordPressサイトの全SSL化…一部リンクがSSLにならない

とあるwordpressを使ってるサイトを常時SSL化することになりました。
VPSだったのでSSL証明書の取得からインストールまでLet’s Encryptですんなり行きました。

Let’s Encrypt 総合ポータル

次にWordpressの設定でホームURLを http から https に変更します。
そして全文検索してhttpのリンクをhttpsにします。
このへんはSearch and Replace for WordPress Database Scriptを使用。

WordPress移行時にURLをSQLで直接一括置換はダメ! 「Search and Replace for WordPress Databases Script」を使おう | infoScoop開発者ブログ

あとはテーマのファイルをgrepしてhttp箇所を //からの表記に直したり…

しかしメニューのリンクとか一部プラグインの出力がSSLにならない。
ソースを見るとget_page_link()とかで呼んでるわけです。
じゃぁ中身の設定に従うはずだよなぁ…と wp-includes/link-templates.php を読み、
データベースを疑い…わからん。

しかし結局Really Simple SSLというプラグインを入れたらあっさり解決。
なんだ、どこにこの違いがあったのだ…

WordPressを一瞬でHTTPS化するプラグイン「Really Simple SSL」の使い方

今後常時SSLサイトが増えるだろうし、もうちょっと根本的に原因を探りたいのだがなぁ

CentOS6にFML8でメーリングリスト

いろいろコラボレーションツールとかありますが、根強い人気のメーリングリスト。
みんなが使い慣れたインターフェースで、スマホにも届くし、
新しいことを覚えなくていいので、使いたいご要望をよくいただきます。

しかしMLは使いたくてもMLの管理はみんなやりたがらない。
コマンドメール送ってねといってもやらない。
今回の目的は、メンバー全員に届く&返信も全員にできる、ぐらいですからね。

そんなわけで久々にCentOS6にFML8を導入しました。他はpostfixとapacheです。

■ポイント
・perlのモジュール揃える
・CGI動かすのに苦労、suexec配下なのとmod_perlじゃダメ

■インストール
本家の説明の通り。
この時点でアレが足りないとか言われたらyumでインストールする。

■バーチャルドメイン
makefml newdomain example.net するのを忘れない
virtual_alias_mapsの指定を忘れない

■管理用webインターフェース(CGI)を使う
SuEXECでfmlユーザーが動かないといけないのでそのようにする。
/home/fml/public_html/cgi-bin/以下略~となるので
http://example.com/~fml/cgi-bin/以下略~と動かす。
表向きのドメインにUserDirが見えるのもなんだかなーということでfmlだけ使えるようにする
続きを読む

WordPress上でAPCのエラー→メモリ調整

そんな爆発的な数のアクセスを裁くわけでもなしー、と、さくらのVPSを使ってデフォルト適当に動かしていたところ、一部WordpressサイトでAPCのメモリ不足だとエラーが出まくる。
「Unable To Allocate Memory For Pool」
こりゃ調整しないといけない。

apc.phpを眺めつつ、たぶんプラグイン入れまくりで何かあるよなーと思うもWPはWPで対処するとして別件に。
サーバー設定としては単純にAPCのメモリ割当量を増やせば解決!というわけにもいかないので、そもそものメモリ割当量が多すぎなんじゃないのかということで調整。
CentOS6、メインメモリ2GB。

/etc/php.d/apc.ini
apc.shm_size = 128M
apc.mmap_file_mask=/dev/zero

php および APC の設定を行う | レンタルサーバー・自宅サーバー設定・構築のヒント
メモリ2GBなので128MBに。1GBで64M、512MBで32Mが適量のよう。

それでもまだエラー出る。しかしこれ以上は増やせない!
ということで1プロセスあたりのメモリを減らすためにapacheのモジュールを外す。

ウェブ開発者のための、1時間でできるLAMP環境構築術(CentOS編) – さくらインターネット創業日記
参考になります。

とりあえずまだPreforkで動かしているので
/etc/httpd/conf/httpd.conf
<IfModule prefork.c>
StartServers 10
MinSpareServers 5
MaxSpareServers 15
ServerLimit 256
MaxClients 128
MaxRequestsPerChild 2000
</IfModule>

と設定して様子見。
KeepAliveはOff。

今のところ穏やか。

WordPress>category-iconsプラグインのエラー回避

なんかエラーが出てるwordpressサイトがあり、cateogory-iconsプラグインの中で問題が起きている模様。

[Tue Jul 08 20:44:38 2014] [error] [client XXX.XXX.XXX.XXX] PHP Warning:  Missing argument 2 for wpdb::prepare(), called in /path/to/wordpress/wp-content/plugins/category-icons/category_icons.php on line 1047 and defined in /path/to/wordpress/wp-includes/wp-db.php on line 1147, referer: http://www.osc-japan.com/wp-admin/plugins.php

WP3.5あたりで必須になったパラメータがついていない。
というかcategory-iconsプラグインがその後バージョンアップしていないっぽい。
なのでcategory_icons.phpに手を入れます。

1047行目
$wpdb->query($wpdb->prepare("CREATE TABLE IF NOT EXISTS `$wpdb->ig_caticons` (`cat_id` INT NOT NULL ,`priority` INT NOT NULL ,`icon` TEXT NOT NULL ,`small_icon` TEXT NOT NULL , PRIMARY KEY ( `cat_id` ))",0));
1338行目
$datas = $wpdb->get_results($wpdb->prepare("SELECT cat_id, priority, icon, small_icon FROM $wpdb->ig_caticons",0));

prepareの第2引数に0を入れてやる。

これでエラーなく動きました。

参考
WordPress › Support » WordPress 3.5 Admin Error