InsertTag {{last_update}}

**purzel** · 10.03.2019, 08:41

Moin!

Ich benutze auf einer Seite meiner Präsenz das InsertTag {{last_update}} damit die Leser/innen sehen können sollen, wann der Artikel zuletzt aktualisiert wurde. Das war zumindest die Absicht. Mir ist das bisher nie aufgefallen - und mit der Board-Suche hatte ich keinen Erfolg: da erscheint dann aber nicht das Datum des Artikels mit dem InsertTag, sondern ganz allgemein das letzte Änderungsdatum der Instanz, auch wenn ganz andere Artikel geändert/ergänzt wurden. Soll das so? Habe ich eine andere Möglichkeit, automatisiert (!) das Änderungsdatum NUR dieses Artikels einzubinden? In der Doku zu InsertTags fand ich nichts. Manuell ändern ginge natürlich, aber das vergisst man doch...

TIA
purzel

**planepix** · 10.03.2019, 09:34

Hallo Purzel,
schau mal in diesen Thread: https://community.contao.org/de/show...ikels-ausgeben

ER: https://contao.org/de/erweiterungsli...000029.de.html
Aus deinem Post geht nicht hervor, für welche Contao Version du das suchst.

**purzel** · 10.03.2019, 10:13

Herzlichen Dank erstmal, das scheint das Richtige zu sein.

Zwar ist es nur bis 3.5.4 freigegeben, scheint aber grundsätzlich mit meiner 3.5.12 zu laufen (sorry für's Vergessen meiner Version).
Ich muss "nur" noch kapieren, wie ich es benutze damit es auch das Richtige anzeigt...
Die Doku auf https://contao.org/de/erweiterungsli...000029.de.html erscheint mir nämlich nicht vollständig, da ist wohl experimentieren angesagt.

**planepix** · 10.03.2019, 10:37

Vermutlich macht es Sinn, den Inserttag in das Template des Artikels zu ergänzen; dann steht es in jedem Artikel zur Verfügung.

**purzel** · 10.03.2019, 11:25

Zitat von planepix

... in das Template des Artikels zu ergänzen; dann steht es in jedem Artikel zur Verfügung.

Ähhh... wie meinst Du das? Sollte ich quasi z.B. {{last_change_page::2::all::datetime}} in das Template ce_text einbauen?

Ich habe aber mehrere Probleme mit der Erweiterung:
a) benutze ich DREI Parameter , gibt es Uncaught exception Errors, Beispiel siehe unten. Mit ZWEI Parametern gehts - aber für mich nicht immer eindeutig nachvollziehbar WIE. (Mag an der IMHO suboptimalen Doku liegen)
b) Ich kriege es schon nicht hin, einen korrekten Zeitstempel anzuzeigen, wenn ich IRGENDEINES von MEHREREN "normalen" Textelementen ändere; hier weiß ich nicht, ob das ein Folgefehler von a) ist oder ich ein Verständnisproblem habe oder ein Bug oder eine "Unvollständigkeit" in der Erweiterung ist.

Die betreffende Seite enthält übrigens ein Formular(-Modul). Das Formular habe ich mit dem Formulargenerator gebaut und das anzuzeigende Änderungsdatum soll das Formular mit einschließen. An das Formular habe ich mich wegen vorgenannter Probleme jedoch noch gar nicht heran getraut - ob Formulare/Module überhaupt berücksichtigt werden?
Sorry, dass es um ein Formular/Modul geht hätte ich schon gleich am Anfang erwähnen können.

Code:

[10-Mar-2019 11:52:20 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'Query error: Unknown column 'tl_module.news_archives' in 'field list' (SELECT tl_module.news_archives AS ids FROM tl_content, tl_module WHERE tl_content.ptable = 'tl_article' AND tl_module.type IN ('newslist','newsreader','newsarchive','newsmenu') AND tl_content.module = tl_module.id AND tl_content.invisible<>'1' AND tl_content.id='1793')' thrown in htdocs/system/modules/core/library/Contao/Database/Statement.php on line 295
#0 htdocs/system/modules/core/library/Contao/Database/Statement.php(264): Contao\Database\Statement->query()
#1 htdocs/system/modules/last_change/classes/lastChange.php(222): Contao\Database\Statement->execute('1', '1793')
#2 htdocs/system/modules/last_change/classes/lastChange.php(77): lastChange->doCe(Array)
#3 htdocs/system/modules/core/library/Contao/InsertTags.php(1129): lastChange->getChange('last_change_ce:...', false, '', Array, Array, Array, 24, 37)
#4 htdocs/system/modules/core/library/Contao/Controller.php(692): Contao\InsertTags->replace('<!DOCTYPE html ...', false)
#5 htdocs/system/modules/core/classes/FrontendTemplate.php(100): Contao\Controller::replaceInsertTags('<!DOCTYPE html ...', false)
#6 htdocs/system/modules/core/pages/PageRegular.php(190): Contao\FrontendTemplate->output(true)
#7 htdocs/system/modules/core/controllers/FrontendIndex.php(285): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#8 htdocs/index.php(20): Contao\FrontendIndex->run()
#9 {main}

**planepix** · 10.03.2019, 11:41

Die erste Zeile der Fehlermeldung könnte daran liegen, dass das Datenbank Update nach der Installation nicht bzw. nicht vollständig erfolgt ist.

Laut Seite im ER gibt es für ein Formular keinen Inserttag. Aber einen für ein Inhaltselement (CE). Damit könnte dann das Formular erfasst werden.

Aber: Ändert sich denn das Formular?

**purzel** · 10.03.2019, 13:12

Zitat von planepix

Die erste Zeile der Fehlermeldung könnte daran liegen, dass das Datenbank Update nach der Installation nicht bzw. nicht vollständig erfolgt ist.

Denkbar - es gab aber keinerlei Fehlermeldungen o.ä. bei der Installation.

Zitat von planepix

Laut Seite im ER gibt es für ein Formular keinen Inserttag. Aber einen für ein Inhaltselement (CE). Damit könnte dann das Formular erfasst werden.

Genau das habe ich auch erstens erkannt und zweitens mir dann auch gedacht. Aber entweder mache ich irgendwas falsch oder es funktioniert nicht (wie erwartet). Beispiel:
Ich habe eine Seite (ID 165), auf der ist genau EIN Artikel (ID 352). Wenn ich in der Ansicht "Artikel" auf das blaue Info-Symbol des Artikels klicke, wird mir (u.a.) "Änderungsdatum: 12.9.2018, 17:11" angezeigt. Klicke ich auf den Bearbeiten-Stift, steht in den hellgrauen Feld in dem man die Artikel-Eigenschaften bearbeiten kann "Änderungsdatum: 10.3.2019, 13:40" - das ist der Zeitstempel der letzten Änderung eines BELIEBIGEN Inhaltselements des Artikels - also eigentlich genau der den ich haben will. Genau den kriege ich aber nicht mit dem Inserttag "zu fassen". (Es gibt zwei ce_text auf meiner Testseite (ID 1793 und 1795) und ein Formular (ID 6))
Allerdings ändert sich das vorgenannte Datum nicht, wenn ich mittels Formulargenerator im Formular selbst Änderungen vornehme.
{{last_change_article::352::datetime}} zeigt 12.9.2018, 17:11 - sollte aber 10.3.2019, 13:40 zeigen.

Zitat von planepix

Aber: Ändert sich denn das Formular?

Gelegentlich, nicht so sonderlich oft - deshalb fiel das Problem(chen) ja lange nicht auf. Gerade deshalb möchte ich aber gern, dass das Änderungsdatum automatisch aktualisiert wird weil man das bei seltenem Ändern wohl vergisst

Ich glaube aber, ich muss mich mit dem Umstand anfreunden, das Änderungsdatum des Formulars DOCH manuell ändern zu müssen. Denn sogar das Formular selbst hat zwei Datümer (Datums?), genau wie im vorherigen Absatz der Artikel 352. Das hinter dem Blauen Info-Button wirkt aber auch hier falsch. Ich habe jetzt dem Formular ganz oben ein ausgeblendetes Feld verpasst welches an die Änderung des Änderungsdatums erinnert: ganz unten das Feld "Stand:" anpassen! um dem vorgenannten Vergessen vorzubeugen. Nicht schö aber selten :-)

**VGT** · 10.03.2019, 21:27

also ich benutze noch problemlos in einer Conto 4.7 und 4.4.34 die Erweiterung last_change, wie oben in einem Link beschrieben; in der Fußzeile eines Rock-Solid-Templates habe ich einfach

PHP-Code:


Zuletzt aktualisiert: {{last_change_page::{{page::id}}::all::date}}

eingetragen;
auf der Webseite steht dann

HTML-Code:

Zuletzt aktualisiert: 03.03.2019

Uhrzeiten wann zuletzt geändert brauche ich nicht, der Tag reicht völlig
Die Erweiterung habe ich manuell installiert unter /system/modules

**purzel** · 11.03.2019, 07:13

Wenn ich Deinen Code einfüge habe ich (siehe auch oben) DREI Parameter und bekomme die schon bekannte Fehlermeldung:

Code:

[11-Mar-2019 07:54:02 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'Query error: Unknown column 'tl_module.news_archives' in 'field list' (SELECT tl_module.news_archives AS ids FROM tl_article, tl_content, tl_module WHERE tl_article.id = tl_content.pid AND tl_content.ptable = 'tl_article' AND tl_module.type IN ('newslist','newsreader','newsarchive','newsmenu') AND tl_content.module = tl_module.id AND tl_content.invisible<>'1' AND tl_article.pid='165')' thrown in htdocs/system/modules/core/library/Contao/Database/Statement.php on line 295
#0 htdocs/system/modules/core/library/Contao/Database/Statement.php(264): Contao\Database\Statement->query()
#1 htdocs/system/modules/last_change/classes/lastChange.php(129): Contao\Database\Statement->execute('1', '165')
#2 htdocs/system/modules/last_change/classes/lastChange.php(67): lastChange->doPage(Array)
#3 htdocs/system/modules/core/library/Contao/InsertTags.php(1129): lastChange->getChange('last_change_pag...', false, '', Array, Array, Array, 33, 43)
#4 htdocs/system/modules/core/library/Contao/Controller.php(692): Contao\InsertTags->replace('<!DOCTYPE html ...', false)
#5 htdocs/system/modules/core/classes/FrontendTemplate.php(100): Contao\Controller::replaceInsertTags('<!DOCTYPE html ...', false)
#6 htdocs/system/modules/core/pages/PageRegular.php(190): Contao\FrontendTemplate->output(true)
#7 htdocs/system/modules/core/controllers/FrontendIndex.php(285): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#8 htdocs/index.php(20): Contao\FrontendIndex->run()
#9 {main}

Installiert habe ich es wie gesagt im Contao 3.5.12 ganz normal über "Erweiterungskatalog; auch erneutes Installieren half nicht. Es kam wie beim ersten Mal auch die Meldung, die Datenbank sei aktuell.

ABER: mir ist auf- bzw. wieder eingefallen, dass ich ja die Erweiterung [news] Nachrichten mangels Bedarf und/oder wegen eines anderen Problems (*) deaktiviert habe. Wenn ich die wieder rein nehme, kriege ich die berühmte Fehlermeldung auch beim Klick auf "Artikel" im BE; ergo BE nicht mehr benutzbar

(*) vielleicht fällt mir auch das wieder wieder ein...

**folkfreund** · 11.03.2019, 07:29

Wie hier im Forum schon öfter erwähnt, solltest du vor dem Versuch Fehler zu beheben zuerst auf die aktuelle Version updaten. In deinem Fall also auf die 3.5.38.
Das ist schon wegen der behobenen Sicherheitslücken anzuraten - und wegen der DSGVO auch erfoderlich (da du ja ein Formular verwendest und also Daten erfasst).

Wie du aus den Antworten sehen kannst, scheint die Erweiterung ja sogar unter 4.7. zu funktionieren. Es sieht also so aus, als wenn in deiner Installation ein Fehler vorliegt - egal, ob nun durch die alte Version oder ein unvollständiges Update der Datenbank (wie von planepix schon angemerkt).

Prüfe also deine Veriosn mit dem Contao-Check, ruf die Datenbankaktualisierung auf und mach auf jeden Fall ein Update auf die Version 3.5.38.

Gruß, folkfreund

**purzel** · 11.03.2019, 09:13

@folkfreund:
Grundsätzlich hast Du natürlich sowas von Recht...
Doch leider habe ich genau die Diskussion (auch in anderen Foren nicht Contao betreffend) schon mehrfach geführt und führen müssen: ich habe erstens die Erfahrung gemacht "mit jedem Update geht irgendwas anderes nicht (mehr)" (natürlich etwas übertrieben) und als Folge davon immer wieder Bammel, dass ich nach einem Update stunden- oder gar tagelang "häkeln" muss bis wieder alles fehlerfrei läuft [1]. Zweitens habe ich ein paar wenige Änderungen (immerhin weniger als zu 2.x Zeiten) in Core-Files gemacht - ergo nicht Update-safe [2]. Drittens nimmt meine Datenschutzerklärung schon Bezug auf das Formular.

[1] schon mehrfach gehabt, ich habe nämlich gern mal "Luxusprobleme"
[2] ich weiß, das das "eigentlich" sch*** ist, fand aber seinerzeit keine andere Möglichkeit

Wenn ich mal viel Lust gepaart mit viel Zeit habe, mache ich mal eine 1:1 Kopie inkl. DB von meiner Instanz und quäle mich durch 26 Updates :-(

@all:
Meine Fehler(meldungen) liegen ja nicht an der Contao-Version, sondern ganz offensichtlich daran, dass ich news und faq deaktiviert habe und deshalb die Erweiterung last_change "auf die Nase fällt". Ich habe aus dem Code der Erweiterung last_change mal die Teile die für für news und faq [3] zuständig sind auskommentiert - und siehe da:

PHP-Code:


 Zuletzt aktualisiert: {{last_change_page::{{page::id}}::all::date}}

funktioniert. Aber leider kriegt es trotzdem nicht mit, wenn ich das Formular ändere - was ja wohl nicht an der Version von Contao liegen kann und auch nicht an den deaktivierten News- und FAQ-Erweiterungen ;-)

[3] ist ebenfalls deaktiviert. Leider kann ich mich nicht mehr erinnern, warum ich seinerzeit News und FAQ deaktivieren musste. Mit irgendwas "beißt" es sich, ich kriege dann wie gesagt die berühmte Fehlermeldung auch beim Klick auf "Artikel" im BE; ergo BE nicht mehr benutzbar.

Diese Fehler bekomme ich, wenn ich über Einstellungen -> inaktive Erweiterungen die News und/oder FAQ 'rein nehme (= Ankreuzung entferne):

Code:

[11-Mar-2019 10:37:58 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'Query error: Unknown column 'j1.news' in 'field list' (SELECT tl_article.*, j1.id AS author__id, j1.tstamp AS author__tstamp, j1.username AS author__username, j1.name AS author__name, j1.email AS author__email, j1.language AS author__language, j1.backendTheme AS author__backendTheme, j1.uploader AS author__uploader, j1.showHelp AS author__showHelp, j1.thumbnails AS author__thumbnails, j1.useRTE AS author__useRTE, j1.useCE AS author__useCE, j1.password AS author__password, j1.pwChange AS author__pwChange, j1.admin AS author__admin, j1.groups AS author__groups, j1.inherit AS author__inherit, j1.modules AS author__modules, j1.themes AS author__themes, j1.pagemounts AS author__pagemounts, j1.alpty AS author__alpty, j1.filemounts AS author__filemounts, j1.fop AS author__fop, j1.forms AS author__forms, j1.formp AS author__formp, j1.disable AS author__disable, j1.start AS author__start, j1.stop AS author__stop, j1.session AS author__session, j1.dateAdded AS author__dateAdded, j1.lastLogin AS author__lastLogin, j1.currentLogin AS author__currentLogin, j1.loginCount AS author__loginCount, j1.locked AS author__locked, j1.calendars AS author__calendars, j1.calendarp AS author__calendarp, j1.calendarfeeds AS author__calendarfeeds, j1.calendarfeedp AS author__calendarfeedp, j1.elements AS author__elements, j1.news AS author__news, j1.newp AS author__newp, j1.newsfeeds AS author__newsfeeds, j1.newsfeedp AS author__newsfeedp, j1.newsletters AS author__newsletters, j1.newsletterp AS author__newsletterp FROM tl_article LEFT JOIN tl_user j1 ON tl_article.author=j1.id WHERE tl_article.id='13' LIMIT 0,1)' thrown in /htdocs/system/modules/core/library/Contao/Database/Statement.php on line 295
#0 /htdocs/system/modules/core/library/Contao/Database/Statement.php(264): Contao\Database\Statement->query()
#1 /htdocs/system/modules/core/library/Contao/Model.php(1082): Contao\Database\Statement->execute('13')
#2 /htdocs/system/modules/core/library/Contao/Model.php(789): Contao\Model::find(Array)
#3 /htdocs/system/modules/core/controllers/BackendMain.php(268): Contao\Model::findByPk('13')
#4 /htdocs/system/modules/core/controllers/BackendMain.php(135): Contao\BackendMain->output()
#5 /htdocs/contao/main.php(20): Contao\BackendMain->run()
#6 {main}
[11-Mar-2019 10:38:35 Europe/Berlin] PHP Fatal error: Uncaught exception 'Exception' with message 'Query error: Unknown column 'j1.faqs' in 'field list' (SELECT tl_article.*, j1.id AS author__id, j1.tstamp AS author__tstamp, j1.username AS author__username, j1.name AS author__name, j1.email AS author__email, j1.language AS author__language, j1.backendTheme AS author__backendTheme, j1.uploader AS author__uploader, j1.showHelp AS author__showHelp, j1.thumbnails AS author__thumbnails, j1.useRTE AS author__useRTE, j1.useCE AS author__useCE, j1.password AS author__password, j1.pwChange AS author__pwChange, j1.admin AS author__admin, j1.groups AS author__groups, j1.inherit AS author__inherit, j1.modules AS author__modules, j1.themes AS author__themes, j1.pagemounts AS author__pagemounts, j1.alpty AS author__alpty, j1.filemounts AS author__filemounts, j1.fop AS author__fop, j1.forms AS author__forms, j1.formp AS author__formp, j1.disable AS author__disable, j1.start AS author__start, j1.stop AS author__stop, j1.session AS author__session, j1.dateAdded AS author__dateAdded, j1.lastLogin AS author__lastLogin, j1.currentLogin AS author__currentLogin, j1.loginCount AS author__loginCount, j1.locked AS author__locked, j1.calendars AS author__calendars, j1.calendarp AS author__calendarp, j1.calendarfeeds AS author__calendarfeeds, j1.calendarfeedp AS author__calendarfeedp, j1.elements AS author__elements, j1.faqs AS author__faqs, j1.faqp AS author__faqp, j1.newsletters AS author__newsletters, j1.newsletterp AS author__newsletterp FROM tl_article LEFT JOIN tl_user j1 ON tl_article.author=j1.id WHERE tl_article.id='13' LIMIT 0,1)' thrown in /htdocs/system/modules/core/library/Contao/Database/Statement.php on line 295
#0 /htdocs/system/modules/core/library/Contao/Database/Statement.php(264): Contao\Database\Statement->query()
#1 /htdocs/system/modules/core/library/Contao/Model.php(1082): Contao\Database\Statement->execute('13')
#2 /htdocs/system/modules/core/library/Contao/Model.php(789): Contao\Model::find(Array)
#3 /htdocs/system/modules/core/controllers/BackendMain.php(268): Contao\Model::findByPk('13')
#4 /htdocs/system/modules/core/controllers/BackendMain.php(135): Contao\BackendMain->output()
#5 /htdocs/contao/main.php(20): Contao\BackendMain->run()
#6 {main}

EDIT: Fehlermeldungen ergänzt

**purzel** · 11.03.2019, 10:29

Zitat von purzel

... mache ich mal eine 1:1 Kopie inkl. DB von meiner Instanz ...

Ich habe sogar eine, geringfügig höher (3.1.14). Leider läuft die nicht. Das BE beschert mir trotz

PHP-Code:


$GLOBALS['TL_CONFIG']['dbDriver'] = 'MySQLi';

eine weiße Seite :-(
Das FE zeigt immerhin die Wartungsseite.
Any hints?

**Spooky** · 11.03.2019, 10:46

Zitat von purzel

PHP-Code:


 Zuletzt aktualisiert: {{last_change_page::{{page::id}}::all::date}}

funktioniert. Aber leider kriegt es trotzdem nicht mit, wenn ich das Formular ändere

last_change_page zeigt das Änderungsdatum der Seite, nicht von Inhaltselementen oder Formularen, die sich vielleicht auf dieser Seite befinden.

**purzel** · 11.03.2019, 11:10

Zitat von purzel

Das FE zeigt immerhin die Wartungsseite.

Hä? was ist nun los? Statt Wartungsseite kommt jetzt die "Richtige" - da ich nicht ins BE komme, habe ich das nicht "vorsätzlich". Die o.g. weiße Seite für BE kommt NACH dem Anmeldeversuch, hatte ich oben vergessen zu erwähnen. Falsche Zugangsdaten müssten ja bemängelt werden denk' ich mir.

@spooky: ich vermute, der Parameter :all: sorgt dafür, dass auch geänderte Inhaltselemente mit ins Änderungsdatum einfließen. Ich habe ein ce_text auf de Seite geändert und das angezeigte Datum ist heute. Also im Prinzip richtig.

**Spooky** · 11.03.2019, 11:30

Stimmt - aber überprüft die Extension dann auch die Änderungsdatums von etwaigen per Inhaltselement inkludierten Modulen oder Formularen?

**folkfreund** · 11.03.2019, 11:36

Ist bezüglich dieses Threads off topic...

Zitat von purzel

Drittens nimmt meine Datenschutzerklärung schon Bezug auf das Formular.

Ich meinte nicht deine Datenschutzerklärung sondern die Pflicht aktuelle Versionen einzusetzen (zumindest nach Bekanntwerden von Sicherheitslücken)

**purzel** · 11.03.2019, 12:48

Zitat von Spooky

Stimmt - aber überprüft die Extension dann auch die Änderungsdatums von etwaigen per Inhaltselement inkludierten Modulen oder Formularen?

Das leider genau nicht, was sehr schade ist. Nur Artikel, News, Events und FAQ. Und natürlich Seiten.
Ich sehe zwei Möglichkeiten:
A (ultra-einfach, mit dem Potenzial es zu vergessen): ich mache wie schon weiter oben erwähnt mein Änderungsdatum immer manuell - so oft ist es ja nicht
B (bisschen Aufwand aber automatisch): jemand liefert einen PHP-Codeschnipsel, der das Änderungsdatum (vorsicht, es gibt zwei, siehe weiter oben, das am blauen Info-Symbol und das im grauen Kasten) eines Formulars ausgibt
Wenn ich erstens diese objektorientierte Syntax kapieren würde (kann nur ein bisschen prozedural) und zweitens eine geeignete SQL-Query "erfinden" könnte könnte ich das vielleicht ins last_change Plugin häkeln (was auch wieder nicht Update-safe wäre)

Zitat von folkfreund

Ist bezüglich dieses Threads off topic...
Ich meinte nicht deine Datenschutzerklärung sondern die Pflicht aktuelle Versionen einzusetzen (zumindest nach Bekanntwerden von Sicherheitslücken)

Äh, ja, auch da hast Du natürlich völlig Recht.
Ich hoffe ja, meine Test-Instanz wieder zum Laufen zu bekommen, um damit probieren, was mit welchem Update mal wieder nicht geht....

Kann man irgendwie "am BE vorbei" eine Art Debug-Mode aktivieren? Im error.log sind nur ein paar Warnings.

**purzel** · 11.03.2019, 14:25

Zitat von purzel

Hä? was ist nun los? Statt Wartungsseite kommt jetzt die "Richtige"

OK, das habe ich immerhin aufklären können: Wenn ich nach hinreichend langer Zeit meine Test-Instanz aufrufe, bekomme ich die Wartungsseite. Versuche ich dann die BE-Anmeldung, kommt nach dem Anmeldedialog und Eingeben der Benutzerdaten die o.g. weiße Seite. Rufe ich dann erneut das FE auf, kommt die "richtige" Seite - was ja normal ist: im BE angemeldet - Wartungsseite wird NICHT angezeigt sondern normales FE.
Das bedeutet aber, dass das BE-Login grundsätzlich funktioniert - das BE selbst aber nicht angezeigt wird. Wo sollte ich da am Besten mit der Fehlersuche ansetzen?

***xchs*** · 11.03.2019, 14:29

Du solltest vor allem einen neuen Thread dafür aufmachen, da dieses Problem mit dem Thema des Threads hier nichts mehr zu tun hat.

**purzel** · 11.03.2019, 15:23

Sehr gern - wenn ich es nicht nachher selbst behoben kriege, z.B. durch eine höhere Version. Habe gerade was entdeckt aber leider keine Zeit mehr:
Fatal error: Cannot use 'String' as class name as it is reserved in system/modules/core/library/Contao/String.php on line 28
Ich melde mich. Oder Du verschiebst die beiden Beiträge einfach in einen neuen Thread *liebguck*

**Spooky** · 11.03.2019, 15:25

Erzeuge lieber einen neuen Thread, wo du dein Problem genau schilderst.

**folkfreund** · 11.03.2019, 16:08

Zitat von purzel

Fatal error: Cannot use 'String' as class name as it is reserved in system/modules/core/library/Contao/String.php on line 28

Das liegt daran, dass du eine Erweiterung (in einer Version) benutzt, die nicht kompatibel mit PHP7 ist.

**purzel** · 11.03.2019, 19:13

Ich habe einen neuen Thread für das Anmeldeproblem erstellt. Vielleicht mag ein Mod oder Admin die Beiträge #18 bis einschließlich diesem dorthin verschieben.

**VGT** · 12.03.2019, 22:33

Zitat von Spooky

last_change_page zeigt das Änderungsdatum der Seite, nicht von Inhaltselementen oder Formularen, die sich vielleicht auf dieser Seite befinden.

last_change prüft nicht, ob eine neue Version eines Formulars inkludiert wird;

@purzel: speichere doch einfach nochmal die Seite ab, in der Du das aktualisierte Formular drin hast, dann hast du doch auch das aktuelle Datum und sparst dir das manuelle eintragen des Datums; du wirst doch das Formular nicht auf -zig Seiten verwendet haben, dann müsste man die alle einzeln abspeichern

Thema: InsertTag {{last_update}}

Themen-Optionen

Thema durchsuchen

InsertTag {{last_update}}

Aktive Benutzer

Aktive Benutzer

Lesezeichen

Lesezeichen

Berechtigungen

Contao

Empfohlene Webdesign-Bücher