herokuもbuildpackでphpが使えるようになってるのでさくらVPSで運用してた大東亜戦争従軍記をherokuに移行しました。

下記を参考にさせていただいてmysqlのままでClearDB addonを使うパターンでやりました。
blog.handswiz: 言語切り替え機能をつけたwordpressをherokuで動かす
WordPressからWordPressへの移行なので楽ですね。さくらVPSのお金をケチりたかったというのと、スマホで見辛いのでレスポンシブにしたかった。
herokuもbuildpackでphpが使えるようになってるのでさくらVPSで運用してた大東亜戦争従軍記をherokuに移行しました。
下記を参考にさせていただいてmysqlのままでClearDB addonを使うパターンでやりました。
blog.handswiz: 言語切り替え機能をつけたwordpressをherokuで動かす
WordPressからWordPressへの移行なので楽ですね。さくらVPSのお金をケチりたかったというのと、スマホで見辛いのでレスポンシブにしたかった。
これをsunzi recipeにした。
sunzi.ymlにremoteのrecipeを持ってくる設定を書く。
wordpress_domain
にはwordpressで使うdomain名を書く。
wordpress_jaは日本語で使いたい時だけ必要。
eval_erbはテンプレート中でrubyを評価するのに必要。
sunzi.yml:
---
attributes:
wordpress_domain: fjord.jp
recipes:
wordpress: https://raw.github.com/komagata/sunzi-recipes/master/recipes/wordpress.sh
wordpress_ja: https://raw.github.com/komagata/sunzi-recipes/master/recipes/wordpress_ja.sh
preferences:
eval_erb: true
install.shで読み込む。
#!/bin/bash
set -e
export DEBIAN_FRONTEND=noninteractive
source recipes/sunzi.sh
sunzi.mute "apt-get update"
sunzi.mute "apt-get -y upgrade"
source recipes/wordpress_ja.sh
sunzi.installを使ってるのでsunzi.shもsourceする。日本語化の必要がなければwordpress.shだけをsourceすればいい。
$ sunzi deploy fjord.jp
便利。
アップデートはdebian任せになるので楽だが最新を追っかけるのとどっちがセキュアなのかはわからない。
setup-mysql
というdebianのwordpress独自のスクリプトを使うのが面白い。
# DEBIAN_FRONTEND=noninteractive apt-get -y install mysql-server
# apt-get -y install wordpress
# cd /usr/share/doc/wordpress/examples
# gunzip setup-mysql.gz
# bash setup-mysql -n wordpress example.com
# vi /etc/apache2/sites-available/example.com
<virtualhost *:80>
ServerName example.com
UseCanonicalName Off
VirtualDocumentRoot /usr/share/wordpress
Options All
# wp-content in /srv/www/wp-content/$0
RewriteEngine On
RewriteRule ^/wp-content/(.*)$ /srv/www/wp-content/%{HTTP_HOST}/$1
<VirtualHost>
# a2ensite example.com
# a2enmod rewrite
# a2enmod vhost_alias
# /etc/init.d/apache2 restart
日本語化する場合。
# sed -i "s/?>/define('WPLANG', 'ja');\n?>/" /etc/wordpress/config-example.com.php
$ open http://example.com
現状渡しされてパスワードがわからない時。
mysql> update wp_users set user_pass = '$P$BQ6n8cNLFJBJyxYYoPK3bDWymBXILO.' where user_login = 'admin';
これでadminユーザーのパスワードがfoo
になります。
コレ、解決してませんでした。
複数カラムに対してORDER指定は可能だけど、ASC,DESCの指定が最初の一個しか効かない。ソースを読んでも確かにそうなってる。
それはquery_postsの仕様で少なくとも今日時点ではそうなってる。WordPress Query APIはSQLのBad Wrapperだ。
具体的には勝手なパラメーターを追加することで強制的にORDER句を指定することにした。
// functions.php
function force_order($orderby, $query) {
return $query->get('force_order') ? $query->get('force_order') : $orderby;
}
add_filter('posts_orderby','force_order');
こんな感じで使う。
query_posts('force_order=menu_order ASC, ID DESC')
俺のこの対応方法も酷い。
この「ORDERに複数指定可能だったら当然ASC,DESCも指定可能だろう」という期待が通用しないのがWordPressという修羅の国。
その肌感覚を散々味わってきたハズが、最近触ったpostMashというプラグインのコードがマトモだったことで油断してた俺をWordPress Query APIのコードが打ちのめした。
WordPressで複数カラムでorder byしたかったんで調べたんですが、WordPressではSQLの代わりにWP_Queryってのがあって記法が独特。
SQL:
SELECT * FROM foo ORDER BY name ASC, id DESC
WP_Query:
orderby=name id&order=ASC DESC
SQL Injectionが多発したので別記法を強制したいんだと推測しますが、プレースホルダでもORMでもなく、何故別の文字列ベースの記法になったのかはワカラナイ。
さくらVPS 512のDebian Squeezeに入れた。(さくらVPS 512にSqueezeを入れる方法はこちら)
$ sudo apt-get remove --purge apache2* apache2.2* php5*
$ sudo apt-get autoremove
$ sudo vi /etc/apt/source.list
deb http://packages.dotdeb.org squeeze all
deb-src http://packages.dotdeb.org squeeze all
$ wget http://www.dotdeb.org/dotdeb.gpg
$ cat dotdeb.gpg | sudo apt-key add -
$ rm dotdeb.gpg
$ sudo apt-get install nginx
server {
listen 80;
server_name unk.fjord.jp;
location / {
root /var/www/unk.fjord.jp;
index index.html index.php;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/unk.fjord.jp$fastcgi_script_name;
}
}
$ sudo apt-get install php5-fpm
$ sudo apt-get install php5-apc
$ sudo apt-get install mysql-client mysql-server php5-mysql
(略)
速いし良い感じッス。
ちょっと頭の片隅においておくといいかもしれないWordPress関連の2つの論争 « WaviaeiWordPress3.0がリリースされましたが、このバージョンからcapital_P_dangit()という関数がコアの中に付け加えられました。このコードが何をするかと言うと、記事のタイトル(the_title)、記事の本文(the_content)、そしてコメントの本文(comment_text)に、間違ったスペルのWordPressが書かれていると、それを自動的に正しいスペルに修正する、というものです。(厳密にいうと、DBには間違ったまま保存され、記事として動的に出力される時に正しいスペルで表示するようfilterがかかります。)
Oh my god! oh my god...
特定の単語のスペルミスを直すためだけの関数がコアに入るとは・・・。
もし僕がやるならWordPressのビジュアルエディタにスペルチェック機能(英語のスペルミスを黄色くハイライトするとか)を実装すると思う。
僕の感覚とのあまりの乖離に一瞬痛快にすら思えたけど、これは間違った悟りだ。