iPad AirでLaravelの開発環境をインストールした2023年8月13日の検証備忘録。Laravel v8.83.27, PHP 8.0.24, のブラウザ上動作確認まで。

• アプリケーション用意
• 必要ライブラリインストール
• 実行

の三本立てである。

アプリケーション用意

App StoreでiSH Shellをインストールする。

仮想化か何かをするアプリのようで、alpine linux環境がまんま使える様子。

インストールするとすぐに立ち上がってLinuxログイン後の状態から使えるのでエンジンスタートは非常に速い。ただ、パフォーマンスは期待出来ない（ライブラリインストール等気長に待つ）所感。

特記事項

１．どうにも困った時はホームに戻りアプリを消せばログインからになる

２．画面上での特殊なキーボード入力

画面左下に４つのキーボード入力ボタンがある。「→|」「＾」「↑」「☩」なマーク。

一番左「→|」はタブだから入力補完に使える。

次にＣｔｒｌだから「＾」を入力した後にCを入力すれば実行していた処理中断に使える。

その次は謎ボタン。電源っぽく見えるマークだから未使用。

その次は上下左右（フリックで入力）である。

３．文字処理

コンソール上テキスト部分をタップしたままにしておけば文字選択状態になる。

この機能でコピー・ペーストによる他アプリ連携が可能である。

必要ライブラリインストール

サクッと必要ライブラリをインストールする　※要：時間がかかる覚悟

apk add php8
apk add composer unzip openssl
apk add php8-openssl php8-mbstring php8-phar php8-dom php8-xml php8-xmlwriter php8-fileinfo php8-iconv php8-tokenizer php8-session
ln -s /usr/bin/php8 /usr/bin/php

本件用プロジェクトを用意する　※要：時間がかかる覚悟

cd
mkdir 20230813
cd 20230813
composer create-project laravel/laravel test
cd test

実行

composer install
php artisan serve

ここまですればアプリに必要なライブラリインストールの上テストサーバーが立ち上がる。画面上で案内されるように http://127.0.0.7/ にアクセスすればLaravelのアプリ動作をブラウザ上で確認できる。

特記事項

デフォルトのブラウザはセキュリティ上の都合でhttpsでないとアクセスしてくれないかもしれない。その場合別のブラウザをインストールして試そう。毎度履歴が消えるFireFox Focusが開発にオススメ。

作りたいものによってはPHPの設定変更が要るかもしれない。その場合 /etc/php8/php.ini を編集して使うのだ。

ブラウザからアクセスする時にiSH Shellアプリが停止状態では応答を得られない。php artisan serve でWEBサーバーを立ち上げた後、ブラウザ側で対象URLにアクセスする。その後応答を得られないようであればWindowを並べる・元のiSH Shellウィンドウに戻るなどしてiSH Shellの処理が続くように工夫してみてほしい。

この後したくなるのはDBインストール・連携だが、ここまでの経緯同様に好みのDBをapk addでインストール→好みのDBドライバをapk add php8-hogefuga→アプリ設定に書き足して実行すればなんとかなるはず。

WordPress 6.1.1環境でマルチドメインサイト運営するまでの設定備忘録である。

経緯

WordPressにはマルチサイトモードがあり、公式機能で複数のサイトを運営できる。

デフォルトでは１つのサイトを運営するのみだが、マルチサイトモードを有効化すると「ネットワーク」を作成出来る。そのネットワークの下に管理・運営したいサイト一つ一つを作成して運営していこうという流れになるのだが、この運営方法の解説が曲者。

マルチサイトモードで『サブサイトやサブディレクトリでの複数ドメイン利用は可能』とあるが、『マルチドメインサイトの運営は可能』との記載は見つからないのだ。

運営方法種別	URLの例	判断
サブドメイン	https://example.com/ https://sub.example.com/	実現可能
サブディレクトリ	https://example.com/apple/ https://example.com/orange/	実現可能
マルチドメインサイト	https://example.com/ https://example.jp/	記載なし

具体的なURL例を挙げれば上記「表１」の通り。

実際にマルチドメインサイトで利用を試みても、サブドメイン情報が固定で載るため『やはりマルチドメインサイトには対応していないな』で諦めがちだ。しかし編集すればなんとかなる。

設定フロー

1. マルチサイトモード有効化
2. ネットワーク作成
3. WEBサーバー設定
4. サイト設定

１．マルチサイトモード有効化

wp-config.php の90行目辺り、define( ‘WP_DEBUG’, false ); の後ろ辺りに以下記述を追加

define( 'WP_ALLOW_MULTISITE', true );

２．ネットワーク作成

WordPress管理画面のメニュー「ツール」配下「サイトネットワークの設置」項目が増えるので遷移。

「サイトネットワーク名」に運営するサイト群の総称、「サイトネットワーク管理者のメールアドレス」に管理者メールアドレスを入力し「インストール」でネットワーク作成は完了する。

３．WEBサーバー設定

サイト設定追加後にアクセス出来るように、DNS / WEBサーバー / WordPress設定を変更する

※元々うまくアクセス出来るよう設定してあるものは省略して良い

DNS

example.jp を追加する場合、 A・AAAA・CNAMEレコードを追加しWordPressを載せたサーバーへアクセス出来るようにする

WEBサーバー

apache ならば Virtual Host 設定追加、 nginx であれば server 設定を追加するイメージ。ようは、WEBサーバーに設定したいドメイン名でアクセス出来るようにWEBサーバー設定を変更すれば良い。

WordPress設定

「２．ネットワークの作成」のインストール後に表示される wp-config.php 設定事項＋αを define( ‘WP_ALLOW_MULTISITE’, true ); の行に続けて挿入する。

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/article/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

注意事項として、一部設定は環境により異なる。

• SUBDOMAIN_INSTALL は false の場合も必ず true に変えて記述
• DOMAIN_CURRENT_SITE は最初にインストールしたドメイン名が入っていれば良い
• PATH_CURRENT_SITE はWordPressをDocumentRootにインストールした場合は / となり、サブディレクトリなら上述の /article/ のようにWordPressインストールフォルダを指定してあれば良い
• SITE_ID_*, BLOG_ID_* は固定項目なのでコピペで良い
• どこから来たのか＋α。define(‘COOKIE_DOMAIN’, $_SERVER[‘HTTP_HOST’] ); は各サイトでのログインを確立するには必要なので深い決め・厳密な考慮がなければとりあえず入れておくこと

４．サイト設定

WordPress管理画面上部メニュー『参加サイト→サイトネットワーク管理→サイト』を辿る

サイト追加画面ではサイトアドレスに最初に登録した .example.com が自動で付与される。そのまま「サイトを追加」し、後で編集するのがみそだ。

再度WordPress管理画面上部メニュー『参加サイト→サイトネットワーク管理→サイト』を辿り、追加したサイトのURLにカーソルを合わせると『編集』メニューが表示されるので遷移する。

ここで自由に編集出来るので、実際にアクセスしたいURLを設定する

確認

ここまで設定出来れば、追加したURLへアクセス出来るか確認。

ネットワークからテーマを追加⇒有効化し、一部のサイトのみでテーマを適用、更にそのサイトのみに投稿すれば、投稿内容もテーマも異なる別々のサイトを運用していると実感出来るはずだ。

ノーマライズ（Normalize）とカノニカライズ（Canonicalize）の違いをまとめた。両方とも数学・コンピュータサイエンスの世界では正規化と翻訳され、構造の標準化・簡易化を意味するが、概念・処理内容は異なる。

※音楽に対するNormalizeは音の大きさを合わせること。これは毛色が異なる処理のため対象外とする

結論

Normalizeのゴールは項目内部での冗長削減である。

対して、Canonicalizeのゴールは項目間での横断的な比較体制の確立である。項目間に相違ないか確認できるよう表記を統一すると言っても良い。Normalizeにある冗長削減は必須でないが、Normalizeにない項目間比較のためのユニーク制約を含む文脈的な対応となる。

シンプルな例でイメージを掴む

数式の例：

• Y = 32 + 2X + 8a + 4
• 32 -2x + y = 8b+4

これら二つの数式をNormalize（冗長削減）すると、それぞれ『Y=36+2X+8a』、『28-2x+y=8b』に出来る。「同類項はまとめられるし、半角スペースは表現の無駄だから消して冗長を削減しよう」という話である。

Canonicalizeは目的によって実施事項が揺れる。

同じ表記にして、項目間に違いがあるか、同じ項目のことを表しているかを明らかにするのがCanonicalizeのゴールだから、式の目的により『同じ項目』の定義が変わってくる。

字ずらが違ったら別のもの扱いしたい：

両方の式がCanonicalize済みの状態。完全一致しないから、二つの式を比較出来て両者に相違ありと機械的に判断できる。

項目を維持した状態で比較したい：

『変数を昇順、定数を昇順（a, bは数値よりも先に記載）、末尾は = 0 で終える』と表記のルールを決めれば『-2X + Y -8a – 32 – 4 = 0』、『-2x + y – 8b + 32 – 4 = 0』にCanonicalize出来る。統一した表記方法になっているから二つの式を比較出来て大文字X, 小文字xの差により両者に相違ありと機械的に判断出来る。

簡素化した式に相違ないか比較したい：

大文字小文字に意味がなく、定数のa, b, c もただの表記ゆれというなら二つの式は『-2x + y -8a – 36 = 0』、『-2x + y – 8a + 28 = 0』にCanonicalize出来る。統一した表記方法になっているから二つの式を比較出来て-36と28の差により両者に相違ありと機械的に判断出来る。

URLの例：

• /home/canonical/shortcut/test/url/
• /hoge/../test/url/
• /test/url/index.html
• /test/url/
• /test/url

※shortcut は /test へのシンボリックリンクとする、index.html はDirectoryIndex設定済みする。

Normalizeすると、二つ目は『/test/url/』にNormalize（冗長削減）出来る

対して、末尾スラッシュありのURLにCanonicalizeすると５項目ともすべて /test/url/ に置き換えられ、同一の基準でURLを比較できる。

※例では静的URLのみを取り扱ったが、#での見出し有の場合や?でのクエリありの場合、更にそのヴァリエーションとして ?hoge=a&fuga=b、?fuga=b&hoge=a、?hoge=a&hoge=aa&fuga=bなんかも取り扱ってみるとよりCanonicalURLの学びになる

※一つのサーバー上でのURLを取り扱ったが、複数サーバーの存在を考慮してURLをCanonicaizeするならドメイン名/ホスト名も含めて考えることとなる

XMLの例：

• <record data1=”x” data2=”y” />
• <record data2=”y” data1=”x1″></record>

Normalizeすると二つ目は<record data2=”y” data1=”x” />に出来る。

『要素（data1, data2）を昇順に並べる』とルール化してCanonicalizeすると二つ目は<record data1=”x1” data2=”y” />となり、表記を統一したので内容が同じか比較しやすくなった。data1の値に相違があるため異なる内容を表すと比較出来る状態となった。

歴史

数学世界ではCanonicalizeは１９００年代（１９００～１９１０年）には存在した話。コンピューターを利用するようになり、データの表記揺れ対応や冗長削減対応が増えたから大きく注目を浴びるようになったようだ。