Lightsail上のWordPressで静的HTMLファイルを効果的かつ安全に扱うための包括的解説
- 1. はじめに
- 2. AWS Lightsail WordPress環境の理解
- 3. HTMLファイルのアップロードと表示方法
- 4. HTML表示方法の比較 (詳細)
- 5. セキュリティのベストプラクティスと考慮事項
- 6. ニーズに合わせた最適な方法の選択
- 7. まとめ
1. はじめに
1.1. ユーザーの目的の確認
本レポートは、AWS Lightsail上で運用されているWordPressサイトにおいて、ユーザーがHTMLファイルを簡単にアップロードし、ウェブサイト上で効果的に表示させるための具体的な方法を包括的に解説することを目的とします。ユーザーが求める「簡単な運用」とは、単に手順が少ないことだけでなく、技術的な複雑さを抑えつつも、多様なニーズ(例:完全な静的ページ、既存コンテンツへの一部埋め込み)に対応できる選択肢と、それぞれの背景にある仕組みを理解することを指すと解釈します。HTMLファイルの用途やユーザーの技術習熟度によって、「簡単」の定義は変わるため、本レポートではこれらの異なる「簡単さ」の側面をカバーし、それぞれの方法がどのような場合に適しているかを示します。
1.2. 本レポートで解説する主な方法の概要
静的なHTMLページ全体をサーバーに直接配置して公開する方法から、WordPressの投稿やページ内にHTMLコードの一部(スニペット)を埋め込む方法、さらにはプラグインやテーマのカスタマイズを活用する方法まで、段階的に複数のアプローチを紹介します。具体的には、SFTP (Secure File Transfer Protocol) を利用したファイルアップロード、WordPressのブロックエディタ(Gutenberg)やクラシックエディタの機能、各種プラグインの利用、そしてカスタムページテンプレートの作成といった手法を詳述します。各手法のメリット・デメリットを明らかにし、特にAWS Lightsail (Bitnami WordPressスタック) 環境特有のファイル構造やパーミッション設定、そして最も重要なセキュリティ上の考慮事項についても深く掘り下げて解説します。HTMLファイルをWordPressサイトに統合する方法の選択は、サイトの将来的なメンテナンス性、拡張性、そしてセキュリティ体制に直接影響するため、初期の「簡単さ」だけでなく、長期的な運用を見据えた判断が重要です。
1.3. Lightsail + WordPress環境の特性
AWS Lightsailで提供されるWordPress環境の多くは、Bitnamiによってパッケージングされたスタックを利用しています。このスタックは、特定のファイルシステム構造(例: /opt/bitnami/wordpress/
がWordPressのルートとなる)や、デフォルトのユーザー・グループ、パーミッション設定を持っています 。これらを理解することが、トラブルなくHTMLファイルを運用する上での基礎となります。セキュリティと利便性のバランスは、特に外部のHTMLコンテンツを扱う際に重要です。WordPress自身のセキュリティ機能(KSESフィルタリングなど)と、サーバーレベルのセキュリティ設定(ファイルパーミッションなど)の両方を考慮した運用が求められることを強調します。
2. AWS Lightsail WordPress環境の理解
2.1. Lightsail上のBitnami WordPressファイル構造の要点
Bitnami WordPressスタックでは、WordPressアプリケーションの主要なファイル群は /opt/bitnami/wordpress/
ディレクトリ以下に配置されるのが標準です。このパスは、ユーザーがHTMLファイルや関連アセットをサーバー上のどこに配置すべきかを判断する際の絶対的な基準点となります。このルートディレクトリ内には、wp-config.php
のようなWordPressの設定ファイル、wp-content
(テーマ、プラグイン、アップロードされたメディアファイルが格納される)、wp-admin
、wp-includes
といったコアディレクトリが含まれます。
カスタムHTMLコンテンツを配置する場合、WordPressのコア構造と衝突せず、かつWebサーバーからアクセス可能な場所を選ぶ必要があります。一般的には、/opt/bitnami/wordpress/
直下に新しいサブディレクトリを作成する方法が推奨されます。Bitnamiのファイル構造とパーミッション設定は、セキュリティとWordPressの正常な動作を両立させるために最適化されています。ユーザーがカスタムHTMLを配置する際は、この既存の枠組みを尊重し、逸脱する場合はその影響を十分に理解する必要があります。
2.2. ファイル管理におけるSFTPアクセスの重要性
SFTPは、ローカルコンピュータからLightsailインスタンス内のファイルシステムへ安全にファイルを転送するための基本的なプロトコルです。HTMLファイルだけでなく、それに付随するCSS、JavaScript、画像ファイルなどをアップロード・管理する際に不可欠な手段となります。
接続には、インスタンスのパブリックIPアドレス、SFTPユーザー名(Bitnami環境では通常 bitnami
)、そしてSSH秘密キーが必要です。この秘密キーは、Lightsailコンソールからダウンロードできます。FileZilla、Cyberduck、WinSCP などのSFTPクライアントソフトウェアが一般的に利用されます。
2.3. パーミッションの基本
Linuxベースのサーバー環境では、ファイルやディレクトリごとに読み取り (r)、書き込み (w)、実行 (x) の権限が、所有者、グループ、その他のユーザーに対して設定されます。これらのパーミッションは、セキュリティとWebサーバーによるファイルへのアクセス可否を決定する上で極めて重要です。
Bitnami WordPressスタックでは、ファイルの所有者は通常 bitnami
ユーザー、グループは daemon
グループとして設定されています。デフォルトのパーミッションは、ディレクトリが 775
(所有者とグループに読み取り・書き込み・実行権限、その他に読み取り・実行権限)、ファイルが 664
(所有者とグループに読み取り・書き込み権限、その他に読み取り権限) となっていることが多いです。カスタムHTMLファイルやディレクトリを配置する際も、これらの標準的なパーミッション設定に倣うことが推奨されます。SFTPでファイルをアップロードする行為自体は簡単でも、その後のパーミッション設定を誤ると、ファイルが表示されない、またはセキュリティリスクが生じるという直接的な結果につながります。特に、bitnami
ユーザーでアップロードした後、Webサーバープロセス(通常 daemon
グループで実行)がファイルを読み取れるように、グループパーミッションが適切に設定されているか確認が必要です。
/opt/bitnami/wordpress/
配下にカスタムディレクトリを作成してHTMLを配置する場合、Apacheのデフォルト設定であれば、特別な設定変更なしにそのディレクトリ以下のファイルにURLで直接アクセスできる可能性が高いです。これは、WordPressのルーティングシステムを経由しないため、純粋な静的コンテンツとして高速に提供できるメリットがありますが、WordPressの機能(ユーザー認証、プラグインによるアクセス制御など)の恩恵は受けられません。
3. HTMLファイルのアップロードと表示方法
方法1:スタンドアロンHTMLページのためのSFTP経由での直接アップロード
この方法は、WordPressのテーマやデータベースから完全に独立した静的HTMLページを公開するのに最も適しています。WordPressの処理を介さないため表示速度が速い可能性があります。
3.1.1. LightsailインスタンスへのSFTP接続手順 (FileZilla例)
- ホスト(H): LightsailインスタンスのパブリックIPアドレスを入力します。
- ユーザー名(U):
bitnami
と入力します。 - プロトコル: SFTP – SSH File Transfer Protocol を選択します。
- ログオンの種類(L): 「キーファイル」を選択します。
- キーファイル(K): LightsailコンソールからダウンロードしたSSH秘密キーファイル(.pem形式など)を指定します。
これらの情報を入力し、「接続」をクリックします。初めて接続する際には、ホストキーの確認を求められることがあります。
3.1.2. カスタムHTMLファイル用の推奨ディレクトリ
WordPressのコアファイル群 (wp-admin
, wp-includes
など) や既存のテーマ・プラグインディレクトリを避け、WordPressのルートディレクトリである /opt/bitnami/wordpress/
内に、静的HTMLコンテンツ専用の新しいサブディレクトリを作成することを強く推奨します。例えば、/opt/bitnami/wordpress/static-content/
や /opt/bitnami/wordpress/my-custom-pages/
といった命名が良いでしょう。このアプローチにより、WordPress本体のアップデートによる影響を受けにくく、コンテンツの管理も容易になります。
3.1.3. 適切なファイルおよびディレクトリパーミッションの設定
アップロード後、作成したカスタムディレクトリには 755
(またはBitnami標準の775
)、HTMLファイルやCSS/JS/画像ファイルには 644
(またはBitnami標準の664
) のパーミッションを設定します。これにより、所有者とグループが必要な操作を行え、かつWebサーバーがファイルを読み取れるようになります。ファイルの所有者とグループは bitnami:daemon
に設定することが一貫性があり、推奨されます。
# SSH経由でのパーミッション設定コマンド例
sudo chown bitnami:daemon -R /opt/bitnami/wordpress/your-custom-directory/
sudo find /opt/bitnami/wordpress/your-custom-directory/ -type d -exec chmod 755 {} \;
sudo find /opt/bitnami/wordpress/your-custom-directory/ -type f -exec chmod 644 {} \;
3.1.4. 直接URLによるHTMLファイルへのアクセス
上記のディレクトリ作成とパーミッション設定が正しく行われていれば、HTMLファイルは http://yourdomain.com/your-custom-directory/yourfile.html
のようなURLでブラウザから直接アクセス可能になります。もし、ディレクトリ内に index.html
という名前のファイルを配置した場合、http://yourdomain.com/your-custom-directory/
のようにディレクトリ名までのURLでアクセスすると、その index.html
が表示されるのが一般的です。
3.1.5. 関連するCSS/JS/画像ファイルの取り扱い
HTMLファイルが外部のCSS、JavaScriptファイル、画像ファイルを参照している場合、これらのアセットファイルもHTMLファイルと同じサーバーの適切な場所にアップロードする必要があります。最も管理しやすいのは、HTMLファイルと同じディレクトリ、またはその中に css
, js
, images
といったサブディレクトリを作成し、そこに各アセットを格納する方法です。HTMLファイル内では、これらのアセットに対して相対パス (例: <link rel="stylesheet" href="css/style.css">
, <img src="images/photo.jpg">
) でリンクします。
このSFTP直接アップロード方法は、WordPressの複雑なテーマシステムやデータベース処理を介さずに、純粋なHTMLページを迅速に公開したい場合に最も「簡単」かつ効率的なアプローチと言えます。特に、LP(ランディングページ)や、WordPressとは構造的に独立させたい小規模な静的サイト部分の運用に適しています。
方法2:WordPress機能を利用したHTMLコンテンツの表示
3.2.1. オプションA:投稿・ページへのHTMLスニペットの埋め込み
WordPressの投稿やページ内に、部分的なHTMLコード(スニペット)を埋め込む方法です。サイト全体のデザインはWordPressテーマに依存しつつ、特定の箇所にカスタムHTMLを挿入したい場合に利用します。
- GutenbergエディタのカスタムHTMLブロックの使用: 現在のWordPress標準エディタであるGutenberg(ブロックエディタ)には、「カスタムHTML」という専用ブロックが用意されています。投稿やページの編集画面でこのブロックを追加し、任意のHTMLコードを直接入力またはペーストすることで、その場所にHTMLをレンダリングできます。
- クラシックエディタのテキストモードの使用: もし旧来のクラシックエディタを使用している場合、またはGutenbergエディタ内で「クラシックブロック」を使用している場合は、「ビジュアル」タブの隣にある「テキスト」(または「HTML」)タブに切り替えることで、HTMLソースコードを直接編集・挿入できます。
セキュリティ:WordPress KSESフィルタリング、unfiltered_html権限、ユーザーロールによる影響
WordPressはセキュリティを重視しており、投稿やページに保存されるHTMLコンテンツに対してKSES (KSES Strips Evil Scripts) という強力なフィルタリング処理を適用します。この処理は、許可されていないHTMLタグや属性、特にクロスサイトスクリプティング(XSS)の原因となりうる危険なコード(例: <script>
タグ、JavaScriptイベントハンドラ属性 onclick
や onerror
など)を自動的に除去または無害化します。
WordPressには unfiltered_html
という特別な権限(Capability)が存在します。この権限を持つユーザー(単一サイトのWordPressではデフォルトで「管理者」および「編集者」ロールのユーザー、WordPressマルチサイト環境では「スーパー管理者」ロールのユーザーのみ)は、このKSESフィルタリングをバイパスし、任意のHTML(<script>
や<iframe>
を含む)を投稿内容として保存できます。しかし、この権限は非常に強力であるため、その付与は信頼できるユーザーに厳密に限定されるべきです。
独自のCSS/JSを持つ複雑なHTMLの制限
カスタムHTMLブロックに<style>
タグでCSSを記述したり、<script>
タグでJavaScriptを記述したりする場合、unfiltered_html
権限を持たないユーザーが入力したこれらのタグは、KSESフィルタリングによって基本的に除去されます。仮に権限があり記述できたとしても、埋め込んだCSSやJavaScriptがテーマや他のプラグインと競合し、サイト全体の表示や機能に問題を引き起こすリスクがあります。競合を避けるためには、CSSセレクタへのユニークな接頭辞付与や、JavaScriptの即時実行関数式(IIFE)でのスコープ限定などの対策が必要です。
3.2.2. オプションB:HTMLアップロード・表示用プラグインの利用
WordPressのプラグインを利用することで、HTMLファイルのアップロードや表示プロセスを簡略化できる場合があります。ただし、プラグインの選択と利用には注意が必要です。
- 「WP Add Mime Types」:メディアライブラリへのHTMLファイルアップロードを許可しますが、表示機能は提供しません。アップロード後、ファイルのURLをリンクとして参照したり、
<iframe>
で埋め込んだりする必要があります。 - 「File Manager」系プラグイン:WordPress管理画面経由で特定ディレクトリへのファイルアップロードを可能にします。SFTPクライアントなしでファイルを配置できますが、プラグインの信頼性・セキュリティに注意が必要です。
- 「Insert HTML Snippet」等:HTML「コード片」を登録し、ショートコードで投稿やページに挿入します。HTML「ファイル」を扱うものではありません。
プラグインを利用する際は、公式サイトからダウンロードし、評価が高く、定期的にアップデートされているものを選択することが重要です。機能と限界、セキュリティ面を十分に評価しましょう。
3.2.3. オプションC:カスタムページテンプレートによるHTMLファイル全体の表示
WordPressのテーマシステムを利用し、特定の固定ページに対して完全に独自のHTMLファイルの内容を表示させる方法です。WordPressのヘッダーやフッターといった共通部分を利用しつつ、メインコンテンツエリアには外部HTMLファイルの内容をそのまま流し込むといった柔軟なレイアウトが実現できます。
カスタムページテンプレート(.phpファイル)作成手順
- 現在有効化しているテーマのディレクトリ内に、新しいPHPファイルを作成します (例:
template-custom-static-html.php
)。 - ファイルの冒頭に特別なコメントヘッダーを記述します:
<?php /* Template Name: マイカスタムHTML表示テンプレート Description: 指定したHTMLファイルの内容を表示するためのカスタムページテンプレートです。 */ ?>
- WordPressの固定ページ編集画面で、このテンプレートを選択します。
PHPのincludeまたはfile_get_contents()を使用したHTMLファイルコンテンツの読み込み
作成したカスタムページテンプレートPHPファイル内で、表示したいHTMLファイルの内容を読み込みます。HTMLファイルは事前にテーマディレクトリ内のサブディレクトリ (例: your-theme/html-files/my-page.html
) にアップロードしておくと管理しやすいです。
<?php /* Template Name: マイカスタムHTML表示テンプレート (file_get_contents使用) */
get_header(); // WordPressの標準ヘッダーを読み込む (任意)
?>
<div id="primary" class="content-area py-8"> <!-- 縦方向の余白を追加 -->
<main id="main" class="site-main" role="main">
<?php
$html_file_relative_path = '/html-files/my-page.html'; // 表示したいHTMLファイルへのパス
$html_file_server_path = get_stylesheet_directory() . $html_file_relative_path;
if ( file_exists( $html_file_server_path ) ) {
$html_content = file_get_contents( $html_file_server_path );
// 注意: ここで$html_content内の相対パスを解決する必要がある場合があります。
// 例: $assets_base_url = get_stylesheet_directory_uri() . '/html-files/';
// $html_content = str_replace('src="images/', 'src="' . $assets_base_url . 'images/', $html_content);
// $html_content = str_replace('href="css/', 'href="' . $assets_base_url . 'css/', $html_content);
echo $html_content; // 読み込んだHTMLコンテンツを出力
} else {
echo '<p class="text-red-500 text-center">エラー: 指定されたHTMLファイルが見つかりません。パスを確認してください。</p>';
}
?>
</main>
</div>
<?php
get_sidebar(); // WordPressの標準サイドバーを読み込む (任意)
get_footer(); // WordPressの標準フッターを読み込む (任意)
?>
読み込まれたHTML内のCSS/JS/画像の相対パスの解決方法
PHPでHTMLファイル内容をWordPressページに挿入した場合、HTML内の相対パスはWordPressページのURL基準で解釈されるため、アセットが正しく読み込まれないことがあります。解決策として、HTMLの<base>
タグの使用(ページ全体に影響するため注意)、PHPによるサーバーサイドでのパス書き換え(より安全)、またはHTMLファイル内でWordPress関数を限定的に利用する方法があります。
カスタムページテンプレートは、WordPressの枠組みの中で自由なHTMLコンテンツを表示するのに強力ですが、アセットのパス解決が技術的な課題となります。
4. HTML表示方法の比較 (詳細)
各アプローチの主要な特徴、技術的な要求事項、適した利用シナリオ、表示の制御の自由度、WordPressテーマとの統合の度合い、そして主なセキュリティ上の留意点を以下の表にまとめます。
方法 | 主な特徴 | 使いやすさ (技術的知識要件) | 最適なユースケース | 表示の制御性 (CSS/JSの独立性) | WordPressテーマとの統合度 | セキュリティ上の主な考慮事項 |
---|---|---|---|---|---|---|
1. SFTP経由で専用ディレクトリにアップロード | WordPressから独立した静的HTMLとして公開。URL直接アクセス。 | 中 (SFTP操作、パーミッション理解要) | LP、独立したミニサイト、WordPressの影響を受けたくないページ。 | 高 (完全に独立) | 低 (テーマのヘッダー/フッター等は適用されない) | ファイルパーミッション設定。サーバー設定(Apache/Nginx)の理解。 |
2A. カスタムHTMLブロック (Gutenberg/Classic) | WordPress投稿/ページ内にHTMLコード片を直接記述。 | 高 (WordPressエディタ操作のみ) | 広告コード、簡単なフォーム、部分的なHTML装飾。 | 低 (テーマのCSS/JSと競合の可能性大) | 高 (テーマの枠内で表示) | KSESフィルタリングによる制限。unfiltered_html 権限の慎重な扱い。XSSリスク。 |
2B. WP Add Mime Types + メディアライブラリ (リンクまたはiframeで表示) | HTMLファイルをメディアとしてアップロード可能にする。表示はURLリンクか別途iframe等が必要。 | 中 (プラグイン設定、HTMLの基本理解要) | HTMLファイルのダウンロード提供。非常に単純なiframe表示(非推奨)。 | HTMLファイル自体は独立。表示方法は別途制御。 | リンクなら低。iframeなら部分的。 | プラグインの信頼性。アップロードファイルのサニタイズ。 |
2B. File Manager系プラグインでアップロード | WordPress管理画面からサーバーにファイルアップロード。URL直接アクセス。 | 中 (プラグイン操作、ディレクトリ構造理解要) | SFTPを使わずに静的HTMLをサーバーに置きたい場合。 | 高 (ファイル自体は独立) | 低 (テーマのヘッダー/フッター等は適用されない) | プラグインの信頼性・脆弱性。ファイルパーミッション管理。 |
2B. Insert HTML Snippet系プラグイン (コード貼り付け) | HTMLコード片を登録しショートコードで呼び出し。 | 高 (プラグイン設定、ショートコード利用) | 定型HTMLスニペットの再利用(広告、定型文など)。 | スニペットによる (テーマと競合の可能性あり) | 高 (ショートコードで任意の位置に挿入) | プラグインの信頼性。登録コードのサニタイズ状況。 |
2C. カスタムページテンプレート + include/file_get_contents | WordPressテーマの枠組みで特定のHTMLファイル内容を表示。 | 低 (PHP、HTML、CSS/JSパス解決の知識要) | テーマのヘッダー/フッターを使いつつ、内容は完全にカスタムHTMLにしたいページ。 | 中~高 (パス解決次第で独立性確保可能) | 高 (テーマの一部として機能) | PHPコードの品質。アセットのパス解決の複雑さ。ファイルパーミッション。 |
5. セキュリティのベストプラクティスと考慮事項
HTMLファイルをWordPressサイトにアップロードし表示する際には、利便性だけでなく、セキュリティへの配慮が不可欠です。不適切な設定や運用は、サイトの脆弱性を高める可能性があります。
5.1. ファイルパーミッションの再確認
アップロードしたHTMLファイルや、それらを格納するディレクトリのパーミッション設定は、セキュリティの基本です。不必要に緩いパーミッション(特に書き込み権限)は、悪意のある第三者によるファイルの改ざんや不正なファイルのアップロードを許す可能性があります。原則として、Webサーバーがコンテンツを読み取り、提供するために必要な最小限の権限のみを付与すべきです。Bitnami WordPressスタックの推奨値を参考に、ディレクトリには 775
または 755
を、ファイルには 664
または 644
を設定します。所有者は bitnami:daemon
が一般的です。
5.2. フィルタリングされていないHTMLのリスクとKSESの重要性
WordPressの投稿エディタを通じてHTMLを挿入する場合、WordPressはKSES (KSES Strips Evil Scripts) というフィルタリングシステムを用いて、潜在的に危険なHTMLコードを無害化または除去します。これは、クロスサイトスクリプティング(XSS)攻撃などからサイトと訪問者を保護するための重要な仕組みです。
unfiltered_html
というWordPressの権限は、このKSESフィルタリングを完全にバイパスする能力をユーザーに与えます。この権限は非常に強力であり、デフォルトではサイト管理者や編集者など、信頼されたロールにのみ限定的に付与されています。この権限を持つユーザーが信頼できないHTMLコードを不用意に貼り付けると、深刻なセキュリティインシデントにつながる可能性があります。入力値の検証、無害化、出力時のエスケープは、HTMLコンテンツを安全に扱う上での普遍的な原則です。
表: unfiltered_html権限を持たないユーザーに対するKSESフィルタリング概要 (wp_kses_post()適用時)
HTML要素/属性 | wp_kses_post() によるデフォルトの動作 | 備考 |
---|---|---|
<script>...</script> | 削除 (Removed) | XSSの主要な原因となるため、基本的に許可されません。 |
<iframe>...</iframe> (汎用) | 削除、または主要属性(src等)以外が削除される可能性が高い | セキュリティリスクが高いため、通常は許可されません。oEmbedや専用ブロック経由での信頼できるソースからの埋め込みは許可される場合があります。 |
<iframe> (YouTube/Vimeoなど、oEmbed経由または専用ブロック) | 許可 (Allowed) | WordPressがoEmbedプロトコルを通じて安全な埋め込みコードを自動生成します。 |
<style>...</style> | 削除または内容がサニタイズされる | 不正なスタイル注入リスクがあるため、通常は許可されません。インラインスタイル属性 (style="..." ) の一部は許可される場合があります。 |
onclick , onerror 等のJavaScriptイベントハンドラ属性 | 属性自体が削除 (Attribute removed) | これらもXSS攻撃の一般的な経路であるため、許可されません。 |
一般的なフォーマットタグ (<p> , <strong> , <a> のhrefなど) | 許可 (Allowed) | WordPressの $allowedposttags グローバル変数で定義された、安全と見なされるタグと属性は許可されます。 |
注: 上記は一般的な動作であり、WordPressのバージョン、テーマやプラグインによるフィルタのカスタマイズによって挙動が変わることがあります。
5.3. WordPressテーマやプラグインとの潜在的な競合(CSS/JS)
アップロードまたは埋め込んだHTMLファイルが独自のCSSやJavaScriptを含んでいる場合、それらがアクティブなWordPressテーマや他のプラグインと競合し、表示崩れや機能不全を引き起こす可能性があります。競合を最小限に抑えるためには、CSSセレクタへのユニークな接頭辞付加や、JavaScriptの即時実行関数式(IIFE)でのスコープ限定などの対策が推奨されます。
5.4. 定期的なバックアップの実施
新しいHTMLファイルを追加したり、既存のファイルを変更したり、関連するプラグインを操作したりする前には、必ずサイト全体のバックアップを取得することを強く推奨します。AWS Lightsailのスナップショット機能などを活用し、万が一問題が発生した場合でも迅速に復元できるように備えましょう。
表: Bitnami LightsailにおけるWordPressファイル/ディレクトリパーミッションの目安
パス (Path) | 推奨パーミッション | 所有者:グループ (Owner:Group) | 備考 |
---|---|---|---|
/opt/bitnami/wordpress/ (WordPressルート) | 775 | bitnami:daemon | BitnamiスタックのWordPressアプリケーションフォルダの基本。 |
/opt/bitnami/wordpress/my-html/ (カスタムHTML用例) | 775 (または 755 ) | bitnami:daemon | Webサーバーがアクセスし、ディレクトリリストを防ぐために実行権限が必要な場合がある。 |
/opt/bitnami/wordpress/my-html/yourfile.html | 664 (または 644 ) | bitnami:daemon | HTMLファイル自体は通常、実行権限は不要。Webサーバーによる読み取り権限が重要。 |
/opt/bitnami/wordpress/wp-config.php | 640 (または 400 ) | bitnami:daemon | 機密情報を含むため、特に厳格なパーミッションを設定。 |
/opt/bitnami/wordpress/wp-content/uploads/ | 775 | daemon:daemon または bitnami:daemon | WordPressがメディアファイルをアップロードするために書き込み権限が必要。 |
注: 上記は一般的な目安です。Bitnamiのバージョンや具体的な設定によって異なる場合があります。
6. ニーズに合わせた最適な方法の選択
これまで解説してきたように、AWS Lightsail上のWordPressサイトにHTMLファイルを表示させる方法は多岐にわたります。どの方法が最適かは、HTMLファイルの内容、ユーザーの技術的なスキルレベル、サイトの運用方針、そしてセキュリティ要件によって異なります。
6.1. 一般的なシナリオに基づく推奨事項
- 単純なランディングページや、WordPressから完全に独立した静的HTMLページを公開したい場合:
→ 方法1:SFTP経由で専用ディレクトリにアップロード が最も直接的です。 - 既存のWordPress投稿やページ内に、少量のHTMLコード片を追加したい場合:
→ 方法2オプションA:カスタムHTMLブロック(Gutenberg)またはテキストモード(クラシックエディタ)が手軽です。KSESフィルタリングの制限に注意してください。 - WordPress管理画面からHTMLファイル群をアップロードし、特定のURLでアクセス可能にしたいが、SFTPの使用は避けたい場合:
→ 方法2オプションB:「File Manager」系プラグイン が選択肢となりますが、プラグインの信頼性とセキュリティには十分注意が必要です。 - WordPressサイトの共通デザインを利用しつつ、特定の固定ページのメインコンテンツだけを完全に独自のHTMLファイルで構成したい場合:
→ 方法2オプションC:カスタムページテンプレートを作成し、PHPでHTMLファイルを読み込む 方法が最も柔軟性が高いですが、アセットのパス解決など技術的な対応が必要です。 - メディアライブラリにHTMLファイルをアップロードしてダウンロードリンクを提供したい、またはごく単純なHTMLをiframeで限定的に表示させたい場合(非推奨):
→ 方法2オプションB:「WP Add Mime Types」プラグイン でアップロードを許可し、URLを利用します。
ユーザーが具体的にどのような「HTMLファイル」を指しているのか(単一のシンプルなHTMLか、CSS/JS/画像群を含むウェブページか)、そして「表示させたい」要望がどのような形か(独立ページか、既存ページの一部か)によって、最適な「簡単な方法」は変わってきます。
7. まとめ
7.1. 主要なポイントの要約
本レポートでは、AWS Lightsail上のWordPressサイトにHTMLファイルをアップロードし表示するための複数の実践的な方法(SFTP直接アップロード、カスタムHTMLブロック、プラグイン利用、カスタムページテンプレート作成)を解説しました。 最適な方法の選択は、HTMLの性質、表示制御レベル、技術スキル、セキュリティ要件を総合的に判断して行うべきです。ファイルパーミッション設定とWordPressのHTMLフィルタリングシステム(KSES、unfiltered_html
権限)の理解が、安全な運用のために不可欠です。
7.2. 慎重な実装の推奨
いずれの方法を選択するにしても、作業前には必ずサイト全体のバックアップ(AWS Lightsailのスナップショット機能など)を取得してください。可能であれば、本番環境とは別のテスト環境で事前に検証し、意図通りに動作すること、そして既存サイトに悪影響を与えないことを確認してください。
セキュリティへの配慮は常に最優先事項です。信頼できないソースからのHTMLコードの使用は避け、ファイルパーミッションは最小限の原則を守り、unfiltered_html
のような強力な権限の取り扱いには最大限の注意を払ってください。
本レポートが、AWS Lightsail上のWordPressサイトでHTMLファイルを効果的かつ安全に運用するための一助となれば幸いです。
コメント