Im Endeffekt schaut es zwar schön aus, kann aber aus meiner Sicht mit dem Fireball CMS nicht mithalten
und das kannst du jetzt schon beurteilen?
ich nutze selber das fireball-cms und finde bis jetzt nichts negatives an der suite.
man kann es zu dem jetztigen zeitpunkt einfach nicht vergleichen und ich bin mir sicher das vieles noch verbessert oder ergänzt werden kann/wird
in sachen php/include wird bestimmt auch etwas folgen...
das fireball-cms ist auch nicht von heut auf morgen entstanden
Unterschiedliche Layouts und Menüs lassen sich bereits individuell über das Boxen-System (Vorstellung folgt) erzeugen und mit den Seiten verknüpfen. Der Fokus liegt hier auf Wiederverwendbarkeit, da man Boxen und Menüs erfahrungsgemäß häufig auf mehr als nur einer Seite verwenden will.
Das ist auf jeden Fall ein Bonus gegenüber dem Fireball CMS, da man dort bisher nicht wirklich etwas wiederverwendbares hat. Aber eine Möglichkeit des Individuellen CSS/SASS, sollte es schon geben, da ich davon ausgehe, dass es via includes als zusätzliches CSS-Script im Header (oder wo auch immer) ja eh inkludiert werden kann. Zumindestens sehe ich da kein Problem mit, so etwas zu implementieren.
und das kannst du jetzt schon beurteilen?
ich nutze selber das fireball-cms und finde bis jetzt nichts negatives an der suite.
man kann es zu dem jetztigen zeitpunkt einfach nicht vergleichen und ich bin mir sicher das vieles noch verbessert oder ergänzt werden kann/wird
in sachen php/include wird bestimmt auch etwas folgen...
das fireball-cms ist auch nicht von heut auf morgen entstanden
Ja, da hast du nicht ganz unrecht. Aber aktuell stört es mich halt eben, dass die Seite direkt typisiert wird. Ist für mich mehr als Contra, anstelle als Pro zu sehen, da man so die Möglichkeit einer Individuellen Gestaltung komplett verliert.
Man kann ergo schon vergleichen, weil das FBCMS eine Seite einfach als Eintrag anlegt, Individuellen CSS zulässt und natürlich Gruppenrechte unterstützt. Der eigentliche Content der Seite entsteht dann durch die vielen Möglichkeiten die man hat. Dies sind u. a.:
Selbstverständlich kann so etwas noch immer implementiert werden, aber vergleiche ich das, was bisher existiert mit dem, was man im FBCMS machen kann, gewinnt eindeutig das FBCMS bei mir, weil ich dort den Content freier anlegen kann und nicht über Boxen gehen muss, wenn zugleich wiederverwendbare Boxen ein Plus gegenüber dem FBCMS sind, weil man dort jeden Content separat anlegen muss.
Es wird am Ende eh ein gewisses Defizit geben, wo man auf gewisse Sachen verzichten muss, dies sollte man nach Möglichkeit jedoch gering halten, wie ich finde ;).
Das ist auf jeden Fall ein Bonus gegenüber dem Fireball CMS, da man dort bisher nicht wirklich etwas wiederverwendbares hat.
Schlag's vor. Du hast momentan gute Chancen. 
ich davon ausgehe, dass es via includes als zusätzliches CSS-Script im Header (oder wo auch immer) ja eh inkludiert werden kann
Du kannst garantiert ein Event ansprechend und dort dein CSS einschleusen.
Oder eine entsprechende Verwaltung schreiben wie vom Fireball CMS bekannt und automatisch zu CSS kompilieren und einschleusen. Das dürfte doch den meisten hier gefallen.
Schlag's vor. Du hast momentan gute Chancen.
Du kannst garantiert ein Event ansprechend und dort dein CSS einschleusen.Oder eine entsprechende Verwaltung schreiben wie vom Fireball CMS bekannt und automatisch zu CSS kompilieren und einschleusen. Das dürfte doch den meisten hier gefallen.
Zählt das nicht als Vorschlag hier in diesem Forum oder werden die nur an bestimmter Stelle angenommen? *blöd frag*
Zählt das nicht als Vorschlag hier in diesem Forum oder werden die nur an bestimmter Stelle angenommen? *blöd frag*
Weil ich auch bei der Weiterentwicklung vom Fireball CMS das komplette WoltLab Forum durchforste nach möglichen Vorschlägen. 
Wie immer gilt, alles, was nicht bei mir im Forum oder auf meinem Block steht, wird vermutlich ignoriert.
Ja, da hast du nicht ganz unrecht. Aber aktuell stört es mich halt eben
das ist dein gutes recht, doch bis zum erscheinen wird wie gesagt noch etliches folgen,umgekrempelt, neu kreiert oder sonst was werden...
schaue ich mir das fcms mit der suite jetzt an, bleib ich dabei, das die suite eine prima alternative ist ...
ich denke das es eh zu zig problemen kommen wird, was den importer (fcms-suite) angeht....thats life...
doch ich bin auch froh, dass überhaupt daran gedacht wird.
Selbstverständlich kann so etwas noch immer implementiert werden, aber vergleiche ich das, was bisher existiert mit dem, was man im FBCMS machen kann, gewinnt eindeutig das FBCMS bei mir, weil ich dort den Content freier anlegen kann und nicht über Boxen gehen muss, wenn zugleich wiederverwendbare Boxen ein Plus gegenüber dem FBCMS sind, weil man dort jeden Content separat anlegen muss.
So wie ich es bisher verstanden habe, verlierst Du keine Freiheiten durch die Verwendung von Boxen.
Im besten Fall kannst Du Deine bisherigen CMS-Seiten und -Funktionen so weiter verwenden, wie Du sie bisher hast, nur dass Du Deinen ganzen Code nicht mehr in einer Datei zusammen gezwängt hast, sondern die Funktionalitäten über Boxen sauber strukturierst. Den Effekt der Wiederverwendung würde ich dann sogar eher noch als Plus oben drauf sehen.
Laut meiner Kristallkugel werden wir nach dem Produktvorstellungsbeitrag über Boxen alle schlauer sein und jeder hier wird Dir präzise sagen können, wie Du Deine bisher über Feuerball gelöste Aufgabenstellung auch in der neuen Suite umsetzen kannst.
das ist dein gutes recht, doch bis zum erscheinen wird wie gesagt noch etliches folgen,umgekrempelt, neu kreiert oder sonst was werden...
schaue ich mir das fcms mit der suite jetzt an, bleib ich dabei, das die suite eine prima alternative ist ...
ich denke das es eh zu zig problemen kommen wird, was den importer (fcms-suite) angeht....thats life...
doch ich bin auch froh, dass überhaupt daran gedacht wird.
wo bitte kann man sich denn das CMS bereits anschauen oder testen. Danke
@rmordico: Schau mal hier: https://support.softcreatr.de/wcf-download/
Die neueste Version natürlich.
wo bitte kann man sich denn das CMS bereits anschauen oder testen. Danke
oder https://beta.mysterycode.de/vortex/
Wird morgen Mittag wieder aktualisiert. Bis dahin habe ich zu wenig Zeit.
Bitte direkt PHP Seiten mit aufnehmen, reine HTML Seiten bringen niemanden weiter.
Bitte direkt PHP Seiten mit aufnehmen, reine HTML Seiten bringen niemanden weiter.
Außer vielleicht den Leuten, die nicht programmieren können und fit im Page Design sind?
Man kann sich also die darzustellende Seite nicht so zusammenstellen, wie es das Fireball CMS tut. Ergo werde ich bestärkt darin, nicht auf die neue WSC 3.0 umzusteigen, schade, aber das ist
Und doch ist der Weg von WoltLab für die meisten wesentlich praktischer und angenehmer, da sie nicht vom "unnötigen" Ballast erschlagen werden. Solche Monster wie Typo3 sind durchaus zwar interessant in bestimmten Umfeldern, doch in der Regel eher absoluter Overkill. Wordpress erfreut sich nicht umsonst immer größere Beliebtheit, auch als CMS, da es relativ einfach ist eine "Webseite" zu erstellen, ohne eben Ballast durch eine große Komplexität.
Es gibt sogar CMS-Systeme die noch weit einfacher sind und sich immer größere Beliebtheit erfreuen, da man nicht sich erst durch ein dickes Handbuch schlagen muss um zum Ergebnis zukommen, sondern man einfach in der Regel eben das machen kann, was viele fordern: Eine HTML-Seite anlegen und mit Inhalt füllen.
Natürlich könnte man auch eine komplexere Datenstruktur pro Seite optional implementieren, die Frage dann wäre aber, wie viele diese Funktionalität wirklich nutzen würden und wie viele sie wirklich brauchen. Gerade oder auch weil WoltLab ja die direkte Eingabe von HTML ermöglicht und sogar von Template-Scripting. Dazu kommt das Boxensystem, welches auch viele Möglichkeiten eröffnet und damit sogar Sachen zulässt, die im FireballCMS meiner Meinung nicht so einfach umzusetzen sind.
Ich selbst kann nur hoffen, dass WoltLab nicht noch ein unnötiges "Datentypen"-Konstrukt hinter die Seiten stellt, bei denen ich anfangen muss auf CSS-Klassen zu achten, damit die Darstellung ordentlich läuft mit jedem Stil. Denn das war eines meiner Hauptprobleme mit dem Fireball CMS: Statt einfach HTML-Seiten anzulegen, musste ich eine "komplexe" Struktur erstellen und gleichzeitig CSS noch erstellen, damit alles in den dazu gehörigen Stil passt.
Bitte direkt PHP Seiten mit aufnehmen, reine HTML Seiten bringen niemanden weiter.
PHP-Seiten kann man über Pakete selbst hinzufügen. Es ist sogar relativ einfach. Zudem bietet das System die Möglichkeit von Template-Scripting, mit dem sogar fast alles möglich ist, was auch mit PHP möglich wäre, nur dass all zu kritische Funktionen nicht mehr unterstützt werden. ...
Ich antworte mal im Quote 
Display MoreUnd doch ist der Weg von WoltLab für die meisten wesentlich praktischer und angenehmer, da sie nicht vom "unnötigen" Ballast erschlagen werden. Solche Monster wie Typo3 sind durchaus zwar interessant in bestimmten Umfeldern, doch in der Regel eher absoluter Overkill. Wordpress erfreut sich nicht umsonst immer größere Beliebtheit, auch als CMS, da es relativ einfach ist eine "Webseite" zu erstellen, ohne eben Ballast durch eine große Komplexität.
Es gibt sogar CMS-Systeme die noch weit einfacher sind und sich immer größere Beliebtheit erfreuen, da man nicht sich erst durch ein dickes Handbuch schlagen muss um zum Ergebnis zukommen, sondern man einfach in der Regel eben das machen kann, was viele fordern: Eine HTML-Seite anlegen und mit Inhalt füllen.
Natürlich könnte man auch eine komplexere Datenstruktur pro Seite optional implementieren, die Frage dann wäre aber, wie viele diese Funktionalität wirklich nutzen würden und wie viele sie wirklich brauchen. Gerade oder auch weil WoltLab ja die direkte Eingabe von HTML ermöglicht und sogar von Template-Scripting. Dazu kommt das Boxensystem, welches auch viele Möglichkeiten eröffnet und damit sogar Sachen zulässt, die im FireballCMS meiner Meinung nicht so einfach umzusetzen sind.
Ich selbst kann nur hoffen, dass WoltLab nicht noch ein unnötiges "Datentypen"-Konstrukt hinter die Seiten stellt, bei denen ich anfangen muss auf CSS-Klassen zu achten, damit die Darstellung ordentlich läuft mit jedem Stil. Denn das war eines meiner Hauptprobleme mit dem Fireball CMS: Statt einfach HTML-Seiten anzulegen, musste ich eine "komplexe" Struktur erstellen und gleichzeitig CSS noch erstellen, damit alles in den dazu gehörigen Stil passt.
Du bist nicht auf den CSS vom FBCMS angewiesen, wenn du die ganzen Klassenattribute von Woltlab nehmen würdest, die im momentanem System hinterlegt sind, wie z. B. die beiden container Klassenattribute.
Erschlagen wird man vom FBCMS nun auch nicht wirklich, ich habe nur so langsam das Gefühl, dass die Menschheit fauler wird, als sie bisher zugegeben hat und sowas toleriere ich nicht. Wenn man etwas vernünftig machen will, dann braucht es schon mehr als nur einen HTML und/oder Template-Script und dann muss man halt auch einmal ein Handbuch lesen, was zu einer guten Software dazugehört. Immerhin müssen Entwickler, die etwas an einer besetehenden Software verändern/erweitern wollen auch die dazu passende Dokumentation bzw. den Quellcode lesen/verstehen, ansonsten endet es in einer Unmenge an Fehlern.
PHP-Seiten kann man über Pakete selbst hinzufügen. Es ist sogar relativ einfach. Zudem bietet das System die Möglichkeit von Template-Scripting, mit dem sogar fast alles möglich ist, was auch mit PHP möglich wäre, nur dass all zu kritische Funktionen nicht mehr unterstützt werden. ...
Genau das ist das Problem des Template-Scripts. Man hat keinen Zugriff auf das gesamte PHP-Portfolio, was essentiell ist. Ich kann Muschelschaf in der Beziehung verstehen. Klar, es ist halt mit einem gewissen Risiko verbunden, aber wenn man weiß, was man tut, dann sollte es Angreifern nicht so leicht sein, Schaden anzurichten.
Deine Antwort im Zitat, so dass man nur schwer darauf eingehen kann, könnte man auch als geschickten Versuch zu trollen werten. Egal, gehen wir mal drauf ein:
QuoteDu bist nicht auf den CSS vom FBCMS angewiesen, wenn du die ganzen Klassenattribute von Woltlab nehmen würdest, die im momentanem System hinterlegt sind, wie z. B. die beiden container Klassenattribute.
Du hast schon gelesen was ich geschrieben habe und es auch verstanden? Diese Einwurf erweckt jedoch deutlich den Eindruck, das dem nicht so ist. Mir ist natürlich klar, dass das jetzt überheblich kling, dir ist aber schon klar, dass du mit diesem kurzen eigentlich unnötigen Einwurf meine Aussage sogar noch unterstützt?
Beim FBCMS muss ich mich erst mal noch in CSS/LESS-Code vom WCF einlesen, der in der Form nicht einmal wirklich gut dokumentiert ist für Laien, damit die Darstellung meines Inhalts mit der Seite valide wirkt ... Wenn ich sowas als Erklärung für andere Mitarbeiter, die den Inhalt der Seite pflegen, abgebe, kann ich mir ziemlich sicher sein, dass mein Chef mich zu einem Gespräch ruft und wäscht mir dabei erst mal ordentlich den Kopf, dass ich von Redakteuren unnötig Arbeitszeit verschwende, die sie besser nutzten könnten.
QuoteErschlagen wird man vom FBCMS nun auch nicht wirklich, ich habe nur so langsam das Gefühl, dass die Menschheit fauler wird, als sie bisher zugegeben hat und sowas toleriere ich nicht.
Welch wunderbar pauschale Aussage und kaum ein Blick über den eigenen Teller hinaus. ... Erinnere ich mich an meine Kommilitonen und Arbeitskollegen in der Uni, dann gibt es da viele die zwar rudimentäre HTML und CSS-Kenntnisse haben, jedoch nicht mehr und dennoch mussten sie relativ schnell auf das CMS zugreifen und neuen Inhalt erstellen können und zwar auch ohne mich und dass ich die Inhalte einpflege. Typo3 und andere CMS-Systeme trennen nicht umsonst die "technische" Sicht von der für die Redakteure, die den Inhalt pflegen. In Typo3 erstelle ich passende "Inhaltstypen" auch für ganze "Seiten" und ein Redakteur muss den Inhalt nur noch hinzufügen und zwar OHNE das er noch sich mit dem CSS-Grundgerüst und HTML-Grundgerüst der Seite auseinander setzten muss ...
Das Fireball CMS mag zwar für einzelne Personen mit entsprechenden Kenntnissen ein zufriedenstellendes System sein, doch für unbedarfte Redakteure ist es absolut ungeeignet und würde sich für viele Projekte eher disqualifizieren, denn auch ich hätte als "Techniker" was besseres zutun, als ständig Inhalte einzupflegen und zu schauen, dass es passt.
Gerade auch heute in der Zeit, in denen man in seinem Job immer mehr "Aufgabenbereiche" abdecken soll und daher jede Zeitersparnis gerne mitnimmt. Ich kann zwar nur aus meinem Berufsfeld sprechen, da findet man aber oft - und auch durch eigene Erfahrungen als Aushilfe - sehr komplexe Beschreibungen, die viele Aufgaben auf einmal abdecken: Thekendienst um Kunden bei der Informationsrecherche zu Unterstützen und ggf. Bücher/Zeitschriften zurücknehmen oder die Ausleihe bearbeiten. Fernleihe bearbeiten, E-Mails und OnLeihe-Status bearbeiten. Recherche für neue Medien für das Institut, Social-Media und Öffentlichkeitsarbeit mit Pressetexte, Webseite pflegen für den eigenen Bereich, nebenbei Katalogisierung und Metadatenpflege. Das kommt dann alles teilweise sogar gleichzeitig auf einen zu ... na ich würd mich beim technischen Admin noch bedanken, wenn ich ein umständliches CMS-System hätte in dem ich noch Aspekte beachten muss, die mir das System eigentlich abnehmen soll, wenn ich nur den Inhalt pflegen will ... Bei dem knappen Zeitbudget was man teilweise hat zählt jede Sekunde und unnötige Arbeit führt zu Überstunden ...
Und ja ich kenne Typo3, Joomla und Drupal und einige CMS-Systeme mehr und ich kann dir aus Erfahrung sagen: Keines dieser Systeme hat von mir - sofern ich nur den Inhalt pflegen wollte - verlangt, dass ich mich mit CSS, HTML oder PHP der Seite beschäftige, sondern nur: Erstelle neue Seite => Welcher Typ soll die Seite sein? => Wo ist die Seite im Hauptmenü ggf. in den Untermenüs. Fertig.
QuoteWenn man etwas vernünftig machen will, dann braucht es schon mehr als nur einen HTML und/oder Template-Script und dann muss man halt auch einmal ein Handbuch lesen, was zu einer guten Software dazugehört.
Würde ich nun nur aus der Seite eine technischen Betreuers einer Seite oder als als Entwickler sprechen/schreiben, würde ich dir tendenziell recht geben, wenn man komplexere Seitenstrukturen und Inhaltstypen umsetzten, dann braucht man auf jeden Fall etwas mehr Freiraum und ein flexibleres System. Ich arbeite aber aktuell mit Typo3 und anderen Systemen in den aktuelleren Versionen und im Endeffekt gibt es für die Seiten-Templates die man baut auch nicht mehr als bestimmte Datentypen, mit denen man eine Seite zusammen klickt und durch entsprechende Template-Systeme das aussehen der Seite beschreibt.
PHP muss man in vielen neueren Systemen alle über entsprechende "Module" nach installieren und anschließend über definierte Variablen im "Template" nutzen, selbst als technischer Admin wird man dazu gezwungen. PHP-Seiten kann man über eigene Pakete anlegen, PHP-Code für eigene Boxen auch über eigene Pakete. Man wird also nicht daran gehindert eigenen PHP-Code zu nutzen ... man kann sogar das Template-Skripting um eigenen PHP-Code erweitern, wenn man sich etwas einarbeitet und muss nicht auf so schmutzige Tricks zurückgreifen, wie sie früher möglich waren ...
QuoteImmerhin müssen Entwickler, die etwas an einer besetehenden Software verändern/erweitern wollen auch die dazu passende Dokumentation bzw. den Quellcode lesen/verstehen, ansonsten endet es in einer Unmenge an Fehlern.
Im Endeffekt widersprichst du dir mit diesem Satz sogar selbst. Als erstes forderst du, dass Menschen Handbücher lesen und sich in ein System einarbeiten, gleichzeitig forderst du jedoch eine schmutzige Funktion, die sogar gegeben ist, wenn man sich in das System einarbeitet. Etwas Paradox finde ich es. Man kann über eigene "Page-Controller", sowie "Box-Controller" und sogar über Template-Plugins jederzeit speziellen PHP-Code in das System einschleusen, nur dass die letzten 3 Methoden wesentlich sauberer sind und zusammen mit dem Template-Skripting alles ermöglichen, was man sich wünscht ...
Man könnte an dieser Stelle nun gemein sein und schreiben: "Ich habe das Gefühl, dass die Menscheit fauler wird, als sie bisher zugegeben hat und sowas toleriere ich nicht." Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.
QuoteGenau das ist das Problem des Template-Scripts. Man hat keinen Zugriff auf das gesamte PHP-Portfolio, was essentiell ist. Ich kann Muschelschaf in der Beziehung verstehen. Klar, es ist halt mit einem gewissen Risiko verbunden, aber wenn man weiß, was man tut, dann sollte es Angreifern nicht so leicht sein, Schaden anzurichten.
Es ist nicht nur mit Risiko verbunden, es ist einfach nicht mehr State-of-the-Art und wird nicht ohne Grund in immer mehr der alten CMS-Systeme nicht mehr ermöglicht und in neueren Systemen überhaupt nicht mehr eingepflegt, höchstens als Plugin durch Dritte. Und es ist nicht unmöglich PHP-Code einzubinden, wenn man es richtig macht. Es ist zwar etwas umständlicher, da man über eigene (Page|Box)-Kontroller-Klassen gehen muss oder ggf. ein Template-Plugin entwickeln muss, doch es ist die saubere Methode. Ich verweise hier mal auf den Satz vor dem Zitat und auch deinen gesamten Beitrag ...
Ihr müsstet euch nur in das System einarbeiten und mal ein Handbuch lesen, so wie du es von mir und anderen verlangst ...
Da ich leider nicht viel Zeit habe, kann ich erst später auf deinen Post eingehen. Kurz gesagt jedoch, sollte man immer Vollzugriff auf etwas haben,
deshalb fallen alle anderen CMS bei mir durch, weil ich sonst gewisse Sachen nicht über Drittanbieter machen kann.
Bin leider nicht mehr so viel hier, aber ein Artikel-System (Container) wie bei Contao wäre eine SUPER-SACHE gewesen. Ansatzweise gab es das beim Fireball-CMS. Möglicherweise darf darüber nachgedacht werden.
Wenn ich alles richtig verstanden habe, wird auch das Fireball-CMS weiter entwickelt! Das bedeutet 2 CMS stehen im Wettstreit miteinander! Das kann WL Kunden doch nur Recht sein!
Ja und jaein und Ansichtssache. Ich nehme an, dass alle Ihh-Drittanbieter-Sind-Scheiße-Schlauberger zum WSC-eigenen CMS wechseln werden, egal, ob das was taugt oder nicht. Verstehe ich zwar nicht immer, aber mei, bei einem kostenlosen Produkt nicht mein Problem.
Wobei das CMS einigermaßen brauchbar zu sein scheint - zwar für keines der Projekte meiner Kunden, aber für kleine inhaltliche Ergänzungen ganz brauchbar.
Diese suite wird aber doch auch letzlich den fireball dienlich sein was die Gestaltung angeht und darüberhinaus sollte es an der 3.0 angepasst werden, wird man ohnehin beide gleichzeitig nutzen können
Don’t have an account yet? Register yourself now and be a part of our community!
