Contao 4.9 > app.php

[ok99]

Hallo in die Runde,

uns ist gerade aufgefallen, dass man bei Contao 4.9(.6) an die URL einfach "app.php" anhängen kann, die Seite ganz normal geöffnet wird (Startseite) und das "app.php" dann weiter geschliffen wird.
Zumindest bei Seiten ohne Suffix.

Beispiel:
https://tao.demo.rocksolidthemes.com ==> normaler Aufruf

https://tao.demo.rocksolidthemes.com/app.php

https://tao.demo.rocksolidthemes.com/app.php/team ==> Aufruf Seite Team


Bei der Contao 4.4 funktioniert das übrigens mit "index.php".

Sollte hier nicht die .htaccess dementsprechend angepasst werden? Stichwort "duplicate content".

    RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

Oder so änhlich....

Viele Grüße

[klimeck]

Ich habe leider auch dieses Problem.

Alle Seiten sind auch über die URL mit www.domain.tld/app.php/de/... aufrufbar.

Meine .htaccess sieht so aus:

<IfModule mod_rewrite.c>
    RewriteEngine On

    <IfModule mod_headers.c>
        # Assets in /assets and /bundles either contain a hash in their filename
        # or are called with a ?version suffix, therefore cache them for 1 year.
        RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
        Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

        # Allow CORS on the Contao TinyMCE skin.
        RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
        Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
    </IfModule>

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the index.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/index.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #   following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

Ich hosted bei ALL-INKL. Hat jemand eine Lösung?

Dank und Grüße!

[tab]

Man könnte natürlich ganz radikal vorgehen und die app.php in Contao 4.9 einfach löschen.

[klimeck]

Ich denke, dass das Löschen einer Datei, die Teil des Symfony Systems ist, nicht wünschenswert sein kann.

[xchs]

Die app.php existiert aus Gründen der Rückwärtskompatibilität und hat in Contao 4.9 den einzigen Zweck die index.php aufzurufen:

<?php

// Backwards compatibility
require __DIR__.'/index.php';

Der Einstiegspunkt ist also die index.php.

[Nightwing]

Ich denke, dass das Löschen einer Datei, die Teil des Symfony Systems ist, nicht wünschenswert sein kann.

Dann füge der .htaccess folgendes hinzu (3x Zeile mit Condition der index.php duplizieren, index gegen app tauschen):

    
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]


# Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/index.php [L]
    RewriteRule ^ %{ENV:BASE}/app.php [L]
</IfModule>


<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        RedirectMatch 302 ^/$ /app.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

ToM

[klimeck]

Wird die gelöschte app.php nach einem Update nicht wieder neu installiert?

Mein Lösungsansatz ist, dass ich jetzt eine Zeile in meiner htaccess zugefügt habe:

War so:

RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

Ist jetzt so:

RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

Funktioniert soweit und ist updatesicher.

[tab]

Die app.php ist mit Contao 4.8 in index.php umbenannt worden. Aus den Changelogs:

4.8.0-RC1 (2019-07-15)

[...]
Rename app.php to index.php (see #362).
[...]

In der aktuellen .htaccess steht auch die RewiteRule zur Umschreibung von URLs auf index.php drin, vor Contao 4.8 wurde hier auf app.php umgeschrieben. Wer freilich beim Update bereits eine .htaccess in /web hat, bei dem wird die alte .htaccess beim Update nicht ersetzt. Wenn man seine eigenen Änderungen in die aktuelle .htaccess einträgt, braucht man m.E. die app.php nicht mehr. Falls sie bei der Neuinstallation von 4.9 noch dabei ist, dann wahrscheinlich nur aus Gründen der Rückwärtskompatibilität. Nach kurzem reinschauen in die app.php bestätigt sich meine Vermutung. Das hier drunter ist alles, was in der app.php drinsteht, es wird also der Code der index.php ausgeführt. Ich habe vorhin in einer 4.9 Installation die app.php umbenannt und kann keine Probleme feststellen, auch nicht nach Löschen des Cache.

<?php

// Backwards compatibility
require __DIR__.'/index.php';

[Spooky]

Die app.php wird aber bei einem composer update/install vermutlich wieder erzeugt.

[tab]

Ja, das ist wohl so, genauso wie auch z.B. die .htaccess. Wenn man die löscht und ein update/install durchführt, ist sie (die Originaldatei) auch wieder da. Insofern ist das keine dauerhafte Lösung.

[lucina]

Hallo in die Runde,

uns ist gerade aufgefallen, dass man bei Contao 4.9(.6) an die URL einfach "app.php" anhängen kann, die Seite ganz normal geöffnet wird (Startseite) und das "app.php" dann weiter geschliffen wird.
Zumindest bei Seiten ohne Suffix.

(...)

Bei der Contao 4.4 funktioniert das übrigens mit "index.php".

Sollte hier nicht die .htaccess dementsprechend angepasst werden? Stichwort "duplicate content".

Ganz ehrlich, ich verstehe das Problem nicht. Wieso soll das 'Duplicate Content' sein? Und wieso verbietest Du Suchmaschinen nicht einfach, die app.php aufzurufen? Und woher wissen die überhaupt, dass es eine app.php gibt, wenn sie doch schon mit index.php vollkommen zufrieden sind? Schliesslich gäbe es sicher noch eine Regel für 'Canonical' ... aber selbst das wäre vermutlich schon zu viel.

[tab]

Ganz ehrlich, ich verstehe das Problem nicht. Wieso soll das 'Duplicate Content' sein? Und wieso verbietest Du Suchmaschinen nicht einfach, die app.php aufzurufen? Und woher wissen die überhaupt, dass es eine app.php gibt, wenn sie doch schon mit index.php vollkommen zufrieden sind? Schliesslich gäbe es sicher noch eine Regel für 'Canonical' ... aber selbst das wäre vermutlich schon zu viel.

Es ist jedenfalls kein böswilliger duplicate content, also eine echte Abstrafung durch Google&Co wird da nicht stattfinden. Natürlich können Links "verlorengehen" dadurch für die richtige URL. Aber wer verlinkt schon mit index.php oder app.php in der URL, wenn nicht explizit aus böser Absicht, um der Konkurrenz Schaden zufügen, indem man alternative Links verbreitet? Dagegen hilft am ehesten die Angabe einer kanonischen URL im Header der Seite, siehe z.B. auch https://developers.google.com/search...duplicate-urls.

[klimeck]

Mir ist das Problem aufgefallen, weil es in der Google Search Console als Fehler angegeben wurde. Wieso Google überhaupt die URL gefunden hat ist mir auch nicht ganz klar, weil die app.php weder in der Sitemap steht noch durchgelinkt wurde.

Ich ziehe selbst die Lösung über die htaccess vor.