"Alles neu macht Drupal 6" oder "My Big Fat Drupal 6 Thread"

Folgende Module sind neu in Drupal 6:

Trigger

Ein System zum Ausführen von Aktionen in Abhängigkeit von Ereignissen

I18N

Für die Übersetzung von Inhalten

OpenID

Erlaubt die Authentifizierung mittels OpenID-Server.

Unter der Haube

• Das Menüsystem wurde komplett neu geschrieben. Für Anwender ändert sich nichts. Für Modulentwickler heißt das
  • es gibt keine Unterteilung in gecachte und nicht gecachte Menüeinträge, alle Einträge werden in der Datenbank gespeichert
  • es genügt während der Entwicklung nicht, die Tabelle {cache_menu} zu leeren, der devel-Block (aus dem devel-Modul) verfügt jetzt über einen Eintrag zum Neubau der Menüs,
  • der Teil eines Menüeintrages, anhand dessen die Callbackfunktion ermittelt wird, ist auf 7 Komponenten beschränkt
• Das Überschreiben von theme-Funktionen ist einfacher geworden. Drupal-Module bieten nun eine Reihen von Dateien {typ}.tpl.php an, die als Basis für eigenes Theming dienen können. Sämtliche verfügbaren Variablen sind in diesen Dateien dokumentiert. Das Bekanntmachen dieser Dateien bei der Theming Engine (wie das bei Drupal 5 noch gemacht werden musste) entfällt.
• Die Forms API verwendet nun ein Array namens $form_state für Werte, die in Forms gespeichert werden. Werte können sein
  • Formulareinträge die gemacht wurden
  • Weiterleitungen die nach Absenden des Formulars erfolgen sollen
  • Alles was der Entwickler sonst noch herumreichen möchte
• Datenbankschemata werden mit der neuen Schema API definiert. Die Definition ist unabhängig von dem verwendeten Datenbankmanagementsystem

Die Entwicklung von Modulen für Drupal 5 wird sich verlangsamen, da sich Modulentwickler jetzt auf Drupal 6 konzentrieren werden.

Module

Nein. Seit Drupal 5 bleibt die API des Kerns mit jedem Minor-Update stabil, ändert sich aber mit jeder Major-Version. Die wichtigsten Drupal-Module werden wahrscheinlich auf Drupal 6 portiert.

Themes

Nein. Themes brauchen in Drupal 6 eine info-Datei, wie es auch Module haben.

CCK-Nodetypes

Wahrscheinlich ja. Das ist abhängig davon, ob CCK eine Update-Funktion anbietet. Da Update-Funktionen ein essentieller Bestandteil von Drupal-Modulen sind (gerade bei den gut gepflegten) sollten hier keine Probleme auftreten.

--

Hallo,

vielen Dank für die Zusammenfassung. Aber wenn ich das so lese, dann ist das eher ein Grund nicht zu wechseln. Ich meine, ich musste nun gerade meine Seite neu aufbauen und habe noch immer nicht alles Nodes übertragen. Es gab hier mal ein Thread, in dem philosophiert wurde, warum Drupal eher von kleineren Seiten oder nur privaten Seiten genutzt wird. Hier ist der Grund, man kann sich dafür entscheiden Drupal auch für größere Projekte einzusetzen, aber dann legt man sich auf eine Major-Version fest.

Ciao, Q
---
Running Gag der IT seit den 70er: "Machen wir eben mal schnell ...".

Wie z.B. MTV, Warner Brothers Records, The New York Observer, Fast Company, Popular Science, Amnesty International, SonyBMG, Forbes, Harvard University.

Das ist normal, never change a running system. Für Drupal gibt es aber einen gut dokumentierten Upgrade-Prozess auf api.drupal.org. Falls du eigene Module hast (oder du auf eine offizielle Portierung nicht warten möchtest) erklärt drupal.org, wie du Module von D5 auf D6 portierst.

--

Oh oh, ich hoffe nicht. Das würde dann jedem Update-Prinzip widersprechen. Auf der anderen Seite unterstützt das nur meine Behauptung, dass man sich auf eine (Major-) Version festlegt.

Ich will ja nur verhindern, dass ich nochmal von gaaaaaannz Vorne anfangen muss. Das möchte keiner so recht, denke ich.

Ciao, Q
---
Running Gag der IT seit den 70er: "Machen wir eben mal schnell ...".

Hallo zusammnen,

habe gerade dieses Thema durchgelesen und glaube nicht das eine grössere Website schon auf Drupal 6.1 läuft. Ich begründe das ganz einfach damit, dass so ein wichtiges Modul wie CCK bis zum heutigen Tag noch im Entwickler-Status ist. Bei Views sieht's auch nicht viel besser aus. So könnte man die Reihe fortsetzen.

Wenn jemand anderer Meinung ist -- ich lasse mich gerne vom Gegenteil überzeugen.

Gruss Klaus

Views und CCK sind m.E. die einzig wirklich gravierenden Problemfälle. Views geht für D7 aber definitiv in den Core - und CCK auch, das wird dann evtl. etwas abgespeckt, dass nur das was muss reingeht.

Es war aber bisher sinnvoll, sie weiter als Contrib zu betreiben, da Views2 nochmal zwei Schippen draufpackt, und es eben auch noch ein ziemlich junges Modul war. Bei CCK gabs das Problem, dass da früher Flexinode war (in die Falle bin ich auch getappt) und daher CCK selber auch noch recht jung.

Speziell der Entwicker von Views aber auch die -in von CCK haben aber einen hohen Qualitätsanspruch, wie auch das Core-Team. Es ist eben erst jetzt bzw. in einem halben Jahr "reif" für den Core. Somit kann man davon ausgehen, dass dieses wirklich ungünstige Szenario sich bei D7 eher nicht wiederholen will. Es sei denn, alle benutzen bis dahin wie wild Panels... Glaub ich aber nicht, da man vieles was Panels macht auch anders lösen kann.

Drupal - the Linux of the Web

Noch etwas dazu, dass die Module immer der Version hinterherhinken!
Das ist und bleibt der größte Vorteil von Drupal, denn sonst würde ein großer Teil der Entwicklung in die Abwärtskompabilität gesteckt werden, z.B. wie bei Microsoft Windows!
-> So wird die API schneller, bleibt schlank usw.
-> Jquery würde viel zu groß sein ...
zu Flexinode: eigentlich war das ganze ja nicht schlecht, wenn man nicht selber Node-Module programmieren konnte. Ein weiterer Punkt ist, dass Flexinode für einen bestimmten Bereich (Nodes ohne Filtern) relativ gut war.
--------------
Mein Blog: www.freeblogger.org: May the source be with you
Deutscher IRC-Channel: irc.freenode.net #drupal.de je mehr desto besser
... Jabber-me: dwehner@im.calug.de Warum Jabb