Wordpressをインストールしてみた » Wordpress基本設定

FireFox先読み機能対策としてnextリンクを解除する

たかちん — Mon, 29 Nov 2010 18:32:01 +0000

こんにちわ。たかちんです。

以前、「必要のないヘッダ情報を削除する」という記事を書きました。今回は、その続編でもあります。
Wordpressでは、ヘッダ情報にいろいろ自動で出力します。

そもそも、この記事を書くに至ったのは、Wordpressで構築したサイトのWEBアクセスログを見ていて、１つ疑問に思ったことが発端です。
その疑問は、WEBブラウザのFireFoxでアクセスがあった時に、必ず、２つのページにアクセスしている点です。

実際に自分でも確認しました。

FireFoxは、処理の高速化？のためか、ページの先読み機能があるらしいのです。（ほとんどの方はご存じだと思いますが、自分は知りませんでした。）
このページの先読み機能のために、あるページへアクセスした場合、次に読み込むであろうページを先読みするためにアクセスしていたみたいです。

今回は、このFireFoxのページの先読み機能への対処を、簡単に紹介してみたいと思います。

何を基準にFireFoxはページの先読みするか？

そもそも、FireFoxのページの先読み機能は、何をもとに先読みするページを決めているかが理解できれば、その決定する要因を取り除けば良いことになりますね。
そこで、その決定するための情報は、何か？を調べてみました。

FireFoxは、表示しようとしている（している）ページのヘッダ情報のmeta情報から、先読みするページを決定しています。
以下は、その決定するための情報例です。

ちょっともったいぶってすみません。ただ、これだけです。
単純にlink rel=’next’が指定しているURLを先読みしているだけです。

この情報は、Wordpressのサイトで、次へ、前へなどのリンクを常に表示しているようなサイトであれば、意味があるかもしれませんね。
ただ、サイトによっては、記事の順番なんて意識していないことも多いと思います。このサイトそうですが・・・。

そのようなサイトにとっては、先読みしてもほとんど無駄になってしまうでしょう。逆にその先読みによるアクセスが、サーバーの負荷を上げてしまうことにもなります。
そこで、早速、このmeta情報をヘッダから削除してしまいましょう。
（SEO的には、多少、意味があるみたいですけど・・・。SEOもちょこちょこ変わりますからね。個人的には、あんまり神経質になることもないかと思います。）

link rel=’next’ 情報をヘッダから削除する

これは、以前の「必要のないヘッダ情報を削除する」という記事のやり方と同じです。remove_actionを使います。
ただ、Wordpress 2.xx と 3.xx では、少し違うので注意が必要です。

Wordpress versions 3.0 以上の場合、テーマ（テンプレート）のfunctions.phpへ以下のように記述します。

remove_action('wp_head', 'adjacent_posts_rel_link_wp_head');

Wordpress versions 3.0 以前の場合（2.xx）、テーマ（テンプレート）のfunctions.phpへ以下のように記述します。

remove_action('wp_head', 'adjacent_posts_rel_link');

簡単ですね。
実は、自分は、この問題の原因から対策にいたるまでに、数時間を要してしまいました。
ほんと、時間がもったいないです。
この記事が、同じ問題を抱えている方の助けになればうれしく思います。

自動保存を解除する

たかちん — Wed, 24 Nov 2010 06:13:27 +0000

こんにちわ。たかちんです。

Wordpressで記事を編集している最中に、グッと重たくなることありませんか？
これって、ほとんどの場合、自動保存の機能が動作しているためです。

記事編集中の画面右下に以下のように一時的に表示されませんか？

今回は、この自動保存機能を無効にする方法を、簡単に紹介してみたいと思います。

自動保存機能を無効にするには

自動保存機能を無効にするには、今使っているテーマ（テンプレート）の functions.php に、以下のように追記するとOKです。

function disable_autosave() {
	wp_deregister_script('autosave');
}
add_action('wp_print_scripts','disable_autosave');

ただ、これだけです。
‘wp_print_scripts’へのフック関数を追加しているでけです。
極端な話、

wp_deregister_script('autosave');

のみを追加しても同じ効果を得ますが、一応、Wordpressのしきたりに従えば、add_actionを使うできなんでしょうね。
追加すべきアクションが、‘wp_print_scripts’で良いのか？という疑問もなくはないですが、自動保存は、スクリプトで動作しているので、そうなんでしょうね。

簡単ですね。
ただ、これをやってしまうとプレビューできませんのでご注意を

WordPressのデータベースをバックアップする

たかちん — Tue, 16 Nov 2010 05:58:23 +0000

こんにちわ。たかちんです。

さて、データベースのバックアップです。
Wordpressは、通常、MySQLを使ってますから、データベースのバックアップは、単純にMySQLのバックアップということになります。

では、早速、簡単に解説してみます。

データベースを丸ごとバックアップ

MySQLのバックアップには、バイナリダンプ(mysqlhotcopy)とSQLダンプ(musqldump)があります。
一般的によく利用されるものは、後者です。

前者のバイナリダンプでは、TABLE LOCKなどの一時的なMySQLの停止処置が必要で、初級者には、少し面倒です。また、mysqlhotcopyを実行するホストでmysqlが動作している必要があります。

後者は、厳密には、同じような処置が必要ですが、一般的には、MySQLを意識的に止めることはありません。すべては、musqldumpの中で実施します。

ここでは、後者を利用してバックアップを作成してみましょう。

$ mysqldump -hzzzz -uxxxx -pyyyy nnnn   > ffff

zzzz:mysqlのホスト名ログインしたサーバーと同じ場合は、”localhost”でOK
※XREAの場合は、localhostなので、-hzzzz は省略可です。
xxxx:mysqlのユーザ名
yyyy:mysqlのパスワード
nnnn:mysqlのデータベース名
ffff:バックアップしたいファイル名（カレントディレクトリにない場合は、フルパスで指定します。）

以下は、例です。
mysqlが動作しているホスト:100.100.100.100 IPアドレスでもホスト名でも可。
mysqlのユーザ名:hoge
mysqlのユーザパスワード:passwordhoge
mysqlのデータベース名:hogedb
mysqlのバックアップファイル名:hoge.sql

$ mysqldump -h100.100.100.100 -uhoge -ppasswordhoge hogedb   > hoge.sql

また、合わせてgzipで圧縮したいなら、

$ mysqldump -h100.100.100.100 -uhoge -ppasswordhoge hogedb | gzip  > hoge.sql.gz

とすれば、gzipで圧縮してくれます。

テーブルごとにバックアップ

先のデータベース丸ごとバックアップと同様に、各テーブルごとにバックアップを作成することもできます。
レンタルサーバーでは、データベース数が限られている場合も多く、１つのデータベースに複数のサイトテーブルを作成している場合もあると思います。

その場合は、テーブルごとにバックアップすればOKですね。

$ mysqldump -hzzzz -uxxxx -pyyyy nnnn t1 t2 ....   > ffff

t1 t2 .... : t1,t2 それぞれテーブル名になります。半角空白をはさみ、複数指定できます。
簡単ですね。

テーブル名がわからないときは、mysqlで出力できます。

$ mysql -hzzzz -uxxxx -pyyyy -Dnnnn
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6268702
Server version: 5.1.22-rc Source distribution
 
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
 
mysql> show tables like 'wp_%';
+-----------------------+
| Tables_in_b3d         |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
11 rows in set (0.00 sec)
 
mysql>

zzzz:mysqlのホスト名ログインしたサーバーと同じ場合は、"localhost"でOK
xxxx:mysqlのユーザ名
yyyy:mysqlのパスワード
nnnn:mysqlのデータベース名

とこんな感じで出力できます。これを単純にバックアップしたいテーブル名を追加しれば良いだけですね。

バックアップした状態に戻す

一般にバックアップしたときの状態に、データベースを戻すことをリストアといいます。
ここでは、単純に先に記述したようなバックアップファイルから、リストアする方法を記述します。

$ mysql -hzzzz -uxxxx -pyyyy -Dnnnn < ffff

zzzz:mysqlのホスト名ログインしたサーバーと同じ場合は、"localhost"でOK
※XREAの場合は、localhostなので、-hzzzz は省略可です。
xxxx:mysqlのユーザ名
yyyy:mysqlのパスワード
nnnn:mysqlのデータベース名
ffff:バックアップしたファイル名（カレントディレクトリにない場合は、フルパスで指定します。）

$ mysql -h100.100.100.100 -uhoge -ppasswordhoge -Dhogedb   < hoge.sql

また、合わせてgunzipで解凍したいなら、

$ gunzip < hoge.sql.gz | mysql -h100.100.100.100 -uhoge -ppasswordhoge -Dhogedb

とすれば、gunzipで解凍した上で、リストラしてくれます。

ざっと、こんな感じです。
Wordpressのデータベースは、基本的にテーブル名の先頭にwp_が付きますから、もし、テーブル名がまったくわからないようなら、wp_の付いたテーブルを探してみてください。

必要のないヘッダ情報を削除する

たかちん — Wed, 10 Nov 2010 00:52:27 +0000

こんにちわ。たかちんです。

さて、今回は、ヘッダ情報の中の無駄な情報を削除することを考えてみたいと思います。
皆さんは、実際にヘッダ情報が、とのように出力されているか確認されたことがありますか？

自分は、よくよく考えるとテーマ（テンプレート）の確認のために１度、２度くらい見たことがあるくらいで、あまり、気にしていませんでした。

今回、このあまり力強くないXREAのサーバーでは、無駄な処理をさせないたくないなぁ・・と思って、いろいろ調べてみると、案外、無駄な情報が出力されていることに気づきます。

今回は、ヘッダ情報内での無駄？な情報を出力しないようにする方法を、簡単な例で紹介してみたいと思います。

まずは、ヘッダの情報でわからない部分を確認します

まずは、ヘッダ情報がどのように出力されるかページのソースコードを確認しましょう。

その中で、自分で理解できない情報やこれは必要ないと思われる情報をピックアップしてみましょう。

自分の場合、以下のような情報が出てきました。

それぞれの意味を確認しましょう。

generator の意味

これは、単純に「WordPress 3.0.1で作成されたページですよ」ということなので、もちろん、残してあげるのがより良いのですが、何分非力なXREAなので、削除してもOKですよね。

pingback の意味

これは、ピンバックのアドレスを指定しているものです。
「誰かがこのページへリンクを貼ったら、ここに指定しているアドレスへ通知してね。」という意味で、ここに指定しているアドレスへ通知が来ると、Wordpressはコメントが投稿された動作と同じ動作をします。

このようなピンバックやトラックバックが必要ない方は、削除して構いませんね。

EditURI の意味

これは、汎用的なブログ編集用のアドレスです。Wordpressに限らず、Movable Type、 MetaWeblog および Blogger XML-RPC 投稿プロトコルで利用される情報が、ここで指定しているアドレスで提供されています。

Wordpressの管理画面でしか編集しない方には、必要ありませんね。

wlwmanifest の意味

これは、Windows Live Writer を使って記事を投稿するときのアドレスです。
Windows Live Writer は、文字通りMSN(MicroSoftさんのWEBサービス)のブログ編集機能（ツール）のことで、これがWordpressを含めていろいろなブログに対応しています。
そのための情報が、「ここで指定されているURLで提供されていますよ」という意味なので、これもWindows Live Writer を使わない人には、意味がありませんね。

削除の仕方

ここからは、削除の仕方を簡単に説明します。

generator を削除

これは、テーマ（テンプレート）のfunctions.phpに以下の1行を追加します。

remove_action('wp_head', 'wp_generator');

これだけです。

pingback を削除

ピンバックは、まず、管理画面で受け付けないように設定してあげます。
管理画面の [ 設定 ] – [ ディスカッション ] を選択します。

□投稿中からリンクしたすべてのブログへの通知を試みる。
□他のブログからのリンク通知を許可する (ピンバックとトラックバック)

いずれもチェックを外します。
最後に、変更を保存ボタンをクリックして保存します。

そのあと、テーマ（テンプレート）のヘッダ情報(header.php)の中の以下の部分を削除します。

link rel=”pingback” で探すと良いと思います。

EditURI を削除

これは、テーマ（テンプレート）のfunctions.phpに以下の1行を追加します。

remove_action('wp_head', 'rsd_link');

これだけです。

wlwmanifest を削除

これは、テーマ（テンプレート）のfunctions.phpに以下の1行を追加します。

remove_action('wp_head', 'wlwmanifest_link');

これだけです。

ほとんどは、テーマ（テンプレート）のfunctions.php、header.phpに手を加えればできます。

ただ面倒な人には、プラグインで提供されているものもあるようです。
例えば、EditURI、wlwmanifest をまとめて削除するWLW Disablerみたいなプラグインです。やってることは、ここで記述していることをプラグインでまとめてやってるだけです。
他にもGoogleさんに聞いてみれば、いろいろと出てきます。

カテゴリごとにテンプレートを切り替える

たかちん — Mon, 08 Nov 2010 09:03:58 +0000

こんにちわ。たかちんです。

さて、今回は、前回の記事で紹介したプラグイン「Custom Post Template」を用いて、記事ごとのテンプレートの切り替え、ページごとのテンプレートの切り替えを実現しました。（ページごとの切り替えは、デフォルトで動作するんですけど、流れで説明しました。）

今回は、カテゴリごとにテンプレートを切り替える方法です。
これは、プラグインを必要としません。

では、早速、簡単に解説してみます。

カテゴリごとのテンプレートを用意する

カテゴリごとにテンプレートを切り替えるためには、カテゴリごとのテンプレートを用意だけです。

あまりにも簡単なので、ちょっとびっくりされたかもしれません。
ただ名前の付け方が違うだけなんですね。

通常は、
category.phpとつけるとことを category-8.phpなどと-8のようにハイフン＋カテゴリ番号をつけてテンプレートを作成するだけです。
※または、ハイフン＋スラッグ名をつけても可。例）category-samaple3.php

カテゴリIDは、昔のWordpressでは、常に表示されていましたが、現在は、表示されていません。
カテゴリの管理画面で、カテゴリ名にマウスをのせると、リンクアドレスが表示されます。その中にカテゴリ番号が表示されます。

現在は、スラッグ名も使えるので、スラッグ名を使うことが推奨されているんでしょうかね。（想像です。）

では、簡単なテスト用テンプレートを作ってみましょう。

これは、テンプレートごとのテスト用テンプレートです。

 if (have_posts()) : while (have_posts()) : the_post();  ?>
 the_title(); ?>
 the_content('続きを読む'); ?>
 endwhile; endif; ?>

例えば、ターゲットのカテゴリIDが8なら、これを、category-8.phpでテーマ（テンプレート）のディレクトリへ保存します。
カテゴリ番号=8のカテゴリリストを表示してみましょう。

こんな感じで表示されます。ここでのサンプル記事が１つなので、リストも１つしかありません。
実際のカテゴリリストは、こちらです。

しかし、これは、あくまでカテゴリリストを表示するためのテンプレートでしかありません。
カテゴリのすべての記事に影響するわけではありません。

つまりは、どんなに独自のテンプレート（テーマ）を持つカテゴリでも、そのカテゴリの記事を表示した場合は、その独自のテンプレート（テーマ）は適用されないわけです。

では、カテゴリの記事に対して、この独自のテンプレート（テーマ）を適用するには、どうしたら良いでしょうか。

カテゴリの全ての記事にテンプレートを適用する

これは、single.php あるいは、index.php に手を加える必要があります。
つまりは、記事を表示するテンプレートファイル（single.phpが存在すれば、そちらが優先されます。）

single.php あるいは、index.php の先頭に以下のコードを追加します。


	$cat = get_the_category();
	if(count($cat)>0){
		$cat = $cat[0];
		$cat_id = $cat->cat_ID;
		if($cat_id==8){
			include(TEMPLATEPATH."/category-8.php");
			exit;
		}
	}
 
?>

記事を表示する前に、カテゴリIDを取り出して、そのIDが対象となるカテゴリIDの場合は、そのテンプレートファイルを読み出して終了・・・だけです。

※この例では、カテゴリID=8の場合で記述されています。カテゴリIDが異なる場合は、8で記述している箇所を変更してください。

これを用いると、該当するカテゴリの記事は、以下のように表示されます。

こんな感じで表示されます。以降も表示されてますね。
実際の記事は、こちらです。

ざっと、こんな感じです。少し、テンプレートに手を加えることで、簡単に切り替えできるんですね。

前回の記事で紹介した内容も、記事数が少なければ、これと同じようなやり方でも切り替えることができます。

でも、プラグインが汎用的ではありますから、そちらが良いのかもしれません。この辺りは、テーマ（テンプレート）をいじる人の好みかもしれませんね。

WordPress 3.0 で記事分割のアドレスをクリックしても表示が切り替わらない問題について

たかちん — Wed, 27 Oct 2010 03:10:36 +0000

こんにちわ。たかちんです。

今回は、前回インストールしたWordpress3.0の問題についてです。

WordPressでは、記事分割という機能があります。これは、長い１つの記事をページ分割して見やすくする機能です。

投稿記事の中で、分割したい位置に以下のタグを埋め込めば、記事の分割をすることができます。

実際に分作した記事は、以下のように表示されます。

サンプル記事は、こちらで実際に記事を確認できます。

上記の例では、１つの記事を３ページに分割しています。
１ページ目は、正しく表示されるのですが、分割された２ページ目以降が、表示できないのです。下の２、３ページへのリンクをクリックしても１ページ目が表示されてしまいます。

そこで、この問題に対応すべく、少し調べてみましたので以降に記載しておきます。

まずは、現象の条件を明確にしましょう

ここの例（サンプル記事です。）で、この問題が、少なくともWordpress3.01までは、発生しています。

いろいろと調べてみると以下のWordpressのフォーラムでも同じ問題が提起されていました。
参照記事：3.0でサブカテゴリに登録した記事をページ分割するとリダイレクトされる

先のフォーラムによれば、

パーマリンク構造をカスタム構造（/%category%/%postname%/）で使用しています。
2.9.2から3.0にバージョンアップをしたところ、サブカテゴリに登録した記事のページ分割ナビゲーションが上手くいかなくなりました。
- サブカテゴリとここで言っているのは、カテゴリの子カテゴリを言っています。

具体的には、
http://example.com/category/category2/postname/2/
という風にアクセスすると、
http://example.com/category/category2/postname/
にリダイレクトされてしまいます。

ということらしいです。実際に、自分でも確認してみました。
確かにこの現象は、上記の２つの条件があいまって発生しているようです。

さらに、

remove_action('template_redirect', 'redirect_canonical');

これをfunction.phpで実施すると、問題が回避できたそうです。

先の‘redirect_canonical’は、実際、どこで処理しているか調べてみれば、wp-includes/canonical.phpというファイルであることがわかります。結局、このファイルのどこかしら原因があって、この問題が発生しているということになるわけですね。

問題の本質を確認しましょう

次に、問題の直接的原因がどこで何をしているためかを明確にします。
先にファイルの限定ができているわけですから、あとは、ソースを追うのか、Wordpress 2.x との差分をとれば、わかると思います。

そこで、単純にコンペアして、その差分から怪しいところを見つけました。
wp-includes/canonical.phpの192行目あたりです。

		} elseif ( is_single() && strpos($wp_rewrite->permalink_structure, '%category%') !== false ) {
			$category = get_term_by('slug', get_query_var('category_name'), 'category');
			$post_terms = wp_get_object_terms($wp_query->get_queried_object_id(), 'category', array('fields' => 'tt_ids'));
			if ( (!$category || is_wp_error($category)) || ( !is_wp_error($post_terms) && !empty($post_terms) && !in_array($category->term_taxonomy_id, $post_terms) ) )
				$redirect_url = get_permalink($wp_query->get_queried_object_id());
		}

この処理は、まさしくパーマリンクに/%category%を使用している場合の処理のようです。
カテゴリのslug名からterm情報を取り出そうとして、取り出せなかったら現在の記事のパーマネントリンクアドレスへ強制的にリダイレクトしています。

ピンポーン！！

ここに違いないようですね。

つまりは、カテゴリのslug名からterm情報を取り出そうとしていることに問題があって、カテゴリは、何階層かなんて意識していないので、ここで２階層のカテゴリでNGとなってしまうんですね。

これは、ほぼ、Wordpressの問題に違いないのですが、対処が問題です。
Wordpress本家によるこの問題の対処を待つのは、ちょっと、気が長すぎますね。

じゃあ、とりあえず、このバグ？っぽいのを自前で修正するかって話ですが、できれば、避けたいですね。
だって、このルートが、この問題を引き起こしているのは間違いないのですが、ここを変更することで、現在、うまくいっているところへの影響も考えないといけなくなって、ちょっと大変です。

そこで、今回は、自前のテーマ（テンプレート）を一部変更してあげることで対応してみましょう。

問題の対処をしましょう

今回の問題は、自前のテーマ（テンプレート）の中で対処したいと思います。
結局ですね、この問題っていうのは、

http://example.com/category/category2/postname/2/
が、↓こうなちゃうのが問題なんですよね。
http://example.com/category/category2/postname/

つまり、URLの最後の（ページ番号を意味する）数値（ここでは、2）が、パラメータじゃなく、URLの通常のアドレスとして処理されるので、リダイレクトされてしまうんですよね。
※この問題の意味は、もう少し説明が必要なんですが、wp-includes/canonical.phpの処理内容を説明しないといけなくなるので、ここでは割愛します。

もっと具体的に言えば、この（ページ番号を意味する）数値を、ちゃんとパラメータだよって渡してあげるとうまくいくんですよね。

例えば、
http://example.com/category/category2/postname/2/
を、↓こんな感じで変換しちゃえばOKなんですよね。
http://example.com/category/category2/postname/?page=2

もし、同じ問題をかかえている方がおられるなら、お試しください。
最後に?page=2のようにしてあげると、ちゃんと表示できると思います。

さて、対処です。
対処するのは、自前のテーマ（テンプレート）の中でwp_link_pages();を使っている箇所を以下のように変更すればOKのはずです。

$page_link=wp_link_pages('echo=0');
if(!empty($page_link)){
	$page_link = preg_replace('/"(http:\/\/[^"]*)\/([\d]+)\/"/i','"\1/?page=\2"',$page_link);
	if(!is_null($page_link)){
		echo $page_link;
	}
}

これは、さっきの?page=2のように、単純に2という数値を取り出して、URLを置換しているだけです。

最初に示した問題の投稿ページに対して、対策を施したページは、こちらです。

どうでした？

さすがに、これは、原因究明と対処に数時間かかってしまいました。

ま、自力でもなんとか対処できるところがオープンソースの良いところでもありますけどね。

プラグインの問題は、もっと限定できるので良いですが、Wordpress本体の問題は、結構、面倒です。バージョンアップは、十分な確認の上にやりましょう。

WordPress3.0をインストールしてみる

たかちん — Tue, 26 Oct 2010 16:44:27 +0000

こんにちわ。たかちんです。

ここにきて、このサイトもWordpress3.0へアップデートしました。
Wordpress3.0は、Wordpress2.xに比べて何が変わったのか？

自分にも実感は、あまりありません。

管理画面がきれいになったのと
デフォルトのテーマ（テンプレート）がカッコよくなったのは、わかります。

ただ、メンテナンスの行われないWordpress2.xを、いつまでの使うわけにもいきませんので、Wordpress3.0をインストールしてみましょう。

※Wordpress2.xをすでにインストールしているなら、アップデート（更新）するだけで、とりあえず問題なく更新作業を終えることができました。
少なくともこの無料版XREAでは、アップデートでOKでした。