Elemente im Backend erst nach page reload sichtbar

Hallo zusammen,

ich habe gerade Contao 4.9 am Start und habe nun schon mehrmals festgestellt, dass im Backend die Listenansichten (Seiten, Artikel, Inhaltselemente, Module, Bildgrößen... etc) oft (fast immer) erst nach einem page reload aktualisiert werden.

Wenn ich also ein neuen Inhaltselement (Seite, Artikel, ...) hinzufüge und Speichern und Schließen anklicke, erscheinen diese Elemente nicht, sondern erst wie beschreieben nachdem ich die Seiten neu geladen habe.

Dasselbe gilt für kopierte bzw. verschobene Elemente.

Hat jemand dasselbe Problem?

Danke und viele Grüße
Timo

Kurzer Nachtrag: Das gilt übrigens auch für den Debug Mode: Die Debug-Leiste wird nicht nach der Aktivierung sondern erst nach einem page reload sichtbar.

Ich habe das Problem seit 4.9 auch. Mir war es zuerst im neuen Table Picker aufgefallen, weil dort neu angelegte Elemente nicht sofort auftauchten. Dann fiel mir auf, dass die Backend-Navigation, wenn die Elemente (bspw. im Log) auf mehrere Seiten aufgeteilt werden, ebenfalls nicht funktioniert. Klicke ich auf eine andere Seitenzahl, wird immer nur die aktuelle Seite neu geladen. Erst bei einem Reload mittels F5 öffnet sich die vorher angeklickte Seite. Die Debug-Leiste wird bei mir ebenfalls erst nach einem Reload angezeigt.

Seltsamerweise betrifft das zwei Contao-Installationen bei WebGo unter PHP 7.3.14, in meiner lokalen Kopie unter Windows mit PHP 7.2.7 tritt der Fehler hingegen nicht auf. Getestet habe ich unter Firefox, Chrome und Edge.

Mir sind inzwischen auch noch weitere Stellen aufgefallen, bei denen das passiert. Meine Installation läuft unter PHP7.4.

Also an der PHP-Version scheint es wohl nicht zu liegen. Ich hatte bei WebGo zwischenzeitlich auf PHP 7.2 umgestellt und das Problem blieb bestehen.

Ich habe das Problem bei mir gelöst! Es war ein Cache-Problem. Wie ich in den Webentwickler-Tools (bspw. von Firefox) sehen konnte, wurde nach dem Anklicken einer anderen Seitenzahl stets die aktuelle Seite wieder aus dem Cache geladen. Ich hatte dann im Tool testweise den Cache deaktiviert und es funktionierte wieder.

Wahrscheinlich hast du, genau wie ich, im web-Ordner eine angepasste .htaccess-Datei liegen, in der eine längere Cache-Zeit für html-Dateien angegeben ist.
Unter <IfModule mod_expires.c> habe ich einfach die Cache-Zeit für Dateien mit den Content-Type "text/html" auf 0 Sekunden gesetzt:

ExpiresByType text/html "access plus 0 seconds"

Warum das seit 4.9 nicht mehr funktioniert, ist mir allerdings ein Rätsel.

Moin zusammen,
gibt es hierfür schon eine Lösung? Die von Silent-Bob genannte Lösung kann ja nur ein Work-Around sein, oder sehe ich das falsch?
Viele Grüße
Timo

Wie sieht deine .htaccess aus? ggf. auch parent .htaccess

Die htaccess aus dem Web-Verzeichnis (unveränderte mit Contao mitgelieferte Version)

Code:

---

<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 sehe gerade: Das ist direkt in den Apache-Anweisungen eingetragen. Die entsprechende Zeile habe ich geändert und nun geht es.
Danke für den Hinweis nochmal.

Code:

---

<IfModule mod_expires.c>
        ExpiresActive On
        ExpiresByType text/css "access plus 1 month"
        ExpiresByType text/javascript "access plus 1 month"
        ExpiresByType text/html "access plus 0 seconds"
        ExpiresByType application/javascript "access plus 1 month"
        ExpiresByType image/gif "access plus 1 month"
        ExpiresByType image/jpeg "access plus 1 month"
        ExpiresByType image/png "access plus 1 month"
        ExpiresByType image/x-icon "access plus 1 month"
        ExpiresByType application/pdf "access plus 1 month"
        ExpiresByType text/x-javascript "access plus 1 month"
        ExpiresByType application/x-shockwave-flash "access plus 1 month"
        ExpiresByType image/x-icon "access plus 1 year"
        ExpiresDefault "access plus 2 days"
</IfModule>

---

Das sind die Standard-Einstellungen des Hosting-Systems. Kann das auch mein anderes Problem verursachen, dass sich verschiedene Änderungen auf den Seiten beim Kunden nicht sauber aktualisieren?

Gibt es hierzu Hinweise, wie welche Einstellung sinnvoll/optimal sind?

Ja klar, wenn dort ExpiresByType text/html "access plus 1 month" eingestellt ist, sagst du dem Browser, er soll die Contao Seite für 1 Monat lang immer nur aus dem Browser Cache laden.

Für Contao ist es in diesem Fall sinnvoll nichts zu setzen, da du ja das Caching über Contao regeln willst.

Danke Spooky!

Das dachte ich mir auch so. Ich habe die Einstellungen bereits angepasst bzw. anpassen lassen. Der Hoster war nur schwer davon zu überzeugen und meint, das wären die korrekten Einstellungen für alle.