Mit welcher Version hast Du das getestet?
Das Problem mit dem Smarty Zeug ist, dass im Backend bestimmte Template Variablen aus dem Frontend nicht existieren.
Es gibt ja eigentlich nichtmal ein richtiges Template. (Das Template besteht sozusagen nur aus dem Smarty Code, der als Wert für einen Parameter angegeben wurde)
Um wirklich alle Variablen, die im Frontend existieren auch im Backend verfügbar zu machen, müsste ich die komplette Seite genauso wie im Frontend verarbeiten, bevor die Seite bearbeitet werden kann.
Und das für jeden Inhaltsblock und jedes seiner Parameter einzeln.
Das entspräche bei 10 Eingabefeldern mit 1-2 Parametern in denen Smarty Code vorkommt 10-20 Seitenaufrufen.
Was das für Auswirkungen auf die Performance beim Bearbeiten einer Seite hat, brauch ich ja nicht weiter zu erwähnen.
Allerdings könnte ich zumindest die gängigen Template Variablen wie {$page_alias} etc. auch im Backend verfügbar machen.
(Hatte nur darauf geachtet, dass im $gCms Objekt alles vorhanden ist was gebraucht wird, damit zumindest die Core Plugins funktionieren.
An Template Variablen hatte ich da noch nicht gedacht.)
Ein weiteres Problem sind insbesondere Variablen oder Plugins, die zur jeweiligen Seite gehören. (Wie z.B. {title} oder eben {$page_alias})
Diese liefern als Ergebnis den Text einer 404 Fehlermeldung (oder ähnliches bis garnichts) zurück, wenn die Seite gerade erst erstellt wird, da diese Werte ja noch garnicht existeren.
Andiministrator wrote:
Ich habe jetzt ersteinmal ein Tag namens "page_alias" angelegt, was den PageAlias ausgibt und den Aufruf mit :::page_alias::: umgeschrieben, dann funktioniert es.
Das ist in diesem Falle ohnehin die bessere Variante, wenn es um Seitenrelevante Daten geht, da Du so besser steuern kannst, was passieren soll, wenn es noch kein {$page_alias} gibt. Insbesondere wenn Du es als vordefiniertes Verzeichnis nutzen willst. Denn beim Hinzufügen einer Seite würde bei Deinem Fall der Parameter "dir" den Wert "/uploads/images/Header//" beinhalten. Und da kommt es wieder auf den Server an, wie er damit umgeht. Entweder landest Du bei "/uploads/images/Header" (was wahrscheinlicher ist) oder Du erhältst die Meldung, dass das Verzeichnis nicht existiert.
Andiministrator wrote:
Freue mich schon auf die Upload-Möglichkeit. Kann man dann auch Bilder löschen? Dann wärs perfekt (für mich)
Ich hab vor beim Filepicker die gleichen Funktionen einzubauen, wie beim Tiny MCE Filepicker.
Und da kann man ja einstellen ob Operationen des FileManagers erlaubt sind (also Verzeichnis erstellen, löschen, upload).
Muss nur im Backend die Preferences des AdvancedContent Moduls erweitern und die Berechtigungen hinzufügen.
Aber bevor ich mich daran mache, neue Fehler... ähm Funktionen einzubauen will ich es erstmal stabil haben.
(Sind ja zum Glück keine Funktionen, die man nicht auch irgendwie anders bewältigen kann)
Das ganze soll aber über Ajax Requests laufen, damit die Seiten nicht ständig neu geladen wird, nur weil man eine Datei hochgeladen hat.
Es soll nur der Filepicker bzw. das Dropdown aktualisiert werden.
Mit jQuery sicher keine große Hürde, aber ich überlege gerade, anstelle von jQuery die Core Funktionen (also Prototype) dafür zu nutzen.
(Wozu zwei Frameworks laden, wenn man alles mit einem realisieren kann?)
Dazu muss ich mich aber erstmal mit Prototype anfreunden.
Also brauchts noch bissel Zeit.
