ウェブサイトの相対URL化は、環境移行やステージング作業の簡素化に繋がる重要なテクニックです。
特にWordPressのような動的なCMSでは、データベースに絶対URLが保存されるため、対応に工夫が要ります。
なぜWordPressのURLを相対化したいのか?
まず、この操作を行う目的を確認しておきましょう。WordPressは、記事内のリンクや画像パス、設定情報に絶対URL(例:https://example.com/wp-content/uploads/image.jpg)を多用します。この絶対URLは、データベース内の多数のテーブルに散りばめられています。
相対URL化のメリット
- 環境移行の手間削減: 開発環境(ステージング)から本番環境へ移行する際、データベース内のURLを一括置換する作業が不要になります。これは非常に大きな時短に繋がるでしょう。
- SSL/TLS対応の柔軟性: HTTPからHTTPSへの移行時や、その逆の場合でも、コンテンツ内のURL修正が不要になるケースが多いです。
- ドメイン変更の簡略化: 将来的にドメインを変更する可能性があっても、コンテンツの修正作業が大幅に軽減されます。
環境移行時のURL置換作業は、忘れがちでミスも発生しやすいポイントです。
相対URL化はその面倒な作業を「そもそも不要にする」という点が最大の魅力と言えるでしょう。
ob_start() を用いた相対化手法
過去にWordPressで出力されるHTML内の絶対URLを相対URLへ変換する手法として、PHPの出力バッファリング関数である ob_start() を用いる方法が広く紹介されていました。ob_start() を用いた手法の概要
テーマファイルの functions.php に ob_start() を記述し、サーバーが出力するHTMLコンテンツ全体をバッファに一旦保持します。その後、バッファ内の文字列に対し、str_replace などの関数で絶対URLを相対URLに置換して、最後にob_end_flush() で出力するという流れです。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
/* functions.php の例(非推奨) */ ob_start("relative_url"); function relative_url($output) { // 自身のドメイン名を絶対URLとして指定 $absolute_url = 'https://' . $_SERVER['HTTP_HOST']; // 絶対URLを相対パスに置換(例として 'https://example.com' を空文字に置換) $output = str_replace($absolute_url, '', $output); return $output; } |
ob_start() の方法は現在は「非推奨」
この方法は、かつては有効な手段でしたが、現代のWordPress開発においては推奨できません。- 処理のオーバーヘッド: すべてのページで出力全体に対して文字列置換を行うため、パフォーマンス低下の原因になり得ます。特に大規模サイトでは処理負荷が無視できません。
- 潜在的なバグ: PHPの出力バッファリングは、予期せぬタイミングでバッファがフラッシュされるなど、他のプラグインやテーマ機能との競合により、文字化けや予期せぬエラーを引き起こすリスクがあります。
- 部分的な適用: HTML内のすべてのURLを一律に置換するため、スクリプト(JavaScript)内で使用されているURLや、一部のメタ情報など、置換してはいけない部分まで誤って変換してしまう可能性があります。
現在のWordPressやPHPの進化に伴い、この種の「力ずくの置換」はトラブルの元ですね。
開発においては、より安全で標準的なアプローチを選択すべきです。
現在のWordPressにおいて最も安全かつ標準的な相対化アプローチ
ob_start() を使わない場合、WordPressのURLを相対的に扱うための現代的なアプローチは、主にカスタム関数またはフックを利用する方法、そしてルートパスを活用する方法の2つがあります。①テンプレートタグへのフックとフィルタ
WordPressには、投稿記事やテーマが出力する特定のURLに対して処理を加えるためのフィルターフックが用意されています。これを利用するのが最も安全な方法です。
- the_content : 記事本文内のリンクや画像URLを処理したい場合に利用。
- wp_get_attachment_url : アップロードされたメディアファイルのURLを処理したい場合に利用。
安全な相対URL化カスタム関数の作成
以下のコードを functions.php に追記し、画像やリンクのURLを相対化します。これは、対象のURLのみを選んで処理するため、ob_start() よりも遥かに安全です。|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
/ * 特定のコンテンツに含まれる絶対URLを相対URLに変換する関数 * @param string $content 処理対象のコンテンツ * @return string 相対URLに変換されたコンテンツ */ function webantenna_make_urls_relative($content) { // 自身のドメインを動的に取得 $home_url = get_home_url(); // URLを相対パスに置換 // 正規表現で、ダブルクォーテーション/シングルクォーテーションで囲まれたドメイン部分を空文字に置換 // $home_url の '/' は正規表現でエスケープが必要 $escaped_url = str_replace('/', '/', $home_url); $pattern = '/(src|href)=["']' . $escaped_url . '/'; // 置換後の文字列 (例: href="/wp-content/...") $replace = '$1=["']'; $content = preg_replace($pattern, $replace, $content); return $content; } // 投稿本文に適用するフック(最も利用頻度が高い) add_filter('the_content', 'webantenna_make_urls_relative', 999); // メディアのURLにも適用する場合 // add_filter('wp_get_attachment_url', 'webantenna_make_urls_relative', 999); |
the_content フィルターを使い、投稿・固定ページが出力される直前に処理を実行します。
正規表現を用いることで、画像やリンクタグの属性内にある自身の絶対URLのみを検出し、相対パスに変換しています。
ルートパス(/)の利用徹底
そもそも、WordPressのテンプレート内でURLを記述する際に、スラッシュ(/)から始まるルート相対パスを意識して記述することで、多くの問題は回避できます。WordPressの標準関数を利用すれば、ルート相対パスで記述することが可能です。
| 標準関数 | 出力されるURLの例 | 相対URL化への寄与 |
|---|---|---|
get_template_directory_uri() |
https://example.com/wp-content/themes/mytheme |
絶対URLが出力される |
get_template_directory() |
/var/www/html/wp-content/themes/mytheme |
サーバー上の物理パス(URLではない) |
(推奨) $template_uri = get_template_directory_uri(); の後に str_replace(get_home_url(), '', $template_uri); をかませる |
/wp-content/themes/mytheme |
ルート相対パス化 |
テンプレート内での実装例は以下のとおりです。
|
1 |
<img src="<?php echo str_replace(get_home_url(), '', get_template_directory_uri()); ?>/images/logo.png" alt="ロゴ"> |
これにより、データベース内の置換作業がなくとも、テーマやプラグインが出力するURLをルート相対パスで統一的に扱えるのです。
安全な相対化こそが2025年のベストプラクティス!
| 比較項目 | ob_start()による一括置換 | フィルターフックによる置換 | ルートパスの利用徹底 |
|---|---|---|---|
| 安全性 | 低い(予期せぬバグリスク) | 高い(対象限定で処理) | 最も高い(記述側で制御) |
| パフォーマンス | 低下しやすい(全体処理) | 影響小(部分処理) | 影響なし |
| 2025年の推奨度 | 非推奨 | 推奨 | 最も推奨 |
| 適用の範囲 | 全HTML出力 | フィルター対象コンテンツ | テンプレート記述箇所 |
ob_start() 関数を使った過去の手法は、確かに手軽でしたが、現在のモダンなWeb開発、特にWordPressの複雑な動作環境においてはリスクが大きすぎます。
2025年においては、フィルターフックやカスタム関数を用いて必要な箇所だけを安全に相対化するか、テンプレート記述の段階でルート相対パスの利用を徹底するアプローチが、保守性、安全性、パフォーマンスの観点から最善の選択と言えるでしょう。


コメント