Ist eigentlich ganz simpel.
Der ContentType ist in erster Linie dazu da, um das Backend um ein paar Funktionen zu erweitern.
D.h. auf das Frontend hat das keinerlei Auswirkung bzw. verhält sich wie der reguläre Inhaltstyp.
Bsp:
Code: Select all
{content block="test" page_tab="Test Tab" label="Testen wir das mal ..." type="dropdown" items="1,2,3"}
Das führt dazu, dass im Backend für diesen Inhaltsblock ein extra Tab mit einem Dropdown-Feld angezeigt wird.
Im Frontend verhät es sich aber vollkommen normal. Es wird lediglich 1, 2 oder 3 ausgegeben (ja nachdem was im Backend ausgewählt wurde).
Code: Select all
{content block="test2" page_tab="Test Tab" label="Testen wir das nochmal ..." type="image"}
Verhält sich im Backend genauso wie {content_image}.
Im Frontend wird allerdings nur der Pfad zum Bild ausgegeben, weil das reguläre Plugin {content} den Parameter type nicht kennt und somit auch die Funktion, ein -Tag auszugeben nicht hat. Man müsste also, um ein Bild anzuzeigen, das Resultat einer Variablen zuweisen und dann das -Tag selber bauen.
Und hier kann man stattdessen {content2} verwenden. Der gibt dann gleich das Bild aus.
Eine andere Funktion ist der FrontEndUser Zugriff auf den Inhalt.
Das reguläre Plugin prüft nicht, ob der Seitenbesucher eingeloggt ist und einer Gruppe angehört, die im Backend für diese Seite festgelegt wurde. Weil das Plugin diese Funktion nicht kennt.
Will man also ohne CustomContent und FrontEndUsers im Template, eine Seite einfach nur für bestimmte User freigeben, braucht man das Plugin {content2}.
(Ich muss hierbei aber noch testen wie es sich mit dem Zwischenspeichern verhält. Möglicherweise kann man das dann für diese Seite sogar aktiviert lassen.)
In den nächsten Tagen werde ich das noch als Modul veröffentlichen. (ist schon im SVN; wer will kann's testen)
Dann kann man sich die einzelnen Dateien sparen.
Dann ruft man seinen Inhalt entweder mit {content} oder mit {XContent} auf. Je nachdem welche Funktion man braucht.