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

Wordpressでは、HTMLで記述しても、自動整形(wpautop)機能があるので、brタグや、pタグが自動で付加され、自分が思っていた画面イメージと異なることがあります。
そういった場合、ほとんどの方は、自身のテンプレート（テーマ）内のfunctions.phpに以下の１文を加えることで対応していることと思います。

remove_filter('the_content', 'wpautop');

これでも十分なのですが、これでも、実際には、記事の編集画面で、HTMLのタブを選んでもbrタグや、pタグがなどは、自動的に付加されることがあります。
これを完全に停止させるのが、今回のプラグイン PS Disable Auto Formatting です。

まずは、Revision Control をインストール

インストールは、簡単ですよね。ネットから直接でOK。
もちろん、あえてZIPファイルが欲しいなら、以下のダウンロード先からダウンロードして、アップしてもOKです。
ダウンロード先：http://www.web-strategy.jp/wp_plugin/ps_disable_auto_formatting/

1. 管理画面のプラグインから新規追加を選択し、検索キーワードにPS Disable Auto Formattingを入力し、検索ボタンをクリックします。

   
   
   

2. 検索結果が表示されます。その中のPS Disable Auto Formattingのいますぐインストールをクリックします。

   
   

3. インストールが完了したら、プラグインの有効化をクリックして、有効にしておきましょう。

   
   

4. 有効が完了したら、管理画面の設定から自動整形をクリックしてみてください。以下のような設定画面が表示されればOK。

   
   
   

自動整形の詳細を設定する

先の管理画面の設定から自動整形をクリックして表示された管理画面で、自動整形の詳細設定を行うことができます。

デフォルトでは、
記事内容の自動整形 のみ停止となっています。

以下の項目毎に、それぞれ自動整形を停止することができます。

• 記事内容の自動整形
• コメントの自動整形
• 抜粋の自動整形
• 説明（カテゴリー、リンクなど）の自動整形

また、さらには、今まで編集してきた記事を一括整形処理することもできます。

• 整形処理時限
  - ここに更新日時を設定します。ここで設定した更新日時以前の記事に対して一括整形処理を実施します。
• 一括整形処理を許可
  - ここにチェックを入れます。

問題なければ、最後に、一括整形処理ボタンをクリックします。

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

Wordpressでパンくずリスト（リンク）を表示するためのプラグインと言えば、Breadcrumb NavXTが超有名です。
このBreadcrumb NavXTの使い方は、いたって簡単で、インストールしてヘッダなどに以下のコードを埋めこむだけで、表示している記事名＋カテゴリ名を階層順に表示してくれます。

if(function_exists('bcn_display'))
{
	bcn_display();
}

このプラグインが、どうもアップデートするとうまくいかないよういなので、少し記事にまとめることにしました。

問題の現象？

どうもWordpress 3.0.1 での症状のようで、Wordpressの更新でこのプラグインを最新版へアップデートすると、以下のような現象が発生します。

• パンくずリスト上にルートと表示中ページのみ表示される。
  ※通常は、カテゴリもルートと記事の間に表示されるはずですが、表示されません。
  
• プラグイン設定画面の情報が一部保存できない。
  ※Breadcrumb NavXT 3.6.0で新たに追加されたパラメータ？あたりが保存できない？みたいです。
  

参照記事 : Breadcrumb NavXT 3.6.0 Auto Upgrade Warning

問題の原因？

上記の参照記事のとおりです。
要は、Wordpress 3.0.1で更新した場合、プラグインで正しく有効・無効が動かないらしい・・・です。

問題の対処？

上記の原因から、正しくプラグインの有効・無効動作を実施すればOKですね。

要は、Breadcrumb NavXT を、一旦、無効にして、有効にしてねってことですね。

どうもBreadcrumb NavXT 3.6.0ではデータを変更したらしいので、無効にして、有効した場合、うまく古いデータを更新できていないかもしれないらしいので、以前のデータが壊れていないかチェックが必要みたいです。

自分の場合、カテゴリがすっかり表示されなくなっていました。全く気付かず、１か月以上経過してしまっていました。
調べてみると、やっぱり問題になってましたね。

データが壊れたケースはありませんでしたが、先の対処でうまくいかなかったサイトもありました。
その場合、アンインストールして、再度、新しいBreadcrumb NavXTプラグインをインストールしたら、うまくいきました。

Wordpressは、ユーザが多いので何か問題があっても検索すると、だいたい出てきますから、安心感もありますよね。
これがマイナーなCMSだと、そうはいかないんですよね。ほとんど自力で解析するはめになりますから、時間がかかって仕方がありません。

そういう意味でもWordpressっておすすめですよね。

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

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

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

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

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

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

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

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

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

<link rel='prev' title='カテゴリごとにテンプレートを切り替える' href='http://wordpress.server-domain.info/setting/category_template.html' />
<link rel='next' title='WordPressのデータベースをバックアップする' href='http://wordpress.server-domain.info/setting/backup_restore.html' />

ちょっともったいぶってすみません。ただ、これだけです。
単純に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');

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

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

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を使っていると、記事を更新するたびに履歴が残っているのをご存じでしょうか？
この履歴が残っているおかげで、もし、仮にも違って記事を修正してももとに戻すことができます。（自分は、ほとんどこの機能を使ったことはありませんが・・。 ）


そそっかしい方には、便利な機能です。
しかし、その履歴を残すために自動バックアップが、編集の最中に動作することがあります。
これは、XREAのような非力なサーバーには、つらい時があります。

今回は、非力なレンタルサーバーのために、このリビジョン（履歴）を停止するプラグイン Revision Control を紹介します。

まずは、Revision Control をインストール

インストールは、簡単ですよね。ネットから直接でOK。
もちろん、あえてZIPファイルが欲しいなら、以下のダウンロード先からダウンロードして、アップしてもOKです。
ダウンロード先：Revision Control

1. 管理画面のプラグインから新規追加を選択し、検索キーワードにRevision Controlを入力し、検索ボタンをクリックします。

   
   
   

2. 検索結果が表示されます。その中のRevision Controlのいますぐインストールをクリックします。

   
   
   

3. インストールが完了したら、プラグインの有効化をクリックして、有効にしておきましょう。

   
   
   

4. 有効が完了したら、管理画面の設定からリビジョンをクリックしてみてください。以下のような設定画面が表示されればOK。

   
   
   

リビジョンの管理条件を設定する

先の管理画面の設定からリビジョンをクリックして表示された管理画面で、リビジョン（履歴）の管理条件を設定できます。

デフォルトでは、

投稿：リビジョン最大保存数: 無制限
固定ページ：リビジョン最大保存数: 無制限

となっています。

全てのリビジョンを保存しない場合は、

投稿：投稿リビジョンを保存しない
固定ページ：投稿リビジョンを保存しない

とすればOKです。

設定を終えて、最後に変更を保存をクリックします。

先の記事の履歴画面は、以下のように１つになってしましました。以降、この記事を編集しても履歴は、作成されなくなります。最新の履歴情報が１つだけ存在するようになります。

また、各記事ごとにリビジョン（履歴）の保存の仕方を変更したい場合は、上記の画面右下のコンボボックスから、変更した条件を選択し、更新をクリックします。

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

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

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

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

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

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

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

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

$ mysqldump -hzzzz -uxxxx -pyyyy nnnn   > 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<meta name="generator" content="WordPress 3.0.1" />
<link rel="pingback" href="http://wordpress.server-domain.info/xmlrpc.php" />
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://wordpress.server-domain.info/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://wordpress.server-domain.info/wp-includes/wlwmanifest.xml" />

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

generator の意味

<meta name="generator" content="WordPress 3.0.1" />

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

pingback の意味

<link rel="pingback" href="http://wordpress.server-domain.info/xmlrpc.php" />

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

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

EditURI の意味

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://wordpress.server-domain.info/xmlrpc.php?rsd" />

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

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

wlwmanifest の意味

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://wordpress.server-domain.info/wp-includes/wlwmanifest.xml" />

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

削除の仕方

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

generator を削除

<meta name="generator" content="WordPress 3.0.1" />

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

remove_action('wp_head', 'wp_generator');

これだけです。

pingback を削除

<link rel="pingback" href="http://wordpress.server-domain.info/xmlrpc.php" />

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

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

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

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

<link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />

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

EditURI を削除

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://wordpress.server-domain.info/xmlrpc.php?rsd" />

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

remove_action('wp_head', 'rsd_link');

これだけです。

wlwmanifest を削除

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://wordpress.server-domain.info/wp-includes/wlwmanifest.xml" />

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

remove_action('wp_head', 'wlwmanifest_link');

これだけです。

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

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

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

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

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

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

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

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

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


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

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

1
2
3
4
5

これは、テンプレートごとのテスト用テンプレートです。<br />
<?php if (have_posts()) : while (have_posts()) : the_post();  ?>
<h1><?php the_title(); ?></h1>
<?php the_content('続きを読む'); ?>
<?php endwhile; endif; ?>

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

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12

<?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で記述している箇所を変更してください。

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

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

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

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

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

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

Wordpressを使っていると、細かいことをやりたくなるたびにプラグインが必要になってきます。
でも、ほとんどの場合、求めているプラグインは、Googleさんが探してくれます。 なんとも便利ですね。

今回の「記事ごとにテンプレートを切り替えるプラグイン」もGoogleさんでヒントをもらって、wordpress.orgで検索をかけるって、感じで探し当てました。
ダウンロード先：Custom Post Template

このプラグインは、表題のとおり、各記事ごとにテンプレートファイルを切り替えることができます。
もともと、各ページごとには、テンプレートファイルを切り替えることができるのですから、できそうな感じなのですが、記事ごとに必要か？なんて考えたら、必要な人は限られてくるんでしょうね。
それで、デフォルトの機能じゃなくってプラグインとなるんでしょうけどね。

今回は、Custom Post Templateを使ってみます。

まずは、インストール

インストールは、簡単ですよね。ネットから直接でOK。
もちろん、あえてZIPファイルが欲しいなら、先のダウンロード先からダウンロードして、アップしてもOKです。
ダウンロード先：Custom Post Template

1. 管理画面のプラグインから新規追加を選択し、検索キーワードにCustom Post Templateを入力し、検索ボタンをクリックします。

   
   

2. 検索結果が表示されます。その中のCustom Post Templateのいますぐインストールをクリックします。

   
   

3. インストールが完了したら、プラグインの有効化をクリックして、有効にしておきましょう。

   
   

特別なテンプレートを作ってみましょう

テスト用に特別なテンプレートを作ってみましょう。

1
2
3
4
5
6
7
8
9

<?php
/*
Template Name Posts: Post Template Test Page
*/
?>
これは、テスト用テンプレートです。<br />
<?php the_post(); ?>
<h1><?php the_title(); ?></h1>
<?php the_content(''); ?>

3行目のように、必ず、テンプレート名（ここでは、Post Template Test Page）を記述しないといけません。
以降は、通常のテンプレートと同じように記述できます。

ここでは、単純にタイトルと記事の内容を出力するようにしています。

これを適当な名前（ここでは、index_test.phpとしましょう）で現在利用しているテーマディレクトリに保存します。
例えば、/wp-content/themes/あなたのテーマ名/ のような名前の直下に保存します。

特別なテンプレートを使う記事を投稿してみましょう

ここまでできたら、あとは、記事を投稿するだけです。

記事の投稿画面の右下を見てみてください。

このようにPost Template というウィジェットが追加表示されているはずです。
ここで、先に作成したテンプレート名が、コンボボックスに表示されるはずですので、それを選択します。（ここでは、Post Template Test Page）

記事の編集を終えたら、公開しましょう。

この表示すると、以下のように表示されます。

実際の記事は、こちら です。

簡単ですね。ページの個別テンプレートと同じ方法です。

ページの個別テンプレートは、デフォルトで動作しますので、テンプレート名を記述するところが、

1 2 3 4 5 6 7

<?php /* Template Name: ページテンプレート名 */ ?> : :

のようにTemplate Name Postsが、Template Nameとなるだけですね。

まだまだ、テンプレートの切り替えには、いろんな切り替えがあります。たとえば、カテゴリごとにテンプレートを切り替えることもできます。Wordpressは、奥が深いですね。

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

最近、XREA（このサーバー）を使い倒しているわけですが、
XREAって、本当になんでも来いって感じで、やりたいことが、ほとんど実現できるのがうれしいです。

無料版の場合、やっぱり、それなりにうまくいかないときは、調べたりするのに時間がかかったりしますけど。

今回は、無料版XREAでWordpressを使っていると、302 Foundが表示されて、正しい記事が表示されないことがあるのを発見しました。
この対処方法を、簡単に解説します。

現象は？

現象は、よくあることで、Wordpressでは、いろんなアクセス方法（アドレス）があります。
実際にパーマリンク設定で、いろいろとアドレスを設定できますが、デフォルトのアドレスは、常に有効なんですね。

パーマリンク設定をデフォルトのhttp://wordpress.server-domain.info/?p=123と設定している場合、

http://wordpress.server-domain.info/?p=123

パーマリンク設定を/%category%/%postname%と設定している場合、

http://wordpress.server-domain.info/category1/post123

というアドレスでアクセスできるようになります。しかし、ここで注意しなければいけないのは、上記のデフォルトのアドレスでもアクセスできることです。

つまり、 パーマリンク設定を/%category%/%postname%と設定していても

http://wordpress.server-domain.info/?p=123

で同じ記事をアクセスできるんですね。

無料XREAの場合、
パーマリンク設定を/%category%/%postname%と設定していて、デフォルトのhttp://wordpress.server-domain.info/?p=123でアクセスすると

302 Found

と表示されて正しい記事へ移動できないんですね。

対処方法は？

この対処方法は、簡単です。
.htaccessに以下の１文を追記します。

LayoutIgnoreURI index.php

どうですか？
たぶん、Wordpressでのリダイレクト問題は、これで回避できたのではないでしょうか。

そもそも、この現象は、広告を表示するために引き起こされた問題のようで、

index.phpは、CGIで、広告の対象外だよ

って宣言することで回避できるのだそうです。

わかっていれば、そんなものか・・・というものですけどね。

この問題は、自分は、ちょっと、躓きました。
何が悪いのか・・・。ちょっと、検討がつかない状況で、わかるまでに時間がかかってしまいました。

少しでも同じ問題でお悩みの方の助けになれば幸いです。