かもメモ

自分の落ちた落とし穴に何度も落ちる人のメモ帳

WordPress SSL 化のメモ

化石のような WordPress サイトのアップデート案件があり付随して SSL 化されてなかったので SSL 化したのでログとしてのメモ。

1. テーマ内にハードコーディングされている URI を修正する

OGP設定や CDN などテーマ内にハードコーディングされている http から始まる URI があれば https 始まりに修正する。サイト内で参照しているパスであれば / 始まりに変更しておく方が今後の取り回しが楽になりそう。

2. 管理画面で httpURI が入力されている箇所を修正する

2-1. 一般設定 WordPress のアドレス・サイトアドレスを修正

WordPress > 設定 > 一般

WordPress アドレスサイトアドレスhttps から始まる URI に変更して保存

2-2. [Optional] メディアのアップロード先を変更している場合はフルパスを修正する

WordPress > 設定 > メディア

ファイルアップロード > ファイルへの完全な URL パスhttps から始まる URI に変更して保存

3. 投稿などに含まれる URI の置き換え

投稿など Database に保存されているコンテンツ内に http から始まるものがあれば https に置き換える。 全てのコンテンツを目視で確認するのは大変なので search-regex というプラグインを使うのが楽。

4. http から始まる URI でアクセスされた場合に https にリダイレクトさせる

SSL 化前の http から始まるアドレスでアクセスされた場合に https に自動的にリダイレクトするようにする。
WordPress を設置しているサイトの root の .htaccess に下記を追加する

.htaccess

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

⚠ リダイレクトの設定は WordPress のルールより先に書かないと上手く動作しない

https にリダイレクトするルールは WordPress が出力するルールより先に記述されていないと https にリダイレクトされないので注意が必要

.htaccess

# WordPress のルールより先に https へのリダイレクト設定のルールを書く
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
...

WordPress は構造上アクセスを root の index.php に送って Routing しているので、先に WordPressindex.php へのリダイレクトルールがあると https へのリダイレクトが上手く動作せず、先に https へのリダイレクトルールが有る場合は先に https にリダイレクトさせた URIindex.php に渡して WordPress のルーティングさせるので上手く動作する。という認識です。(正確ではないかもです)

これで SSL 化されてない WordPressSSL 化対応を行なうことができました。
テーマ内の JS や CSS など発見が難しい所にハードコーディングされた URI があると結構ハマりどころなので、極力 / 始まりの URL を使ったり WordPress の設定から URI が生成できる hooks ・メソッドを使っておくのが良さそうだと思いました。

更新やメンテナンスをせずに何年もたったサイトを一気にアップデートするのはメンテせずに築年数のたった家を一気にリフォームするようなもので工数・金額もかかってしまいますから、サイト管理者の方はホントランニングコストかけてでも定期的にメンテした方が良いと思います… (本当にお願いします…)

おわり


[参考]

Docker WordPress コンテナから MySQL コマンドが使いたい

三畳紀ぶりに WordPress の案件があって触ってます。
20世紀みたいに PHP 環境を local に作るのつらすぎるので docker を使ってい環境構築していたのですが、WordPress のコンテナから mysql コマンドが使えなかったので使えるようにしたメモ

Docker WordPress 環境構築

公式のチュートリアルにある構成を利用する

docker-compose.yml

version: '3'
services:
   mysql:
     image: mysql:5.7
     volumes:
       - ./docker/mysql/data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
       MYSQL_DATABASE: ${DB_DATABASE}
       MYSQL_USER: ${DB_USER}
       MYSQL_PASSWORD: ${DB_PASSWORD}

   wordpress:
     depends_on:
       - mysql
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     volumes:
      - ./app/public:/var/www/html
     environment:
       WORDPRESS_DB_HOST: mysql:3306
       WORDPRESS_DB_USER: ${DB_USER}
       WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}

cf. クィックスタート: Compose と WordPress — Docker-docs-ja 20.10 ドキュメント

配布されている wordpress イメージには mysql コマンドが含まれてないっぽくコンテナ内から接続を試みても command not fount: mysql になってしまう

$ docker compose up -d
$ docker compose exec wordpress mysql -h mysql -u root -p
command not found: mysql

mysql-client をコンテナにインストールすればOK

depends_on で database のコンテナとは接続できているので、単純に mysql コマンドが使えるようにすれば良いっぽい
wordpress コンテナに mysql-client をインストールするように変更する

docker-compose.yml

   wordpress:
     depends_on:
       - mysql
-    image: wordpress:latest
+    build:
+      context: "./docker/wordpress"
+      dockerfile: "Dockerfile"
     ports:
       - "8000:80"
     restart: always
     volumes:
      - ./app/public:/var/www/html
     environment:
       WORDPRESS_DB_HOST: mysql:3306
       WORDPRESS_DB_USER: ${DB_USER}
       WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}

./docker/wordpress/Dockerfile

FROM wordpress:latest
# Install MySQL client
RUN apt-get update && apt-get install -y sudo less default-mysql-client

cf. installing mysql client on docker php - Super User

  • mysql-client だとインストールできなかった。どうやら default-mysql-client が正しいっぽい。 mariadb-client にすればインストールできるという記事もあったが MySQL を使っているので default-mysql-client をインストールするようにした
  • apt-get ではなく apt を使うべきという記事も見かけたが wordpress のコンテナでは apt コマンドが使えなかったのと、apt から apt-get が推奨に戻っているっぽかったので apt-get を使用した。(この辺りは知識不足です)

動作確認

Docker コンテナを再ビルドして wordpress コンテナから mysql コマンドでデータベースに接続できれば OK

$ docker compose build
$ docker compose up -d
$ docker compose exec wordpress mysql -h mysql -u root -p
Enter password: $DB_ROOT_PASSWORD
MySQL [(none)]> 

₍ ᐢ. ̫ .ᐢ ₎ できた!
Docker 便利なのですがインフラとか環境構築系の知識が付け焼き刃なのでいつもハマってしまいます… 1年ほどコード書いてなかった期間もあったのでことごとく忘れてるし… ちからが欲しい…


[参考]

WordPress PHP7.3にしたらデフォルトテーマでno more memoryってWarningが表示された件

phpbrewでPHP 7.3.1をインストールしてPHPのバージョンを上げました。
問題がないかローカル環境でWordPressの動作を確認した所、次のようなWarningが表示されていました。(確認用にローカル環境はWarningも表示する設定にしています)

Warning: preg_match(): JIT compilation failed: no more memory

PHP7.3のバグっぽい

この記事を書いたではPHP7.3のバグが原因で、解決方法としてはphp.iniコメントアウトされている;pcre.jit=1pcre.jit=0として有効にすればいいっぽい。

php.iniの場所

$ php --ini
Configuration File (php.ini) Path: /Users/<USER_NAME>/.phpbrew/php/php-7.3.1/etc
Loaded Configuration File:         /Users/<USER_NAME>/.phpbrew/php/php-7.3.1/etc/php.ini

php.ini を編集する

pcre.jitで検索して、pcre.jit=0を追加

; Enables or disables JIT compilation of patterns. This requires the PCRE
; library to be compiled with JIT support.
;pcre.jit=1
pcre.jit=0 ; <= 追加

apacheを再起動

$ sudo apachectl restart

ブラウザをリロードしたらWordPressで表示されていたWarningは表示されなくなりました!
とはいえPHP側のバグなようなので、いずれまた修正しないとだめになりそうです... (′• દ •‵)
PHP 7.3 って2018年12月にリリースされたばかりだったんですね…
バグってやがる。早すぎたんだ…
安定版みたいに書かれてたからインストールしたのですが、リリースされてすぐのものには気を付けないとダメですね、、、


[参考]

Apache 2.4 も MySQL 8 も色々あったんだゼ... (解決したら戻さないといけないからセルフメモ