AdvancedContent

Hilfe zu Modulen und Tags
redigo
Forum Members
Forum Members
Posts: 80
Joined: Mon Nov 23, 2009 3:33 pm

AdvancedContent

Post by redigo »

Hallo allerseits
Ich möchte in CSMS 1.7.1 das  Modul AdvancedContent (0.3.3) ausprobieren. Ich habe es von der Forge heruntergeladen und installiert. Es erscheint jetzt auch in /modules. Aber den entsprechenden Tag suche ich vergeblich. Entsprechend erscheint im TinyMCE auch kein Content-Feld.
Bestimmt habe ich etwas übersehen. Ich wäre für sachdienliche Hinweise dankbar. ;-)
Last edited by redigo on Mon Jun 21, 2010 12:43 pm, edited 1 time in total.
nockenfell
Power Poster
Power Poster
Posts: 751
Joined: Fri Sep 12, 2008 2:34 pm

Re: AdvancedContent

Post by nockenfell »

du musst als "Inhaltstyp" der Seite "Content (Extensible)" wählen (ev heisst es mittlerweile auch ein wenig anders)
[this message is written with 100% recycled bits]
redigo
Forum Members
Forum Members
Posts: 80
Joined: Mon Nov 23, 2009 3:33 pm

Re: AdvancedContent

Post by redigo »

Danke, Nockenfell, für Deinen Tipp. Ich habe den Inhaltstyp auf AdvancedContent geändert. Jetzt  zeigt der Tiny wieder ein Inhaltsfeld. Dieses ist aber das gewöhnliche "Content"-Feld, keine Spur von "Advanced". Hast Du eine Ahnung, woran das liegen könnte?
NaN

Re: AdvancedContent

Post by NaN »

Was hast Du denn erwartet?
Hast Du Dir die Hilfe durchgelesen?
Die dürfte eigentlich, wenn momentan erstmal auch nur auf englisch (bin zu faul während der Entwicklung immer zwei Sprachen zu pflegen), ganz genau erklären wie man zu den "Advanced" Möglichkeiten kommt ;)

Edit: Okay, was noch nicht in der Hilfe steht ist, dass es unter Erweiterungen->AdvancedContent ein paar Einstellungen gibt. Muss ich noch anpassen.
(Gibt übrigens schon die 0.3.4; Mit Uploadfunktion im FilePicker; hat zwar noch ein paar kleine Macken mit den Thumbnails, aber die sind schon so gut wie behoben)
Last edited by NaN on Tue Jun 22, 2010 11:35 am, edited 1 time in total.
redigo
Forum Members
Forum Members
Posts: 80
Joined: Mon Nov 23, 2009 3:33 pm

Re: AdvancedContent

Post by redigo »

Ein Wunder natürlich!  ;)
Nein, im Ernst, ich habe Asche auf mein sündiges Haupt gestreut und die "Hilfe" gelesen. Dass man das buchstäblich "buchstäblich" tun sollte", zeigt die Wirkung des Unterschieds zwischen {advancedcontent} und {AdvancedContent}.
Dafür, dass Du die Hilfe erst auf Englisch anbietest, habe ich volles Verständnis.
Ich werde also fleissig üben.
Die neue Version habe ich inzwischen auch installiert.
Danke.
NaN

Re: AdvancedContent

Post by NaN »

redigo wrote:
Dass man das buchstäblich "buchstäblich" tun sollte", zeigt die Wirkung des Unterschieds zwischen {advancedcontent} und {AdvancedContent}.
Ah, okay. Da sollte ich vielleicht auch nochmal extra drauf hinweisen, dass man auf Groß- und Kleinschreibung achten muss.
Man muss halt den extakten Namen des Moduls verwenden. Sonst kann das CMS mit dem Tag nichts anfangen.
redigo
Forum Members
Forum Members
Posts: 80
Joined: Mon Nov 23, 2009 3:33 pm

Re: AdvancedContent

Post by redigo »

Ja, ein solcher Hinweis wäre wohl nicht schlecht, weil die Tag-Namen  im allgemeinen ja durchwegs mit  kleinen Buchstaben geschrieben werden. Das verleitet halt dazu, nicht so genau hinzuschauen.  Aber AdvancedContent ist natürlich besser lesbar als advancedcontent ;-)
NaN

Re: AdvancedContent

Post by NaN »

Das hat nichts mit Lesbarkeit zu tun.
Das liegt daran, dass es kein wirklicher Tag ist.
Das Modul registriert sich selbst beim CMS als "Plugin".
Dafür gibt es eine Funktion, die eigens vom CMS für solche Sachen bereitgestellt wird.
Es gibt leider keine Parameter, die man dieser Funktion übergeben könnte um festzulegen unter welchem Namen es sich als Plugin registrieren soll. Wäre auch blödsinnig, weil dadurch Kollisionen entstehen können, wenn irgendwer ein echtes Plugin oder ein Modul mit dem gleichen Namen erstellen würde.
Daher wird bei solchen Sachen immer der exakte Modulname genommen um die Eindeutigkeit zu erhalten.

Geht leider nicht anders.
redigo
Forum Members
Forum Members
Posts: 80
Joined: Mon Nov 23, 2009 3:33 pm

Re: AdvancedContent

Post by redigo »

Alles klar!  ;)
Danke für die Aufklärung.
owr_bgld

Re: AdvancedContent

Post by owr_bgld »

redigo wrote: Ja, ein solcher Hinweis wäre wohl nicht schlecht, weil die Tag-Namen   im allgemeinen ja durchwegs mit  kleinen Buchstaben geschrieben werden.
Tags ja - aber nicht die Module, da ist kleinschreibung die Ausnahme. Einige Core-Module nutzen die Kleinschreibung z.B. news, search) EDIT: bei UDT's kann auch die groß/Kleinschreibung hilfreich sein imho

den Rest hat NaN ohnehin schon erklärt. Also am besten den Tag mit Copy&Paste reinkopieren, dann klappts auch mit dem Nachbarn ähhh der Einbindung (ich spreche aus Erfahrung - hab mir schon öfters die Haare gerauft, weil ich irgendwo einen Buchstaben irrtümlich klein/groß geschrieben hab und nicht draufgekommen bin ;D )
NaN

Re: AdvancedContent

Post by NaN »

Die Version 0.5 kann zum Testen vorab schonmal hier heruntergeladen werden.

Der Parameter filter wurde entfernt.
Dafür gibt es 4 neue Parameter exclude_prefix, include_prefix, exclude_sufix, include_sufix.

Einige Feature Requests wurden auch noch eingebaut.
Hauptsächlich habe ich mich darum bemüht, Fehler zu beheben.
Das Modul sollte jetzt auch unter E_STRICT funktionieren ::)
Die Filterfunktion des Filepickers funktioniert jetzt auch beim Dropdown.
Für mehr Infos einfach Changelogs und Doku lesen.

Das Modul ist jetzt auch im Translationscenter.
Wird es also demnächst auch in anderen Sprachen geben.
NaN

AdvancedContent - {content_image} Kompatibilität

Post by NaN »

Ich habe die Frage zwar bereits im englischen Forum gestellt, aber doppelt hält besser ;)

Ich frage mich, ob es sinnvoll ist, dass AdvancedContent für Inhaltsblöcke vom Typ image das Image-Uploads-Verzeichnis verwendet.
Der standard Inhaltstyp verwendet für {content_image}-Blöcke das Uploads-Verzeichnis.
D.h. das Modul ist nicht mehr kompatibel zum normalen Inhaltstypen.

Hier mal ein Beispiel, wieso mich das beschäftigt...

Sagen wir mal das Uploads-Verzeichnis ist "uploads" und das Image-Uploads-Verzeichnis ist "uploads/images".
Im Template haben wir mal folgenden Inhaltsblock:

{content_image block="image" dir="banners"}

Wenn ich eine Seite vom Typ Inhalt erstelle, wird also für jeden {content_image}-Block in "uploads/banners" nach Bildern gesucht. Wenn ich die Seite speichere, wird auch ganz brav "uploads/banners/meinBild" gespeichert.

Ändere ich jetzt den Typ der Seite auf AdvancedContent, wird für den gleichen Inhaltsblock in "uploads/images/banners" nach Bildern gesucht. Dort werde ich aber nicht die Bilder finden, die ich ursprünglich zur Auswahl hatte.

Bewege ich alle Bilder in das Bilder-Verzeichnis, um sie auch im Backend aufgelistet zu bekommen und speichere den Spaß, dann werden mir 1. bei allen Seiten, die vom Typ Inhalt sind, im Backend keine Bilder aufgelistet und 2. im Frontend werden mir für alle Seiten, die vom Typ AdvancedContent sind, keine Bilder angezeigt.

Denn AdvancedContent speichert im Gegensatz zum standard Inhaltstypen nicht "uploads/images/banners/meinBild" sondern nur "banners/meinBild". Der {content_image} Tag stellt dem gespeicherten Pfad aber nicht die aktuellen Uploads-Verzeichnisse vorran.
Der {AdvancedContent} Tag schon, aber das ist erstmal egal, denn mir gehts um die Kompatibilität zum {content_image} Tag. Ich will erreichen, dass ein problemloses wechseln zwischen den Inhaltstypen möglich ist.

D.h. bei AdvancedContent werden für Bilder nur Pfade relativ zum Image-Uploads-Verzeichnis gespeichert. (Analog dazu für Blöcke vom Typ file relativ zum Uploads-Verzeichnis)

Ihr werdet Euch bestimmt fragen, warum ich nicht einfach das Modul an den standard Inhaltstypen anpasse.

Ganz einfach. Der standard Inhaltstyp hat nämlich gegenüber AdvancedContent ein kleines Manko. Er speichert wie oben bereits erwähnt den Pfad relativ zum Stammverzeichnis (also auch den Namen des Uploads-Verzeichnisses). Ziehe ich mit dem Server um oder ändere aus irgendeinem anderen Grund in der config.php die Systempfade, dann werden mit dem standard Inhaltstypen im Frontend keine Bilder mehr angezeigt. Ich müsste jede Seite neu bearbeiten. (bei großen Projekten einfach unzumutbar)

Bei AdvancedContent wird dagegen im Frontend alles weiterhin funktionieren.

Da der standard Inhaltstyp und {content_image} Tag also sowieso bereit für einen kleinen Feature Request sind, frage ich mich, ob man das Image-Uploads-Verzeichnis nicht auch im standard Inhaltstypen / {content_image} Tag verwenden sollte, oder ob ich bei AdvancedContent nicht besser auch generell nur das Uploads-Verzeichnis verwenden sollte.

Was meint Ihr dazu?
Bilder generell im Image-Uploads-Verzeichnis oder lieber doch frei wählen?
(Wobei ich mich bei letzterem allerdings frage, wozu das Image-Uploads-Verzeichnis dann überhaupt da ist.)

Grüße,
NaN.
Last edited by NaN on Thu Aug 19, 2010 4:40 pm, edited 1 time in total.
nockenfell
Power Poster
Power Poster
Posts: 751
Joined: Fri Sep 12, 2008 2:34 pm

Re: AdvancedContent

Post by nockenfell »

Zwei Ansätze wären:

- Mit AdvancedContent prüfen, ob ein Bild in /uploads/banner ist und dann dieses Verzeichnis anstelle des korrekten nehmen
- Ein Parameter mit dem man Einstellen kann, dass direkt in /uploads gesucht werden soll

Dadurch kannst du AdvancedContent weiterhin "korrekt" laufen lassen und Leute welche beides brauchen können AdvancedContent für ihre Bedürfnisse anpassen.
[this message is written with 100% recycled bits]
NaN

Re: AdvancedContent

Post by NaN »

Danke für die Ansätze.
nockenfell wrote: - Mit AdvancedContent prüfen, ob ein Bild in /uploads/banner ist und dann dieses Verzeichnis anstelle des korrekten nehmen
Das halte ich aber nicht für sinnvoll, da auch zufällig mal beides vorkommen kann, der User aber nur eines von beiden meint. Welches meint er nu?
nockenfell wrote: - Ein Parameter mit dem man Einstellen kann, dass direkt in /uploads gesucht werden soll
Das gefällt mir schon eher.
Eine Art Schalter für "Kompatibilitätsmodus ON / OFF"

(" ... Das Modul schaltet jetzt in den Murks-Modus  ;D Klingt nach IE Zeugs ;) ")

Im Kompatibilitätsmodus läuft alles so wie im standard Inhaltstypen und im {content_image} Tag. Ansonsten so, wie ich es für richtig halte.

Das wäre sogar recht einfach umzusetzen.
Das könnte man sogar sowohl als Block-Parameter als auch als globale Modul-Einstellung einbauen.

Aber wie steht's denn allgemein mit der Frage nach dem Image-Uploads-Verzeichnis?
Ich sehe da ehrlich gesagt keinen Sinn in dieser Option.
Es gibt schließlich auch kein PDF-Uploads-Verzeichnis etc.
Ich vermute mal das hängt noch mit dem ImageManager zusammen.
Diese Einstellung sollte meiner Meinung nach von Modul zu Modul entschieden werden anstatt in der config.php.

Gibt es jemanden, der massiven Gebrauch vom Image-Uploads-Verzeichnis macht?
Ich will nur wissen ob sich der Aufwand lohnt, bei den Pfaden immer zwischen block_type="file" oder block_type="image" unterscheiden zu müssen. Letzendlich sind es beides Dateien, bei denen lediglich bei der Ausgabe im Frontend bzw. bei der Ausgabe der Input-Felder und beim Filtern der Dateien etwas ändert. Aber in welchem Verzeichnis nach Dateien gesucht wird, das würde ich lieber dem User überlassen.
Last edited by NaN on Thu Aug 19, 2010 6:55 pm, edited 1 time in total.
nockenfell
Power Poster
Power Poster
Posts: 751
Joined: Fri Sep 12, 2008 2:34 pm

Re: AdvancedContent

Post by nockenfell »

NaN wrote:
nockenfell wrote: - Mit AdvancedContent prüfen, ob ein Bild in /uploads/banner ist und dann dieses Verzeichnis anstelle des korrekten nehmen
Das halte ich aber nicht für sinnvoll, da auch zufällig mal beides vorkommen kann, der User aber nur eines von beiden meint. Welches meint er nu?
ACK

nockenfell wrote: - Ein Parameter mit dem man Einstellen kann, dass direkt in /uploads gesucht werden soll
Das gefällt mir schon eher.
Eine Art Schalter für "Kompatibilitätsmodus ON / OFF"

(" ... Das Modul schaltet jetzt in den Murks-Modus  ;D Klingt nach IE Zeugs ;) ")
;D ;D

Gibt es jemanden, der massiven Gebrauch vom Image-Uploads-Verzeichnis macht?
Ich will nur wissen ob sich der Aufwand lohnt, bei den Pfaden immer zwischen block_type="file" oder block_type="image" unterscheiden zu müssen. Letzendlich sind es beides Dateien, bei denen lediglich bei der Ausgabe im Frontend bzw. bei der Ausgabe der Input-Felder und beim Filtern der Dateien etwas ändert. Aber in welchem Verzeichnis nach Dateien gesucht wird, das würde ich lieber dem User überlassen.
Ich finde es Vorteilhaft die Bilder in einem separaten Ordner zu haben. Extrem gebrauch mache ich nicht davon. Als Modul fällt mir einzig Gallery ein, welche die Bilder im Ordner ./uploads/images/Gallery speichert.
[this message is written with 100% recycled bits]
Post Reply

Return to “Module und Tags”