Druckbare Version
Hallo zusammen,
Ich habe den Effekt schon gefühlt "ewig", jetzt frage ich doch mal: Warum passiert das was im Screenshot zu sehen ist: Obwohl Datum per Selektor gewählt (oder manuell eingetippt, ist egal) ist es "angeblich" falsch formatiert. Meist habe ich mir dadurch beholfen, dass ich diese "Automatik" Funktion nicht benutze - ist doch aber blöd...
In den Einstellungen habe ich für Datums- und Zeitformat "j.n.Y, G:i" eingetragen - falls das von Belang ist.
Warum hast du dieses Datumsformat eingestellt? Wenn du nur die Ausgabe eines Datums im Frontend ändern möchtest, dann solltest du nur die Einstellung im jeweiligen Website Startpunkt benutzen. Denn das Datumsformat, welches du in den System Einstellungen setzt wirkt sich auch auf das Datumsformat bei Eingaben im Backend aus. Dieses Datumsformat sollte möglichst Standard bleiben, wie zB Y-m-d H:i oder d.m.Y H:i. Ansonsten kann das Datumsformat möglicherweise nicht erkannt werden.
Das kann ich gar nicht eindeutig beantworten, weil auch das gefühlt "schon immer" so ist. Vielleicht gab es die Möglichkeit zum Einstellen des Datum-/Zeit-Formats in (ur)alten Versionen unter "Website Startpunkt " noch nicht? Möglicherweise habe ich das damals zu Typolight-Zeiten in die Systemeinstellungen eingetragen und mich lange nicht dran gestört? Vielleicht wußte ich es aber auch nicht bzw. hab es nicht unter Webseite Startpunkt (gesucht oder) gefunden. DA steht jedenfalls GAR NICHTS in meinen Feldern zu Datum und Zeit Format.Zitat:
Zitat von Spooky
In den Systemeinstellungen kann ich Deine Vorschläge auch gar nicht eintragen, da springt es immer auf meine alte Einstellung "j.n.Y, G:i" zurück - trotz Firefox Cache Leerung. Selbst wenn ich mal einen anderen Browser - der die Seite NOCH NIE gesehen hat benutze, springt es beim Speichern auf meine alte Einstellung zurück.
In der "Popup-Hilfe" steht auch sinngemäß, dass "mein" Format grundsätzlich machbar und erlaubt ist:
Contao unterstützt alle Datums- und Zeitformate, die mit der PHP-Funktion date() geparst werden können. Um alle Eingaben in einen UNIX-Zeitstempel umwandeln zu können, sind im Backend jedoch ausschließlich numerische Formate (j, d, m, n, y, Y, g, G, h, H, i, s) erlaubt.
Nun bin ich noch mehr verwirrt...
Die gibt es seit Contao 2.11 oder sogar früher.Zitat:
Zitat von purzel
Dann hast du das wohl in einer Config Datei fixiert.Zitat:
Zitat von purzel
Echt schon so lange? *staun*Zitat:
Zitat von Spooky
Meine erste Installation hieß noch Typolight ;) und ich musste bei irgendeinem Update diverse Verzeichnisse umbenennen.
Danke aber für den Tipp, da habe ich es gefunden, sogar ZWEI Mal - vermutlich ebenfalls archaisch bedingt:
Sollte ich da mal aufräumen? Zum Beispiel habe ich ja eigentlich 4.4.49 und die zweiten ("falschen") Datum-/Zeit-Einstellungen sollten wohl ersatzlos raus.PHP-Code:### INSTALL SCRIPT START ###
...
$GLOBALS['TL_CONFIG']['dateFormat'] = 'd.m.Y';
$GLOBALS['TL_CONFIG']['timeFormat'] = 'H:i';
$GLOBALS['TL_CONFIG']['datimFormat'] = 'd.m.Y H:i';
### INSTALL SCRIPT STOP ###
...
$GLOBALS['TL_CONFIG']['timeFormat'] = 'G:i';
$GLOBALS['TL_CONFIG']['datimFormat'] = 'j.n.Y, G:i';
...
$GLOBALS['TL_CONFIG']['latestVersion'] = '3.5.40';
...
Ja, da solltest du aufräumen. Das was außerhalb von ### INSTALL SCRIPT START ### und ### INSTALL SCRIPT STOP ### steht musst du entfernen - bzw. entsprechend innerhalb der beiden Markierungen anpassen oder hinzufügen.
Hm, AUSSERHALB habe ich bedeutend mehr als innerhalb.Zitat:
Zitat von Spooky
Date und Tijme AUSSERHALB habe ich schon gelöscht.PHP-Code:### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['licenseAccepted'] = true;
$GLOBALS['TL_CONFIG']['installPassword'] = '######'; // entfernt
$GLOBALS['TL_CONFIG']['calendar_ical']['csvimport'] = <ewig langer String>; // nur Dummy
$GLOBALS['TL_CONFIG']['dateFormat'] = 'd.m.Y';
$GLOBALS['TL_CONFIG']['datimFormat'] = 'd.m.Y H:i';
### INSTALL SCRIPT STOP ###
/* Werte hinter = im Folgenden gelöscht */
$GLOBALS['TL_CONFIG']['websiteTitle']
$GLOBALS['TL_CONFIG']['adminEmail']
$GLOBALS['TL_CONFIG']['dbDriver']
$GLOBALS['TL_CONFIG']['dbHost']
$GLOBALS['TL_CONFIG']['dbUser']
$GLOBALS['TL_CONFIG']['dbPass']
$GLOBALS['TL_CONFIG']['dbDatabase']
$GLOBALS['TL_CONFIG']['dbPconnect']
$GLOBALS['TL_CONFIG']['dbCharset']
$GLOBALS['TL_CONFIG']['dbPort']
$GLOBALS['TL_CONFIG']['dbSocket']
$GLOBALS['TL_CONFIG']['encryptionKey']
$GLOBALS['TL_CONFIG']['uploadPath']
$GLOBALS['TL_CONFIG']['checkFileTree']
$GLOBALS['TL_CONFIG']['rewriteURL']
$GLOBALS['TL_CONFIG']['defaultChmod']
$GLOBALS['TL_CONFIG']['maintenanceMode']
$GLOBALS['TL_CONFIG']['installCount']
$GLOBALS['TL_CONFIG']['disableIpCheck']
$GLOBALS['TL_CONFIG']['templateFiles']
$GLOBALS['TL_CONFIG']['allowedTags']
$GLOBALS['TL_CONFIG']['allowedDownload']
$GLOBALS['TL_CONFIG']['uploadTypes']
$GLOBALS['TL_CONFIG']['calendar_ical']['csvimport']
$GLOBALS['TL_CONFIG']['debugMode']
$GLOBALS['TL_CONFIG']['maxFileSize']
$GLOBALS['TL_CONFIG']['imageWidth']
$GLOBALS['TL_CONFIG']['imageHeight']
Zu welchem Vorgehen rätst Du mir?
EDIT
bzw. anders gefragt: was davon wird (noch) benötigt und was ist historisch bedingt und sollte weg?
Du musst das machen, was ich gesagt habe ;)
Schon klar :)Zitat:
Zitat von Spooky
So ganz eideutig empfinde ich es aber nicht:
Zitat:
Zitat von Spooky
Deswegen fragte ich ja
Ich könnte also einfach stumpf alles (außer etwaige Duplikate) von "außerhalb" nach "innerhalb" verschieben - oder eben nur die Teile die (noch) benötigt werden.Zitat:
Zitat von purzel
Letzteres weiß ich aber nicht... Vielleicht ist ja ALLES benötigt? Ich will es ja "nachhaltig" richtig machen ;)
Ich habe beides mal probiert:
Zitat:
Zitat von Spooky
Die Einträge mit 'db...' werden anscheinend nicht (mehr) wirklich benötigt (*), während viele andere "wiederkommen", wenn ich in den Feldern im Backend SYSTEM -> EINSTELLUNGEN Änderungen vornehme.Zitat:
Zitat von purzel
(*) Die Inhalte hat mir grep in app/config/parameters.yml gefunden
Ich denke, ich kann - weil keine Einträge mehr drin sind, die ich selbst ergänzt habe - die config Datei jetzt ruhigen Gewissens als "aufgeräumt" deklarieren :)
Danke nochmal @spooky.