Single Page
【Windows/MacOS共通】DockerでWordPress環境やってみた

はじめに

ApacheをインストールしてなくてもOK。

Windows / MacOS共通でOK。

ただしWindowsの場合はターミナルの扱いに注意点あり。

とりあえずVS CodeとDocker Desktopさえ動けばいけるWordPress開発環境など試してみる者あり。

GitHub Desktopも動くのなら更によいとされている。

必要な環境

ソフトウェア

  • VS Code
  • Docker Desktop
Windowsのみ
  • WSL

ターミナル

現在選択中のVS Codeのプロファイルは、ターミナルを開いたところ。

「」アイコンの右に書いてあります。

Windowsなら「powershell」とか「wsl」とか、MacOSなら「bash」とか「zsh」とか。

プロファイルを変更するには「＋」アイコン横の下矢印をクリックして、出てきた一覧の中から選択。

既定プロファイル（VS Codeを起動した状態でのデフォルトのプロファイル）を変更するには、同じく下矢印をクリックして「既定のプロファイルの選択」をクリック。

同様に出てきた一覧の中から選べばOK。

Windowsで使うもの
  • Windows PowerShell
  • VS Code（WSLプロファイル）

Windows PowerShellはほとんど使わないです。

パソコンを起動した直後と、WSLをインストールする時くらい。

MacOSで使うもの
  • VS Code（zshプロファイル）

（Windowsのみ）WSLのインストール

Windowsではパソコン起動時とWSLインストール時にのみWindows PowerShellを使い、それ以外でのターミナル操作はVS CodeのWSLプロファイルを使用します。

ところがこのWSLは自分でインストールする必要があったりします。

WindowsでのDockerはWSLに依存しているので必須なんですな。

インストール

Windowsボタンから「powershell」と検索欄に入力して、「Windows PowerShell」が検索結果として出てきたら「管理者として実行する」をクリック。

起動したら次のコマンドを実行。

wsl --install

パソコンを再起動してWSLを有効化。

ログイン

再びWindows PowerShellを起動して、今度はWSLにログインできるか確認します。

wsl

ターミナルの入力欄が「【LINUXのアカウント名】@【パソコン名】:【フォルダパス】#【カーソル】」のようになっていたら動作しているっぽい。

初期ユーザは、ユーザ名「root」・パスワード「（なし）」だったような記憶。

ユーザは新規に作成しなくても作成してもよいものとする。

VS Codeで動作確認

VS Codeのターミナルを開いて、プロファイルをWSLに変更。

何のディストリビューションをインストールしたかで表記は変わりますが、「Ubuntu (WSL)」みたいな感じになってると思います。

ターミナルの入力欄がWindows PowerShellでWSLにログインした時と同じような感じになっているなら完了です。

（Windowsのみ）WSLのマウント設定

今回はMySQL（WordPressのデータベース）をDockerで扱いますが、WindowsのみSSL関係のパーミッションエラーが発生するので設定変更します。

具体的には次のようなエラーが出て、Dockerコンテナは起動しても強制終了されます。

mysqld: Cannot change permissions of the file 'private_key.pem' (OS errno 1 - Operation not permitted)

UIDとGIDが、OSとDockerコンテナ間とで一致してないために起きているらしい。

設定ファイルを開く

Windows PowerShellからWSLにログイン。

wsl

設定ファイルを開く。

パスワード入力を求められたらそれに従う。

sudo vi /etc/wsl.conf

私の場合の初期設定はこれだけでした。

[boot]
systemd=true

設定ファイルを編集する

「a」キーを押して編集開始。

以下の設定を追記します。

[automount]
options="metadata"

入力が終わったら「Esc」キーで編集モードを中断。

「:wq」と入力すれば上書き保存が完了です。

なお「a」とか「:wq」とかの詳細はviコマンドを参照のこと。

正直全部は覚えきらん。

設定変更の有効化

WSLからログアウトして、

exit

WSLをシャットダウンして、

wsl --shutdown

WSLを再起動。

wsl

これで設定は有効になります。

一応VS Codeも一度終了して、新しいウィンドウで開き直した方がいいと思います。

（パソコン起動時のみ）MySQL WorkBenchをインストールしている場合

こちらはWIndows / MacOS共通。

WordPressを扱う時のデータベースアクセスで競合してしまうので、MySQL WorkbenchなどMySQLを管理するソフトウェアのプロセスをシャットダウンします。

ソフトウェアを終了させるだけではダメです。

Windowsの場合

Windows PowerShellから次のコマンドを実行します。

netstat -ano | Select-String ":3306"

以下のようなリストが現れたらば処置が必要。

数値は毎回変わります。

TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING 99999

上例の場合は「99999」がプロセス番号なのでメモしておいて、次のコマンドを実行する。

taskkill /F /PID 99999

「成功: PID 99999 のプロセスは強制終了されました。」と表示されれば成功です。

MacOSの場合

ターミナルから次のコマンドを実行します。

パスワード入力を求められたらそれに従います。

sudo lsof -i:3306

以下のようなリストが現れたらば処置が必要。

数値は毎回変わります。

httpd 99999 4u IPv4 0x000000000000000 0t0 TCP *:http (LISTEN)

上例の場合は「99999」がプロセス番号なのでメモしておいて、次のコマンドを実行する。

sudo kill 99999

Windowsのとは異なり、特にメッセージは表示されないです。

3306番ポートを使っているプロセスがない場合も一覧すら表示されないです。

プロジェクトの初期化

ここまでがインストールの下準備。

プロジェクトファイルを作っていきます。

いつも通りphewを流用しますが動的サイトになるためプレビューはナシ。

ビューワーの小さいエリアのためだけにWordPress用意するのも大変ですんで。

Phew WP をビューワーで開く

留意事項は2点。

  • パソコンを起動したら、3306番ポートを使っているプロセスを忘れずに殺しておくこと
  • ターミナルのプロファイルを変更し忘れないように

特にWindowsはWSLにすることが必須です。

MacOSはzshでなくても動くことは動くって感じ。

プロジェクトフォルダの作成

新しいフォルダを作成して、VS Codeの新しいウィンドウを開いて、作ったフォルダをドラッグ＆ドロップ。

いつでもコマンドを実行できるようにターミナルを開いておく（Windows / MacOS共通: Control + @）

機能ごとのフォルダを作る

次のコマンドを一気にターミナルへコピペして、フォルダを全部作ります。

mkdir config
mkdir config/mysql
mkdir config/mysql/data
mkdir config/web
mkdir html
mkdir html/app
mkdir html/src
mkdir html/src/css
mkdir html/src/img
mkdir html/src/js
mkdir html/src/public

ファイルを作る（１）

  • config/web/Dockerfile
  • html/app/index.php
  • .gitignore
  • docker-compose.yml

DockerはApache + PHP + xdebug + MySQL同梱セット。

WordPress向けに、mod_rewrite.soも有効化させたり、WebPを扱えるようにするためにGDやImageMagickを追加してたりするよ。

index.phpはDockerの起動確認テストにしか使わないのですぐ消える運命にありますが、テストで表示させている $SERVER["DOCUMENT_ROOT"] の値は後で使うのでコピペって保存。

html/app/index.php
<!DOCTYPE html>
<html>
  <head>
    <title>Docker test</title>
  </head>
<body>
  <h1>Docker test</h1>
  <?php echo '<p>PHP works.</p>'; var_dump($_SERVER["DOCUMENT_ROOT"]); ?>
</body>
</html>

Dockerの起動テスト

Docker Desktopを起動した状態で、次のコマンドを実行する。

docker compose up -d

http://localhost:8880にアクセスしてみて、Apache+PHPが動いていることを確認。

続いてhttp://localhost:8881にアクセスして、phpMyAdmin（＝MySQL）が動いていることを確認する。

起動テスト終了につき、Dockerコンテナを次のコマンド入力で終了させます。

docker compose down -v

テスト用に作ったhtml/app/index.phpも不要なので削除しちゃってください。

Dockerの構成を変更した場合

テスト起動でうまく行かなくてDockerfileやdocker-compose.ymlを変更した場合、DockerコンテナやDockerイメージを削除します。

docker system prune -a

またMySQLのデータベースも削除するので、データを保存しているファイル群であるconfig/mysql/dataフォルダの中身をまるごと削除しちゃってください。

WordPressをインストールする

ダウンロードページに行って、「WordPress x.x.x をダウンロード」をクリック。

最新バージョンを示す数字はその時々によって変わります。

ZIPファイルを解凍して、wordpressフォルダの中身をhtml/appフォルダの中に移動させます。

（html/appフォルダの直下にwp-adminフォルダなどが来る状態にします）

.htaccessファイルが同梱されていないと思うので、公式サイトからテンプレートをコピペしてきてhtml/app/.htaccessとして保存します。

存在しない場合はWordPressでエラーが発生しつつインストールの手順を進めることになるのだ。

（コピペ用のwp-config.phpファイルのソースが表示されるので、コピペしてhtml/app/wp-config.phpを新規作成すれば完了しました）

Phew WP（再掲）

なおプレビューに設置している次のファイルはこの段階では作らないでください。

  • html/src/public/.htaccess
  • html/src/public/wp-admin/.htaccess
  • html/src/public/wp-admin/.htpasswd

次のコマンドでコンテナを起動。

docker compose up -d

http://localhost:8880にアクセスするとWordPressのセットアップ画面に変わっていますので必須10項目の設定開始。

ようこそ

「さあ、始めましょう！」をクリック。

設定（１）
  • データベース名: docker_db
  • ユーザー名: docker_user
  • パスワード: docker_pw
  • データベースのホスト名: db
  • テーブル接頭辞: wp_

「送信」をクリック。

「インストール実行」をクリック。

設定（２）
  • サイトのタイトル: test（適当なものでよい）
  • ユーザー名: docker_user
  • パスワード: docker_pw
    • 脆弱なパスワードの使用を確認: チェックを入れる
  • メールアドレス: admin@docker.test（適当なものでよい）
  • 検索エンジンがサイトをインデックスしないようにする: チェックを入れる

「WordPress をインストール」をクリック。

「ログイン」をクリック。

WordPressダッシュボードへのログイン画面
  • ユーザー名またはメールアドレス: docker_user
  • パスワード: docker_pw
  • ログイン状態を維持する: チェックを入れる

「ログイン」をクリック。

WordPressのインストール完了を確認

WordPressダッシュボードから「サイトを表示」をクリック

http://localhost:8880が開かれるので、WordPressテーマが表示されているかを確認すれば完了です。

制作環境を作る

gulp.jsを使うので、必要なパッケージを導入します。

ターミナルから次を実行。

npm init -y
npm i -D autoprefixer cross-env dotenv esbuild glob gulp gulp-filter gulp-plumber gulp-postcss gulp-pug gulp-rename gulp-sass gulp-sharp-optimize-images postcss-csso sass tailwindcss
npm i -D --include-optional sharp
npx tailwindcss init

ファイルを作る（２）

  • .env
  • gulpfile.mjs
  • package.json
  • tailwind.config.js

.env

*_SERVERの設定は、レンタルサーバのドメインに合わせて書き換えるなり煮るなり焼くなり。

package.json

package.jsonは次の変更を行います。

  • scriptsプロパティの変更
  • mainプロパティのファイル拡張子を「.mjs」にする
  • typeプロパティを追加
  • versionプロパティを更新

versionはCSS・Javascriptファイルのキャッシュ切りの他、バージョン表記をする時に使います。

tailwind.config.js
  • tailwindcss/pluginをimportする（pluginsプロパティでの拡張に使う）
  • TailwindCSSの「dark:**」を使えるように、darkModeプロパティを追加
  • contentプロパティでTailwindCSSの処理対象ファイルを指定
  • theme.extendプロパティで色とかフォントとか拡張
  • pluginsプロパティでTailwindCSSにないコンポーネントを追加

ちょっとゴリゴリに改造を施しました。

CMSを作る場合はこれくらいの規模でやった方が後々楽かなって。

制作

制作環境ができたら制作開始です。

開発モードを起動しっぱなしにしておいてください。

ちなみにGitに登録するならこの段階がおすすめ。

コマンド

開発モード
npm run dev

WordPressダッシュボードから「サイトを表示」押下、またはhttp://localhost:8880にアクセスすることで表示される。

gulpのwatchが効いている状態なのでフロントエンドを作り込む時に使う。

オートリロード機能はないです。

製品モード（ローカルサーバ）
npm run local

同じくhttp://localhost:8880でアクセスすれば表示されるものを出力する。

gulpのwatchをしないだけだが、サーバサイドを作り込む場合は逆にこっちの方が使い勝手が多分いい。

製品モード（レンタルサーバ）
npm run server

link[rel="canonical"]などのパスを、.envで設定した本番環境向けに変更して出力する。

開発が終わったら開発モードをCtrl + Cで終了して、製品モード（レンタルサーバ）で書き出し。

それが終わったら、html/appフォルダの中身のhtml/app/wp-config.phpを除く全ファイル・フォルダをレンタルサーバにアップロードすれば公開・更新処理は完了です。

ただし初アクセス時はWordPressのセットアップ画面が始まるので、.htaccessや.htpasswdファイルなどでアクセス制限を掛けた方がよいと思われる（後述）

セットアップ画面で入力するデータベース情報はDockerのものとは違うはずなので要注意。

そもそもレンタルサーバでのMySQLデータベースを用意しないといけない。

サーバパネルなど作成する手段が用意されているなら実行。

phpMyAdminがあるなら「CREATE DATABASE IF NOT EXISTS docker_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;」で作成。

それすらない場合はSSH通信などでがんばれー。

WordPressテーマファイルの作成

  • html/src/public/wp-content/themes/docker_theme/footer.php
  • html/src/public/wp-content/themes/docker_theme/functions.php
  • html/src/public/wp-content/themes/docker_theme/header.php
  • html/src/public/wp-content/themes/docker_theme/screenshot.jpg
  • html/src/public/wp-content/themes/docker_theme/style.css
  • html/src/wp-content/themes/docker_theme/index.pug

上記のファイルが揃うと、開発モードの変換処理を通じて、WordPressダッシュボード 外観 テーマに「Docker WP」というテーマが作成されるはず。

html/src/public/footer.php
html/src/public/header.php

wp_head()関数とwp_footer()関数を含めた、共通ヘッダ・共通フッタ処理を書きます。

それぞれはテンプレートファイルからget_header()・get_footer()関数で呼び出し可能。

functions.php

中身なしの空ファイルでいいです。

ファイルが存在していることが大事。

screenshot.jpg

jpeg形式でなく、png形式でも問題なし。

画像サイズは1200px × 900pxの、4 : 3比率。

なんかネット検索だと880x660が最適って記事がやたらと目に付きますが、公式テーマも公式ドキュメントも1200x900になってるんでそれに倣いました。

style.css

テーマ名の定義のためだけの存在。

html/src/index.pug

テーマのindex.phpになります。

404.pug・single.pug・page.pug・search.pugなど、WordPressのテンプレートヒエラルキーに沿ったファイルを作るとCMSらしくなります。

Pugで作らずPHPで直接書きたい場合はhtml/src/wp-content/themes/docker_themeフォルダでなく、html/src/public/wp-content/themes/docker_themeフォルダにPHPファイルとして設置してください。

制作用フォルダの構造

  • html/
    • app/
    • src/
      • css/
      • img/
      • js/
      • public/
        • favicon.icoなど
        • wp-admin/
        • wp-content/themes/docker_themes/
          • functions.phpなど
      • wp-content/themes/docker_theme/
        • index.pugなど
html/app/

ドキュメントルート。

http://localhost:8880にアクセスした時の対象フォルダはここ。

gulp.jsで自動処理されてくるので基本的には触りません。

WordPressのpluginsを追加するとか、そういう時くらい。

html/src/css/

Sass (SCSS)ファイルです。

html/app/cssフォルダに出力します。

html/src/img/

このフォルダに格納した画像ファイルは、圧縮処理またはWebP変換処理を加えた上でhtml/app/imgフォルダに出力します。

header.jpgが存在する場合、header.jpg（圧縮済み）とheader.webpになります。

html/src/js/

TypeScriptファイルです。

html/app/jsフォルダに出力します。

html/src/public/

このフォルダはhtml/appフォルダに出力されます。

html/src/public/favicon.icoなどがあると、html/app/favicon.icoとして出力します。

同階層同名のファイルが存在する場合は、既存のファイルを上書きします。

それを利用して、.htaccess関連のファイルを後で設置します（後述）

html/src/public/wp-content/themes/docker_theme/

Pug変換を行わないWordPressテーマファイルを設置します。

WordPressのフォルダ構造に合わせた深さになりますね。

html/src/wp-content/themes/docker_theme/

Pug変換を行うWordPressテーマファイルを設置します。

同じくWordPressのフォルダ構造に合わせた深さ。

作例

Phew WP（再掲）

改めてソースファイル。

まだ.htaccess・.htpasswdは作成・編集しないでくださいな。

npm

npm i smooth-scrollbar

WordPress設定

パーマリンク

WordPressダッシュボード 設定 パーマリンクと選択して、パーマリンク構造を「基本」から「投稿名」へ変更してから「変更を保存」する。

テーマ

html/app/wp-content/themes/の中の、docker-wpと最新の公式テーマ（執筆時点ではtwentytwentyfour）以外を削除。

WordPressダッシュボード 外観 テーマと選択して、現在選択中の「Docker WP」と最新の公式テーマ以外が削除されていることを確認する。

テーマ「Docker WP」を選択して、「有効化」をクリック。

プラグイン

html/app/wp-content/plugins/の中の、index.php以外を削除。

WordPressダッシュボード プラグイン インストール済みプラグインと選択して、「利用可能なプラグインはありません」と表示されていること（プラグインが全削除できていること）を確認する。

何かインストールしたプラグインがあればフォルダに適当に投入。

投稿と固定ページ

WordPressダッシュボード 投稿 投稿一覧

初期データを全て削除する。

WordPressダッシュボード 固定ページ 固定ページ一覧

初期データを全て削除する。

カスタムフィールド

WordPressダッシュボード 固定ページ 新規固定ページを追加

まだ投稿はしないです。

カスタムフィールドを表示する設定だけ行います。

右上のオプション（「︙」アイコン）を開いて「設定」をクリック。

一般 高度な設定 カスタムフィールドまで進んで、これを有効にします。

ページの再読み込みを促されるので従ってから退出。

固定ページのデータ作成

今回は固定ページのサムネイル画像をカスタムフィールドで管理します。

本来WordPressのブロックエディタだと、「ブロックの追加」ボタンから「投稿のアイキャッチ画像」を選択するだけで完了しますがこれって画像は1種類しか指定できないんです。

WebP画像とJPEG画像を両方使ったサムネイル画像表示ができないので少々無茶をしました。

PAGE_1
  • タイトル：PAGE_1
  • 表示状態：公開
  • URL：page_1
カスタムフィールド：heading
img/header-page1.jpg
本文

妹の夫まで呼び寄せた私が、その時の私はすでに大学生であった。幸いにＫはまたそれと前後して死んでしまったのです。

どうも様子が少し変だからなるべく傍にいる私は、頭を使う込み入った問題には触れませんでした。

私にいわせると、彼の顔色や眼つきは、全くそこにはまるで注意を払っていないらしかったからです。

私の性質としてその妻をいっしょに連れて来た。自分でよく知っているくせに、白粉を豊富に塗ったものだから仕方がないとも思っていた。しかも傍のものが全く性質を異にして、こっちから自分の未来を想像して見ると叔父の態度にもお嬢さんもお帰りと坐ったまま腰を浮かした時の事でした。

それでも私はこの場合もあるいは彼にとっても、痛ましい極端としか私にはなぜか金の問題が遠くの方に妾をもっていた。

しかし私は誘き寄せられるのが辛いなどという言葉を連想し出しました。私は彼に向って書見をしてくれと頼みました。私はその時何かいいはしなかったかと声を掛けた。

世の中では否応なしに自分の前が塞がったのではありませんかそれはそうかといって、軽く驚いた時の事などを書き連ねた。

遠い往来を荷車を引いて見られるのかと聞きました。私は会釈して外へ出て何かしている先生でないような変な紙に思われたのである。しかし先生が干した椎茸なぞを食うかしら旨くはないが、始終接触して親しくなり過ぎた男女の間に結ばれた新しい関係について正月以後何にも知らせたくないのかと聞けばよかったのです。

PAGE_2
  • タイトル：PAGE_2
  • 表示状態：公開
  • URL：page_2
カスタムフィールド：heading
img/header-page2.jpg
本文

私は先生が私の顔を見ても、そら年が上でしょうだから先へ死ぬか、奥さんが席へ現われる場合などには、私の運命に非常な変化を来しています。

けれども先生の思想の方がいつでも大抵宅にいる時の事などを話した。私はそうした腹ができても、どこからか頭の底に這い込んで来た。

そうして私を苦しめます。はたして大丈夫なのだろうかと思って下さい。大病は好いが、呼ばないとまた何とかいう文字のまだない時分でした。

そうして駄菓子屋の上さんに教わった通り、それからまた一年経っても開きません。

私は彼の健康と精神の上に落ちた手拭を拾い上げているところでも悉皆は私にとっては非常な重大事件に見えたのでしょう、いつでも呼んで、必要の書物を、二、三年来また急に盛り返して来たのは突然でも、俗にいう神経質という意味をもっと判然いって聞かして下さい。

私の性質としている間に、こっそりこの世からいなくなるようにして話しかけた時のように、ちやほや歓待されるのに、東京で好い地位を求めろといって、手紙でその様子を聞き合せたりした結果兄は今遠国にいた時より、かえって賑やかで陽気になったのだろう。なにね、自分で厭になったのです。

今度いらっしゃるときっと吃驚しますよ、変っているところへ母が顔を出した。九月始めになっていましたが、私の運命が本当に気の毒になったんだがなあ先生の言葉が私の背後で打ち合せをした経験のない当時の私の心は動いたらしいのです。

散歩として変な顔をして見ようかという疑念が絶えず私を制するようになったのか、いないのだというのです。じゃ失礼ですがもっと真中へ出て来なかったのです。

私は父や母のいた時と全く同じ事であった。

アクセス制限

最後に。

本番環境に最初にアップロードする時はhtml/appフォルダの階層全体、公開が完了した後でもhtml/app/wp-adminフォルダの階層（WordPressダッシュボード）にはセキュリティの問題からアクセス制限を掛けておくと安全。

ただし開発中の段階からBASIC認証がポンポン出てくるのは邪魔なので、ここまでは.htaccessファイルを作成・編集しないように書いていたのでした。

パスワードを生成する

Docker Desktop Containersの一覧から、Nameの所が「web」あるいは「web-（何か数字）」になっている行を探してクリック。

トップメニューのExecをクリックすると、Dockerコンテナ内のターミナルに入ります。

ログインするユーザ名・パスワード・4から31までの中で好きな数字を決めてコピペします。

コピペはControl + Vではなく右クリックメニューから「Paste」をクリックなので注意。

htpasswd -nb -B -C 【好きな数字】 【ユーザ名】 【パスワード】

【ユーザ名】:【暗号化されたパスワード】が出力されるので、1行まるごとマウスで選択して、右クリックでコピーしておきます。

好きな数字とは？

パスワードの強度です。

数字が大きいほどパスワードを突破されにくくなる一方で、計算に時間が掛かるためページ表示が遅くなります。

脆弱パスワードにご用心

ユーザ名とパスワードの情報を保存する.htpasswdファイルですが、「htpasswd」でGoogle検索するとLUFTさんのhtpasswd作成ページが最上位に来ます。

あちら様に敵意はないんですが、これは危ないので使わないように。

パスワードの暗号化にはいくつか種類があって、こちらで使っているアルゴリズムはcrypt形式による暗号強度の低いやつでして。

今回指定したのはbcrypt形式で、2024年6月時点では最も暗号強度の高いのを採用しています。

安全第一。

絶対パスを確認する

最初にDockerの起動テストをした時に、$_SERVER["DOCUMENT_ROOT"] の内容をメモに残しておきました。

これが.htaccessから.htpasswdを呼び出す時のために必要になります。

開発モードで実行した場合は「/var/www/html」になると思いますが、レンタルサーバではどのようなディレクトリパスが出てくるか分かりません。

XSERVERのサブドメインを切った私の場合だと「/home/【アカウントID】/【ドメイン名】/public_html/【サブドメイン名】」になりました。

ローカルサーバの場合は「/var/www/html/.htpasswd」が同ファイルへのパスになります。

またwp-adminフォルダ（ダッシュボード）へのアクセス制限を行う場合は「/var/www/html/wp-admin/.htpasswd」も必要になるでしょう。

.htaccessをコピペする

html/app/.htaccessを、html/src/public/.htaccessにコピーしてきます。


# BEGIN WordPress
# "BEGIN WordPress" から "END WordPress" までのディレクティブ (行) は
# 動的に生成され、WordPress フィルターによってのみ修正が可能です。
# これらのマーカー間にあるディレクティブへのいかなる変更も上書きされてしまいます。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

多分こんな状態になっているかと思われる。

この1行目に挿入する形で、次のように編集・上書き保存します。

<FilesMatch "^\.ht">
  Deny from all
</FilesMatch>

AuthUserFile 【.htpasswdへの絶対パス】
AuthName "Please enter your ID and Passwd."
AuthType Basic
require valid-user
Order deny,allow


# BEGIN WordPress
#（以下略）

.htpasswdを作成する

html/app/.htpasswdを新規作成して、生成したパスワードをコピペ保存します。

必ず最後に空白の行が必要なので要注意。

wp-admin用の.htaccessと.htpasswd

今の手順は初回アップロード時の、WordPress全体に掛かるアクセス制限です。

WordPressダッシュボードへのアクセス制限を掛ける場合は、追加手順としてhtml/src/public/wp-adminフォルダに.htaccessファイルを新規作成してください。

<FilesMatch "^\.ht">
  Deny from all
</FilesMatch>

AuthUserFile 【.htpasswdへの絶対パス】
AuthName "Please enter your ID and Passwd."
AuthType Basic
require valid-user
Order deny,allow

今回はリダイレクト処理は不要なので上例の部分だけでいいです。

.htpasswdへの絶対パスには「wp-admin/」が追加されているので間違えないように。

そして.htpasswdも同様の手順で、パスワード生成・ファイル新規作成・コピペ保存です。

製品モード（レンタルサーバ）で書き出してアップロード

npm run server

この状態で書き出してレンタルサーバにアップロードすれば、BASIC認証によるアクセス制限が効いているためWordPressダッシュボードに第三者が乱入してくる危険性は大幅にカットできるはず。

そして公開が終わったら、

  • html/src/public/.htaccessの、.htpasswd読み込み部分の削除
  • html/src/public/.htpasswdの削除
  • html/app/.htpasswdの削除
  • npm run serverの実行
  • サーバ上の.htpasswdを削除
  • サーバへアップロード

の手順を踏むとBASIC認証は外れます。

wp-adminフォルダ側は引き続きアクセス制限を掛けた方が良いと思われる。