• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

「パーマリンクの使い方」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(続き一部訳/言語間リンク追加)
(少しだけ和訳追加/要更新・要和訳)
1行目: 1行目:
原文・最新版: [[:en:Using Permalinks|WordPress Codex » Using Permalinks]]
+
{{NeedTrans|途中から}}
 +
{{Old}}
  
 
__TOC__
 
__TOC__
  
パーマリンクとは、ブログの個々の投稿記事、カテゴリなどの記事一覧ページへの恒久的(半永久的)な URL です。パーマリンクは、他のブロガーがあなたの記事(やセクション)について触れるときや、あなたの記事へのリンクを Eメールで送ったりするときに使います。特に、個々の記事へリンクを張られることを考えれば、一度記事を投稿したら、その記事への URL は常に存在して決して変らないようにすべきです。そういう訳で、''perma'' リンクといいます。
+
パーマリンクとは、ブログの個々の投稿記事、カテゴリなどの記事一覧ページへの恒久的(半永久的)な URL です。パーマリンクは、他のブロガーがあなたの記事(やセクション)について触れるときや、あなたの記事へのリンクを Eメールで送ったりするときに使います。特に、個々の記事へリンクを張られることを考えれば、一度記事を投稿したら、その記事への URL は常に存在して決して変らないようにすべきです。そういう訳で、「perma」リンクといいます。
  
 +
<div id="Permalink_Types">
 
== パーマリンクの形式 ==
 
== パーマリンクの形式 ==
(Permalink Types)
+
</div>
  
 
WordPress の基本的なパーマリンク形式 3種類:
 
WordPress の基本的なパーマリンク形式 3種類:
  
 +
<div id="Default:_.22Ugly.22">
 
=== デフォルト: "Ugly" ===
 
=== デフォルト: "Ugly" ===
(Default: "Ugly")
+
</div>
  
 
デフォルトでは、記事番号が <code>N</code> のときに <pre>http://example.com/?p=N</pre> のようになります。全てのサーバ環境で動くように、新規インストール時のデフォルトはこうなっています。しかしながら、他のオプションが付くと見苦しくなるので好ましくありません。<!-- 「他のオプション」の例を書く。2ページ目とか検索とか? -->
 
デフォルトでは、記事番号が <code>N</code> のときに <pre>http://example.com/?p=N</pre> のようになります。全てのサーバ環境で動くように、新規インストール時のデフォルトはこうなっています。しかしながら、他のオプションが付くと見苦しくなるので好ましくありません。<!-- 「他のオプション」の例を書く。2ページ目とか検索とか? -->
  
 +
<div id="mod_rewrite:_.22Pretty_Permalinks.22">
 
=== mod_rewrite: "Pretty Permalinks" ===
 
=== mod_rewrite: "Pretty Permalinks" ===
 +
</div>
  
 
理想的なパーマリンクです<!-- the holy grail of permalinks -->。フォーマットは様々ですが、最も一般的で万能なのは次のような形です。
 
理想的なパーマリンクです<!-- the holy grail of permalinks -->。フォーマットは様々ですが、最も一般的で万能なのは次のような形です。
25行目: 30行目:
 
<code>mod_rewrite</code> パーマリンクには '''Apache の <code>mod_rewrite</code> モジュール'''が必要です。これがないサーバ環境の WordPress では使えません。[[Introduction_to_Blogging#Pretty_Permalinks|Pretty Permalinks]] もご覧ください。
 
<code>mod_rewrite</code> パーマリンクには '''Apache の <code>mod_rewrite</code> モジュール'''が必要です。これがないサーバ環境の WordPress では使えません。[[Introduction_to_Blogging#Pretty_Permalinks|Pretty Permalinks]] もご覧ください。
  
 +
<div id="PATHINFO:_.22Almost_Pretty.22">
 
=== <small>PATHINFO</small>: "Almost Pretty" ===
 
=== <small>PATHINFO</small>: "Almost Pretty" ===
 +
</div>
  
 
<code>PATHINFO</code> パーマリンクは、<code>mod_rewrite</code> パーマリンクによく似ていますが、例外的なものです<!-- but for one exception -->。これは、<pre>http://example.com/index.php/yyyy/mm/dd/post-name/</pre>のように、途中に <code>/index.php</code> が挿入されます。それ以外は "pretty" <code>mod_rewrite</code> と変わりなく、柔軟さも同じです。<code>mod_rewrite</code> パーマリンクができることは、<code>/index.php</code> の部分のおかげで <code>PATHINFO</code> パーマリンクでも可能です。
 
<code>PATHINFO</code> パーマリンクは、<code>mod_rewrite</code> パーマリンクによく似ていますが、例外的なものです<!-- but for one exception -->。これは、<pre>http://example.com/index.php/yyyy/mm/dd/post-name/</pre>のように、途中に <code>/index.php</code> が挿入されます。それ以外は "pretty" <code>mod_rewrite</code> と変わりなく、柔軟さも同じです。<code>mod_rewrite</code> パーマリンクができることは、<code>/index.php</code> の部分のおかげで <code>PATHINFO</code> パーマリンクでも可能です。
31行目: 38行目:
 
(mod_rewrite モジュールが使えないサーバ用?)
 
(mod_rewrite モジュールが使えないサーバ用?)
  
 +
<div id="Structure_Tags">
 
== 構成タグ ==
 
== 構成タグ ==
(Structure Tags)
+
</div>
  
 
"Pretty" と "Almost Pretty" パーマリンクのカスタマイズには、次のタグが使えます。
 
"Pretty" と "Almost Pretty" パーマリンクのカスタマイズには、次のタグが使えます。
48行目: 56行目:
 
これらのパーマリンクはほとんどのシステムで問題なく動作しますが、問題が生じる環境もあります。
 
これらのパーマリンクはほとんどのシステムで問題なく動作しますが、問題が生じる環境もあります。
  
 +
<div id="Using_only_.25postname.25">
 
=== <code>%postname%</code> のみの使用 ===  
 
=== <code>%postname%</code> のみの使用 ===  
(Using only <code>%postname%</code>)
+
</div>
  
 
パーマリンクを <code>myblog.com/post-title</code> といった構成にするために <code>%postname%</code> だけを使う場合、(これと似た URI 形式の)スタイルシートや <code>/wp-admin/</code> ディレクトリといったページへアクセスできるリライトルールにしなくてはなりません<!-- If you use postname as the only element in your permalinks to create a structure such as myblog.com/post-title, the rewrite rules may make it impossible to access pages such as your stylesheet (which has a similar format) or the <tt style="font-weight:bold; color:#036">/wp-admin/</tt> folder. -->。この問題を防ぐには、パーマリンクに何らかの数値データ(例えば 記事ID や日付)を含めるのが最適です。加えて、WordPress v1.2.x では、カレンダーのようないくつかの機能を正常に機能させるために、日付構造の使用が必須です。このようなときにも <code>/%year%/%monthnum%/%day%/%postname%/</code> はいい選択です。
 
パーマリンクを <code>myblog.com/post-title</code> といった構成にするために <code>%postname%</code> だけを使う場合、(これと似た URI 形式の)スタイルシートや <code>/wp-admin/</code> ディレクトリといったページへアクセスできるリライトルールにしなくてはなりません<!-- If you use postname as the only element in your permalinks to create a structure such as myblog.com/post-title, the rewrite rules may make it impossible to access pages such as your stylesheet (which has a similar format) or the <tt style="font-weight:bold; color:#036">/wp-admin/</tt> folder. -->。この問題を防ぐには、パーマリンクに何らかの数値データ(例えば 記事ID や日付)を含めるのが最適です。加えて、WordPress v1.2.x では、カレンダーのようないくつかの機能を正常に機能させるために、日付構造の使用が必須です。このようなときにも <code>/%year%/%monthnum%/%day%/%postname%/</code> はいい選択です。
 
<!-- 実ファイルを使う URI と記事のパーマリンク URI が一致すると、片方(たぶん実ファイル)にしかアクセスできない。%postname% だけ使ったときの URI 文字列は、実ファイルの URI に似た形なので、URI が一致する可能性が高くなる。<code>%postname%</code> の値が偶然実ファイル名と同じだった場合など。-->
 
<!-- 実ファイルを使う URI と記事のパーマリンク URI が一致すると、片方(たぶん実ファイル)にしかアクセスできない。%postname% だけ使ったときの URI 文字列は、実ファイルの URI に似た形なので、URI が一致する可能性が高くなる。<code>%postname%</code> の値が偶然実ファイル名と同じだった場合など。-->
  
 +
<div id="">
 
=== Apache ver.1.x と <code>%category%</code> ===
 
=== Apache ver.1.x と <code>%category%</code> ===
(Using <code>%category%</code>)
+
</div>
  
 
Apache の 2 より前のバージョンでは、mod_rewrite の''一部の実装''上、<code>%category%</code> が正しく動作しません(%category% does not work correctly with ''some implementations'' of mod_rewrite in Apache versions prior to version 2.)。Apache 1 を使っていて <code>%category%</code> の使用で問題が起きたら、パーマリンク構造に <code>%category%</code> を使わないようにするか、[http://isaacschlueter.com/plugins/i-made/lucky-13-rewrite/ Schlueterica's plugin] を参照してください。
 
Apache の 2 より前のバージョンでは、mod_rewrite の''一部の実装''上、<code>%category%</code> が正しく動作しません(%category% does not work correctly with ''some implementations'' of mod_rewrite in Apache versions prior to version 2.)。Apache 1 を使っていて <code>%category%</code> の使用で問題が起きたら、パーマリンク構造に <code>%category%</code> を使わないようにするか、[http://isaacschlueter.com/plugins/i-made/lucky-13-rewrite/ Schlueterica's plugin] を参照してください。
  
 +
<div id="Using_.25category.25_with_multiple_categories_on_a_post">
 
=== 複数カテゴリにした投稿記事の <code>%category%</code> ===
 
=== 複数カテゴリにした投稿記事の <code>%category%</code> ===
(Using <code>%category%</code> with multiple categories on a post)
+
</div>
  
 
一つの投稿に複数カテゴリを指定していても、パーマリンクには一つしか表示できません。一番小さいカテゴリ ID([[Manage_Categories_SubPanel|カテゴリ管理]] 参照)が使われます。アクセスはどのカテゴリからでも普通にできます。
 
一つの投稿に複数カテゴリを指定していても、パーマリンクには一つしか表示できません。一番小さいカテゴリ ID([[Manage_Categories_SubPanel|カテゴリ管理]] 参照)が使われます。アクセスはどのカテゴリからでも普通にできます。
 
<!-- 同レベルのカテゴリの話? -->
 
<!-- 同レベルのカテゴリの話? -->
  
 +
<div id="Properly_terminating_permalinks">
 
=== パーマリンクの末尾には記事名かID が必須 ===
 
=== パーマリンクの末尾には記事名かID が必須 ===
(Properly terminating permalinks)
+
</div>
  
 
カスタム URI を用いたときに、個々の記事へのパーマリンクを保証することは重要です。パーマリンク構造の最後には、必ず <code>%post_id%</code> か <code>%postname%</code> のどちらかを付けてください。(これがないと個別記事を示す文字列が URI から抜けることになり、記事にアクセスできない。)
 
カスタム URI を用いたときに、個々の記事へのパーマリンクを保証することは重要です。パーマリンク構造の最後には、必ず <code>%post_id%</code> か <code>%postname%</code> のどちらかを付けてください。(これがないと個別記事を示す文字列が URI から抜けることになり、記事にアクセスできない。)
  
 +
<div id="Where.27s_my_.htaccess_file.3F">
 
== <code>.htaccess</code> ファイルはどこ? ==
 
== <code>.htaccess</code> ファイルはどこ? ==
(Where's my <code>.htaccess</code> file?)
+
</div>
  
 
<code>.htaccess</code> ファイルは、一般オプション設定パネルの「ブログ・アドレス (URI)」のディレクトリにあります。ファイル名が「.」で始まるため、FTP クライアントソフトウェアで隠しファイルを含む全ファイルを表示するように設定していないと、ファイルが見えないかもしれません。
 
<code>.htaccess</code> ファイルは、一般オプション設定パネルの「ブログ・アドレス (URI)」のディレクトリにあります。ファイル名が「.」で始まるため、FTP クライアントソフトウェアで隠しファイルを含む全ファイルを表示するように設定していないと、ファイルが見えないかもしれません。
77行目: 90行目:
 
それでも <code>.htaccess</code> ファイルがない場合は、新たに作成してください。シェルや SSH でサーバへアクセスしているなら、単純に <pre>touch .htaccess</pre> コマンドでファイルを作ります。ファイル転送に FTP を使っているなら、ローカルコンピュータに <code>1.htaccess</code> という名前のファイルを作成して、WordPress ディレクトリ(のルート)へアップロードしてから、<code>.htaccess</code> へリネームします。このファイルの編集方法については、以下のセクションをお読みください。
 
それでも <code>.htaccess</code> ファイルがない場合は、新たに作成してください。シェルや SSH でサーバへアクセスしているなら、単純に <pre>touch .htaccess</pre> コマンドでファイルを作ります。ファイル転送に FTP を使っているなら、ローカルコンピュータに <code>1.htaccess</code> という名前のファイルを作成して、WordPress ディレクトリ(のルート)へアップロードしてから、<code>.htaccess</code> へリネームします。このファイルの編集方法については、以下のセクションをお読みください。
  
 +
<div id="">
 
== リライトルールの作成(<code>.htaccess</code>) ==
 
== リライトルールの作成(<code>.htaccess</code>) ==
(Creating Rewrite Rules (<code>.htaccess</code>))
+
</div>
  
 
パーマリンクの書き換えには、サーバに <code>[[用語集#mod_rewrite|mod_rewrite]]</code> が必要です。さらに、<code>[[用語集#.htaccess|.htaccess]]</code> ファイルを作成して WordPress のメイン index.php ファイルが存在するディレクトリに置いておくか、WordPress がファイルを自動作成できるようにこのディレクトリを書き込み可能にしておかなければなりません。例えば、WordPress を <code>domain.com/wordpress/</code> にインストールしたなら、<code>.htaccess</code> ファイルは <code>domain.com/wordpress/.htaccess</code> に置きます。しかし、[[Giving WordPress Its Own Directory|WordPress をサブディレクトリに設置しておいて、サイトへの訪問者はドメインのトップレベルにアクセスするようにしている場合]]は、ドメインのルート <code>domain.com/.htaccess</code> に置きます。
 
パーマリンクの書き換えには、サーバに <code>[[用語集#mod_rewrite|mod_rewrite]]</code> が必要です。さらに、<code>[[用語集#.htaccess|.htaccess]]</code> ファイルを作成して WordPress のメイン index.php ファイルが存在するディレクトリに置いておくか、WordPress がファイルを自動作成できるようにこのディレクトリを書き込み可能にしておかなければなりません。例えば、WordPress を <code>domain.com/wordpress/</code> にインストールしたなら、<code>.htaccess</code> ファイルは <code>domain.com/wordpress/.htaccess</code> に置きます。しかし、[[Giving WordPress Its Own Directory|WordPress をサブディレクトリに設置しておいて、サイトへの訪問者はドメインのトップレベルにアクセスするようにしている場合]]は、ドメインのルート <code>domain.com/.htaccess</code> に置きます。
85行目: 99行目:
  
 
<code>.htaccess</code> ファイル作成・編集についての注意:
 
<code>.htaccess</code> ファイル作成・編集についての注意:
* WordPress will play nice with an existing <tt style="font-weight:bold; color:#036">.htaccess</tt> and will not delete your existing rules
+
* WordPress は既存の <code>.htaccess</code> は上手く処理できますが、既存のルールの削除はできません。
* If you have other mod_rewrite rules, they should go before WordPress' rules, [http://www.askapache.com/htaccess/mod_rewrite-tips-and-tricks.html see this advanced mod_rewrite tutorial].
+
* もし、他の mod_rewrite ルールを定義しているなら、WordPress のルールを実行する前に [http://www.askapache.com/htaccess/mod_rewrite-tips-and-tricks.html この advanced mod_rewrite tutorial をお読みください]
* You must have FTP or SSH access to create the <tt style="font-weight:bold; color:#036">.htaccess</tt> file
+
* <code>.htaccess</code> ファイルの作成は、FTP か SSH アクセスで行なってください。
* You must [[Changing File Permissions|<tt style="font-weight:bold; color:#036">chmod</tt>]] the <tt style="font-weight:bold; color:#036">.htaccess</tt> file to 666 to allow WordPress to write its rules to it automatically. After applying the permalinks, you should change the permissions to something stronger like 660 or 644 to prevent others on the server from potentially having access to it.
+
* 自動的に WordPress にリライトルールを書き換えさせるには、<code>.htaccess</code> ファイルのパーミッションを [[Changing File Permissions|<code>chmod</code>]] 666 にしておいてください。 After applying the permalinks, you should change the permissions to something stronger like 660 or 644 to prevent others on the server from potentially having access to it.
 
* If your <tt style="font-weight:bold; color:#036">.htaccess</tt> file contains errors that bring down your site, you will need to use FTP or your host's [[Using cPanel|control panel]] to delete the rogue <tt style="font-weight:bold; color:#036">.htaccess</tt> file. Once a fatal change has been saved in the WordPress editor, the editor (along with the rest of your site) will not be available until the problem is fixed.
 
* If your <tt style="font-weight:bold; color:#036">.htaccess</tt> file contains errors that bring down your site, you will need to use FTP or your host's [[Using cPanel|control panel]] to delete the rogue <tt style="font-weight:bold; color:#036">.htaccess</tt> file. Once a fatal change has been saved in the WordPress editor, the editor (along with the rest of your site) will not be available until the problem is fixed.
 
* You may also be able to use your host's [[Using cPanel|control panel]] to create and edit the <tt style="font-weight:bold; color:#036">.htaccess</tt> file. If so, it is likely you will still be able to edit the <tt style="font-weight:bold; color:#036">.htaccess</tt> file through this method, even if errors in the file have brought down your site itself.
 
* You may also be able to use your host's [[Using cPanel|control panel]] to create and edit the <tt style="font-weight:bold; color:#036">.htaccess</tt> file. If so, it is likely you will still be able to edit the <tt style="font-weight:bold; color:#036">.htaccess</tt> file through this method, even if errors in the file have brought down your site itself.
 
* Because of the previous item, it is recommended that you make small changes to <tt style="font-weight:bold; color:#036">.htaccess</tt> saving frequently, and testing your site.  That way, you'll know when you've made a mistake, and will be able to quickly roll the change back by editing the file via FTP
 
* Because of the previous item, it is recommended that you make small changes to <tt style="font-weight:bold; color:#036">.htaccess</tt> saving frequently, and testing your site.  That way, you'll know when you've made a mistake, and will be able to quickly roll the change back by editing the file via FTP
  
 +
<div id="Using_Permalinks_Without_mod_rewrite">
 
== mod_rewrite なしでのパーマリンクの設定 ==
 
== mod_rewrite なしでのパーマリンクの設定 ==
(Using Permalinks Without mod_rewrite)
+
</div>
  
For cruftless permalinks, you must use <tt style="font-weight:bold; color:#036">[[Glossary#mod_rewrite|mod_rewrite]]</tt>, and IIS (common on Windows servers) does not support <tt style="font-weight:bold; color:#036">mod_rewrite</tt>. If you are using Apache 2.0.54, on Windows, mod_rewrite may work. If you put a filename at the beginning, WordPress will attempt to use that to pass the arguments and bypass the necessity for <tt style="font-weight:bold; color:#036">mod_rewrite</tt>.
+
For cruftless permalinks, you must use <tt style="font-weight:bold; color:#036">[[用語集#mod_rewrite|mod_rewrite]]</tt>, and IIS (common on Windows servers) does not support <tt style="font-weight:bold; color:#036">mod_rewrite</tt>. If you are using Apache 2.0.54, on Windows, mod_rewrite may work. If you put a filename at the beginning, WordPress will attempt to use that to pass the arguments and bypass the necessity for <tt style="font-weight:bold; color:#036">mod_rewrite</tt>.
 
<pre>
 
<pre>
 
  /index.php/%year%/%monthnum%/%day%/%postname%/
 
  /index.php/%year%/%monthnum%/%day%/%postname%/
122行目: 137行目:
 
[http://www.deanlee.cn/wordpress/url-rewriting-for-wordpress-under-iis/ URL Rewriting for WordPress under IIS] by Dean Lee
 
[http://www.deanlee.cn/wordpress/url-rewriting-for-wordpress-under-iis/ URL Rewriting for WordPress under IIS] by Dean Lee
  
 
+
<div id="Fixing_Permalink_Problems">
 
+
 
== パーマリンクについての問題点と対処法 ==
 
== パーマリンクについての問題点と対処法 ==
(Fixing Permalink Problems)
+
</div>
  
 +
<div id="Fixing_.htaccess_Generation_Issues">
 
=== <code>.htaccess</code> 生成時の問題 ===
 
=== <code>.htaccess</code> 生成時の問題 ===
(Fixing <code>.htaccess</code> Generation Issues)
+
</div>
  
 
If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this. Work step by step and continue to the next step only if the previous step does not work.
 
If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this. Work step by step and continue to the next step only if the previous step does not work.
142行目: 157行目:
 
</ul>
 
</ul>
  
 +
<div id="Permalinks.2C_.htaccess.2C_and_MS_Frontpage">
 
=== パーマリンクと .htaccess と マイクロソフト・フロントページ ===
 
=== パーマリンクと .htaccess と マイクロソフト・フロントページ ===
(Permalinks, .htaccess, and MS Frontpage)
+
</div>
  
 
A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with <tt style="font-weight:bold; color:#036">mod_frontpage</tt> compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the <tt style="font-weight:bold; color:#036">httpd.conf</tt> file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because <tt style="font-weight:bold; color:#036">extensions/mod_frontpage</tt> exist on your server.   
 
A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with <tt style="font-weight:bold; color:#036">mod_frontpage</tt> compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the <tt style="font-weight:bold; color:#036">httpd.conf</tt> file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because <tt style="font-weight:bold; color:#036">extensions/mod_frontpage</tt> exist on your server.   
152行目: 168行目:
 
<tt style="font-weight:bold; color:#036">mod_rewrite</tt> rules to the .htaccess file. ''There is however now a fix for this situation.''
 
<tt style="font-weight:bold; color:#036">mod_rewrite</tt> rules to the .htaccess file. ''There is however now a fix for this situation.''
  
 +
<div id="Quick_Fixes.2C_Frontpage_or_Permalinks">
 
==== Quick Fixes, Frontpage or Permalinks ====
 
==== Quick Fixes, Frontpage or Permalinks ====
 +
</div>
  
 
'''Frontpage Extensions Fix:''' If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the wordpress section with the rewrite rules.  
 
'''Frontpage Extensions Fix:''' If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the wordpress section with the rewrite rules.  
160行目: 178行目:
 
You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the wordpress mod_rewrite code.  
 
You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the wordpress mod_rewrite code.  
  
 +
<div id="Using_Frontpage_AND_Permalinks_Together">
 
==== Using Frontpage AND Permalinks Together ====
 
==== Using Frontpage AND Permalinks Together ====
 +
</div>
  
 
'''Finally, A solution.'''
 
'''Finally, A solution.'''
191行目: 211行目:
 
Edit and save each <tt style="font-weight:bold; color:#036">.htaccess</tt> file and you're done. Now everyhting works perfectly, including MS Frontpage, AND the permalinks of your choosing.
 
Edit and save each <tt style="font-weight:bold; color:#036">.htaccess</tt> file and you're done. Now everyhting works perfectly, including MS Frontpage, AND the permalinks of your choosing.
  
 +
<div id="A_Final_Note">
 
==== A Final Note ====
 
==== A Final Note ====
 +
</div>
  
 
On a personal note, I prefer to use Frontpage to manage/maintain sites, I've been using it since around '96, and by now, since I do most work on UNIX servers anyway I have it configured to use external editors for just about everything, including Zend Studio for php files, Bradbury TopStyle for stylesheets, Adobe ImageReady/Photoshop for images, etc. I'm more or less just using Frontpage as a convenient way to manage the site and access everything, etc. Then when I hit the "save" button in any of the other applications, they have Frontpage save my changes directly to the server, with no need to be FTP'ing files around, etc. It does help to get lots accomplished very quickly, and I was pretty bummed for the past year or so with the permalink frustration, since I was either needing to not use permalinks or not use Frontpage, or keep re-installing the FP extensions. At one point I found a way to make a .htaccess for my "running" site, but then change it to a FP .htaccess when I was doing any work (permalinks of course didn't work), either way it was a real pain.  
 
On a personal note, I prefer to use Frontpage to manage/maintain sites, I've been using it since around '96, and by now, since I do most work on UNIX servers anyway I have it configured to use external editors for just about everything, including Zend Studio for php files, Bradbury TopStyle for stylesheets, Adobe ImageReady/Photoshop for images, etc. I'm more or less just using Frontpage as a convenient way to manage the site and access everything, etc. Then when I hit the "save" button in any of the other applications, they have Frontpage save my changes directly to the server, with no need to be FTP'ing files around, etc. It does help to get lots accomplished very quickly, and I was pretty bummed for the past year or so with the permalink frustration, since I was either needing to not use permalinks or not use Frontpage, or keep re-installing the FP extensions. At one point I found a way to make a .htaccess for my "running" site, but then change it to a FP .htaccess when I was doing any work (permalinks of course didn't work), either way it was a real pain.  
199行目: 221行目:
 
--[[User:Chradil|Chradil]] 17:24, 17 May 2006 (GMT)
 
--[[User:Chradil|Chradil]] 17:24, 17 May 2006 (GMT)
  
 +
<div id="Long_Permalinks">
 
=== 長いパーマリンク ===
 
=== 長いパーマリンク ===
(Long Permalinks)
+
</div>
  
 
When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.
 
When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.
233行目: 256行目:
 
Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.
 
Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.
  
 +
<div id="Fixing_Other_Issues">
 
=== その他の問題点 ===
 
=== その他の問題点 ===
(Fixing Other Issues)
+
</div>
  
 
If your <tt style="font-weight:bold; color:#036">.htaccess</tt> file is being generated correctly, but Permalinks still do not function, the following might be a problem.  If problems persist, post a note in the [http://www.wordpress.org/support WordPress Forum's] How To section.
 
If your <tt style="font-weight:bold; color:#036">.htaccess</tt> file is being generated correctly, but Permalinks still do not function, the following might be a problem.  If problems persist, post a note in the [http://www.wordpress.org/support WordPress Forum's] How To section.
287行目: 311行目:
 
:If that still doesn't work, take a look at the wordpress support forums, specifically, [http://wordpress.org/support/topic/51613#post-283222 this support post].
 
:If that still doesn't work, take a look at the wordpress support forums, specifically, [http://wordpress.org/support/topic/51613#post-283222 this support post].
  
;「ページ」へのパーマリンクが効かない (Permalinks to pages don't work) :If you've tried to navigate to a newly created [[Glossary#Page|Page]] and encounter an error, you likely need to [[Permalinks_Options_SubPanel|update your Permalink structure]]. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to <tt style="font-weight:bold; color:#036">.htaccess</tt> (WordPress 1.X) or to the internal rewrites array (WordPress 2.X).
+
;「ページ」へのパーマリンクが効かない (Permalinks to pages don't work) :If you've tried to navigate to a newly created [[用語集#Page|Page]] and encounter an error, you likely need to [[Permalinks_Options_SubPanel|update your Permalink structure]]. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to <tt style="font-weight:bold; color:#036">.htaccess</tt> (WordPress 1.X) or to the internal rewrites array (WordPress 2.X).
  
 
;Ultimate Tag Warrior のタグページへのパーマリンクが効かない (Permalinks to Ultimate Tag Warrior tag pages don't work) :If you get 404 errors on local tag URLs when using the UltimateTagWarrior plugin on WordPress 2.X, it's because the internal rewrites generated by WordPress are being overly greedy and getting invoked before UTW's rewrite rules have a chance. This usually occurs only when using a custom permalink structure (like <tt style="font-weight:bold; color:#036">/%postname%/</tt>). To fix it, either [[Permalinks_Options_SubPanel|switch your Permalink structure]] to "Date and name based" or hack the UTW plugin to place the UTW rewrites at the top of the internal rewrites array. [http://www.naturalsearchblog.com/archives/2007/01/20/getting-404-errors-on-ultimate-tag-warrior/ More Info on this].
 
;Ultimate Tag Warrior のタグページへのパーマリンクが効かない (Permalinks to Ultimate Tag Warrior tag pages don't work) :If you get 404 errors on local tag URLs when using the UltimateTagWarrior plugin on WordPress 2.X, it's because the internal rewrites generated by WordPress are being overly greedy and getting invoked before UTW's rewrite rules have a chance. This usually occurs only when using a custom permalink structure (like <tt style="font-weight:bold; color:#036">/%postname%/</tt>). To fix it, either [[Permalinks_Options_SubPanel|switch your Permalink structure]] to "Date and name based" or hack the UTW plugin to place the UTW rewrites at the top of the internal rewrites array. [http://www.naturalsearchblog.com/archives/2007/01/20/getting-404-errors-on-ultimate-tag-warrior/ More Info on this].
293行目: 317行目:
 
;パーマリンクは動作・ページが存在しないと返される (Permalinks work but no pages are returned) :Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.
 
;パーマリンクは動作・ページが存在しないと返される (Permalinks work but no pages are returned) :Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.
  
 +
<div id="More_Help">
 
=== その他のヘルプ ===
 
=== その他のヘルプ ===
(More Help)
+
</div>
  
If these steps do not work, search for your problem in the [http://codex.wordpress.org Codex], [[Troubleshooting]], or in the [http://wordpress.org/support/ Support Forum]. As a last resort, [[Submitting_Bugs|file a bug report]].
+
If these steps do not work, search for your problem in the [http://codex.wordpress.org Codex], [[トラブルシューティング]], or in the [http://wordpress.org/support/ Support Forum]. As a last resort, [[Submitting_Bugs|file a bug report]].
  
 +
<div id="Tips_and_Tricks">
 
== ヒントと小技 ==
 
== ヒントと小技 ==
(Tips and Tricks)
+
</div>
  
 +
<div id="Having_your_posts_end_in_.html">
 
=== 投稿記事の末尾に <code>.html</code> を付けるには ===
 
=== 投稿記事の末尾に <code>.html</code> を付けるには ===
(Having your posts end in <code>.html</code>
+
</div>
 
 
 
 
 
There's an easy way to having your posts end in a <tt style="font-weight:bold; color:#036">.html</tt> extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:
 
There's an easy way to having your posts end in a <tt style="font-weight:bold; color:#036">.html</tt> extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:
310行目: 337行目:
 
Note that this does not generate actual <tt>.html</tt> files.  It is only an illusion.  There is no benefit to this... some people mistakenly think it offers search engine benefits, and some want their permalinks to emulate those of another publishing system.
 
Note that this does not generate actual <tt>.html</tt> files.  It is only an illusion.  There is no benefit to this... some people mistakenly think it offers search engine benefits, and some want their permalinks to emulate those of another publishing system.
  
 +
<div id="External_Resources">
 
== 外部資料 ==
 
== 外部資料 ==
(External Resources)
+
</div>
  
 
* [http://www.cypherhackz.net/archives/2007/03/25/beautify-your-urls-with-permalinks/ Beautify your URLs with Permalinks]
 
* [http://www.cypherhackz.net/archives/2007/03/25/beautify-your-urls-with-permalinks/ Beautify your URLs with Permalinks]
321行目: 349行目:
 
* [http://www.htaccesselite.com/htaccess/ mod_rewrite and htaccess help forum]
 
* [http://www.htaccesselite.com/htaccess/ mod_rewrite and htaccess help forum]
 
* [http://www.micronovae.com/ModRewrite/articles/CleanPermalinks.html Clean Permalinks for IIS using .htaccess]
 
* [http://www.micronovae.com/ModRewrite/articles/CleanPermalinks.html Clean Permalinks for IIS using .htaccess]
 +
 +
{{原文|Using Permalinks|39433}}
  
 
{{DEFAULTSORT:はあまりんくのつかいかた}}
 
{{DEFAULTSORT:はあまりんくのつかいかた}}
329行目: 359行目:
  
 
[[en:Using Permalinks]]
 
[[en:Using Permalinks]]
[[ja:Using Permalinks]]
 
 
[[es:Using Permalinks]]
 
[[es:Using Permalinks]]
 
[[it:UsingPermalink]]
 
[[it:UsingPermalink]]

2008年4月3日 (木) 03:55時点における版

このページ「パーマリンクの使い方」は途中から未翻訳です。和訳や日本語情報を加筆してくださる協力者を求めています

このページ「パーマリンクの使い方」は 情報が古くなっている可能性があります。最新版英語)も合わせてご覧ください。最新に更新してくださる協力者を求めています

パーマリンクとは、ブログの個々の投稿記事、カテゴリなどの記事一覧ページへの恒久的(半永久的)な URL です。パーマリンクは、他のブロガーがあなたの記事(やセクション)について触れるときや、あなたの記事へのリンクを Eメールで送ったりするときに使います。特に、個々の記事へリンクを張られることを考えれば、一度記事を投稿したら、その記事への URL は常に存在して決して変らないようにすべきです。そういう訳で、「perma」リンクといいます。

WordPress の基本的なパーマリンク形式 3種類:

デフォルト: "Ugly"

デフォルトでは、記事番号が N のときに
http://example.com/?p=N
のようになります。全てのサーバ環境で動くように、新規インストール時のデフォルトはこうなっています。しかしながら、他のオプションが付くと見苦しくなるので好ましくありません。

mod_rewrite: "Pretty Permalinks"

理想的なパーマリンクです。フォーマットは様々ですが、最も一般的で万能なのは次のような形です。

http://example.com/category/post-name/

or

http://example.com/year/month/day/post-name

短いパーマリンクにするために、日付の要素(日・月・年)の全部か一部を取り除く人もいます。

mod_rewrite パーマリンクには Apache の mod_rewrite モジュールが必要です。これがないサーバ環境の WordPress では使えません。Pretty Permalinks もご覧ください。

PATHINFO: "Almost Pretty"

PATHINFO パーマリンクは、mod_rewrite パーマリンクによく似ていますが、例外的なものです。これは、
http://example.com/index.php/yyyy/mm/dd/post-name/
のように、途中に /index.php が挿入されます。それ以外は "pretty" mod_rewrite と変わりなく、柔軟さも同じです。mod_rewrite パーマリンクができることは、/index.php の部分のおかげで PATHINFO パーマリンクでも可能です。

(mod_rewrite モジュールが使えないサーバ用?)

構成タグ

"Pretty" と "Almost Pretty" パーマリンクのカスタマイズには、次のタグが使えます。

%year% 
投稿年・4桁 (例)2004
%monthnum% 
投稿月 (例)05
%day% 
投稿日 (例)28
%hour% 
投稿時刻の「時」(hour) (例)15
%minute% 
分 (例)43
%second% 
秒 (例)33
%postname% 
投稿タイトルの簡潔版=投稿スラッグ。タイトル「This Is A Great Post!」だったら URI は「this-is-a-great-post」になります。下記注釈参照。
%post_id% 
投稿の一意な ID 番号(例)423
%category% 
カテゴリ名の簡潔版=カテゴリスラッグ。入れ子であるサブカテゴリは、URI でも入れ子のディレクトリとして表されます。
%author% 
著者名の簡潔版

これらのパーマリンクはほとんどのシステムで問題なく動作しますが、問題が生じる環境もあります。

%postname% のみの使用

パーマリンクを myblog.com/post-title といった構成にするために %postname% だけを使う場合、(これと似た URI 形式の)スタイルシートや /wp-admin/ ディレクトリといったページへアクセスできるリライトルールにしなくてはなりません。この問題を防ぐには、パーマリンクに何らかの数値データ(例えば 記事ID や日付)を含めるのが最適です。加えて、WordPress v1.2.x では、カレンダーのようないくつかの機能を正常に機能させるために、日付構造の使用が必須です。このようなときにも /%year%/%monthnum%/%day%/%postname%/ はいい選択です。

Apache ver.1.x と %category%

Apache の 2 より前のバージョンでは、mod_rewrite の一部の実装上、%category% が正しく動作しません(%category% does not work correctly with some implementations of mod_rewrite in Apache versions prior to version 2.)。Apache 1 を使っていて %category% の使用で問題が起きたら、パーマリンク構造に %category% を使わないようにするか、Schlueterica's plugin を参照してください。

複数カテゴリにした投稿記事の %category%

一つの投稿に複数カテゴリを指定していても、パーマリンクには一つしか表示できません。一番小さいカテゴリ ID(カテゴリ管理 参照)が使われます。アクセスはどのカテゴリからでも普通にできます。

カスタム URI を用いたときに、個々の記事へのパーマリンクを保証することは重要です。パーマリンク構造の最後には、必ず %post_id%%postname% のどちらかを付けてください。(これがないと個別記事を示す文字列が URI から抜けることになり、記事にアクセスできない。)

.htaccess ファイルはどこ?

.htaccess ファイルは、一般オプション設定パネルの「ブログ・アドレス (URI)」のディレクトリにあります。ファイル名が「.」で始まるため、FTP クライアントソフトウェアで隠しファイルを含む全ファイルを表示するように設定していないと、ファイルが見えないかもしれません。

それでも .htaccess ファイルがない場合は、新たに作成してください。シェルや SSH でサーバへアクセスしているなら、単純に
touch .htaccess
コマンドでファイルを作ります。ファイル転送に FTP を使っているなら、ローカルコンピュータに 1.htaccess という名前のファイルを作成して、WordPress ディレクトリ(のルート)へアップロードしてから、.htaccess へリネームします。このファイルの編集方法については、以下のセクションをお読みください。

リライトルールの作成(.htaccess

パーマリンクの書き換えには、サーバに mod_rewrite が必要です。さらに、.htaccess ファイルを作成して WordPress のメイン index.php ファイルが存在するディレクトリに置いておくか、WordPress がファイルを自動作成できるようにこのディレクトリを書き込み可能にしておかなければなりません。例えば、WordPress を domain.com/wordpress/ にインストールしたなら、.htaccess ファイルは domain.com/wordpress/.htaccess に置きます。しかし、WordPress をサブディレクトリに設置しておいて、サイトへの訪問者はドメインのトップレベルにアクセスするようにしている場合は、ドメインのルート domain.com/.htaccess に置きます。

管理パネルでパーマリンク構造を作成したとき、WordPress はリライトルールを生成し、適切な位置にある .htaccess ファイルの中にそのコードを書き込もうとします。書き込めなかった場合、あなたが自分で .htaccess ファイルにコピー&ペーストできるように、リライトルールのコードが画面に表示されます。

.htaccess ファイル作成・編集についての注意:

  • WordPress は既存の .htaccess は上手く処理できますが、既存のルールの削除はできません。
  • もし、他の mod_rewrite ルールを定義しているなら、WordPress のルールを実行する前に この advanced mod_rewrite tutorial をお読みください
  • .htaccess ファイルの作成は、FTP か SSH アクセスで行なってください。
  • 自動的に WordPress にリライトルールを書き換えさせるには、.htaccess ファイルのパーミッションを chmod で 666 にしておいてください。 After applying the permalinks, you should change the permissions to something stronger like 660 or 644 to prevent others on the server from potentially having access to it.
  • If your .htaccess file contains errors that bring down your site, you will need to use FTP or your host's control panel to delete the rogue .htaccess file. Once a fatal change has been saved in the WordPress editor, the editor (along with the rest of your site) will not be available until the problem is fixed.
  • You may also be able to use your host's control panel to create and edit the .htaccess file. If so, it is likely you will still be able to edit the .htaccess file through this method, even if errors in the file have brought down your site itself.
  • Because of the previous item, it is recommended that you make small changes to .htaccess saving frequently, and testing your site. That way, you'll know when you've made a mistake, and will be able to quickly roll the change back by editing the file via FTP

For cruftless permalinks, you must use mod_rewrite, and IIS (common on Windows servers) does not support mod_rewrite. If you are using Apache 2.0.54, on Windows, mod_rewrite may work. If you put a filename at the beginning, WordPress will attempt to use that to pass the arguments and bypass the necessity for mod_rewrite.

 /index.php/%year%/%monthnum%/%day%/%postname%/

If you use this option, you can ignore the rewrite rules (that is, you can ignore .htaccess).

  • This option may not always work, especially in cases of WordPress running on IIS 6. To make this option work on IIS, add these 2 lines to a php.ini file and store that file in your webroot:
 cgi.fix_pathinfo = 1
 cgi.force_redirect = 0

This reference from Cem.

Another solution exists using IIS' custom 404 redirects. It requires that your web host allows you to add a custom 404 redirect, but it doesn't require you to install any 3rd party mod_rewrite software and it also doesn't require that your permalink structure begin with /index.php/...

Here is the link to the installation files and instructions:

http://www.keyboardface.com/IIS-Permalinks/

If you have administrator privileges on your server, you may be interested in these solutions:

WordPress URL Rewrite Plugin for blogs running on IIS by Binary Fortress Software

URL Rewriting for WordPress under IIS by Dean Lee

.htaccess 生成時の問題

If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this. Work step by step and continue to the next step only if the previous step does not work.

  1. Change File Permissions: You must chmod the .htaccess file to 666 to edit it with the WordPress template editor, but this is not recommended, since if you do that, any user of your blog, who can edit templates will be able to edit it. You can change the permissions to 660 to make it server-writable, which again will have the same limitation.
  2. Server Blockage: Your host might have blocked the SERVER_SOFTWARE variable and this will cause WordPress' .htaccess generation to fail. If you are sure that your server is running Apache, you can force WordPress to believe that your server is running Apache by changing your wp-includes/vars.php file. Follow the steps below to implement these changes.
  • Open the wp-includes/vars.php file using the built in file editor in your WordPress Admin panel. To navigate to this panel, login to WordPress, click on "Manage", then on "Files", scroll to the bottom and type in wp-includes/vars.php into the text box under the "Other Files" title.
  • Look for
    $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
    and replace it with
    // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
  • Add a new line under
    // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
    and type in
    $is_apache = 1;

パーマリンクと .htaccess と マイクロソフト・フロントページ

A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with mod_frontpage compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the httpd.conf file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because extensions/mod_frontpage exist on your server.

Wordpress will operate correctly with the Frontpage Extensions installed, however permalinks will not function at all and ANY change to the permalinks section from the Wordpress admin interface will cause corruption of the Frontpage server extensions due to the addition of the mod_rewrite rules to the .htaccess file. There is however now a fix for this situation.

Frontpage Extensions Fix: If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the wordpress section with the rewrite rules.

To Use Permalinks: If you don't care about Frontpage(but your hosting company has the extensions installed)

You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the wordpress mod_rewrite code.

Finally, A solution.

There have been a number of threads on this issue in the support forums, and until now, no solution to the problem.

Normally, on a Unix server with the Microsoft Frontpage Server extensions installed wordpress works just fine and you are able to edit and publish pages (with MS Frontpage) - UNTIL - you make a change to the permalinks (for example to the date based kind that I like /2005/04/etc). I often suggest that type of URI to folks asking about permalinks etc, as that is the method recommended by the w3c (see http://www.w3.org/Provider/Style/URI ).

Now, the problem is that MS Frontpage uses the .htaccess file (which the wordpress mod_rewrite rules must go into) for it's "publishing" and "web authoring" configuration. As soon as the wordpress mod_rewrite code is added to the file, two things happen — the permalinks don't work and the MS Frontpage Server extensions become corrupted.

I have tried countless ways to get around this, including trying to use rewrite rules that "ignore" the %{HTTP_USERAGENT)% used by Frontpage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked so that a person would be able to both use MS Frontpage to manage the website and use the permalinks for wordpress at the same time.

The solution is acctually quite simple, and I kind of figured it out by accident.

If you are using or wish to use MS Frontpage (or that's just how your hosting company has things configured) along with wordpress you'll need to take the following simple steps on your server (or have your hosting company do it for you).

MS Frontpage creates the following directory

_vti_bin
Nested within that it creates both
_vti_adm
and
_vti_aut

In addition to in your website (or wordpress) root folder in all of those directories you will find additional .htaccess files.

In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:

Options +FollowSymlinks

There may or may not already be a line in each like

Options None

Edit and save each .htaccess file and you're done. Now everyhting works perfectly, including MS Frontpage, AND the permalinks of your choosing.

A Final Note

On a personal note, I prefer to use Frontpage to manage/maintain sites, I've been using it since around '96, and by now, since I do most work on UNIX servers anyway I have it configured to use external editors for just about everything, including Zend Studio for php files, Bradbury TopStyle for stylesheets, Adobe ImageReady/Photoshop for images, etc. I'm more or less just using Frontpage as a convenient way to manage the site and access everything, etc. Then when I hit the "save" button in any of the other applications, they have Frontpage save my changes directly to the server, with no need to be FTP'ing files around, etc. It does help to get lots accomplished very quickly, and I was pretty bummed for the past year or so with the permalink frustration, since I was either needing to not use permalinks or not use Frontpage, or keep re-installing the FP extensions. At one point I found a way to make a .htaccess for my "running" site, but then change it to a FP .htaccess when I was doing any work (permalinks of course didn't work), either way it was a real pain.

This should work with most versions of FP and most of the unix versions of the extensions in use today.

--Chradil 17:24, 17 May 2006 (GMT)

When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

Can result in:

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

To click on the lower link, the user would get a 404 Page Not Found Error. If you have a tendency to use very long permalink post titles, take these steps to prevent this problem.

1. Check that you are indeed using Permalinks.

2. Edit your .htaccess file and add the following:

 RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]

3. Test it. Find a post's ID number and type the following (with your information) in your browser and you should be redirected to your post:

http://yourdomain.example.com/post/(the ID #)

It is also worth noting that most email software will not cut off URLs that have been delineated with angle-brackets (< and >), so when pasting URLs into emails, you should write them as so:

Read my blog post at <http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog>

Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.

その他の問題点

If your .htaccess file is being generated correctly, but Permalinks still do not function, the following might be a problem. If problems persist, post a note in the WordPress Forum's How To section.

AllowOverride が無効 (AllowOverride Not Enabled) 
Your server may not have the AllowOverride directive enabled. If the AllowOverride directive is set to None in your Apache httpd.config file, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem. When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. Example of enabled AllowOverride directive in httpd.config:
 <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

You may also have to enable the AllowOverride directive in your DocumentRoot:

 <Directory /var/www/html>
    # ... other directives...
    AllowOverride All
 </Directory>
You may also have to change the AllowOverride settings for the site. This is surely the case when using Mac OS X Server, but might be likewise with other systems. Usually you can find the site configuration files in /etc/httpd/sites/
If you don't want to set AllowOverride to all (as it is above) then your AllowOverride list must include the FileInfo directive. You must restart your Apache server for any httpd.config file changes to take effect. For more information on which overrides are allowed, read about Apache Core Features.
ページナビゲーションが動かない (Paged Navigation Doesn't Work) 
Sometimes navigation to second (and subsequent) pages of posts does not work as expected. Your page may generate a link to a page with one of these URIs:
 http://www.example.com/page/2/
 http://www.example.name/category/categoryname/page/2/
 http://www.example/year/month/day/page/2/
 http://www.example/year/month/page/2/
The result of clicking one of those links is that the page loads with all the surroundings (header, footer, sidebar), but instead of a page of posts, there is an error message: "Sorry, no posts match that criteria."
This is due to a glitch in the .htaccess file that WordPress generates. To fix it, delete the contents of your .htaccess file and re-create it.
  1. In the Control Panel, go to Manage > Files (More Info on Editing Files)
  2. Click the link to your .htaccess file to edit its contents
  3. Copy the contents of the file and paste it to a text file in a text editor. This is a precaution in case your .htaccess file has manual entries for redirects, denials or other handy htaccess tricks
  4. Delete all contents from your .htaccess file and click the Update File button.
  5. In the Control Panel, go to Options > Permalinks.
  6. Click the Update Permalink Structure button to freshly generate new rewrite rules for your permalinks.
  7. Test the results using a link that had previously broken.
  8. Add any manual htaccess entries back in your file (Place manual htaccess entries before the # BEGIN WordPress or after # END WordPress lines.)
You may also perform similar steps by deleting the .htaccess files from the server, creating a fresh empty .htaccess file, changing its permissions to 666, and then in Options > Permalinks generate a new set of htaccess rules by clicking the Update Permalinks Structure button.
If that still doesn't work, take a look at the wordpress support forums, specifically, this support post.
「ページ」へのパーマリンクが効かない (Permalinks to pages don't work) 
If you've tried to navigate to a newly created Page and encounter an error, you likely need to update your Permalink structure. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to .htaccess (WordPress 1.X) or to the internal rewrites array (WordPress 2.X).
Ultimate Tag Warrior のタグページへのパーマリンクが効かない (Permalinks to Ultimate Tag Warrior tag pages don't work) 
If you get 404 errors on local tag URLs when using the UltimateTagWarrior plugin on WordPress 2.X, it's because the internal rewrites generated by WordPress are being overly greedy and getting invoked before UTW's rewrite rules have a chance. This usually occurs only when using a custom permalink structure (like /%postname%/). To fix it, either switch your Permalink structure to "Date and name based" or hack the UTW plugin to place the UTW rewrites at the top of the internal rewrites array. More Info on this.
パーマリンクは動作・ページが存在しないと返される (Permalinks work but no pages are returned) 
Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.

その他のヘルプ

If these steps do not work, search for your problem in the Codex, トラブルシューティング, or in the Support Forum. As a last resort, file a bug report.

ヒントと小技

投稿記事の末尾に .html を付けるには

There's an easy way to having your posts end in a .html extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:

 /%year%/%monthnum%/%day%/%postname%.html

Note that this does not generate actual .html files. It is only an illusion. There is no benefit to this... some people mistakenly think it offers search engine benefits, and some want their permalinks to emulate those of another publishing system.

外部資料

最新英語版: WordPress Codex » Using Permalinks最新版との差分