このページは、システム管理者がルーティングエンジンを正しく設定するためのものです。
Moodleは、ハイパーリンクで相互にリンクされた何千ものウェブページで構成されています。HTMLはプログラミング言語ではなく静的なマークアップ言語であるため、それ自体では変数やリンクを動的に処理できません。
PHPは、Moodleを動かしているサーバサイドのプログラミング言語です。PHPは内部でデータ変数を使用しますが、従来のPHPでは、ページ間で情報を受け渡すために、ウェブリンクの末尾に付加された煩雑な「クエリ文字列」(?id=123など)に頼っています。
そこで登場するのがルータです。ルータは、Moodleのウェブリクエストの交通整理を一元的に行うソフトウェア機能です。何千もの個々のPHPファイルへの固定的な直接パスをハードコードする代わりに、すべてのハイパーリンクはこの中央のルータを経由します。開発者がウェブページのファイル名や場所を変更した場合も、リンク切れを修正するために何千ものコードファイルを探し回る必要はなく、ルータスクリプト内の「ルート」ルールを1つ更新するだけで済みます。この一元的な制御により、プログラミングの生産性と品質が大幅に向上するとともに、人間が読みやすいクリーンなURLも実現されます。
ルーティングアーキテクチャは複数のMoodleバージョンにわたって段階的に導入されてきましたが、正式な動作環境チェックと設定に関する警告はMoodle 5.2で明示的に導入されました。Moodle 5.2では、基本的なインストールを完了するために、機能するルータの設定が厳密に強制されるわけではありませんが、Moodle HQは今後の安定版リリースで、完全に機能するルータを必須にする予定です。早めに設定しておくことで、サイトの長期的な安定性と、将来のスムーズなアップグレードが確保されます。
Moodleにはデフォルトでルータのコードが含まれていますが、ルータは、基盤となるウェブサーバに組み込まれている書き換え機能およびルーティング機能に完全に依存しています。これらはMoodleのコードの一部ではありません。
これらの機能がデフォルトで有効になっているウェブサーバもあれば、そうでないウェブサーバもあります。サーバ環境はそれぞれ異なるため、Apache、Nginx、その他のプラットフォームのどれを実行しているかによって、異なる技術的手順を踏む必要があります。すべての環境に通用する万能の解決策はありません。
しかし、Moodleはサーバのハードウェアを自動的に設定できないため、サーバのルータ環境が適切に設定され機能していることを確認する責任は、最終的にはご自身にあります。次の手順に従うことを検討してください。
ステップ1:ルータファイルが存在することを確認する
Moodleは、Moodle 5.1でコアのルーティングアーキテクチャを導入し、Moodle 5.2.0で完全に安定させました。Moodle 5.2以降を実行している場合、必要なフレームワークはすでにコードベースに含まれています。
ルータのエンドポイントがシステム上に物理的に存在することを確認するには、メインのMoodleディレクトリ内を確認してください。public/サブディレクトリがあり、その中に次の2つの重要なファイルがあるはずです:
- index.php - 標準のアセットとエントリポイントを提供します
- r.php - 仮想URLパスを受け取ってルーティングするメインのエンジンです
ステップ2:Moodleのルータをテストする
動作環境の警告について
サイト管理 > サーバ > 動作環境に移動すると、「その他のチェック」セクションにルータが設定されていませんという通知が表示される場合があります。
他の動作環境テスト(データベースやPHPバージョンのチェックなど)とは異なり、Moodleはウェブサーバを能動的に調べて、ルータが機能しているかどうかを確認することはできません。この通知は静的なステータスメッセージであり、リアルタイムのエラートラッカーではありません。config.phpファイルに$CFG->routerconfigured = true;を追加すると警告を非表示にできますが、そうしてもアラートが非表示になるだけで、実際にサーバが設定されるわけではありません。
ルータをテストする方法
サーバのコードを編集する前に、次の簡単なテストのいずれかを実行して、ルータが正しく機能していることを確認してください:
テストA:404動作テスト
https://yourmoodle.com/fakefile.php(Moodleがフォルダ内にある場合はhttps://yourdomain.com/moodle/fakefile.php)など、存在しないパスをブラウザに入力します。
- ルータが機能していない場合:汎用的な、空白の、またはサーバのデフォルトの「404 Not Found」ページが表示されます(多くの場合、白黒のプレインテキストです)。
- ルータが機能している場合:サイトの現在のグラフィックテーマに合わせたスタイルの、Moodleの「見つかりませんでした」エラー画面が表示されます。
テストB:ディープリンクテスト
サイトにログインして任意の有効なコースに移動し、そのコース固有のID(例:19)をメモします。次に、以下のルーティングされたURLをアドレスバーに直接入力します:https://yourmoodle.com/course/19/manage(Moodleがフォルダ内にある場合はhttps://yourdomain.com/moodle/course/19/manage)
- ルータが機能していない場合:ブラウザにサーバの汎用的な「Not Found」ページが表示されます。
- ルータが機能している場合:ブラウザにMoodleの「コース管理」ページが正常に表示されます。これは、ルータが本来どのようにページを処理して配信するのかを明確に示しています。
テストC:システムステータスレポートテスト
ブラウザでサイト管理 > レポート > システムステータスに移動します。
config.phpファイルに$CFG->routerconfigured = true;設定(フラグ)がない場合、またはルータが設定されていない場合、Moodleはルータ設定エラーを表示し、「ルータは正しく設定されていません。」と示します。
ルータ設定リンクをクリックすると、詳細なステータスページが開きます。表示される情報は設定によって異なります:
- config.phpのフラグがない場合:追加の情報は表示されません。
- フラグは有効だが、ルータの設定が誤っている場合:ページに具体的なトラブルシューティングのエラーが表示されます。
- フラグが有効で、ルータが正しく設定されている場合:ページにOKの一覧が表示されます。
テストD:コマンドラインテスト
コマンドラインを使用したい場合は、管理用CLIスクリプトを実行して、同じステータス情報を確認できます:
php admin/cli/checks.php
これらのテストを手元に控えておいてください!現在サイトがこれらのテストに失敗する場合は、次のステップでサーバの設定を完了した後に、同じテストを実行して設定を確認することになります。
ステップ3:ウェブサーバを設定する
Moodleはさまざまなホスティング環境で動作するため、サーバの設定は大きく異なります。以下の例は一般的なガイドラインであり、特定のシステムに合わせて調整が必要な場合があります。Apache、Nginx、IISといったソフトウェアプラットフォーム間だけでなく、cPanelやPleskのような管理ツール間にも大きな違いがあります。すべての環境に当てはまる単一の手順はないため、サーバのルーティングルールの設定は難しい場合があり、それぞれ固有の環境に合わせて慎重に対応する必要があります。
Apache(Apache2)の設定
方法A:メインサーバのバーチャルホストファイル(httpd.confまたはapache2.conf)を使用する
この方法は、コア設定ファイルに直接かつ無制限にアクセスできる、自身で管理する仮想プライベートサーバ(VPS)または専用rootサーバの管理者に最適です。
サーバレベルでルータを設定するには、rootアクセスが必要です。ローカルファイルを使用する代わりに、サイトのディレクトリ設定ブロックでグローバルディレクティブFallbackResourceを指定して、ApacheがMoodleルータをサポートするように指示します。
# Set the server's front door directly to Moodle's public folder
DocumentRoot /var/www/moodle/public
<Directory /var/www/moodle/public>
AllowOverride None
Require all granted
DirectoryIndex index.php
FallbackResource /r.php
</Directory>
サブディレクトリの扱い
FallbackResourceのパスは、指定したDocumentRootからの相対パスです。ルートドメイン(例:https://yourdomain.com)ではなくサブディレクトリでMoodleを実行している場合は、フォールバックパスをそのサブフォルダに合わせて調整する必要があります:
# Example configuration for a Moodle subdirectory installation
DocumentRoot /var/www/html
<Directory /var/www/html/moodle/public>
AllowOverride None
Require all granted
DirectoryIndex index.php
FallbackResource /moodle/public/r.php
</Directory>
- DirectoryIndex index.php:この行は、不要なHTTP 404エラーによってMoodleルータが妨げられないように、フォールバックディレクティブの直前に配置する必要があります。
- Require all granted:これにより、通常のウェブトラフィックが、公開されているMoodleのルーティングエンドポイントに無条件にアクセスできるようになります。
方法B:.htaccessファイルを使用する
.htaccessファイルの使用は、共有ホスティング環境や、cPanelなどのコントロールパネルで管理されているサーバに最適な解決策です。この方法はApacheでのみ機能し、グローバル設定ファイルを変更したり、サーバのルートディレクトリを変更したりする必要はありません。また、シンボリックリンクを使用して複数のMoodleサイトをインストールしている場合にも機能します。多くの場合、ルータを導入する最も簡単で柔軟な方法です。
多くのホスティング業者(GoDaddyなど)は、LinuxとcPanelなどのコントロールパネルをバンドルしています。コントロールパネルが有効な場合、コントロールパネルがサーバのレイアウトを管理し、多くの場合、フォルダ名を変更したり、コア設定をカスタムのシステムサブディレクトリの奥深くに埋め込んだりします。 幸い、.htaccessによる解決策では、グローバルなサーバファイルを完全に回避できます。この方法は、1台のサーバで複数の独立したMoodleインスタンスを実行することもスムーズにサポートします。各サイトの`/public`フォルダに個別の.htaccessファイルを配置するだけです。
.htaccessファイルの作成
以下のルールを含む`.htaccess`という名前の新しいファイルを作成し、Moodleサイトの`public/`ディレクトリに直接配置します。
注:このファイルはピリオド(.)で始まるため、Linuxでは隠しファイルとして扱われます。ファイル管理システムによっては、「隠しファイルを表示する」よう指定しない限り、このファイルが表示されない場合があります。または、作業中は`htaccess.txt`という名前にしておき、`moodle/public`フォルダに置いてから`.htaccess`に名前を変更する人もいます。
# Name this file ".htaccess" and place it into the moodle/public subdirectory.
DirectoryIndex index.php
# Essential if your Moodle environment utilizes symlinks
Options +FollowSymLinks
# Safely disable open directory browsing
Options -Indexes
<IfModule mod_rewrite.c>
RewriteEngine On
# ==========================================
# 1. PATH SECURITY RESTRICTIONS
# ==========================================
RewriteRule "(\/vendor\/)" - [F]
RewriteRule "(\/node_modules\/)" - [F]
RewriteRule "(^|/)\.(?!well-known\/)" - [F]
RewriteRule "(composer\.json)" - [F]
RewriteRule "(\.lock)" - [F]
RewriteRule "(\/environment.xml)" - [F]
RewriteRule "(\/install.xml)" - [F]
RewriteRule "(\/README)" - [F]
RewriteRule "(\/readme)" - [F]
RewriteRule "(\/readme_moodle)" - [F]
RewriteRule "(\/upgrade\.txt)" - [F]
RewriteRule "(\/UPGRADING\.md)" - [F]
RewriteRule "(phpunit\.xml\.dist)" - [F]
RewriteRule "(\/tests\/behat\/)" - [F]
RewriteRule "(\/fixtures\/)" - [F]
RewriteRule "(\/upgrade\.txt|UPGRADING\.md|UPGRADING\-CURRENT\.md)" - [F]
# ==========================================
# 2. HARDCODED MOODLE ENVIRONMENT TEST ROUTES
# ==========================================
RewriteRule ^core/check/controller/test$ r.php [QSA,L]
RewriteRule ^api/rest/v2/openapi.json$ r.php [QSA,L]
RewriteRule ^lib/exampleshimroute2\.php$ r.php [QSA,L]
# ==========================================
# 3. CATCH-ALL ROUTING FALLBACK
# ==========================================
# If the requested file or directory does not exist physically on disk, route to r.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ r.php [QSA,L]
</IfModule>
これは、包括的で本番環境に対応した「.htaccess」設定です。より短いファイルでも技術的には機能しますが、これらの追加ルールは、Moodleのパフォーマンスを損なうことなく、セキュリティと環境への準拠に関する貴重な層を追加します。
標準的なルータの設定には、通常「FallbackResource」ディレクティブが必要です。しかし、この`mod_rewrite`ブロックを使用すると「FallbackResource」が不要になり、スクリプトが特定のMoodleルートフォルダ名を知る必要がないため、柔軟性が高まります。「mod_rewrite」モジュールは、ほぼすべての最新の商用ウェブサーバでデフォルトで有効になっています。
ローカル環境:MAMPおよびLaragon
ローカル開発環境では、この.htaccessファイルによる解決策を利用するために、Apacheを実行する必要があります。ローカルのテストサイトは通常パブリックなインターネットに公開されないため、.htaccessファイルは本番サーバのものほど包括的である必要はありません。これは、.htaccessファイルの内容が異なる場合があることも示しています。
簡略化した.htaccessファイルを作成し、次のルールを記述して、ローカルサイトのpublic/ディレクトリに配置します:
Options +FollowSymLinks
DirectoryIndex index.php
<IfModule mod_rewrite.c>
RewriteEngine On
# Let Apache serve real files or folders directly
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
# Catch everything else and force-route it to r.php
RewriteRule ^ r.php [L]
</IfModule>
サーバのオーバーライドの強制
このローカルファイルを使用するには、サーバがローカルのオーバーライドを許可していることを確認してください。デフォルトでは、MAMPおよびLaragonの新規インストールでは.htaccessファイルによる変更がブロックされるため、メインサーバのhttpd.conf設定ファイルを変更する必要があります。
MAMPの場合:
- メインのApache設定ファイル(通常は/Applications/MAMP/conf/apache/httpd.confにあります)を開きます。
- <Directory "/Applications/MAMP/htdocs">に一致するコードブロックを検索します。
- AllowOverride Noneという行を探し、AllowOverride Allに変更します。
- ファイルのさらに下を確認して2つ目の同じブロックを探し、そのAllowOverride Noneの行もAllowOverride Allに変更されていることを確認します。
- このファイルを開いている間に、LoadModule rewrite_module modules/mod_rewrite.soを検索します。行頭にハッシュ(#)がある場合は、それを削除してコメントを解除し、モジュールを有効にします。
- ファイルを保存し、MAMPサーバを再起動します(ステップ5)。
Laragonの場合:
- Apache設定ファイル(通常はC:/Laragon/bin/apache/httpd-[version]/conf/httpd.confのようなパスにあります)を開きます。
- 上記のMAMPとまったく同じ編集手順に従い、AllowOverrideディレクティブをAllに更新し、mod_rewriteが有効になっていることを確認します。
- ファイルを保存し、Laragonサーバを再起動します(ステップ5)。
mod_rewriteモジュールを有効にすると、ローカルのディレクトリ設定から厳密なFallbackResourceの要件を取り除くことができます。コードツリーにMoodleのインストールフォルダ名をハードコードする必要がなくなるため、ファイルの柔軟性が高まります。
Nginxの設定
注:役立つ可能性のあるNginxに関するドキュメントページがあります。
オプション1:標準的なルートインストール
Moodleサイトがメインドメイン(例:`https://yourdomain.com`)に直接インストールされている場合は、次のブロックをNginxの設定に追加します:
location / {
try_files $uri /r.php$is_args$args;
}
オプション2:サブディレクトリインストール
Moodleインストールがルートドメイン(例:`https://yourdomain.com`)ではなくサブフォルダにある場合は、パスを指定する必要があります:
location /moodle/ {
try_files $uri $uri/ /moodle/r.php$is_args$args;
}
オプション3:複数のMoodleインストール(上級)
1台のサーバで複数の独立したMoodleサイトをホストしている場合は、大文字と小文字を区別する正規表現を使用して、サイトフォルダのパスを動的に取得できます:
location ~ ^/(?<sitepath>[^/]*)/ {
try_files $uri $uri/ /$sitepath/r.php;
}
- $uri:ブラウザが要求した正確なファイルパスです。学生が実際のファイル(コアのスタイルシートやJavaScriptアセットなど)を要求した場合、Nginxはそのファイルを即座に提供します。
- /r.php:リクエストが実際のファイルに一致しない場合、Nginxはこのファイルにフォールバックし、Moodleのルーティングエンジンに制御を渡します。
IISの設定
Internet Information Services(IIS)は、Windows環境向けのMicrosoftのウェブサーバプラットフォームです。Apacheと同様に、IISはweb.configという名前のローカルファイルによるディレクトリレベルの設定をサポートしています。
'注:'以下の手順はコミュニティから提供されたもので、Moodle HQによるテストは行われていません。IIS環境を管理していて、検証済みの更新を提供できる場合は、このページへの寄稿をご検討ください。
Moodleルータをサポートするには、サーバにMicrosoft公式のURL Rewriterがインストールされている必要があります。モジュールが有効になったら、Moodleサイトの`public/`ディレクトリにある`web.config`ファイルを開くか作成し、次のXMLリライトブロックを挿入します:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Moodle Router" stopProcessing="true">
<match url="^(.*)$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<!-- If the requested path is a real file, serve it directly -->
<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
</conditions>
<!-- Otherwise, forward the clean URL request directly to r.php -->
<action type="Rewrite" url="r.php" appendQueryString="true" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
- negate="true":学生がディスク上に存在する実際のファイル(グラフィックアイコンやコアのJavaScriptファイルなど)を要求した場合に、書き換えルールを無視するようIISに指示します。
- appendQueryString="true":リンクに付加されたデータパラメータが、書き換えルールを経由してMoodleのルーティングエンジンに直接渡されるようにします。
ステップ4:サーバを再起動する(必要な場合)
ホスティング環境によっては、新しい設定ルールを適用するために、ウェブサーバの再起動が必要な場合があります。
- ローカル開発環境:MAMP、XAMPP、Laragonなどのプラットフォームでは、設定の更新を適用するために、ほぼ必ずサーバの手動での再起動または再読み込みが必要です。
- 本番サーバおよびコントロールパネル:多くのエンタープライズ環境、仮想プライベートサーバ(VPS)、またはcPanelのようなコントロールパネルでは、ディレクトリレベルの変更は、サーバ全体を再起動しなくても直ちに反映されます。
ステップ5:ルータの機能を確認する
サーバの設定を更新して稼働させたら、作業内容を確認しましょう。ステップ2に戻り、テストA(404動作テスト)とテストB(ディープリンクテスト)を再実行します。ブラウザにスタイル付きのMoodleエラーページと「コース管理」ページが表示されれば、ルータは正式に機能しています。
ステップ6:動作環境の通知を消去する
ルータが正しく機能していることを確認したら、Moodleの動作環境チェックにある静的な警告メッセージを消去できます。
メインのconfig.phpファイルを開き、スクリプトの末尾までスクロールします。次の設定行を、通常は最後の「require_once」ステートメントのすぐ上に挿入します:
$CFG->routerconfigured = true;
require_once(__DIR__ . '/lib/setup.php');
これにより、動作環境が正常に検証されたことがMoodleに伝わり、サイト管理 > サーバ > 動作環境ページのステータスが更新されます。