WordPressでサイトURL設定を間違えたとき

WordPressはユーザの目的に合わせて様々なカスタマイズに対応していますが、それゆえ僕のような初心者が弄ってしまうと途端に動かなくなってしまう場合があります(ありました)。
そのうちの1つが、設定 › 一般設定 にある「サイトアドレス(Site URL)」です。

WordPressのサイトアドレス設定
WordPressのサイトアドレス設定

そのBlogの各ページへのリンク生成に必要となる文字列で、この値を間違えるとスタイルシートが読み込めずに表示が崩れたり、正しく別ページへ移動できなくなってしまいます。
最悪の場合、WordPressの管理ページにもアクセスできなくなりますので、お手上げになってしまいかねません。

検索してみると、このミスは大変多くの人が経験しているようで、解決策もあっさり発見できました。
もしかして定番中の定番なのでしょうか。
今回、修正の参考にしたのは以下のページです。

WordPress › フォーラム » 階層変更後ログインできない

この問題の修正方法は、大雑把に分けて2つ。

  1. データベース(DB)を直接編集
  2. wp-config.phpで設定を上書き

WordPressの投稿データや設定等は、基本的にDBに格納されます。これを直接編集してしまえば当然ですが元に戻ります。
また、DBに設定が保存されていてもwp-config.phpに記載があればそちらが優先されるらしく、その仕組みを利用することも出来ます。
手軽なのは2番でしょうか。

wp-configを上書きする

FTPでウェブサーバにアクセスし、WordPressディレクトリの直下にあるwp-config.phpをダウンロードします。
[php]
define(‘WP_SITEURL’, ‘http://odproject.net/blog’);
[/php]
PHPには余り明るくないのですが、定数定義の構文のようですので、これを追記してみます。
ローカルマシンで修正した後はウェブサーバに戻す(アップロードする)必要があります。
この一手間が面倒なら、ターミナルでログインし、直接phpファイルを編集してしまいましょう。

いずれにせよ、復旧したら管理画面からサイトアドレスを再設定しておいた方が良さそうです。

データベースを編集する

今回、実はこちらの面倒な方法を使って復旧させました。
昨今のレンタルサーバですと、ウェブからDBを操作できるツール「myPHPadmin」が導入されていることが多いので、そちらを使用するのが得策です。
ただし僕はmyPHPadminを使ったことが無く、また変な操作をしてしまっては面白くありません。
ですので確実な方法でDBにアクセスすることにしました。はい、例によってターミナルからログインです。

[bash]
% mysql -u USER_NAME -h mysql***.db.sakura.ne.jp -p
[/bash]
ターミナルからコマンドラインツールのmysqlを起動します。
WordPressのDBは別の場所にあるらしく、サーバを指定しなければなりません。
オプションの意味についてはMySQLのリファレンスを参照してください。

[sql]
mysql> use DATABASE_NAME;
Database changed

mysql> show fields from wp_options;
+————–+———————+——+—–+———+—————-+
| Field | Type | Null | Key | Default | Extra |
+————–+———————+——+—–+———+—————-+
| option_id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| option_name | varchar(64) | NO | UNI | | |
| option_value | longtext | NO | | NULL | |
| autoload | varchar(20) | NO | | yes | |
+————–+———————+——+—–+———+—————-+
4 rows in set (0.00 sec)
[/sql]
WordPressの各種設定は、wp_optionsテーブルに保存されています。
option_nameフィールドからそれっぽいものを探してみると、「siteurl」という文字列を発見しました。

[sql]
mysql> select * from wp_options where option_name =’siteurl’;
+———–+————-+————————-+———-+
| option_id | option_name | option_value | autoload |
+———–+————-+————————-+———-+
| 1 | siteurl | http://example.net/blog | yes |
+———–+————-+————————-+———-+
1 row in set (0.00 sec)

mysql> update wp_options set option_value="http://odproject.net/blog" where option_name =’siteurl’;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
[/sql]

というわけで、さくっとUpdateしてしまいましょう。

WordPressの高速化(キャッシュプラグイン)

WordPressは高機能な分、ちょっと重いところもあるので高速化プラグインをいくつか入れてみました。

1 ページキャッシュプラグイン

 毎回DBにアクセスせずに、キャッシュしたページを表示してくれるプラグインを
入れます。
 調べると「W3 Total Cache」が有名なのですが、最近、脆弱性が発見されているというのと、サーバのリソースをがっつり食うようなので、今回は「Quick Cache」をインストールすることにします。

○インストール方法
「プラグイン」>「新規追加」>「Quick Cache」を検索
「いますぐインストール」を選択して、インストールが完了したら
「プラグインを有効化」で機能をONにします。

メニューの中から「Quick Cashe」>「Config Options」
Caching Enabled? の所を「ON(Enabled)」を選択して保存

2 MOファイルキャッシュプラグイン

 Wordpressの翻訳ファイルであるMOファイルをキャッシュします。
 「MO Cache」というのが有名そうですが、他のObject Cache も同時必要
 今回は、単体でキャッシュしてくれる「001 Prime Strategy Translate Accelerator」を導入します。

3 MySQL クエリキャッシュプラグイン

 データベースもキャッシュします。
 「DB Cache Reloaded Fix」をインストールして有効化

とりあえず、定番のプラグインを3つほどいれてみました。

<参考にしたページ>

さくら(スタンダード)にWordPressを導入してみました

WordPressをインストールしてみましたのでそのメモ

さくらサーバの契約を確認すると「ライト」ではインストールできない様子。
「スタンダード」以上で入れましょう。

1 データベースを新規作成

WordPressはデータベースを使います。
さくらのサーバコントロールパネルから新規データベースを作成
https://secure.sakura.ad.jp/rscontrol/

文字コードは「UTF-8」を選択
データベース名、パスワードははあとで使います。
作成されたデータベースはサーバ名が表示されているのでこれもメモ

2 WordPressをダウンロード

公式ページからダウンロードして解答

ホーム

FFFTPあたりで適当なフォルダにまるごとアップロード
いつもアップロードしてから、パーミッションの設定をしていたのですが、
アップロードのタイミングで自動で設定してくれる機能があるようです。
FFFTPの[環境設定]→[オプション]→[転送3]
今回は「*.php」を「705」に指定します
FFFTP

3 URLにブラウザからアクセス

「ファイルが見つかりません」といわれるので「wp-config.php ファイルを作成する」ボタンを。
あとは自動でインストール作業が始まります、
このとき、1で作ったデータベース名、ユーザ名、パスワード、サーバ名が必要になります。

TRPGリプレイの電子書籍化を計画中

ODプロジェクトでは、TRPGリプレイを電子書籍での発行を計画しています。

第1弾はダブルクロス3rdリプレイ「儚~ヒトノユメ~」を電子化の予定です。

その後、逐次既刊リプレイの電子化を予定しています。
p1