Text im <body> - woher kommt dieser code?

Druckbare Version

11.04.2019, 11:35
m-werk

Text im <body> - woher kommt dieser code?

Hallo, ich ab jetzt mal eine neue HP eingerichtet und hab im Frontend ein ganz komisches Phänomen.

Zu sehen hier: test.bestyou.at

Wenn ich in den Quelltext sehe, steht folgendes dort:

Zitat:

<body id="top" class="<esi:include src="/_fragment?_hash=UC%2BkBy0kmGPsidy73JpTcGdOvvcdW5eu qpnGu9QaGa8%3D&_path=insertTag%3D%257B%257Bua%253A %253Aclass%257D%257D%26_scope%3Dfrontend%26_format %3Dhtml%26_locale%3Dde%26_controller%3Dcontao.cont roller.insert_tags%253ArenderAction&clientCache=0& pageId=2&request=home.html" />" itemscope itemtype="http://schema.org/WebPage">

Was bedeutet das?
11.04.2019, 11:47
m-werk

Komisch, hab jetzt im Layout was übersehen und hab nun einen Header/Footer und ne Hauptspalte ausgewählt. Jetzt ist es weg!
11.04.2019, 11:48
mlweb

Vielleicht verrätst Du noch um welche Contao-Version es sich handelt und ob Du im normalen Modus oder im Vorschaumodus bist.
11.04.2019, 12:04
webstar

Die esi:include Tags sind Inserttags, die nicht gecacht werden. Eigentlich werden diese ersetzt bevor die Response an den Browser geschickt wird. Wenn nciht, gibt es wohl vorher einen Fehler.
12.04.2019, 09:27
m-werk

Hallo, ok, nur wo finde ich diesen Fehler, leider ist es jetzt so, dass der Wrapper von oben einen Abstand hat, da genau diese Zeile noch im Quelltext steht, war zwar kurzfristig weg, aber ist wieder da, nur dass dieser Text jetzt nicht angezeigt wird, da ich im Header eine Backgroundfarbe habe.

Es handelt sich um Contao 4.7.4 und es ist im Normalen Modus gleich wie im Vorschaumodus. Der Link ist eh im 1. Posting enthalten.

Was kann ich hier jetzt noch tun?
12.04.2019, 11:35
m-werk

So, hab nun was herausgefunden.

Wenn ich im Firefox den gesamten Cache lösche, und die Seite aufrufe mit F5, kommt dieser Eintrag nicht. Es steht dann im Quelltext:

Zitat:

<body id="top" class="win firefox gecko fx66" itemscope itemtype="http://schema.org/WebPage">

Sobald ich aber jetzt mit F5 die Seite aktualisiere, kommt wieder folgender Eintrag:

Zitat:

<body id="top" class="<esi:include src="/_fragment?_hash=UC%2BkBy0kmGPsidy73JpTcGdOvvcdW5eu qpnGu9QaGa8%3D&_path=insertTag%3D%257B%257Bua%253A %253Aclass%257D%257D%26_scope%3Dfrontend%26_format %3Dhtml%26_locale%3Dde%26_controller%3Dcontao.cont roller.insert_tags%253ArenderAction&clientCache=0& pageId=2&request=home.html" />" itemscope itemtype="http://schema.org/WebPage">

Das gleiche in Chrome und auch im Edge! Vielleicht liegt es am Webserver? Ich weiß es aber nicht. Hat jemand eine Idee?
15.04.2019, 06:36
m-werk

Hallo,

hat jemand schon eine Idee, was das sein kann? Wie gesagt, wenn der Browsercache neu aufgebaut wird, passt es, aber wenn dann nur die Seite aktualisiert wird, dann hab ich wieder den Text im Frontend stehen. Der Provider des Kunden ist "easyname" aus Österreich.

Ich hab den Kunden darüber auch schon informiert. Vielleicht geht es, dass er auf domainfactory wechselt, da der dort auch schon eine HP liegen hat. Er klärt das mit seinem Partner.

Aber mich würde trotzdem interessieren, was es damit auf sich hat.
15.04.2019, 07:25
Spooky

Schalte mal den Varnish Cache von easyname ab.
15.04.2019, 07:33
m-werk

Hi, diesen hab ich dekativiert. Es steht bei "Varnish Cache (Minuten)* eine 0.

Dies hab ich bei den Einstellungen der Subdomain gemacht. hat aber trotzdem nichts gebracht.

Nachtrag: Im Quelltext vom Backend hab ich jetzt auch gesehen, dass dieser Teil fehlt

Zitat:

itemscope itemtype="http://schema.org/WebPage">

Das Backend funktioniert einwandfrei. Hier gibt's keine Cach-Probleme.
15.04.2019, 07:47
Spooky

Leere außerdem den Varnish Cache in der Oberfläche von easyname. Teste es in 5 Minuten noch mal. Hast du den Contao eigenen Cache aktiv?
15.04.2019, 07:50
m-werk

Ich hab diesen Cache schon am Freitag auf 0 gestellt. Weiters hab ich in der Subdomain den OPcache aktivieren auch auf 0 gestellt.

Wie kann ich diesen Cache (bzw. wo) in Easyname löschen?

In Contao hab ich keinen Cache eingestellt. Es funktioniert trotzdem nicht. Ich begreif nur nicht, warum das Backend einwandfrei ohne jegliche Meldung funktioniert und das FE nicht. Ist im BE die <body> Programmierung anders?
15.04.2019, 07:54
Spooky

Zitat:

Zitat von m-werk

Wie kann ich diesen Cache (bzw. wo) in Easyname löschen?

Im Easyname Control Panel unter Webhosting » Webserver Einstellungen » Varnish » VERWALTEN. Dann die jeweilige Domain auswählen und unten auf CACHE FÜR DIE AUSWAHL LEEREN klicken.
15.04.2019, 08:03
m-werk

Ok, danke. Ich sehe zwar die angemeldete Domain, aber meine erstellte Subdomain darunter seh ich nicht, da ich in der Subdomain ja auch 0 eingetragen habe. Den Cache hab ich jetzt gelöscht. Ich hab aber auch gelesen, dass bei https dieser Cache erst gar nicht angewendet wird.

Ich hab jetzt aber trotzdem mal auf http wieder umgestellt, da es sich hier sowieso nur in erster Linie um eine Test-Seite handelt.

Aber das mit dem Cache dürfte es nicht gewesen sein, denn es funktioniert noch immer nicht.
15.04.2019, 08:05
Spooky

Zitat:

Zitat von m-werk

Ich hab aber auch gelesen, dass bei https dieser Cache erst gar nicht angewendet wird.

Wo steht das?

Zitat:

Zitat von m-werk

Aber das mit dem Cache dürfte es nicht gewesen sein, denn es funktioniert noch immer nicht.

Hm, dann bin ich momentan auch überfragt. Denn theoretisch sollte dieses Problem nur durch einen fehlerhaft agierenden Proxy verursacht werden, denke ich.

Wie hast du Contao 4 bei easyname überhaupt installieren können? Gibt es diese Probleme nicht mehr?
15.04.2019, 08:11
m-werk

Ich hab über SSH Contao installiert.

Hat soweit eigentlich super funktioniert. Auch Module hab ich über SSH installiert. easyname hat symlinks deaktiviert und haben auch gesagt, das aktivieren sie nicht aus sicherheitsgründen, aber ich kann über ssh diese manuell erstellen.
Daher funktioniert auch das Löschen des Caches im Backend nicht ganz, da keine Symlinks erstellt werden. Diese muss ich dann in SSH manuel wieder erstellen.

Betreffend der Info über https: https://www.easyname.at/de/support/h...arnish-caching
15.04.2019, 08:19
Spooky

Ich würde dir nicht empfehlen bei easyname zu bleiben.
16.04.2019, 10:27
m-werk

Hallo nochmal, ich hab den Kunden diesbezüglich ja schon informiert. Ich hoffe, er gibt mir bald mal bescheid bezüglich eines wechsels.

Ich hab jetzt aber noch etwas herausgefunden:
Wenn ich via "app_dev.php/home.html" auf das Frontend zugreife, kommt dieser Fehler bzw. diese Meldung nicht. Egal wie oft ich F5 bzw. STRG + F5 drücke. Es dürfte irgendwo noch ein Cache laufen, nur finde ich diesen nicht.
16.04.2019, 16:19
m-werk

Was ich jetzt auch nicht verstehe, warum {{ua::class}} nicht funktioniert im FE. Ich nehme an, dass das BE auch diesen Inserttag im Body hat und dort funktioniert es einwandfrei. Auch wenn ich via app_dev.php ins FE gehe, funktioniert es.

Nachtrag:
Ich habe gesehen, dass im Backend dies mit

PHP-Code:

<?= $this->ua ?>

eingebunden wird. Könnte man das nicht im fe_page auch machen? Wenn ich dies so eingebe, steht dann nur class=""

Hab jetzt testweise mal versucht anstelle von ua::class {{env::ip}}. Das wiederum hat funktioniert. Ich hab meine IP gesehen. Irgendwo hab ich hier den Wurm drin.
17.04.2019, 13:20
m-werk

Hallo, hat hier keiner eine Idee?

Warum geht dies im Backend (zwar wird hier nicht {{ua::class}} angegeben) aber nicht im FE? Ich hab mal einen Artikel erstellt mit {{ua::class}}. Leider Ohne Erfolg. Es muss doch eine Möglichkeit geben, dass man dies im FE so lösen kann wie im Backend?
17.04.2019, 13:34
Spooky

Ohne die Contao Installation im Detail genauer zu analysieren, habe ich hier keine weitere Idee. Und da der Betrieb von Contao 4 bei easyname sowieso nicht reibungslos funktioniert, würde ich das auch nicht weiter verfolgen.
17.04.2019, 14:59
m-werk

Ich hoffe, dass der Kunde wechselt.

ABER jetzt hab ich noch etwas herausgefunden. Ich hab jetzt mal eine Leere Installation in einer neuen Subdomain mit Contao 4.4.38 gemacht.

HIER TRITT DER FEHLER NICHT AUF.

Weiters hab ich dann eine Leere Installation mit Contao 4.7.4 gemacht. HIER IST DER FEHLER WIEDER VORHANDEN.

Morgen Teste ich noch 4.5 und 4.6.

Es hat also was mit contao nun zu tun! Hier wurde was geändert.
17.04.2019, 15:04
Spooky

Ja, zwischen 4.4 und 4.7 hat sich bezüglich Caching und Esi Tags einiges geändert.
18.04.2019, 06:50
m-werk

Ok, das muss sich aber zwischen der 4.6er und 4.7er Version geändert haben, denn die 4.6.14 funktioniert auch einwandfrei.
Hm, hab auch mal {{ua::class}} bzw. {{ua::browser}} in einen Artikel gegeben in der 4.7er Version. Leider auch der gleiche Fehler. Irgendwie müsste man den Cache doch hierfür deaktivieren können, denn wenn ich das richtig verstanden habe (siehe hier: https://leofeyer.github.io/konferenz-2017/#79)

Der Kunde wird wechseln, die Frage ist jetzt, nur wann!

Wie soll ich weiter vorgehen: Soll ich jetzt zurück auf die 4.6.12 und die HP soweit fertig gestalten? Oder kann ich die ua irgendwie vorübergehend anders lösen in der 4.7er Version?
18.04.2019, 07:29
Spooky

Öffne ein issue auf GitHub, vielleicht kann man das irgendwie nachvollziehen.
18.04.2019, 09:02
Spooky

So wie es aussieht kann man den Varnish Cache Proxy bei easyname nie komplett deaktivieren. Denn: wenn dein Browser einen Cache-Control: no-cache Request Header mitsendet, dann werden die ESI Tags korrekt ersetzt von Contao zurück gegeben.

Du könntest mal bei easyname nachfragen, ob es möglich wäre den Varnish Cache Proxy komplett umgehen zu lassen. Aber vielleicht gibt es dafür auch eine Lösung in Contao.
18.04.2019, 10:50
m-werk

So, hab das ganze jetzt nochmals easyname geschildert. Es wird jetzt dies an die Techniker von easyname weitergeleitet. Ich hab diesbezüglich auch eine Ticket-Nummer schon erhalten.

Bin jetzt mal gespannt, was heraus kommt. Mal sehen, ob sie das lösen können.

Natürlich wäre auch eine Lösung via Contao sinnvoll bzw. eine Alternative.

Nachtrag:
Ich glaube, es geht um diesen Code in der app.php unter Contao 4.7

PHP-Code:

$cache = $kernel->getHttpCache(); // Enable the Symfony reverse proxy if request has no surrogate capability if (null !== $cache->getSurrogate() && !$cache->getSurrogate()->hasSurrogateCapability($request)) { $kernel = $cache; }

In Contao 4.6 steht folgender nur darin:

PHP-Code:

// Enable the Symfony reverse proxy if (!($_SERVER['DISABLE_HTTP_CACHE'] ?? false)) { $kernel = $kernel->getHttpCache(); }

Und in der app_dev.php steht sowieso nur:

PHP-Code:

$kernel = new ContaoKernel('dev', true);
02.05.2019, 06:11
m-werk

So, ich werde nächste Woche die app.php wie Leo im GitHub geschrieben hat, mal testen.

Ich hab auch easyname schon gebeten, den Varnish Cache Proxy für diese Seite umgehen zu lassen. Leider hatte ich keine kompetente Person am Telefon. Dieser hat nur gesagt, dass er das den Technikern so weiterleitet. Hat er sicherlich nicht gemacht, denn ich hab keine Antwort bis dato erhalten und funktionieren tut es auch noch nicht.

Egal, der Kunde wird den Anbieter sowieso wechseln. Dauert halt nur etwas.

Vorübergehend bin ich jetzt mal auf die Version 4.6.x heruntergegangen, damit ich wenigstens mal sauber weitermachen kann.

Eine Frage: Wäre es eventuell vielleicht angedacht, dass auch solche Fälle in den Contao-Code mit einbezogen werden? Der Varnish Cache sollte eigentlich eine gar nicht so schlechte sache sein, oder?
02.05.2019, 08:23
Spooky

Wird voraussichtlich in Contao 4.8 gehen: https://contao.org/de/news/die-jagd-...e-cookies.html
07.05.2019, 14:04
m-werk

Das klingt ja eh gut.

Inzwischen hab ich von Easyname auch eine Meldung bekommen: Der Varnish kann nicht deaktiviert werden, weil er noch für einige andere Dinge zuständig ist (z.B.. WebApplication Firewall, filtering, etc..)
07.05.2019, 14:24
Spooky

Ja, das habe ich mir schon gedacht.
24.06.2019, 10:26
heyho

Ich habe das Problem auch lokal mit WAMP.
Meine Lösung - {{ua::class}} ersetzen durch:

PHP-Code:

<?php echo $this->replaceInsertTags('{{ua::class}}', false);?>

Alle Zeitangaben in WEZ +1. Es ist jetzt 19:25 Uhr.