diff --git a/book/02-ueber-joomla/abschnitte/01-cms.adoc b/book/02-ueber-joomla/abschnitte/01-cms.adoc index 4fec502..5dd991e 100644 --- a/book/02-ueber-joomla/abschnitte/01-cms.adoc +++ b/book/02-ueber-joomla/abschnitte/01-cms.adoc @@ -15,7 +15,8 @@ Content-Management-Systemen gehören, bezieht sich der Begriff des CMS i. d. R. auf Web-Content-Management-Systeme, die _ausschließlich_ als Webanwendungen arbeiten, also über den Webbrowser administriert werden. -Diese WCMS erlauben es mehreren Benutzern, gemeinschaftlich an den +Diese WCMSfootnote:[https://de.wikipedia.org/wiki/Content-Management-System] +erlauben es mehreren Benutzern, gemeinschaftlich an den hinterlegten Informationen zu arbeiten, und sind medienneutral in ihrer Ausgabe. Medienneutral bedeutet dabei, dass die hinterlegten Informationen unabhängig vom Ausgabeformat (HTML, PDF, Excel) bzw. der diff --git a/book/02-ueber-joomla/abschnitte/02-geschichte.adoc b/book/02-ueber-joomla/abschnitte/02-geschichte.adoc index 53b9e55..2434a7e 100644 --- a/book/02-ueber-joomla/abschnitte/02-geschichte.adoc +++ b/book/02-ueber-joomla/abschnitte/02-geschichte.adoc @@ -37,3 +37,38 @@ von Grund auf neu geschriebene Joomla!-Version 1.5 zu schreiben, die im Januar 2008 erschien und dem Projekt nochmals einen enormen Aufwind gab. In den aktuellen Versionen findet sich dadurch kein Code des Vorgängers Mambo mehr. + +Wesentliche Neuerung der Version 1.6, die im Januar 2011 erschien, war +ein Benutzerverwaltungssystem. Bereits ein Jahr später erschien die +Version 2.5, die einen schnelleren Seiten­aufbau, eine verbesserte +Suchfunktion und vereinfachte Updates mitbrachte. + +Einen großen Schritt nach vorne brachte im September 2012 die Version +3.0. Neben einer vereinfachten Installation, verbesserter +Mehrsprachigkeit und einer neuen Administrationsoberfläche ist die +Unterstützung des CSS-Frameworks Bootstapfootnote:[https://de.wikipedia.org/wiki/Bootstrap_(Framework)] zu erwähnen, +weil hiermit die Grundlage für Responsives Webdesign von +Joomla!-Webseiten gelegt wurde. Damit wurde die Möglichkeit erschaffen, +Webseiten zu erstellen, die auch auf den kleinen Bildschirmen von +Smartphones ansprechend dargestellt werden. Denn während in den +Anfangsjahren von Joomla noch ausschließlich für Desktop PCs und +Notebooks entwickelt wurde, verschob sich die Internet-Nutzung +zunehmend in Richtung Mobilgeräte wie Smartphones und Tablets. +Die Versionen 3.x brachten nach und nach viele Verbesserungen, z.B. +Das Einfügen von Bildern per Drag-and-Drop (V3.5), benutzerdefinierte +Felder (V3.7) und Datenschutzfunktionen (V3.9). Im August 2021 +erschien die Version 3.10 als Brücke zur gleichzeitig vorgestellten +neuen Hauptversion 4. + +Mit Version 4.0 änderte sich vieles: Es gab ein nahezu vollständiges +internes Redesign, eine erneut überarbeitete Administrationsoberfläche, +höhere Mindestanforderungen an die Systemumgebung sowie eine neue Struktur +für Erweiterungen. Das führte nicht nur zu erheblichem Migrationsaufwand +beim Update vieler Webseiten, sondern auch zu einigem Unmut bei +Webseitenbetreibern und Herstellern von Joomla!-Erweiterungen. +Nachdem Joomla! 3 sehr lange (für manche viel zu lange) aktuell war, +wurde jetzt eine neue Release-Strategie eingeführt; doch dazu später +mehr. + +Entsprechend dieser neuen Strategie wurden die Hauptversionen 5.0 im +Oktober 2023 und 6.0 im Oktober 2025 wie vorgesehen veröffentlicht. diff --git a/book/02-ueber-joomla/abschnitte/03-organisation.adoc b/book/02-ueber-joomla/abschnitte/03-organisation.adoc index d856ff5..6efff11 100644 --- a/book/02-ueber-joomla/abschnitte/03-organisation.adoc +++ b/book/02-ueber-joomla/abschnitte/03-organisation.adoc @@ -1,102 +1,54 @@ === Organisation -Das Joomla!-Projekt ist in den letzten Jahren massiv gewachsen und -musste dabei seine Strukturen mehrfach an die veränderten Anforderungen -anpassen. Die aktuelle Organisationsstruktur befindet sich zum Zeitpunkt -der Erscheinung dieses Buchs in einem Übergangsprozess, ist also noch -nicht vollständig umgesetzt worden. - -Die Grundstruktur des Projekts entspricht auf den ersten Blick der eines -klassischen Unternehmens (siehe Abb 2.1). +Das Joomla!-Projekt musste seine Strukturen seit 2005 mehrfach an +veränderte Rahmenbedingungen anpassen. Die Grundstruktur des Projekts +hat sich allerdings in den letzten Jahren kaum verändert und entspricht +auf den ersten Blick der eines klassischen Unternehmens (siehe Abb 2.1). image::media/02/03-01.png[Projektstruktur,width=548,height=389] -Bild 2.1 Neue Organisationstruktur des Joomla!-Projekts +Bild 2.1 Organisationstruktur des Joomla!-Projekts Basis des Projekts ist die juristische Person hinter Joomla!, nämlich -die bereits erwähnte not-for-profit Organisation "OpenSourceMatters -Inc." mit Sitz in New York. +die gemeinnützige Organisation "OpenSourceMatters Inc." mit Sitz in New York. OpenSourceMatters hat einen Vorstand, bestehend aus den Sonderrollen -"President/in", "Vize-President/in", "Generalsekträr/in" und -"Schatzmeister/in" sowie den Abteilungsleiter/innen der 7 Abteilungen, +"Präsident/in", "Vize-Präsident/in", "Generalsekretär/in" und +"Schatzmeister/in" sowie den Abteilungsleiter/innen der 3 Abteilungen, im Projektjargon als "Department Coordinator" bezeichnet. -Derzeit sind die folgenden Abteilungen im Projekt vorgesehen: +Derzeit sind die folgenden Abteilungen im Projekt realisiert: -* Production: zuständig für die technische Entwicklung des eigenen +* Production: zuständig für die technische Entwicklung des Kernprodukts "Joomla! CMS" -* Legal: verteidigt die rechtlichen Interessen des Gesamtprojekts, -insbesondere im Bezug auf die Marke "Joomla!" -* Marketing & Communication: koordiniert die interne und externe -Kommunikation des Projekts und versucht die Verbreitung von Joomla! zu -erhöhen -* Events: zuständig für alle Fragen rund um Veranstaltungen und Meetups -* Operations: kümmert sich um den Betrieb der Infrastruktur, den das +* Outreach: koordiniert die interne und externe Kommunikation des +Projekts und versucht, die Verbreitung von Joomla! zu erhöhen +* Operations: kümmert sich um den Betrieb der Infrastruktur, die das Projekt benötigt, wie zum Beispiel die joomla.org Websites -* Programs: dieses Department betreut die verschiedenen Programme und -Initiativen, an denen Joomla beteiligt ist. Hierzu gehört zum Beispiel -das "Google Summer of Code" Programm oder das geplante -Zertifizierungs-Programm für Joomla-Administratoren und Dienstleister -* Local Communities: repräsentiert die lokalen Communities wie -Usergroups oder nationale Vereine -Jedes Deparment kann wiederrum aus beliebig vielen Teams bestehen, die -für jeweils einen bestimmten Aspekt zuständig sind. Im Deparment -"Production" könnte es hier z.B. ein Team für die Übersetzung von Joomla -in andere Sprachen geben, ein Team für die Entwicklung von Joomla 4.x -sowie ein Team für die Dokumentation. Die Anzahl der Teams unterliegt -dabei keiner Begrenzung sondern kann frei gewählt werden. +Jede Abteilung kann aus beliebig vielen Teams bestehen, die für jeweils +einen bestimmten Aspekt zuständig sind. In der Abteilung "Production" +gibt es beispielsweise Teams für Barrierefreiheit, für automatisierte Testverfahren, +für die Beseitigung von Fehlern, für die Wartung von Joomla!, für die +Veröffentlichung von Releases, für die Dokumentation, für die Sicherheit +und einige mehr. Die Anzahl der Teams unterliegt dabei keiner Begrenzung, +sondern kann innerhalb der Abteilung frei gewählt werden. -Auf der Ebene der Teams angekommen besteht jedes Team aus den Positionen +Auf der Ebene der Teams angekommen, besteht jedes Team aus den Positionen "Teamleiter/in" und "stellv. Teamleiter/in" sowie einer beliebigen -Anzahl Teammitgliedern. Die Aufnahme in ein Team erfolgt über ein -Bewerbungsverfahren, dass die Teams individuell gestalten können. Ein -Team wiederrum wählt dann den Teamleiter sowie seinen Stellvertreter, +Anzahl von Teammitgliedern. Die Aufnahme in ein Team erfolgt über ein +Bewerbungsverfahren, das die Teams individuell gestalten können. Ein +Team wiederum wählt dann den Teamleiter sowie seinen Stellvertreter, die Teamleiter eines Departments wählen den Department Coordinator und -alle Deparment Coordinator wählen die passenden Personen für die vier +alle Deparment Coordinators wählen die passenden Personen für die vier genannten Sonderposten auf Vorstandsebene. Die Projektstruktur verfügt somit über einige bemerkenswerte Merkmale: -* absolut alle Mitarbeiter im Projekt, ganz egal auf welcher Ebene, -arbeiten unbezahlt und ehrenamtlich -* es gibt nicht "die Firma" hinter dem Projekt, die die Entwicklung +* Absolut alle Mitarbeiter im Projekt, ganz egal auf welcher Ebene, +arbeiten unbezahlt und ehrenamtlich. +* Es gibt nicht "die Firma" hinter dem Projekt, die die Entwicklung steuert, sondern die Richtungsfindung und Entwicklung erfolgt im Rahmen -von demokratischen Prozessen -* es gibt klare Prozesse für Abstimmungen, Team-Gründungen und --Auflösungen sowie die Aufnahme neuer Mitarbeiter - -An dieser Stelle sollte jedoch nicht verschwiegen werden, dass die neue -Struktur in der Community nicht unumstritten ist. Die Abstimmung über -den Wechsel zum neuen Aufbau ging denkbar knapp aus und der derzeit -stattfindende Wechsel von der alten auf die neue Struktur ist massiv -hinter dem aufgestellten Zeitplan. Kritiker äußern dabei vor allem die -folgenden Kritikpunkte: - -* - die neue Struktur ist zu bürokratisch. Langatmige Prozesse -verlangsamen die Entscheidungsfindung und nehmen allen Beteiligten die -nötige Flexibilität -* in der neuen Struktur ist zu viel "Macht" auf einige wenige Menschen, -nämlich den Vorstand von OpenSourceMatters konzentriert. Ein System der -gegenseitigen Prüfung von mehreren, gleichberechtigten Instanzen, wie es -in der alten Struktur der Fall war, fehlt -* der Wechsel zur neuen Struktur würde das Projekt über Monate -beschäftigen und lähmen - -Zum jetzigen Zeitpunkt (Februar 2017) ist noch nicht absehbar wie die -neue Struktur sich auf das Projekt auswirkt - man darf daher gespannt -sein. - -[width="99%",cols="14%,86%",options="header",] -|=== -|CHV++_++BOX++_++ID++_++02 | -|icn002 |Als Mitglied des Joomla! Community Leadership Teams war ich, -der Autor dieses Kapitels, direkt an der Abstimmung über die Adaption -der neuen Struktur beteiligt und habe dabei gegen deren Einführung -gestimmt. Ich habe mich bemüht, die Struktur dennoch so neutral wie -möglich darzustellen und hoffe, dass mir das gelungen ist. -Nichtsdestotrotz sind Sie herzlich eingeladen, die offizielle -Beschreibungfootnote:[https://docs.google.com/document/d/1gsUK0kePsBg6xiaUVdN6oExZ0hKEjBxH6bRVAeZy-IE/edit?usp=sharing] -des Strukturentwurfs zu lesen und sich ein eigenes Bild zu machen. -|=== +von demokratischen Prozessen. +* Es gibt klare Prozesse für Abstimmungen, Team-Gründungen und +-Auflösungen sowie die Aufnahme neuer Mitarbeiter. diff --git a/book/02-ueber-joomla/abschnitte/04-releasestrategie.adoc b/book/02-ueber-joomla/abschnitte/04-releasestrategie.adoc index 345306d..1047bce 100644 --- a/book/02-ueber-joomla/abschnitte/04-releasestrategie.adoc +++ b/book/02-ueber-joomla/abschnitte/04-releasestrategie.adoc @@ -1,70 +1,121 @@ === Releasestrategie -Mit der Veröffentlichung von Joomla! 3.2 hat das Joomla-Projekt einen -Wechsel der Releasestrategie beschlossen. Das System des sog. -Time-Based-Releasecycle, das zum Release von Joomla 1.6 im Jahr 2011 -eingeführt wurde und auf der Idee von fest terminierten -Veröffentlichungen und Langzeit- und Kurzzeitsupport-Versionen basierte, -wurde aufgegeben und stattdessen eine Strategie auf Basis der beiden -Grundsätze "_schlanke, schnelle_ _Releases_" und "_semantische -Versionierung_" eingeführt. - -Schlanke, schnelle Releases bedeuten dabei, dass neue Joomla!-Versionen -in relativ kurzen zeitlichen Abständen (im Idealfall ca. 1 Release pro -Quartal) veröffentlicht werden sollen und die jeweiligen Releases dabei -jeweils nur relativ, kleine überschaubare Sets an Funktionen mitbringen -sollen. Das gegenteilige Modell wäre z.B. die Veröffentlichung von nur -einem Update pro Jahr, das dann aber wesentlich umfangreicher ist und -eine Vielzahl von Funktionen mitbringt. Dieser Ansatz erlaubt den -Joomla!-Entwicklern sehr schnell auf neue Anforderungen der Web-Welt zu -reagieren und führt zudem zu schnellen Erfolgserlebnissen für -Entwickler, die eine Funktion zu Joomla! beisteuern. - -Der zweite Grundsatz, die sogenannten semantische Versionierung, gibt +Mit der Veröffentlichung von Joomla! 4 im August 2021 hat das Joomla!-Projekt +eine neue Release-Strategie eingeführt. Diese steht auf zwei Grundsätzen: + +* Semantische Versionierung +* Feste Release-Termine + +Doch bevor wir zu diesen beiden Teilen der Strategie kommen, noch ein paar +allgemeine Bemerkungen. + +Joomla! benötigt einen Unterbau aus drei Komponenten: + +* einen Webserver (meist Apache), +* einen Webserver-Erweiterung für die Skriptsprache PHP und +* eine Datenbank (MySQL, MariaDB oder PostgresQL). + +Diese Komponenten (alle genannten stehen ebenso wie Joomla! jeweils unter +einer Open-Source-Lizenz) entwickeln sich ebenso weiter wie Joomla! Und +natürlich müssen die eingesetzten Versionen miteinander harmonieren, was +durch die Releasestrategie von Joomla! sichergestellt werden muss. + +==== Semantische Versionierung + +Der erste Grundsatz, die sogenannte Semantische Versionierung, gibt vor, welche Art von Änderung sich auf welche Stelle der Versionsnummer -auswirkt. Eine dreistillige Versionsnummer, also x.y.z lässt sich dabei +auswirkt. Eine dreistellige Versionsnummer, also X.Y.Z, lässt sich dabei in die folgenden Komponenten aufteilen: [arabic] -. X ist die sog. Majorversion. Eine Änderung dieser Ziffer ist -notwendig, wenn das Joomla! Projekt eine Änderung einbaut, die einen -Bruch der Rückwärtskompatiblität zur Folge hat. Mit anderen Worten: -ändert sich die erste Stelle der Versionsnummer, müssen Entwickler ihre -Erweiterungen an die neue Version anpassen, da diese ansonsten nicht -mehr lauffähig ist. Somit ist der Wechsel von der einen zur anderen -Majorversion ein etwas komplexerer Prozess, der im Joomla!-Jargon als -Migration bezeichnet wird und in Kapitel 22 genauer beschrieben ist. -. Y ist die sog. Minorversion. Hier ist eine Änderung immer dann -notwendig, wenn eine neue Funktion zu Joomla! hinzugefügt wird. Diese -Minorversionen erscheinen im oben bereits beschriebenen -Quartalsrhythmus. Ein Update auf eine neue Minorversionen ist sehr -simpel und in der Regel mit einem simplen Mausklick durchführbar. +. X ist die sog. Majorversion. +Eine Änderung dieser Ziffer erfolgt, wenn das Joomla! Projekt eine +Änderung einbaut, die einen Bruch der Rückwärtskompatiblität zur Folge +hat. Mit anderen Worten: Ändert sich die erste Stelle der Versionsnummer, +müssen Entwickler ihre Erweiterungen an die neue Version anpassen, da +diese ansonsten nicht mehr lauffähig sind. Somit ist der Wechsel von +der einen zur anderen Majorversion ein etwas komplexerer Prozess, der +im Joomla!-Jargon als Migration bezeichnet wird und in Kapitel 22 genauer +beschrieben ist. +Für jede Hauptversion legt das Joomla! Projekt die Mindestanforderungen +an den Webserver sowie an PHP und Datenbank fest. Diese Mindestanforderungen +bleiben während der gesamten Lebenszeit der jeweiligen Hauptversion +unverändert. +. Y ist die sog. Minorversion. Bei einer Änderung der Minorversion +können neue Funktionen zu Joomla! hinzugefügt werden. Ein Update auf +eine neue Minorversionen ist relativ unkritisch und in der Regel mit +einem simplen Mausklick durchführbar. . Z ist die sog. Patchversion. Diese kleinste Art von Update enthält -ausschließlich Fehlerbehebungen (auch als Patches bezeichnet) und können +ausschließlich Fehlerbehebungen (auch als Patches bezeichnet) und kann ebenfalls bedenkenlos per Mausklick direkt in der Administration von -Joomla eingespielt werden. +Joomla! eingespielt werden. + +==== Feste Release-Termine + +Die Einführung fester Release-Termine ist eine Konsequenz aus den +Erfahrungen mit der Hauptversion 3 von Joomla! Joomla 3.0.0 erschien +im August 2012, Joomla 4.0.0 aber erst im August 2021. Da sich ja innerhalb +einer Hauptversion die Mindestanforderungen nicht ändern dürfen, +musste z.B. Joomla 3.10.0 im August 2021 noch PHP 5.2 unterstützen, das +neun Jahre vorher aktuell war. Damit konnten die Joomla-Entwickler die erweiterten +Möglichkeiten der inzwischen erschienenen PHP-Hauptversionen 7 und 8 +nicht nutzen. Ähnlich sah es bei den Datenbanken aus. + +Für Webseitenbetreiber und Entwickler von Erweiterungen schien das eine gute +Zeit zu sein: Die Webseiten liefen, die Erweiterungen ebenfalls. Warum sollte +man da viel ändern? Dass sich die Softwarelandschaft in den langen Jahren +von Joomla 3 gründlich gewandelt hatte, wurde von vielen ignoriert. + +Dann kam Joomla 4, und mit ihm der Schock. Joomla hatte neue Mindestanforderungen +und eine neue Architektur für Erweiterungen. Alte Erweiterungen (einschließlich +der Templates) funktionierten nicht mehr mit Joomla 4 und PHP 8. Viele +Updateversuche gingen schief, weil der Migrationsleitfadenfootnote: +[https://docs.joomla.org/Joomla_3.x_to_4.x_Step_by_Step_Migration/de] nicht +beachtet wurde oder gar nicht bekannt war. Darüber hinaus stellten viele +Webseitenbetreiber erschrocken fest, dass so manche lieb gewonnene Erweiterung +nicht mehr weiterentwickelt wurde und für Joomla 4 damit nicht mehr zur +Verfügung stand. + +All dies führte zu großer Verunsicherung bei den Joomla-Anwendern. Als +Reaktion darauf beschloss das Joomla-Projekt die Einführung von festen +Release-Zyklen mit folgenden Vorgaben: + + ++ +Alle zwei Jahre erscheint eine neue Majorversion von Joomla. Beginnend +mit Joomla 5.0.0 ist der Releasetermin immer an einem Dienstag Mitte Oktober. ++ +Nach dem Release einer Hauptversion (N+1) wird die vorhergehende +Hauptversion (N) noch für zwei weitere Jahre unterstützt, also bis zum +Release der Hauptversion (N+2). ++ +Alle sechs Monate erscheint eine neue Minorversion, also jeweils Mitte +April und Mitte Oktober. ++ +Innerhalb einer Majorversion (N) ist die Minorversion (N).4 die letzte. Sie +erscheint gleichzeitig mit der neuen Majorversion (N+1) und bildet die +Brückenversion von der alten auf die neue Hauptversion. Ein Update auf +die neue Majorversion (N+1) ist nur von der Minorversion (N).4 möglich. +Die Minorversion (N).4 erhält nur noch Fehlerkorrekturen und +Sicherheitsupdates, aber keine neuen Funktionen mehr. +Mit dem Erscheinen der Minorversion (N).4 ist der Zeitpunkt gekommen, +an dem mit der Planung der Migration auf die neue Hauptversion begonnen +werden sollte. ++ +Innerhalb einer Minorversion erscheint alle sechs Wochen eine neue +Patchversion. + -Um den Nutzern von Joomla! eine gewisse langfristige Planungssicherheit -zu geben, gibt das Joomla!-Projekt feste Mindestzeiträume an, in denen -eine bestimmte Version noch mit Sicherheitsupdates und Fehlerbehebungen -versorgt wird. Grundregel ist dabei, dass die jeweils letzte -Minorversion eines Major-Zweigs für 2 Jahre unterstützt wird. +In der Release-Ankündigung wird jeweils angegeben, ob es sich um +ein Sicherheits-kritisches Update handelt. + -Ein kleines Beispiel, um diesen etwas abstrakten Satz mit konkreten -Inhalten zu füllen: +Ab Joomla 5 gibt es für jede Majorversion (N) ein sogenanntes +"Kompatibilitäts-Plugin". Ist dieses Plugin aktiviert, laufen alle +Erweiterungen (inkl. Templates), die in der Majorversion (N-1) lauffähig +waren, auch in der Majorversion (N). + -Wir nehmen einmal an, dass am 01.01.2018 eine fiktive Joomla!-Version -4.0 erscheint. Im weiteren Entwicklungsverlauf erscheinen für diesen -neuen Versionszweig 4.x nun mehrere Minor-Releases, die neue Funktionen -nachrüsten. Die letzte Minor-Version, in unserem fiktiven Fall wäre das -zum Beispiel 4.9.0, erscheint dabei am 01.03.2020. Der Releasetermin -dieser letzten Minor-Version wäre nun ausschlaggebend für das Ende des -Supportzeitraums von 2 Jahren, womit der Support für die Joomla!-Version -4.x am 28.02.2022 enden würde. Im Rahmen dieses Supportzeitraums würde -es weiterhin Fehlerbehebungen und Sicherheitsupdates geben, die sich -dann auf die letzte Ziffer der Versionsnummer (z.B. als 4.9.1, 4.9.2 -etc.) auswirken würden. +Speziell bezüglich PHP gilt, dass die mindestens geforderte PHP-Version +während der gesamten Lebenszeit der Joomla!-Hauptversion unterstützt wird. + -Joomla! bietet Entwicklern und Nutzern hier also eine langfristige -Planungssicherheit und eignet sich daher perfekt für Projekte, die über -einen längeren Zeitraum unterstützt werden müssen. +Bei der Migration von einer Version (N).4 auf eine neue Hauptversion (N+1) +wird dem Administrator ein "Pre-Update-Check" eingezeigt, der auf mögliche +Fehlerquellen beim Übergang auf die neue Hauptversion hinweist.