Moodle 5.2 Router nicht korrekt konfiguriert

Was der Fehler meistens bedeutet

Wenn Moodle 5.2 meldet, dass der Router nicht korrekt konfiguriert ist, leitet der Webserver nicht passende Routen meist nicht an Moodles Front Controller r.php weiter. Der scharfe Hinweis ist eine geroutete URL, die auf .php endet und 404 Not Found zurückgibt, obwohl Moodle eine Router-Antwort erwartet.

In der Moodle.org-Diskussion “Moodle 5.2: router is not correctly configured” drehte sich der Fall um /lib/exampleshimroute2.php: 404 statt erwarteter 302. PHP funktioniert, aber ein nicht existierender PHP-ähnlicher Pfad wird abgefangen, bevor Moodle routen kann.

Warum Moodle 5.x Routing braucht

Der Moodle-Router ist ein Front Controller. Die Dokumentation Configuring the Router beschreibt r.php als Ziel für Anfragen, die keiner echten Datei entsprechen.

Seit Moodle 5.1 ist das wichtiger, weil öffentliche Anfragen durch moodle/public laufen sollen, während interner Code und Konfiguration außerhalb des Webroots liegen.

Beginnen Sie beim Webroot

Wenn Ihr Moodle-Code hier liegt:

/var/www/moodle

sollte die öffentliche Website hierhin zeigen:

/var/www/moodle/public

nicht hierhin:

/var/www/moodle

Ist der Webroot falsch, wird Router-Debugging unübersichtlich.

Apache-Fix

Die Basiskonfiguration für Apache nutzt FallbackResource:

<Directory "/var/www/moodle/public">
    FallbackResource /r.php
</Directory>

Manche Hosts erlauben dies in .htaccess innerhalb von public:

FallbackResource /r.php

Der häufige Apache + PHP-FPM-Fall ist subtiler. Wenn Apache jede URL mit .php an PHP-FPM sendet, auch wenn die Datei nicht existiert, gibt PHP-FPM 404 zurück, bevor FallbackResource greifen kann.

Beschränken Sie den PHP-Handler auf echte Dateien:

<FilesMatch ".+\.ph(?:ar|p|tml)$">
    <If "-f %{REQUEST_FILENAME}">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </If>
</FilesMatch>

Übernehmen Sie den Socket oder Backend-Pfad aus Ihrer bestehenden Konfiguration.

Nginx-Fix

Für Nginx ist try_files der Kern:

location / {
    try_files $uri $uri/ /r.php$is_args$args;
}

Wenn Moodle in einem Unterverzeichnis lebt:

location /moodle/ {
    try_files $uri $uri/ /moodle/r.php$is_args$args;
}

Das gehört in die Serverkonfiguration. Nginx kennt kein .htaccess.

OpenLiteSpeed und cPanel

In Panel-Hosting funktioniert oft eine Rewrite-Regel besser:

RewriteEngine On
 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME}/index.php -f
RewriteRule ^(.*)$ $1/index.php [L]
 
RewriteRule ^$ ./index.php [L]
 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ r.php [L,QSA]

Legen Sie diese Regel in das .htaccess im public-Verzeichnis, nicht in das alte Elternverzeichnis.

Den genauen Check debuggen

Öffnen Sie Website-Administration > Berichte > Systemstatus.
Notieren Sie den exakten Router-Test.
Rufen Sie die URL direkt im Browser oder mit curl -I auf.
Klären Sie, wer antwortet: Apache, Nginx, PHP-FPM, Moodle, CDN oder Security-Layer.
Lesen Sie Webserver- und PHP-FPM-Logs zum selben Zeitpunkt.
Korrigieren Sie die erste Schicht, die falsch antwortet.
Laden Sie Webserver und PHP-FPM neu.
Leeren Sie Moodle-Caches und starten Sie den Check erneut.

Die entscheidende Frage lautet: Wer hat den 404 zurückgegeben?

Was Sie nicht tun sollten

Machen Sie nicht das gesamte Moodle-Verzeichnis öffentlich. Damit unterlaufen Sie den Sicherheitsgrund für public.

Verteilen Sie Rewrite-Regeln nicht gleichzeitig im Elternverzeichnis und in public. Konfigurieren Sie den tatsächlichen Webroot.

Setzen Sie $CFG->routerconfigured = true nicht als Ersatz für die Serverkonfiguration. Das kann einen Check beruhigen, routet aber keine Anfrage.

FAQ

Ist Routing in Moodle 5.2 Pflicht?

Die Moodle-Dokumentation nennt die Router-Konfiguration seit Moodle 5.1 verpflichtend.

Wo liegt der Moodle-Router?

Der Einstiegspunkt ist r.php.

Warum erwartet Moodle 302 und bekommt 404?

Meist landet ein gefälschter .php-Pfad bei PHP-FPM, bevor er zu r.php fallen kann.