Seltsames Verhalten in Verbindung mit Servercache - Inserttags werden nicht aufgelöst

[Der Astronaut]

Hallo zusammen,

so langsam bin ich echt ratlos und hoffe hier auf Hilfe und Unterstützung.

Seit einiger Zeit (2-3 Monate?) sind mir beim Check mit dem HTML-Validator vom W3C immer mal wieder seltsame Fehler aufgelistet worden. Prüfte ich die Seite noch mal einmal, waren diese Fehler verschwunden. Zuerst schob ich das Problem auf den Validator. Aber jetzt, wo ich seit ein paar Tagen recht viel an meinem Portal arbeite und diverse Tests mit verschiedenen Browsern machte, sah ich genau die Stellen, an denen der Validator meckerte.

Es handelt sich um mein Projekt "Handballforum-Dormagen", zu finden unter handballforum-dormagen.de. Benutzt wird Contao 3.3.3.

Im Footer habe ich © Handballforum Dormagen gefolgt von der Jahreszahl, dynamisch per Inserttag {{date::Y}} eingefügt. Darunter ein Logo von all-inkl.com, meinem Webhoster. Der w3C-Validator monierte immer wieder, dass die URL zum Bild fehlerhaft sei und zeigte mir {{file::abc123}} an. In Tests mit verschiedenen Browsern (Chromium, Epiphany, Midory, Firefox Android, Safari iOS) sah ich dann, dass das all-inkl.com-Logo fehlte und der darüber liegende Datums-Inserttag nicht aufgelöst wurde. Lade ich die Seite neu, sind die fehlenden Elemente da. Gehe ich auf eine andere Unterseite fehlen die Elemente wieder. Lade ich die Seite neu, sind sie wieder da.

Ich probierte viel rum, habe den Inserttag mehrfach neu geschrieben (nicht kopiert), fügte das Logo neu ein. Das Problem besteht. Dann fiel mir auf, dass das Problem mit meinem Hauptbrowser Firefox nicht bestand. Vielleicht liegt es daran, dass ich auch mit dem FF im Backend eingeloggt bin? Ich öffnete ein Fenster im privaten Modus. Fehler tauchte wieder auf. Ich schloss daraus, dass es ein Cache-Problem sein könnte. Also in den Backend-Einstellungen den Cache ausgeschaltet und siehe da, das Problem verschwand. Cache an = Problem da, Cache aus = Problem weg. Eingestellt ist Servercache. Stelle ich auf Browsercache um, tritt das Problem ebenfalls nicht auf. Also dachte ich, dass es am Servercache liegen könnte. Ich schrieb eine E-Mail an all-inkl.com. Antwort: Es liegt nicht am Servercache, ich solle das Script überprüfen.

Ganz toll!!!

Ok. Heute Morgen dann ein paar neue Ideen, wie ich das Problem einschränken könnte. Eventuell könnte es am TinyMCE-Legacy liegen. Ich habe also mal {{date::Y}} als HTML-Element und nicht wie vorher als Textelement angelegt. Gleiches Problem. Also kann man doch TinyMCE-Legacy ausschließen, oder? Füge ich ein Bild als Textelement ein, habe ich wieder das Problem. Nehme ich stattdessen ein Bildelement, tritt das Problem nicht auf.

Dann habe ich das Inserttag mal an verschiedene Stellen im fe_page-Template eingefügt. Da funktioniert's!

Zurück im Backend habe ich das Inserttag mal an verschiedenen Stellen der Seite positioniert und mir ist aufgefallen, dass es seltsamer Weise in der Hauptspalte funktioniert, im Header, Footer, linke und rechte Spalte jedoch nicht. Diese hatte ich damals (noch unter Contao 2) wie im Contao-Wiki beschrieben, angelegt. Den Vermerk mit article-header für Contao ab 3.1 habe ich gesehen und die Artikel-Elemente heißen mittlerweile auch so bei mir. Daran liegt es also nicht.

Contao-Check meldet nichts! Erweiterungen hatte ich auch deaktiviert. Der Fehler besteht weiterhin.

Das all-inkl.com-Logo habe ich mittlerweile statisch eingebunden. Deshalb kann man das Problem nur noch anhand des Inserttags darüber ausmachen.

Es ist echt zum Mäuse-melken! Ich weiß einfach nicht mehr weiter und hoffe hier auf Hilfe!

Danke schon mal für's Lesen des langen Textes und vorab für eure Antworten!!!

2014-07-09_contao-servercache.png

[BugBuster]

Verstehe ich auch nicht, da "date" und "file" Instert Tags sind die gar nicht gecachet werden. Die werden erst unmittelbar vor dem Senden an den Browser ersetzt.
Übrigens, mit Servercache ist der Contao eigene Cache auf dem Server gemeint, daher kan dir da der Hoster auch nicht helfen.

Hast du den Check nur aufgerufen oder auch unten den Überprüfungs Button geklickt? Weil nur dann werden die Dateien auch geprüft.

Für mich sieht das so aus, als wenn alle nicht gecachten Insert Tags bei dir beim Output direkt aus dem Cache nicht ersetzt werden, und das kann dann eigentlich nur eine Core Änderung sein.

[Der Astronaut]

Danke für die Antwort BugBuster!

Übrigens, mit Servercache ist der Contao eigene Cache auf dem Server gemeint, daher kan dir da der Hoster auch nicht helfen.

Ah ok, das wusste ich nicht. Danke für die Info.

Hast du den Check nur aufgerufen oder auch unten den Überprüfungs Button geklickt? Weil nur dann werden die Dateien auch geprüft.

Ich hatte auch auf den Überprüfen-Button geklickt. Der Check zeigte mir drei korrupte Dateien an und, dass Contao nicht uptodate sei. Letzteres habe ich dann herausgefunden, dass es an den editieren Dateien liegt, die korrupt genannt werden. Das sind einmal die komprimierte und normale CSS-Datei von Colorbox und die TinyMCE.php in /config/.

Für mich sieht das so aus, als wenn alle nicht gecachten Insert Tags bei dir beim Output direkt aus dem Cache nicht ersetzt werden, und das kann dann eigentlich nur eine Core Änderung sein.

Ui, also am Core habe ich definitiv nichts gefrickelt. Ich hatte mir nur selber mal eine Erweiterung für die Handball-Tabelle zusammen geschustert. Daran kann es aber auch nicht liegen, weil ich die vor zwei Jahren erstellt hatte und das o.g. Problem mir das erste mal erst vor 2 oder 3 Monat über den Validator aufgefallen war. Außerdem hatte ich die Erweiterung über die Einstellungen im Backend deaktiviert und das Problem besteht immer noch.

Was halt seltsam ist, ist, dass die Umwandlung in der Hauptspalte anstandslos funktioniert. Nur im Header, Footer, linke und rechte Spalte wird gezickt. Meinst du es bringt etwas Header, Footer etc. zu löschen und neu anzulegen? Ich habe das bis jetzt versucht zu vermeiden, weil's schon etwas aufwendig ist.

[tab]

Aktiviere doch mal die Fehlerausgabe in die Logdateien. Vermutlich ist die eh schon defaultmäßig aktiv. Falls das der Fall sein sollte, dann schau doch mal in die system/logs/error.log rein, ob das was drinsteht. Ansonsten schalte es in den System-Einstellungen ein und schaue in die error.log nach dem nächsten Auftreten des Problems.

[Der Astronaut]

Ist schon aktiviert. Es wird aber nichts sonderbares protokolliert.

Fehlermeldungen anzeigen hatte ich auch mal kurzzeitig aktiviert, wird aber nichts ausgegeben.


Edit: Sorry, ich war ein wenig schnell und hatte das mit dem error.log überlesen. Ich poste einfach mal die Ausgabe von gestern:

[09-Jul-2014 18:00:02 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'Could not find template "gallery_list"' thrown in /www/htdocs/012345/system/modules/core/library/Contao/TemplateLoader.php on line 127
#0 /www/htdocs/012345/system/modules/core/library/Contao/Controller.php(74): Contao\TemplateLoader::getPath('gallery_list', 'html5')
#1 /www/htdocs/012345/system/modules/core/library/Contao/BaseTemplate.php(85): Contao\Controller::getTemplate('gallery_list', 'html5')
#2 /www/htdocs/012345/system/modules/core/library/Contao/Template.php(244): Contao\BaseTemplate->parse()
#3 /www/htdocs/012345/system/modules/core/classes/FrontendTemplate.php(46): Contao\Template->parse()
#4 /www/htdocs/012345/system/modules/core/elements/ContentGallery.php(370): Contao\FrontendTemplate->parse()
#5 /www/htdocs/012345/system/modules/core/elements/ContentElement.php(174): Contao\ContentGallery->compile()
#6 /www/htdocs/012345/system/modules/core/elements/ContentGallery.php(84): Contao\ContentElement->generate()
#7 /www/htdocs/012345/system/modules/tags/elements/ContentGalleryTags.php(133): Contao\ContentGallery->generate()
#8 /www/htdocs/012345/system/modules/core/library/Contao/Controller.php(468): Contao\ContentGalleryTags->generate()
#9 /www/htdocs/012345/system/modules/core/library/Contao/Controller.php(1013): Contao\Controller::getContentElement('1803')
#10 /www/htdocs/012345/system/modules/news/classes/News.php(183): Contao\Controller->replaceInsertTags('?<div class="ce...', false)
#11 /www/htdocs/012345/system/modules/news/classes/News.php(78): Contao\News->generateFiles(Array)
#12 /www/htdocs/012345/system/cron/cron.php(110): Contao\News->generateFeeds()
#13 /www/htdocs/012345/system/cron/cron.php(177): CronJob->run()
#14 {main}
[09-Jul-2014 18:49:54 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6
[09-Jul-2014 18:49:57 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6
[09-Jul-2014 19:30:24 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6
[09-Jul-2014 19:30:24 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6
[09-Jul-2014 19:30:26 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6
[09-Jul-2014 19:30:27 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6
[09-Jul-2014 19:59:56 Europe/Berlin] PHP Fatal error:  Cannot redeclare is_facebook() (previously declared in /www/htdocs/012345/templates/desktop/fe_page.html5:3) in /www/htdocs/012345/templates/desktop/fe_page.html5 on line 6

[BugBuster]

Nun, da gibt ein Problem mit einem fehlenden Template "gallery_list.html5", ist wohl ein selbst definiertes und zugewiesenes was nun plötzlich fehlt
Wenn das ein Core Template wäre, hatte der Check schon gemeckert.

Aber warum der in Main das Insert Tag ersetzt wird, in den anderen dann nicht mehr.... hmm, dann müsste es in Main zum Absturz der Methode bzw. zur Unterbrechung kommen.
Das kann auch eine externe Erweiterung sein. Trotzdem seltsam, kenne ich so auch noch nicht.

Ansonsten brechen Fatal Error die Bearbeitung ab! Das könnte eventuell auch der Grund sein. Hier musste unbedingt was tun, auch bei "Cannot redeclare is_facebook()"

Im übrigen verwendest du eine angepasste fe_page wo auch einer der Fehler fabriziert wird.

[Der Astronaut]

Erst einmal vielen Dank für eure Hilfe!

Ich habe die Fehler aus dem error.log beseitigt. Daran liegt es aber nicht. Das fe_page-Template hatte ich zwischenzeitlich zu Test durch die aktuelle Version ersetzt. Das Problem besteht weiter.

Nun kam mir die Idee zusätzlich zum {{date::Y}} mal irgendein anderes Inserttag daneben zu setzen. Also habe ich {{env::ip}} daneben geballert. Während das Datum immer noch keinen Bock hat, wird die IP daneben anstandslos ausgegeben. Schon ziemlich strange...

Noch irgendwelche Ideen?

[Der Astronaut]

Also das Problem scheint sich nur auf die Inserttags "date" und "file" zu beziehen und kommt nur im Header, Footer, linke und rechte Spalte vor. Andere Inserttags wie "link" oder "env" funktionieren. Das Problem tritt auch nur mit Inhalten aus der Datenbank auf. Setze ich ein Inserttag direkt in ein Template funktioniert die Umwandlung.

Apropos Datenbank. Im Error.log traten heute Nacht folgende Fehler auf:

[11-Jul-2014 03:46:25 Europe/Berlin] 
PHP Warning: Error while sending QUERY packet. PID=21872 in /www/htdocs/012345/system/modules/core/library/Contao/Database/Mysqli/Statement.php on line 78
#0 [internal function]: __error(2, 'Error while sen...', '/www/htdocs/012...', 78, Array)
#1 /www/htdocs/012345/system/modules/core/library/Contao/Database/Mysqli/Statement.php(78): mysqli->query('SELECT id, chec...')
#2 /www/htdocs/012345/system/modules/core/library/Contao/Database/Statement.php(281): Contao\Database\Mysqli\Statement->execute_query()
#3 /www/htdocs/012345/system/modules/core/library/Contao/Database/Statement.php(254): Contao\Database\Statement->query()
#4 /www/htdocs/012345/system/modules/core/library/Contao/Search.php(148): Contao\Database\Statement->execute('news/artikel/sp...', '13')
#5 /www/htdocs/012345/system/modules/core/classes/FrontendTemplate.php(310): Contao\Search::indexPage(Array)
#6 /www/htdocs/012345/system/modules/core/classes/FrontendTemplate.php(121): Contao\FrontendTemplate->addToSearchIndex()
#7 /www/htdocs/012345/system/modules/core/pages/PageRegular.php(189): Contao\FrontendTemplate->output(true)
#8 /www/htdocs/012345/index.php(263): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#9 /www/htdocs/012345/index.php(447): Index->run()
#10 {main}

[11-Jul-2014 03:46:25 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'Query error: MySQL server has gone away (SELECT id, checksum FROM tl_search WHERE url='news/artikel/spitzenhandball-im-dormagener-tsv-bayer-sportcenter-beim-derbystar-cup' AND pid='13' LIMIT 0,1)' thrown in /www/htdocs/012345/system/modules/core/library/Contao/Database/Statement.php on line 283
#0 /www/htdocs/012345/system/modules/core/library/Contao/Database/Statement.php(254): Contao\Database\Statement->query()
#1 /www/htdocs/012345/system/modules/core/library/Contao/Search.php(148): Contao\Database\Statement->execute('news/artikel/sp...', '13')
#2 /www/htdocs/012345/system/modules/core/classes/FrontendTemplate.php(310): Contao\Search::indexPage(Array)
#3 /www/htdocs/012345/system/modules/core/classes/FrontendTemplate.php(121): Contao\FrontendTemplate->addToSearchIndex()
#4 /www/htdocs/012345/system/modules/core/pages/PageRegular.php(189): Contao\FrontendTemplate->output(true)
#5 /www/htdocs/012345/index.php(263): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#6 /www/htdocs/012345/index.php(447): Index->run()
#7 {main}

[11-Jul-2014 03:46:25 Europe/Berlin] 
PHP Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/012345/system/modules/core/library/Contao/Template.php:270) in /www/htdocs/012345/system/helper/functions.php on line 129
#0 [internal function]: __error(2, 'Cannot modify h...', '/www/htdocs/012...', 129, Array)
#1 /www/htdocs/012345/system/helper/functions.php(129): header('HTTP/1.1 500 In...')
#2 /www/htdocs/012345/system/helper/functions.php(114): show_help_message()
#3 [internal function]: __exception(Object(Exception))
#4 {main}

Kann damit jemand etwas anfangen?

Das fe_page-Template hatte ich heute Morgen komplett neu erstellt, da sich über die letzten zwei Jahre doch einiges geändert hat. Der Fehler tritt aber dennoch auf. Ich habe {{date::Y}} jetzt kurzerhand manuell in den Footer geschrieben, damit das nicht mehr so kacke ausschaut. Auch hatte ich heute Morgen noch mal Contao geladen und mit rsync drüberlaufen lassen. Hat aber leider nichts gebracht...

[tab]

Sieht auf den ersten Blick erst mal so aus, als ob du Probleme mit der Verbindung zum Datenbankserver hast.

Edit: Vielleicht kannst du ja nötigenfalls mal testen, ob es am Hosting liegt. Wenn es auf einem anderen Webspace nicht passiert (mit einer 1:1 Kopie der Website) ...

[Der Astronaut]

Hallo zusammen,

ich muss den Thread leider noch einmal rausgraben, da das Problem mit den nicht umgewandelten Inserttags leider immer noch besteht. Das Problem bezieht sich mittlerweile auf vier (!) Contao-Installationen (3.4.4). Zwei davon sind relativ frisch. Eine letztes Jahr im Herbst, die andere im Februar aufgezogen. Überall aber das selbe Problem: In der Hauptspalte werden die Inserttags bei aktivem Caching (Server) rigoros umgewandelt, in allen anderen Spalten, auch Header und Footer, wann Contao Bock hat! Und langsam fuckt mich das echt mega ab! Vor allem jetzt, wo ich das Caching dringendst brauche und ebenso die Möglichkeit in den Spalten Inserttags zu benutzen, denn die Erweiterung "Banners" bindet die Banner per Inserttag ein und alles was angezeigt wird ist "{{cache_banner_module::58::ce_::mod_banner mBottom05::::::html5::}}". Mir bleibt da nur die Option das Caching auszustellen und das geht mir echt gegen den Strich!

Leider habe ich nicht die Möglichkeit es bei einem anderen Hoster (bin bei All-Inkl.com) zu testen. Aber selbst bei einer frischen Installation, die keine Erweiterungen, bei der nichts an der htaccess geändert wurde und keine exotischen Einstellungen gemacht wurden, passiert das.

Header, Footer, linke und rechte Spalte habe ich nach dieser Anleitung angelegt: http://de.contaowiki.org/Die_erste_W...l_.22Header.22


Ich wäre sehr sehr dankbar, wenn man das Problem noch einmal angehen könnte!!!


Beste Grüße
Sebastian

[BugBuster]

tut mir ja Leid das zu sagen, aber du bist der einzige mit diesem sehr merkwürdigem Problem.
Keine Ahnung was du da machst, irgendwas was alle Installationen gemeinsam haben muss da stören.

Funktioniert eine frische Installation inkl. einer der beiden Demos ohne eigene Anpassungen Änderungen? (Music Academy / COD)
(mal vom Insert Tag Test abgesehen)

[Spooky]

Ich würde mal direkt debuggen und hier ansetzen:

• Contao 3.2.x: index.php#L379
• Contao >= 3.4.x: system/modules/core/controllers/FrontendIndex.php#L374

[Der Astronaut]

Ich habe das Debugging eingeschaltet, aber das sagt mir leider alles absolut gar nichts. (Bin leider kein Entwickler)

Ich bin jetzt noch mal sämtliche Einstellungen durchgegangen, auch mit den Wiki-Seiten verglichen, die htaccess überprüft, verschiedene PHP-Versionen über CGI versucht, permanente DB-Verbindung. Keine Ahnung...

Mir vergeht so langsam auch die Lust. Seit einem 3/4 Jahr schlage ich mich mit dem Problem herum und habe schon so viele Stunden darin investiert, dass ich gar nicht mehr weiß, wo ich überhaupt noch ansetzen soll.

Ich bezweifle, dass es am Hosting (All-Inkl.com) liegt, denn ich bin ja nicht der einzige, der bei denen eine Contao-Seite hat. Und jetzt extra bei einem anderen Hoster testweise eine Contao-Installation hochziehen, habe ich keinen Nerv und will dafür auch kein Geld ausgeben. Zu einem anderen Hoster umziehen möchte ich sehr ungern, da ich seit über 13 Jahren bei All-Inkl bin und sehr zufrieden mit denen bin.

Auch wenn Contao für mich das beste CMS ist, dass ich seit fast 5 Jahren nutze, mit diesem blöden Fehler kann ich einfach nicht produktiv arbeiten. Da muss ich wohl in den sauren Apfel beißen und mir ein anderes CMS suchen

Ich danke euch sehr für die Unterstützung!!!

Viele Grüße
Sebastian

[tschero]

Hi,

ich kann Dir zwar bei dem Problem selbst nicht helfen aber hier kannst Du 30 Tage kostenlos bei Alphahosting Deine Installation mal testen um zu sehen ob´s am Hoster liegt.

http://alfahosting.de/webhosting-kostenlos-testen/

Gruß
tschero

[Der Astronaut]

Danke für den Tipp. Das werde ich mal in Angriff nehmen.

Inzwischen habe ich bei einer Bekannten, die auch bei All-Inkl.com ist, aber auf einem anderen Server, eine frische Contao-Installation (3.4.4) nach dem Wiki aufgesetzt. In der linken Spalte habe ich dann {{date::Y}} eingefügt und gehe ich mit einem anderen Browser auf die Seite, als mit dem ich Backend eingeloggt bin, dann wird der Inserttag einfach nicht umgewandelt. Mit dem Browser, mit dem ich im Backend eingeloggt bin, wird es korrekt angezeigt, nämlich 2015. Stelle ich das Caching komplett aus, wird der Inserttag auch im anderen Browser umgewandelt.

Es ist echt zum Mäuse melken...

[Spooky]

Wie genau hast du den Inserttag in diesem Fall nun eingefügt?

[Der Astronaut]

Als Textelement.

[Spooky]

Welche PHP Version läuft am all-inkl Server? Ist eine AddHandler Direktive in der .htaccess im Einsatz?

[Der Astronaut]

Eine htaccess ist bei der Testinstallation gar nicht im Einsatz, somit auch kein AddHandler. Seit einiger Zeit kann man die PHP-Version auch über das KAS von All-Inkl.com einstellen. Eingestellt ist 5.6.6 (CGI).

Ich hatte aber auch die "normale" PHP-Version versucht, die als Modul läuft. Das ist 5.4.38. Ging nicht.

[Spooky]

Ich konnte das Problem auf einem all-inkl Webspace von mir nicht nachvollziehen. Evt. kannst du uns FTP und Contao Zugang zu einer der Contao Installationen geben, wo das Problem Auftritt, damit man sich das mal genauer ansehen kann.

[Der Astronaut]

Ich habe dir gerade eine PN geschrieben.

[Jens.]

Hallo zusammen,
bei meiner Installation habe ich, so wie es aussieht, ein ähnliches Verhalten.
In der Fusszeile habe ich ein " © {{date::Y}} Basar ... " als Text definiert und wird mir in der Vorschau auch als " © 2015 Basar ..." angezeigt.
Wenn ich den Seitencache leere und mir die Seite aufrufe, habe ich dann unten in der Fusszeile " © {{date::Y}} Basar ..." stehen, erst ein erneutes laden der Seite bringt die Jahreszahl.
Die Installation ist die 3.4.4 mit php Version 5.6.6 und läuft bei alfahosting.

Gruß
Jens

date.png

[Der Astronaut]

Daaaaaanke Jens für deinen Beitrag!!! Der beweist, dass ich nicht halluziniere!!!

Spooky schaut sich das Problem bei einer Testinstallation auf meinem Webspace gerade an. Ich bin sehr gespannt.

[Spooky]

Ok, es scheint hier tatsächlich ein Problem in Contao vorzuliegen. Man kann das auch tlw. in der Contao Online Demo reproduzieren.

Es hängt mit dem rekursiven replacement von Insert Tags zusammen. Der Astronaut verwendet nämlich folgende Struktur:

• In einer nicht veröffentlichten Seite gibt es je einen Artikel für den Header, Left und Right.
• In den Modulen gibt es je ein HTML Modul, wo diese Artikel per {{insert_article::XX}} eingefügt werden.
• Diese Module sind an ihren jeweiligen Positionen im Seitenlayout eingebunden.

Stellt man dies in der Online Demo nach und fügt in einen dieser eingefügten Artikeln einen Insert Tag in einem normalen Text Content Element ein, wie zB {{date::Y}}, und aktiviert den Seitencache von Contao, dann ist, zumindest in der Online Demo von Contao, beim ersten Seitenaufruf, also wenn die Seite noch nicht im Cache liegt, der Insert Tag zu sehen, anstatt das Jahr. Bei den nächsten Seitenaufrufen, also wenn die Seite schon aus dem Cache kommt, passiert dies jedoch nicht mehr. In der Testinstallation von Der Astronaut ist der {{date::Y}} Insert Tag jedoch immer zu sehen.

Lokal konnte ich das in einer Contao 3.2.19 Installation jedoch noch nicht reproduzieren, was mich gerade ein wenig verwundert.


Sobald ich das geanuer analysiert habe, werde ich dazu ein Ticket erstellen.

[Der Astronaut]

WOW, das ging ja echt fix! Vielen lieben Dank für deine Hilfe! Das ist richtig toll!

[Bennie]

Ich habe wie Jens auch eine Installation 3.4.4 und php 5.6.6 bei alfahosting und kann das Problem nicht reproduzieren.
Ich habe in den Einstellungen nur den Servercache aktiviert - vielleicht das noch als Hinweis.

Grüße
Bennie

[Der Astronaut]

Ich hatte in diesem Beitrag weiter oben ursprünglich auch die Version 3.2.19 erwähnt. Ich habe es in dieser Installation jetzt noch mal getestet und da funktioniert alles. Allerdings hatte ich diese Installation auch vor wenigen Tagen erst von 3.2.12 auf die aktuelle LTS aktualisiert. Entweder bestand das Problem bei der 3.2.12 noch oder ich habe mich vertan, was ich bei dem Chaos, der bei mir gerade herrscht leider nicht ausschließen kann. Sorry!

[Spooky]

Ich habe wie Jens auch eine Installation 3.4.4 und php 5.6.6 bei alfahosting und kann das Problem nicht reproduzieren.
Ich habe in den Einstellungen nur den Servercache aktiviert - vielleicht das noch als Hinweis.

Grüße
Bennie

Hast du es exakt wie hier beschrieben nachgestellt? Es tritt nur bei rekursiv ersetzten Insert Tags auf.

[Jens.]

Hallo Bennie,
meine Struktur ist wie die vom Astronaut, die Spooky beschrieben hat.
Den Copyright-Hinweis "© {{date::Y}}" als nicht veröffentllichten Artikel angelegt und über ein HTML-Modul per {{insert_content::xxx}} in das Seitenlayout als Fusszeile eingebunden
Einstellung "nur Servercache" ist aktiviert.

Gruß
Jens

[Bennie]

Ich hab es genauso nachgestellt , da ich das auch ständig nutze mit dem © {{date::Y}}
Habe einige Varianten durchprobiert, bei mir trat es jedenfalls bisher nie auf.

[BugBuster]

Hmm, warum über den Artikel? Ich schreibe in dem HTML Modul direkt das © {{date::Y}} rein (bzw. den gesamten Footer) und gut ist.
Das html Modul wird dann übers Layout eingebunden und fertig.

Was mich hier grad stören würde, das ich unveröffentlichte Artikel per Insert-Tag einbingen kann, wenn das hier wirklich so getan wird.

[Jens.]

Hallo BugBuster,
den Tipp habe ich mal aufgeschnappt, denn wenn ich dieses über den Artikel macht, kann ich Backendnutzern es ermöglichen die Fusszeile zu editieren, wenn gewünscht, ohne das diese auf die Module zugreifen müssen.
Ja, es funktioniert mit einem unveröffentlichen Artikel.

Gruß
Jens

[Der Astronaut]

Hmm, warum über den Artikel? Ich schreibe in dem HTML Modul direkt das © {{date::Y}} rein (bzw. den gesamten Footer) und gut ist.
Das html Modul wird dann übers Layout eingebunden und fertig.

Was mich hier grad stören würde, das ich unveröffentlichte Artikel per Insert-Tag einbingen kann, wenn das hier wirklich so getan wird.

Warum überhaupt ein CMS verwenden, wenn ich doch alles gleich in HTML schreiben könnte... Wenn man gleich ein HTML-Modul verwenden kann/soll, was soll dann die Anleitung im Contao-Wiki? Nicht jeder Kunde kann HTML!

Es geht ja nicht nur um das {{date::Y}}! Das Banner-Modul z.B. wird auch per Inserttag eingebunden, welches dann von dem Problem ebenfalls betroffen ist. Deswegen hatte ich das Thema hier ja überhaupt noch mal aufgegriffen. Außerdem tritt der Fehler auch bei einem HTML-Modul auf.

Bei mir sind die Artikel alle veröffentlicht.

[tab]

Ich kenne das etwas anders. Nämlich mit einem veröffentlichten Artikel in einer nicht veröffentlichten Seite. Bei einem unveröffentlichten Artikel wäre ich auch eher Bugbusters Meinung, dass sowas im FE nicht angezeigt werden sollte. Wusste gar nicht, dass das tatsächlich geht?!?

[BugBuster]

Wer sagt denn, das der Wiki Artikel die einzige und richtige Lösung wäre? Ich habe damit zeigen wollen, das es auch ohne Rekursion geht.

Das Banner Modul legst du dann auch in den Artikel oder was? Das packe ich immer direkt übers Layout rein, sofern es in eine Spalte soll. Dafür ist die ja da, da gehen ja mehrere Module rein.
Bzw. als Artikel Elelment Modul und dann den Artikel direkt ins Layout. (bei meinen Grid basierten Seiten)

Sowas ginge auch über eine Erweiterung, Name grad entfallen (glaub von Oliver Hoff). Im Modul definierte man, welche Artikel/Elemente man zu einem virtuellem Modul zusammenfassen möchte und hat dann ganz normal das Modul ins Layout eingebunden.

[Der Astronaut]

Wer sagt denn, das der Wiki Artikel die einzige und richtige Lösung wäre? Ich habe damit zeigen wollen, das es auch ohne Rekursion geht.

Niemand sagt das. Ich gehe aber davon aus, dass die im Wiki beschriebene Methode die empfohlene ist. Magst du kurz erklären, was mit Rekursion gemeint ist?

Das Banner Modul legst du dann auch in den Artikel oder was? Das packe ich immer direkt übers Layout rein, sofern es in eine Spalte soll. Dafür ist die ja da, da gehen ja mehrere Module rein.
Bzw. als Artikel Elelment Modul und dann den Artikel direkt ins Layout. (bei meinen Grid basierten Seiten)

Nein, die Banner-Erweiterung binde ich als Modul ein. Nur wurde es bei mir als "{{cache_banner_module::58::ce_::mod_banner mBottom05::::::html5::}}" ausgegeben. Erst beim Reload wurde der Banner angezeigt. Deshalb ging ich davon aus, dass das Modul einen Inserttag generiert.

[Spooky]

Hmm, warum über den Artikel? Ich schreibe in dem HTML Modul direkt das © {{date::Y}} rein (bzw. den gesamten Footer) und gut ist.
Das html Modul wird dann übers Layout eingebunden und fertig.

Im Fall von Der Astronaut ist es ja mehr als nur dieser eine Insert Tag. In seinem Fall wird der Inhalt für Left, Right und Header über diese Include Artikel befüllt, was ja grundsätzlich nichts falsches ist. Wenn sich in diesen Artikeln weitere Insert Tags befinden (was ja nicht unwahrscheinlich ist), kommt es zu diesem Fehlverhalten. Und es liegt ja auch definitiv ein Fehler in Contao vor.

Was mich hier grad stören würde, das ich unveröffentlichte Artikel per Insert-Tag einbingen kann, wenn das hier wirklich so getan wird.

Die Artikel selbst sind ja veröffentlicht, die Page selbst ist nicht veröffentlicht.

[Jens.]

Hallo Spooky,
ich glaube wir haben hier zwei unterschiedliche Wege der vom Astronaut mit dem über die unveröffentliche Seite und der die ich verwende über einen unveröffentlichen Artikel.
Gruß
Jens

[Spooky]

Hallo Spooky,
ich glaube wir haben hier zwei unterschiedliche Wege der vom Astronaut mit dem über die unveröffentliche Seite und der die ich verwende über einen unveröffentlichen Artikel.
Gruß
Jens

Nein, ist eigentlich das selbe Prinzip . Einmal ist es unveröffentlichte Seite + veröffentlichter Artikel + {{insert_article::*}} und bei dir ist es ein unveröffentlichter Artikel + ein veröffentlichtes Inhaltselement + {{insert_content::*}}. Der unveröffentlichte Parent spielt bei {{insert_*}} keine Rolle, jedoch wenn das eingefügte Element selbst unveröffentlicht ist, dann würde es auch dort wo es eingefügt wurde nicht angezeigt.

[Spooky]

Ok, Der Astronaut, ich weiß nun was bei dir passiert, also warum bei deiner Testseite die Insert Tags in manchen Browsern nie ersetzt werden.

• Es ist prinzipiell so wie ich beschrieben habe: sobald der Seitencache aktiviert ist und die Seite zum ersten mal generiert wird, werden die Insert Tags nicht rekursiv ersetzt - aufgrund eines Fehlers in Contao, den ich noch nicht gefunden habe.
• Jetzt spielt hier zusätzlich auch noch dieser Fehler in Contao eine Rolle: #7618. Kurz erklärt: in manchen Situationen lädt Contao die Seite nie aus dem Seitencache, obwohl eine gecachte Seite vorhanden wäre.
• Dadurch wird die Seite jedes mal neu generiert (und neu in den Cache geschrieben) und es tritt dadurch auch jedes mal der Fehler auf, dass die Insert Tags beim ersten mal generieren der Seite nicht rekursiv ersetzt werden.

Mit Contao 3.4.5 wird das Problem behoben sein, dass die Seite jedes mal neu ge-cached wird. Das Problem, dass beim erzeugen der Cache Seite die Insert Tags nicht rekursiv ersetzt werden ist meines Wissens nach aber noch nicht erfasst worden.