この記事は約 16 分で読めます。

制作・開発はWordPressで行いたいけど「静的なHTMLソースが欲しい」というケースはけっこうあると思います。

サーバーにインストールしたWordPressディレクトリを見ても、○○.htmlといったHTMLファイルは見当たりません。

WordPressでウェブサイトを制作する場合、基本的に静的なHTMLは出力されず、ユーザーがページにアクセスする度にDBを経由して動的にページが表示される仕組みになっているのは既知の通りかと思います。

ではどんなケースで「静的HTMLがあったらいいな」と思うかと言えば、、、

  • WordPressサイトをまるごと静的HTML化したい時
  • 制作途中の画面確認用HTMLとして
  • テンプレートからページを量産するためのHTMLジェネレーターとして

上記例に挙げた以外でも、WordPressで作ったサイトの静的HTMLデータが欲しいケースはたまにあると思います。

本格的に静的HTMLサイトで運用することを目的としている場合は「静的サイトジェネレーター」を利用するという選択肢もありますが、本記事の趣旨からは外れるため、ここでは一旦無視します。

本記事では「WordPress ⇒ 静的HTML化」というニーズをシンプルに叶えてくれるプラグイン「Simply Static」について、便利な活用方法と考察を交えつつ実際に静的HTMLを出力するまでの流れを解説します。

シンプルですがクセが強いプラグインのため、利用時の注意点も漏れなくお読みください。

※本記事は事業統合前のブルーアンドアソシエイツ社のエンジニアによって書かれた記事であり、本記事内で使用されている検証データ等は当時の内容となっておりますことをご了承ください。

Simply Staticのインストール

WordPressのプラグイン新規追加ページの右上の検索窓に「Simply Static」と入力すると表示されますのでこちらをインストールして有効化してください。

公式のプラグイン配布サイトは以下になります。

◆公式のプラグイン配布サイト
https://ja.wordpress.org/plugins/simply-static/

1年以上前から更新されておらず、直近の過去3回のWordPressのメジャーリリースに対してテストされていない、という点は若干のマイナスポイントではあります。

筆者のWordPress環境は本記事執筆時点でWP 5.2.2で運用していますが、現時点で特に競合や不具合は確認していません。

Simply Staticの機能説明

プラグインのインストール&有効化が完了すると、(設定の中ではなく)サイドバー内に独立したメニュー項目が表示されます。

Simply Staticのメニュー項目を見ると「生成」「設定」「診断」と3つの項目に分かれています。

本項では各設定項目の見方について簡単に紹介して、実際に静的HTMLを出力する手順については次項で解説します。

それではひとつずつ内容を見ていきましょう。

設定

まず最初に設定メニューを開きます。
「一般」タブが選択された状態ですね。

図1:設定(一般)
図1:設定(一般)

一般

「リンク先URL」の項目では生成されるHTML内の画像やリンクパスの形式を以下3つから選択します。

リンク先URL:絶対URLを使用する
https://blueasc.jp/といったような絶対パスで出力する際に選択します。

図2:絶対URLを使用する
図2:絶対URLを使用する

以下注意点になります。

デフォルトではhttpが選択状態になっているため、ご自身の環境に合わせて適宜プルダウンから「https」を選択すること、そしてドメインの末尾にスラッシュ(/)を付けること。


リンク先URL:相対URLを使用する
下記図のように「/wp-static/」スラッシュ(/)で始まるサイトルート相対パスで出力する際に選択します。

図3:相対URLを使用する
図3:相対URLを使用する

サイトルート相対パスは汎用的に使えるため、一般的な案件では一番使いやすい設定かもしれません。

但しサイトルート相対パスの場合、サーバーにアップした場合は問題ありませんが、そのままローカルマシンで開いてもパスが通らずページは正常に表示されません

ローカルPCでページを見れるようにするためにはXAMMPのようなパッケージをインストールしてローカルサーバの構築とバーチャルホストの設定が必要となります。

ここではふれませんが、ローカルサーバーの構築自体は30分程度あれば完了する作業なので、ご興味ある方はトライしてみてください。


リンク先URL:オフラインで使用するために保存
「./../wp-static/」といったような相対パスで出力する際に選択します。

図4:オフラインで使用するために保存
図4:オフラインで使用するために保存

インターネットに繋がっていない環境下のローカルマシンでも普通に見ることができます。

ウェブサイトとして制作・管理するには相対パスは時として不便ですが、単純にローカルマシンでページを見れるようにしたい場合は相対パスが便利ですね。


配送方法:ZIPアーカイブ
生成したHTMLをZIPアーカイブでダウンロードする時はこちらを選択します。

図5:配送方法(ZIPアーカイブ)
図5:配送方法(ZIPアーカイブ)

配送方法:ローカルディレクトリ
生成したHTMLを任意のディレクトリに出力する際はこちらを選択します。

図6:配送方法(ローカルディレクトリ)
図6:配送方法(ローカルディレクトリ)

ローカルディレクトリに設定するパスはWordPressがインストールされているサーバーのドキュメントルートからの任意のパスを設定します。

ドキュメントルートパスについては説明書きの下のあたりに自サーバーでの例が記載されていますので参考にしてください。

インストールされている環境によって異なりますが、上記図6では「/home/users/0/blueasc/web/blueasc.jp/」となっており、任意で「wp_static」フォルダを作成して、そこにHTMLが出力されるように設定しました。

ローカルディレクトリはローカルマシンのDドライブなどのローカルディレクトリパスを設定するわけではありませんのでご注意ください。

但しXAMMPなどでローカルサーバーを構築していて、そこでをWordPressを運用している場合はローカルマシンのローカルディレクトリパスを設定することになります。


インクルード / エクスクルード

追加するURL・追加ファイルとディレクトリ
特に変わった仕組みのサイトでなければ設定は必要ないかもしれません。

必要な構成ファイルの内、特定のファイルやフォルダが生成ファイルに含まれない場合、またはAJAXで動的に参照されるファイルなどがある場合はこちらに追加することで対処できます。

図7:設定(インクルード / エクスクルード)
図7:設定(インクルード / エクスクルード)

上級者向け

Temporary Files(一時ファイルディレクトリ)
静的HTMLを出力する際の一時的なファイル保存先ディレクトリを指定します。
基本的には特に変更する必要はありません。

Simply StaticでHTMLが生成されるまでの手順として、一度ここで設定したディレクトリ内に書き込み・展開してから、ZIPファイルに変換したり指定ディレクトリにコピーする流れとなっています。

「Delete Temporary Files」はデフォルトでチェックが入っていますが、そのままチェック状態にしておきましょう。(オフにすると処理の度にファイルがどんどん溜まっていきます・・・)

図8:設定(上級者向け)
図8:設定(上級者向け)

HTTP Basic Authentication
ベーシック認証付のサイトでもIDとパスワードを入れることでHTML生成が可能となっています。

地味に便利な機能ですね。


リセット

プラグインの設定をリセットするボタンが置いてあるだけで、特に利用する機会はないとは思います。

図9:設定(リセット)
図9:設定(リセット)

赤色の「プラグインの設定をリセット」ボタンが目立つので、つい興味本位で押したくなってしまうかもしれませんが・・・クリックした場合に「本当に設定をリセットしますか?」といったような確認用のダイアログは表示されずに普通にリセットされてしまうのでご注意ください。(笑)

診断

設定を終えてHTMLを生成する前に一度確認しておくとよいでしょう。

図10:診断
図10:診断

確認すべき点はオールグリーンで「OK」になっているかどうか

例えばFilesystemの項目において赤字でエラーが表示される場合、大半はフォルダの書き込み権限の問題です。
フォルダのパーミッション設定で書き込みOKになっているかどうかを確認してみましょう。

またローカルディレクトリに指定したパス(ディレクトリ)が存在しない場合もエラーになるため、ディレクトリに出力する場合は事前に指定した任意のディレクトリを用意しておきましょう。


デバッグオプション

デバッグモードON/OFFのチェックボックスがありますが、出力内容に影響はないため任意でどちらでもかまいません。

HTML生成時にどのような処理が行われているのか確認したい人は見てみるとよいかもしれませんね。

生成

HTMLを生成するページです。
静的ファイルを生成する」ボタンをクリックするとHTMLの生成が開始されます。

図11:生成
図11:生成

機能説明は以上です。

ここまでの説明に沿って実際に手を動かして設定が済んでいる場合は、そのままHTMLを生成してしまって問題ありません。

次項ではここまでの手順について改めてまとめています。

Simply StaticでHTMLを生成してみる

ここまで一通りSimply Staticの機能説明を行ってきましたが、その内容を以下にまとめてみました。

一通りの設定が完了して、診断でエラーが出ていないことを確認したら「静的ファイルを生成」するボタンをクリックしましょう。

図12:Simply StaticでHTMLを生成してみる
図12:Simply StaticでHTMLを生成してみる

ボタンクリック後はHTML生成が完了するまで暫く待ちます・・・

リンク先URLや配送方法の設定にも左右されますが、当サイトで試したところ全ファイル生成が完了してダウンロード可能な状態になるまでに約3分~12分といった処理のバラつきが見られました。

インターネット回線の状況やサーバースペック・ウェブサイトの規模にもよりますが、処理が完了するまでにそれなりの時間を要します。

図13:生成ファイルを保存
図13:生成ファイルを保存

配送方法でZIPを選択した場合はHTML生成完了後にZIPアーカイブをダウンロードするリンクが表示されます。

HTMLを生成する度にダウンロードリンクは更新されますが、FTPでプラグインディレクトリに接続して一時ファイルディレクトリ(/plugins/simply-static/static-files/)を開けば、過去に生成したZIPアーカイブをダウンロードすることが可能です。

図14:FTP(/wp-static/フォルダ)
図14:FTP(/wp-static/フォルダ)

配送先でローカルディレクトリを選択した場合は上記図14のようにサーバーの指定したディレクトリ内に静的HTMLが直接出力されます。

以上で静的HTMLの生成は完了です。

あとは実際に出力されたHTMLに問題がないかどうかページを開いて確認してみましょう。

エラー挙動と注意点について

生成した静的HTMLページを無事問題なく表示できればよいのですが、静的HTML化した際に何かしらの原因で表示不具合が出るケースがあります。

筆者が直面した代表的なエラー例を掲示しておきますね。

  • 静的ファイル生成時にPHPエラーが表示される
  • パーマリンク設定次第で出力ファイル名が変わる
  • 一部の画像が表示されない
  • アイコンフォントで指定しているアイコンが表示されない
  • 一部のプログラムが正常動作しない

それでは上記エラー事例について順番に解説していきます。

静的ファイル生成時にPHPエラーが表示される

静的HTML生成中に赤字で以下のようなエラーが表示されて完了しないことがあります。

Allowed memory size of 134217728 bytes ・・・

図15:ファイル生成時エラー発生
図15:ファイル生成時エラー発生

何となくドキッとしますが、原因はPHPのメモリー不足です。

サーバースペックや設定にも依存しますが、PHPで容量の大きなファイルを操作したり、高負荷な処理を行う際に予め割り当てられているメモリ上限を超えた場合、このようなエラーが表示されるというわけですね。

筆者のケースでは同じサイトを生成しても「エラーが出ずに完了する場合」と上記画面のように「エラーが出てしまうケース」がありました。

この場合の解決法は主に2通りあります。

  • 一部生成ファイルの除外指定をする(生成ファイルサイズを軽くする)
  • PHPのメモリ上限を変更する

一部生成ファイルの除外指定をする(生成ファイルサイズを軽くする)

「設定 > インクルード / エクスクルード」の「除外するURLを追加」から除外するパスもしくはファイル名を記入して保存します。

以下図16では「/wp-content/uploads/」以下を除外指定したため、/uploads/以下の画像ファイルが生成ファイルから除外されます。

図16:ファイル除外指定
図16:ファイル除外指定

画像類を除外指定しておくと生成ファイルのサイズが大幅に削減できるため、結果としてPHPエラーを誘発しにくくなります。

この場合、除外した画像ディレクトリについては後でフォルダごとダウンロードすれば問題ないでしょう。


PHPのメモリ上限を変更する

Memory limit」と呼ばれるPHPのメモリ上限設定値を変更することで処理能力を引き上げて対処する方法です。

Memory limitの変更方法については、PHPの設定ファイルの「php.ini」もしくは「wp-config.php」から変更できますが、、、本プラグインのためだけに変更するのはあまりオススメしません。

気になる人は「Allowed memory size of」で検索するといろいろ事例が出てきますので調べてみてください。

大規模サイトを本格的に静的HTMLに変換したい場合は別の方法を考えましょう。

パーマリンク設定次第で出力ファイル名が変わる

WordPressでページを表示する際は通常「○○.html」といった拡張子は付きません。

例えば本記事のパーマリンクは「simply-static」で、URLだとカテゴリ名を経由して「https://blueasc.jp/wordpress/plugins/simply-static/」となります。

これがSimply Staticで静的HTMLとして生成される際にファイル名がどのようになるかと言うと、「/simply-static/index.html」として生成されます。

ひとつのディレクトリ内に1ファイルしか存在ない場合は問題ありませんが、同一ディレクトリ内に複数ファイルが存在する場合はパーマリンク設定を工夫する必要があります。

「%postname%.html」といった感じで「.html」を付けておきましょう。

またカテゴリやファイル名に日本語を使用している場合も表示不具合に繋がりますので、運用上特別な理由がない限り半角英数字で命名することを心掛けましょう。

一部の画像が表示されない

比較的よく遭遇する不具合で主な原因は以下になります。

  • ソース圧縮系のプラグインを使っている
  • キャッシュ系のプラグインを使っている
  • サーバー側のキャッシュ設定により独自の圧縮ファイルに変換されている
  • LazyLoadで画像を読み込ませている

これらが原因で画像パスが変換されてしまい正常に画像が読み込まれていなかったり、画像が認識されずSimply Staticの生成ファイルに含まれないことがあります。

ソース圧縮系・キャッシュ系プラグインをOFFにする
サーバー管理画面のキャッシュ設定を確認する
LazyLoadをOFFにする

などを試してみましょう。

アイコンフォントが表示されない

こちらはブラウザに依存して発生するクロスドメインに起因する問題です。

Chromeだとアイコンフォントは普通に表示されますが、FireFoxで見た場合はに表示されなかったりします。

FireFoxのコンソールを開いてみると以下のようなエラーメッセージが出ていました。

クロスオリジン要求をブロックしました: 同一生成元ポリシーにより、file:///D:/Users/kenji/Desktop/simply-static-1-1563685877/wp/wp-content/themes/blueasc/common/fonts/icomoon.ttf?ct94a7 にあるリモートリソースの読み込みは拒否されます (理由: CORS 要求が http でない)。

ウェブフォントやアイコンフォントを利用する際、それらが実際に使用されている本番のウェブサイトと静的HTMLとしてローカルに保存したHTMLの場合で参照元ページ(ドメイン)が異なる場合、ブラウザとバージョンによってはクロスドメイン制約のためフォントにアクセスできず、正常に表示されないことがあります。

クロスドメインの解決方法についてはここではふれませんが、今すぐ解決したい方は「クロスドメイン フォント 解決方法」とかで検索すると、いくつか解決方法が出てきますので、調べてみてください。

「.htaccess」ファイルを(ケースによってはfunctions.phpも)編集する必要がありますが、頑張ればわりとあっさり解決できたりします。
※環境によっては解決できないケースもあるようですが。

一部のプログラムが正常動作しない

動的に読み込まれるものやデータの送受信が必要なプログラムは静的HTMLとして保存したローカルファイルでは正常に動作しません。

以下に主な例を挙げておきます。

  • Googleマップなどの地図
  • サーバーで動的に生成・取得して表示させるコンテンツ全般
  • お問い合わせフォームの送受信

上記についてはサーバー上にアップしても、登録ドメインの関係で正常に読み込まれない可能性があります。

小手先の調整や一括置換で対応できるケースもありますが、そうでないケースもあります。

Simply Staticを使ってWordPressサイトを静的HTML化して運用する際は、この辺りの処理をどう補完するか検討する必要があるでしょう。

Simply Staticの便利な活用方法

本項ではSimply Staticで生成したHTMLの活用方法を筆者の利用例を交えて考察してみます。

WordPressで開発したサイトを静的HTMLで運用

最初の例として挙げておいて何ですが、このような使い方はあまり実用的ではないことを先お伝えしておきます。(笑)

ブログなどのコンテンツや外部サイト・外部ドメインと連携した動的コンテンツを保持している場合、恐らく表示不具合が多発することが予想されます。

但し小規模でシンプルな構成なウェブサイトの場合は以下のような活用法が考えられます。

  1. ローカル環境のWordPressでウェブサイトを開発
  2. Simply Staticで静的HTMLを生成
  3. 本番環境にHTMLをアップして静的HTMLで運用

WordPressで効率的に開発しつつ、運用は静的HTMLで行うケースです。

ちょっと強引にメリットを上げるとすれば静的HTMLであるがゆえの「表示スピードの速さ」「セキュリティ面の安心感」でしょうか。

生成後のHTMLに不具合がなくそのまま利用できる場合は、出力された静的HTMLを本番環境にデプロイする処理を自動化しておくと運用が楽になりますね。

あまり効率的な運用方法とは言えませんが、WordPressで開発したファイルを静的HTMLで運用したい時の参考程度に。。。

制作途中の確認用HTMLとして

これはあると思います。

制作サイドのニーズになりますが、客先でノートPCを開いてWordPressで開発中の画面を見ながら説明するケースが想定されます。

打ち合わせする部屋にネット環境がない
Wifiが不安定でネットに接続ができない・重たい

というケースは都市部以外では往々にしてあり得ます。

WordPressで開発中のデータを静的HTMLに落とし込んでローカルPCで見れると大変便利ですね。

営業さんにとっても、客先でネットが上手く繋がらずにヒヤヒヤする心配がなくなりますね。(笑)

制作途中の確認用HTMLとして便利な使い方がもうひとつあります。

WordPressで開発する際、開発ファイル自体はローカル環境で保持しつつフレームワークやタスクランナーを利用してビルド・デプロイするケースが多いかと思います。

外部の様々な人達とチームを組んで案件を進める場合、制作に関わる全員が必ずしもWordPress開発環境やフレームワーク・タスクランナーを利用した開発環境を共有しないケースがあります。

外部のシステム会社さんに○○の部分のHTMLだけ納品して欲しい
この部分のアニメーションだけ外注の○○さんにお願いしたい

といったケースもたまに遭遇します。

そんな時に該当箇所のHTML一式を渡して調整してもらうことができたりします。

後にCSSやJSの差分を別途吸収する手間は発生しますが、WordPressで開発中のページの一部をサクッとHTML化できるとこういった依頼もしやすくなりますね。

LP(ランディングページ)などのHTMLジェネレーターとして

これは本命の使い方だと思います。

その昔、筆者が担当していたLP(ランディングページ)案件がありまして、以下のような仕様を決めてWordPressでLPを量産して納品していた時期がありました。

  • 数パターンのレスポンシブ対応テンプレートをローテーションで使用
  • レイアウトパターンは流用可能なブロックの増減積み替えで対応
  • 案件毎の変更箇所は「商品名」「画像」「テキスト原稿」「配色」
  • フォームは外部サービスを利用または埋め込み

テンプレート設計をしっかり行えば、品質を保ちつつ納品までの工程が超スピードで完結します。(笑)

使い回すテンプレート数が少ないと「単調になりがち」というデメリットはありますが、最初に設計するテンプレートの品質を意識してしっかり作り込めば、十分なメリットを享受できるでしょう。

LPはHTML形式での納品を求めれることが多いため、HTMLベースで管理していましたが、こういった理由もあり現在はLP作成用のWordPressを建てて管理しています。

こういったシンプルな使い方こそSimply Staticの本領が発揮される気がします。

Simply Staticのプラグイン競合について

Simply Staticプラグインを有効化した状態でフォームを送信すると「送受信データともにメール本文の全ての改行が削除されて1行に繋がってしまう」という不具合を確認しています。

もう少しわかりやすく説明すると、本来読みやすいように改行が入っているはずのメール本文から改行がなくなり、全て文章が1行に繋がった状態になってしまう、という挙動です。

困りますよね。

筆者が運営する環境の異なる複数サイトで当該挙動を確認済みです。

推測の域を出ませんが、特定のプラグインと競合するというよりは、PHPMailerを利用して送信するフォームと競合しているように思えます。

プラグインを無効化した状態だとこの不具合は発生しないため、利用する時以外は無効化しておいた方がよいでしょう。

本件については別記事にて取り上げていますので、ご興味ある方はご一読ください。

環境によってはこの現象が発生しないケースもあるのかもしれませんが、Simply Staticプラグインを利用される場合は、プラグイン有効化状態でウェブサイト内に設置してある各種フォームの送受信テストを行うことをオススメします。

文末に筆者の開発環境を記載していますのでご参考までに。

まとめ

本記事で紹介した「Simply Static」はアイデアと使い方次第で活躍する幅が大きく広がるポテンシャルを秘めたプラグインと言えるでしょう。

「Simply Static」を日本語に直訳すると「単に静的」。
より近い意味に置き換えると「シンプルに静的に」。

プラグイン名に「WordPress」や「HTML」といったワードが入っていない所に妙な潔さを感じます。

WordPressサイトを静的HTML化するプラグインなのだから、SEO的にはキーワードを入れた方が探されやすいとは思うのだけど、入っていない。

そこにプラグイン制作者のこだわりが見れ隠れしますね。
勝手な解釈ですが。(笑)

ちょっと気になったので制作者さんを調べてみると、アメリカ人でネブラスカ州在住の方のようです。

wordpress.orgでの活動は2年前から止まっていますが、Simply Staticプラグイン自体の更新は1年前に行われています。

Simply Staticプラグインの更新を希望される方はメールアドレスが記載されていますので、リクエストを送ってみるとよいかもしれませんね。(笑)


少し話が脱線しましたが、Simply Staticはシンプルな構成のウェブサイトを静的HTML化する際に活躍するプラグインです。

それ以外の使い方もいくつか例を挙げて紹介しましたが、アイデア次第で活用方法の幅が広がる面白いプラグインですね。

但し、 本来ウェブサイトを静的HTMLで運用するメリットは、

表示スピードの速さ
セキュリティ面の安心感

です。

本格的に静的HTMLサイトで運用することを目的としている場合はやはり安定した「静的サイトジェネレーター」 を利用した方がよいでしょう。

気になる方は「静的サイトジェネレーター」で検索してみてはいかがでしょうか。

以上、WordPressで静的HTMLを生成するプラグイン「Simply Static」の紹介でした。

開発環境
Simply Static:2.1.0
WordPress version:5.2.2
PHP version:7.1.14
MYSQL:5.6.23
Web server:Apache
Server OS:Linux

弊社では、企業サイトや採用サイトの制作、WordPress構築、shopifyを活用したECサイト構築を得意としています。ホームページ制作やリニューアル、サイト運用に関する無料相談を承っていますのでお気軽にご相談ください。
無料で相談してみる