Bachelorarbeit - Einsatz und Modifikation von Contenido

[high-end]

Hallo Gemeinde,

ich sitze schon seit einiger Zeit an meiner Bachelorarbeit, die sich dem wunderbaren CMS Contenido widmet.

Das Thema ist sinngemäß: "WCMS Contenido: Einsatz, Modifikation und Entwicklung eigener Funktionen"

Also es soll für den Leser (Zielgruppe: Angehende Contenido-Administratoren und -Entwickler) eine Art Handbuch werden, die alle wichtigen Aspekte rund um das CMS abdeckt:
Von der Bedienung des Backends (nicht in den Handbüchern beschriebene Eigenheiten, Schwächen), über das geniale "Contenido-Prinzip" (welches sich übrigens total schwer in Worte fassen lässt, zumindest so das ein Entwickler damit was anfangen kann^^), die Architektur des CMS,
Datenbank und Datenstrukturen, wichtige Klassen, Funktionen, usw... (was halt alles für die Entwicklung von Modulen, Plugins oder Coremodifikationen erforderlich ist!).

Im praktischen Teil wird dann Anhand von Beispielen gezeigt, wie man den CMS-Kern seinen eigenen Anforderungen anpassen kann und Erweiterungen implementiert.

Ich bin noch lange nicht fertig mit der Arbeit, obwohl die Zeit langsam knapp wird.
Über jede Hilfe würde ich mich freuen und auch entsprechende Credits im Werk vergeben.

Im Anhang habe ich mal die Arbeit mit den Kapiteln 3 (Vorstellung von Contenido) und 4 (Technische Betrachtung) hochgeladen.
Kapitel 3 ist eigentlich fertig. Kapitel 4 noch nicht ganz. Die restlichen Kapitel sind erstens noch Baustellen und ich möchte sie wegen möglicher Geschäftsgeheimnisse des Praktikumsbetriebes (zumindest ist mein Betreuuer der Meinung; muss also noch abgeklärt werden) nicht veröffentlichen, bitte habt Verständnis dafür.

Ich würde mich freuen, wenn ihr euch das ganze mal durchlest oder zumindest überfliegt und mir eure harte Kritik zukommen lassen könnt. Ich stelle die Erkenntnisse und das fertige Ergebnis gerne der Community zur Verfügung - als Nachschlagewerk mit allen wichtigen Informationen gebündelt sollte es (zumindest hoffe ich das) für Contenido-Entwickler-Einsteiger ganz nützlich sein und einige sucherei im Internet ersparen.

Vielleicht habt ihr auch noch einige Tipps für mich, was ich besser machen könnte. Natürlich würde ich mich z.B. über Klassendiagramme (die von Doxygen taugen nicht viel) oder Datenbankschemas von offizieller Seite freuen, das ich in der Arbeit verwenden könnte. Bitte weist mich auch auf Fehler oder totalen verzapften Blödsinn hin - dafür schonmal im Vorraus ein fettes Dankeschön!

Beste Grüße,
High-End

Hier die Arbeit, da das Forum keine PDFs erlaubt (~800kb): http://paradox-marmot.de/projekte/conte ... arbeit.pdf

[Oldperl]

Hallo High-End,

nett, sehr nett.

Beim Überfliegen der PDF gesehen: Es gibt nicht nur

zwei Arten von Backend-Benutzern mit
voneinander verschiedenen Kernkompetenzen

sonder derer 3.
Du hast den Systemadministrator (sysadmin) vergessen, den "Master of Desaster".
Im Gegensatz zu Administratoren (admin), die nur Zugriff auf zugewiesene Mandanten und/oder Sprachen haben, kann der Systemadministrator auf "Alles" zugreifen.

Gruß aus Franken

Ortwin

PS: Würde mich freuen wenn du mich auf dem Laufenden hälst.

[high-end]

hallo Oldperl,

japp das ist klar und wird dann unter dem Punkt "Administration" genauer auseinanderklamüsert.
Soll ja am Anfang nur allgemein gesehen werden, in Bezug auf die offiziellen Handbücher gibt es in Contenido also zwei verschiedene Kernkompetenzen:

Admins die sich um die Integration der Webseite, Module und alles andere kümmern. (Adminhandbuch)
Der Sysadmin, der sich ja hauptsächlich um Installation und Wartung des CMS kümmert... hmm gehört hier *erstmal* zur ersten Gruppe, oder?
Redakteure die nur für die Bearbeitung von Inhalten zuständig sind (Redakteurhandbuch)

Den Absatz hab ich auch nur eingefügt, um irgendwie sinnvoll auf die Handbücher zu verweisen. ^^ Mal sehen wie ich den Sysadmin da noch unterbringe.

grüße,
dark

[Oldperl]

Hallo dark (high-end),

hmm, ja, könnte man so verstehen, ist aber definitiv nicht korrekt, auch wenn es durch vorhandene Handbücher so rüber kommt. Das BE (Backend) hat definitiv 3 unterschiedlich gewertete Zugangsebenen (sysadmin, admin, user), wobei der sysadmin wirklich an Alles ran kommt, der admin nur an, vom sysadmin, zugewiesene Mandanten/Sprachen und die des users, dem der sysadmin/admin explizite Rechte zuweisen kann.
Damit ist die Rechteverwaltung mit eine der Aufwendigsten von den derzeit am Markt zu findenden CMS.

Eine andere "Unrichtigkeit" ist mir noch aufgefallen. Contenido nutzt definitiv kein MVC-Modell so wie Frameworks wie ZF oder FLOW3. Den Abschnitt sollte man ersatzlos streichen.

Gruß aus Franken

Ortwin

[high-end]

vielen dank für die Infos,

Eine andere "Unrichtigkeit" ist mir noch aufgefallen. Contenido nutzt definitiv kein MVC-Modell so wie Frameworks wie ZF oder FLOW3. Den Abschnitt sollte man ersatzlos streichen.

Danke für den Hinweis. Ich habe ziemlich viel Recherchiert, auf welchem Modell/Architektur denn Contendo fußen könnte. MVC war dann irgendwie das Naheliegendste, da ja zur Generierung der Ausgabe (View) Template-Systeme/Container verwendet werden und durch die ganzen Klassen in "/classes/" ja das Datenmodell abgebildet wird.

Du scheinst zu den Entwicklern zu gehören, oder?

Wenn es nicht MVC ist, kannst du mir sagen, worum es sich dann handelt? Gar kein Entwurfsmuster/Modell?

Dann noch einige Fragen: Die Datenbankstruktur von Contenido ist flach und ohne Beziehungen - es gibt in der Datenbank selbst keine definierten Constraints, foreign keys, etc.
Also es gibt sie schon, aber nicht in SQL-Anweisungen sondern nur durch die Klassen und Funktionen realisiert?
Auch die Klassenstruktur ist laut Doxygen ziemlich flach, es gibt kaum Hierarchien, die meisten Klassen stehen für sich alleine? nur wenige abstrakte Klassen, extends und Ableitungen. Sehe ich das richtig?

grüße,
HighEnd

[kummer]

Wenn es nicht MVC ist, kannst du mir sagen, worum es sich dann handelt? Gar kein Entwurfsmuster/Modell?

in der tat gleich es einem mvc in dem sinn, als das zunächst eine trennung zwischen logik, layout und inhalten vorliegt. und es gibt - mindestens für den frontend-bereich - tatsächlich eine bootstrap, die front_content.php nämlich. im backend sieht es ähnlich aus, ist jedoch nicht konsequent umgesetzt. will heissen, es gibt zahlreiche scripte, die über den browser direkt angesprochen werden.

kurz gesagt, es gibt oder gab vermutlich die versuche, entwurfmuster umzusetzen. ich würde auf diesen punkt ehrlich gesagt nicht gross eingehen. wesentliche teile von contenido stammen aus einer zeit (so um PHP 3), wo entwurfmuster wohl bestanden haben, in der php-welt jedoch noch keine bedeutung gehabt haben. und soviel ist sicher: wenn es eine strategie für die weiterentwicklung geben sollte, dann ist diese ausschliesslich 4fb bekannt.

[kummer]

vielleicht noch zur lizenzbestimmung:

Umbenennung/Rebranding jeglicher Art ist untersagt (Logos austauschen,
Copyright Informationen löschen, etc.)

das ist kompletter unsinn. wenn die software eine gnu/gpl-lizenz aufweist, und das ist der fall, dann ist so eine einschränkung explitzit nicht möglich. die entfernung von copyright-hinweisen darf zwar nicht vorgenommen werden (das hat jetzt zunächst nichts mit gpl zu tun, sondern ist generell nicht erlaubt), aber ansonsten darf man damit fast alles tun. insbesondere natürlich dem ganzen ein aussehen verpassen, das nicht mehr an contenido erinnert.

das gleich gilt für:

Das CMS darf nicht gegen Entgelt weiterveräußert werden

hier muss man sich einfach die gpl genauer anschauen. es gilt generell: die gpl gilt.

PS: schöne arbeit im übrigen. das mit dem unsinn bezieht sich nicht auf dich oder deine arbeit, sondern auf das selbstverständnis von 4fb.

[high-end]

Hallo kummer, danke für das Lob.. motiviert mich doch gleich weiterzuschreiben.

Ja ich weiß. Die Sache mit den "Lizenzbestimmungen" lasse ich aber lieber mal so drin, schließlich ist das ganze ja mit ner Quellenangabe versehen und wurde von offizieller Seite so vorgeschrieben. Einfach um potentiellem Ärger aus dem Weg zu gehen, man weiß ja nie...


Hmm zum Architekturmuster: was soll ich da jetzt schreiben?
Dass aus softwaretechnischer Sicht das CMS ein ziemlicher Sauhaufen ist aber trotzdem gut funktioniert?
(unnormalisierte DB, redundanzen, multiple IDs, keine strikt durchgezogenen Entwurfsmuster)

klingt irgendwie unglaubwürdig oder?

[idea-tec]

Hmm zum Architekturmuster: was soll ich da jetzt schreiben?
Dass aus softwaretechnischer Sicht das CMS ein ziemlicher Sauhaufen ist aber trotzdem gut funktioniert?
klingt irgendwie unglaubwürdig oder?

Hatte Woodstock ein Konzept?

[high-end]

ich hab jetzt anstelle der näheren Betrachtung von Architekturmustern, objektorientierung und weiteren Mustern folgenden Text als Begründung hingeschrieben.

Viele Programmteile des Content-Management-Systems stammen noch aus den Anfangszeiten
der Contenido-Entwicklung unter Verwendung von PHP3. Das System
wurde stetig, später auch mit Hilfe der Entwicklergemeinschaft, weiterentwickelt und
hat bereits zwei Umstellungen der PHP-Version hinter sich. Auch in der aktuellen
Version sind immer noch Algorithmen und Datenstrukturen aus frühen Entwicklungsstadien
erhalten.
Entwurfsmuster und andere Programmierprinzipien sind in neuen Programmteilen
ansatzweise vorhanden, jedoch nicht durchgängig und konsequent umgesetzt. Das
Architekturmodell Model View Controller (MVC) ist teilweise präsent, vor allem im
Frontend-Bereich und in Ansätzen im Kernsystem. Dies ist durch die Verwendung
eines Layout- und Templatesystems als View, der Klassen- und Datenbankstruktur als
Model (Klassen repräsentieren in der Datenbank gespeicherte Elemente, z.B. Artikel
oder Kategorien) sowie der Module und API-Funktionen als Controller erkennbar.1
Objektorientierte Programmierung wurde mit dem Umstieg auf PHP4 ansatzweise
und erst mit PHP5 vollständig ermöglicht. Vor allem bei Kernfunktionen sind noch
prozedurale Algorithen zwischen später hinzugefügten, objektorientierten Implementierungen
zu finden. Die Umstellung scheint derzeit im Gange zu sein, teilweise sind
zum erreichen eines Ziels mehrere Möglichkeiten (alte und neue) vorhanden, z.B. der
Zugriff auf Datenbankinhalte.
Eine nähere Betrachtung der betreffenden softwaretechnischen Aspekte wurde aufgrund
dieser Umstände nicht durchgeführt.

[kummer]

du brauchst ja in deiner arbeit contenido nicht zu verteidigen. du arbeit wird ja nicht bewertet werden aufgrund der qualität von contenido, sondern aufgrund der qualität deiner arbeit. contenido hat schwächen. und zwar einige. um nur ein paar zu nennen:

* die db-normalisierung ist schwach
* sämtliche für den ablauf notwendigen variablen finden sich globalen scope
* es gibt keine registry
* es gibt mehr als eine db-verbindung (je nach situation können hunderte verbindungen bestehen)
* die abfragen sind zum teil sehr schlecht (zum beispiel werden zuweilen joins als zwei abfragen abgebildet, wobei die zweite abfrage innerhalb einer schlaufe vorgenommen wird)
* es gibt unzähliche includes, welche die logik extrem verteilen, wobei auch hier wieder der globale kontext zur statuserhaltung herangezogen wird

zur frage des mvc: ich denke nicht, dass es ein mvc in contenido gibt. auch nicht, wenn gezielt danach gesucht wird. zunächst würden models benötigt. ungeachtet dessen, wie man diese definiert (mit oder ohne persistenz) wird man bei contenido nicht fündig werden. es gibt zwar apis für kategorien und artikel; diese werden jedoch auch im kern nicht konsequent verwendet und dienen in erster linie der vereinfachung der plugin- und modulprogrammierung. das m fällt definitv weg. bleibt also noch vc. auch eine view wird man vergebens suchen. schau dir mal die con_code an. dort wird das layout mit hilfe des templates mit den modulen verschmolzen, abgelegt und später ausgeführt. wir haben hier also sowohl logik als auch layout. will heissen: minus v. bleibt noch das c. controller. für ein mvc müsste es einen geben. nicht zwei, oder drei. dazu kannst du den code mal nach page_open() durchsuchen. wenn in einem script page_open auftaucht, kann es direkt angsprochen werden, respektive das wäre der sinn und zweck. ich weiss jetzt nicht genau, wieviele resultate du finden wirst. aber es werden einige sein. also fällt auch das c weg. von mvc bleibt also noch:

es handelt sich übrigens um ein problem, welches viele system aufweisen. und einige, die ein wunderbares konzept haben, sind dann eben doch nicht besser. ich bin der meinung, hier müsste man was machen und es liesse sich viel gewinnen. aber - und hier liegt das wesentliche problem - eine entwickler-community gibt es eigentlich nicht. die entwicklung wird von 4fb 'behind the curtain' vorgenommen. es gibt contributions in form von modulen und plugins. aber keine echte entwicklung und steuerung durch eine community.

wenn jetzt vielleicht der eindruck entsteht, ich würde contenido für schlecht halten, dann trifft das nicht zu. na ja, mindestens nicht ganz. bei den kunden kommt das system sehr gut an, weil es in der bedienung sehr intuitiv ist. und wenn man etwas daran herumschraubt, kann man ein ziemlich leistungsfähiges system etablieren. aber im kern wird man nicht gold finden. da hilft auch langes schürfen nicht.