Content2 / XContent / AdvancedContent ...

[NaN]

Es sieht so aus als werden Modul-Inhaltstypen generell nicht mehr unterstützt.
Die Funktionen dazu sind aus dem Core raus und es gibt keine alternativen Funktionen dafür. Die Funktion RegisterContentType() ist "deprecated" was für mich soviel heißt wie "Keine eigenen Inhaltstypen mehr". Muss aber erstmal nachfragen, ob das so gewollt ist. Im Changelog und in den Ankündigungen habe ich nichts dazu gefunden.

[nicmare]

Hmm. genau. erstmal nachhaken. und wenn dem so ist, wird lautstark protestiert .
ich meine die tun doch so auf framework. dann sollen sie es ordentlich machen und nicht wieder beschränken.

[NaN]

So, Calguy scheint da etwas zu basteln.
Im Moment funzt es zwar immer noch nicht, aber ausgelöst durch den ersten Schreck habe ich gleich damit begonnen, einen Weg zu finden, wie man AdvancedContent trotzem auch ohne Inhaltstypen nutzen kann.
Also egal wie es nun am Ende mit CMSms 1.9 aussieht, AdvancedContent lebt weiter.
Man muss dann im schlimmsten Fall nur auf die Pagetabs verzichten.
(Funktioniert dann so wie ich es hier schonmal erwähnt habe)

Allerdings wird das Smarty-Procedere in späteren Versionen nicht mehr so funktionieren wie bisher. D.h. alle Plugins, die für's Frontend gedacht sind, werden im Backend nicht mehr funktionieren. (Das nurmal so als Hinweis für die Zukunft, falls es keine Alternativen gibt.)

[nicmare]

klingt gut! dann kann ich mich ja weiterhin auf cmsms1.9 freuen

[uniqu3]

gute nachricht 
Bin aber zuversichtlich das es calugy in ordnung bringt, so wie es ursprünglich war  sonst muss ich mir ein Flugticket besorgen 

[NaN]

So, da bislang keine weiteren Beschwerden kamen, ist die Version 0.6 jetzt auch im Downloadbereich.

Habe noch ein paar Optionen hinzugefügt mit denen man nun den Tab AdvancedContent ausblenden kann.

Außerdem kann man festlegen, ob die Sichtbarkeit der Contentblöcke im Backend pro Seite, pro Template, pro Seite ODER Template oder pro Seite UND Template gespeichert wird. (bzw. ausgelesen wird - gespeichert wird eh immer beides)

Bei "pro Seite" wird beim Auslesen der, die, des ... ich nenne es jetzt mal "Collapse-Status" - ihr wisst sicher was ich meine ... nur nach einer gespeicherten Einstellung gesucht bei der die conten_id übereinstimmt.

Analog dazu bei "pro Template" nur nach Einstellungen bei denen die template_id übereinstimmt.

Der Unterschied der letzten beiden liegt darin, dass bei "Seite ODER Template" in der Datenbank nach content_id ODER template_id gesucht wird und bei "Seite UND Template" nach einer Übereinstimmung von content_id UND template_id.

Weiterhin kann man festlegen, ob neue Blöcke o. Blockgruppen zusammengeklappt oder aufgeklappt erscheinen sollen. Diesen Wert kann man im Template mit dem Parameter "collapse" überschreiben.

Ich glaube damit dürften jetzt alle zufrieden sein was die Anzeige von Blöcken oder Tabs angeht

Dass der FilePicker draußen ist, hatte ich ja schon erwähnt.
Ebenso die Blocktypen file und image.

Bis jetzt läuft die 0.6 inzwischen auch unter CMSms 1.9 - sofern sich bis zum Release nicht noch irgendwas groß ändert.

Noch ein Hinweis:
Im SVN hat sich wieder etwas geändert. Die aktuelle Version ist im Verzeichnis /tags/0.6.+/
Im Verzeichnis /trunk/ ist schon die Vorbereitung auf die 0.7. Die benötigt aber mindestens CMSms 1.9 - und das lässt sich auch nicht einfach durch eine Änderung der MinimumCmsVersion ändern, da hier spezielle Funktionen verwendet werden, die erst ab CMSms 1.9 verfügbar sind.

In AdvancedContent 0.7 wird es auch die Möglichkeit geben, die Content-Blöcke mit dem {content_module} Tag zu erzeugen, sodass keine Änderung des Inhaltstypen nötig ist. Allerdings muss man dazu nicht nur auf die Pagetabs verzichten, sondern vorraussichtlich auch auf einige andere optionen. Aber dazu mehr, wenn es soweit ist.
Den Inhaltstypen wird es aber weiterhin geben (solange wie es eben möglich ist), nur wird man logischerweise nicht beides gleichzeitig nutzen können.

[JamieFraser]

Sorry, dass ich mir einklinge, aber kann mir einer kurz sagen, was dieses Modul - AdvancedContent - eigentlich genau macht?

[NaN]

Steht doch in der Modul Hilfe.
Du hast dann einen weiteren Inhaltstypen wenn Du Seiten erstellst/bearbeitest.
Dieser bietet die Möglichkeit, Inhaltsblöcke im Backend nicht nur als Text (mit oder onhe WYSIWYG), oder Image-Dropdown sondern als Dropdown, Dropdown mit Mehrfachauswahl, Sortierbare Mehrfachauswahl, Checkbox etc. anzeigen zu lassen. Das ist einfach eleganter als ein Textinput bei dem man die Werte selber eintragen muss. Außerdem kann man so die Seite wirklich Leuten überlassen die keine Ahnung haben. Man kann sie damit regelrecht anleiten, nur gültige Eingaben zu machen, die im Template dann auch korrekt interpretiert werden können.

Außerdem ermöglicht es dynamische Werte. D.h. Du kannst die Ausgabe eines Moduls, Plugins oder UDTs nutzen, um Dir die Werte eines Dropdowns generieren zu lassen.

Weiterhin kann man eigene Tabs erstellen und dort ganz bestimmte Inhaltsblöcke platzieren oder Blöcke in andere Tabs platzieren. (Du könntest z.B. eine weitere Option im Tab "Opionen" platzieren oder einen Tab "Weitere Optionen" erstellen.)
Innerhalb dieser Tabs kannst Du Ihaltsblöcke in weitere Tabs unterteilen.
Du kannst zusammengehörige Inhaltsblöcke in Fieldsets gruppieren.

Blöcke und Fieldsets lassen sich auch zusammenklappen.
Gilt dann entweder für alle Blöcke deren Seiten auf dem gleichen Template beruhen oder nur für die Blöcke einer Seite.

Nützlich um bei vielen Blöcken etwas Ordnung zu schaffen.

Du kannst außerdem festlegen welcher Inhaltsblock von welchem User / welcher Usergruppe bearbeitet werden darf. (Wenn Du z.B. einen Block hast, in dem nur Smarty-Code drin vorkommt und Du unerfahrene Redakteure davon fernhalten willst.)

Kurz: Man kann sich damit sein Backend beim Bearbeiten der Seite selbst gestalten und sich die Arbeit dadurch erleichtern.


Außerdem bietet es die Möglichkeit, Seiten nur für bestimmte User der FrontendUsers Moduls freizugeben.
Weiterhin eine Zeitsteuerung für Seiten wie bei einem Newsartikel...

Hab ich was vergessen?

Ach ja, man kann die Einstellungen für die FrontendUser von der übergeordneten Seite übernehmen.
D.h. man muss garnicht wissen, was da eingestellt ist. Man sagt einfach "erbe diese Eigenschaft" und schon ist diese Seite für die gleichen User sichtbar wie die übergeordnete Seite.
(Hier besteht aber noch Verbesserungspotential. Da das nicht funktioniert, wenn der Editor diese Option nicht bearbeiten darf. Mach ich in der nächsten Version.)

Jetzt fällt mir selber gerade erstmal auf, was da alles drinsteckt bzw. was man noch alles einbauen kann

[nicmare]

ja super update mal wieder! und als wäre das modul nicht schon perfekt ist mir bei der Benutzung gerade was neues eingefallen. Kam bestimmt schon woanders als Featurerequest:
die Anzeige der zur Verfügung stehenden Zeichen + Limitierung. also zB als Parameter maxchar=100. Dann darf man maximal 100 Zeichen eintippen. Optimalerweise mit einem Counter der die verbleibenden Zeichen runterzählt als Orientierung. Nichts notwendiges aber ein nettes Gimmick für die Notizen oder?

[JamieFraser]

Danke für die genaue Beschreibung. Werde mir das Modul mal installieren und etwas genauer betrachten

[JamieFraser]

Ähm, wie installiere ich denn das Modul am besten?

[NaN]

Ähm, wie installiere ich denn das Modul am besten?

So wie alle Module, die nicht im ModulManager verfügbar sind.
Zip-Datei herunterladen, entpacken und das gesamte Verzeichnis "AdvancedContent" auf den Server ins Verzeichnis "modules" hochladen.
Dann im Backend unter "Erweiterungen->Module" auf "installieren" klicken.

Die Sprachdateien sind evtl. noch nicht aktuell (vor allem die Hilfe), weil die Übersetzer nicht immer alles rechtzeitig ändern können.
Die englische Doku sollte aber auf dem neuesten Stand sein.

Ich habe noch keine XML Datei für den ModuleManager erstellt, weil das Modul bislang noch nicht stabil genug war und man bei Dateien, die via ModuleManager installiert wurden, aufgrund von Problemen mit den Zugriffsrechten, nicht so einfach Patches vornehmen kann.

die Anzeige der zur Verfügung stehenden Zeichen + Limitierung.
...
Nichts notwendiges aber ein nettes Gimmick für die Notizen oder?

Also der Parameter maxlength zum Begrenzen der Zeichen ist für einfache Textinputs schon drin.
So ein Counter wäre nicht schlecht, aber das geht meiner Meinung nach zu tief in die Aufgabe des WYSIWYG Editors rein. Bei einfachen Textareas/Textinputs, bei denen der WYSIWYG Editor generell deaktiviert ist, könnte man das evtl. machen, aber alles wo der TinyMCE (o.ä.) mit dranhängt würde ich lieber dem Editor überlassen. Da gibt es vielleicht sogar schon Plugins für den TinyMCE. Außerdem wüsste ich jetzt nicht, ob man nur die reinen Zeichen, oder auch die HTML Sachen (die der Editor ja nicht als Text anzeigt) mit einbeziehen sollte.

[nicmare]

jup. meinte das auch eher für wysiwyg=false. also zB bei oneline=true

[nicmare]

wieso sprecht ihr euch modul entwickler eigentlich nicht gegenseitig ab?!
ist das nicht das gleiche wie GBfilepicker?
LINK

[NaN]

Ja, sieht fast so aus.
Und sieht auch garnichtmal schlecht aus.
Vor allem mit der Sortier- und Suchfunktion. (da werd ich ja richtig neidisch )
Habe das Modul bei meiner Suche damals aber komischerweise nicht gefunden.

Allerdings unterstützt es den {content_module}-Tag nicht. Ich wollte den Blocktyp file/image ganz raus aus dem AdvancedContent modul haben und lieber von den core-Funktionen handhaben lassen, sodass diese Blocktypen vom Core auch ohne AdvancedContent wie ganz normale Inhaltsblöcke gehandhabt werden können. Mit plFileHanlder hätte ich nur das gleiche erreicht, als wenn ich den FilePicker drin gelassen hätte.

Da plFileHandler offenbar auch im Frontend eingesetzt werden kann, ist mir das Mitschleifen von sicherheitsrelevanten Parametern im Link allerdings keine besonders gute Lösung. Man kann somit durch den gesamten Webspace browsen und was weiß ich nicht alles anstellen. Ich speichere die Parameter lieber in einer Session-Variable auf dem Server und sorge weiterhin dafür, dass das Modul immer und auschließlich nur im angegebenen Verzeichnis bleibt.

Außerdem kann man als Modulentwickler bei GBFilePicker seine eigenen FilePicker-Templates verwenden und ist nicht auf die Einstellungen des Users im Backend angewiesen.

Und dann sind mir da beim plFileHandler noch zu viele Fehlermeldungen im debug-Modus. GBFilePicker läuft dagegen mit CMSms 1.8.2 und 1.9 und das auch noch unter E_DEPRECATED und E_STRICT. (ich blöder Angeber )

Aber dafür hat plFileHanlder einige nette Bildbearbeitungs-Tools wie Crop, Wasserzeichen etc. Ich werde es auf jeden Fall mal im Auge behalten. Zumal ich nicht wirklich vorhabe, GBFilePicker groß zu erweitern. Vielleicht noch ein paar Templates zum selber anpassen, aber das war's dann auch schon. Sogesehen hat plFileHanlder eventuell etwas mehr Potenzial.