Autor: Raphael

Per Zufall habe ich soeben gelesen, dass es die Leute von Joomla endlich geschafft haben, die Version 1.5 zu veröffentlichen. Ich wollte schnell einen Blick auf die Demoseite werfen, doch leider ging diese nicht. Schade. Ein kurzer Blick auf die Funktionsseite zeigt jedoch, dass auch die neue Version ein sehr hübsches Backend System hat. Hier wird wohl Drupal nachwievor das Nachsehen haben. Soviel ich weiss, wird hier daran gearbeitet, aber es wird wohl noch ein wenig dauern. Meiner Meinung nach muss es auch nicht so vergoldet sein, wie das bei Joomla der Fall ist, aber hier und da wären ein paar Zusatzfeature schon nicht schlecht.

Was mich jedoch brennend interessiert ist die angekündigte API:

With Joomla! 1.5, developers have an object-oriented, pattern based API that follows best practices and is organized into well structured and logical framework packages.

Das klingt schon sehr verlockend, aber dann kommt etwas, was mich ein wenig stutzig gemacht hat:

The Joomla! framework is built to support backwards compatibility to PHP 4.3 while also supporting the most current versions of PHP 5.

Soweit ich mich an PHP 4 bezüglich OOP errinnern kann ist dies nur sehr rudimentär vorhanden und verzichtet auf viele Dinge, was die OOP eigentlich gerade ausmacht. So be it.

Ich bin eigentlich ein Umsteiger von Joomla, nachdem ich mir ein wenig die Finger an Joomla verbrannt habe. Dies mag unter Umständen daran liegen, dass ich einfach zu wenig Erfahrung mit Joomla hatte, dass die Community nicht so freundlich wie die Drupalianer sind oder was weiss ich. Auf jeden Fall war ich sehr genervt und umso glücklicher, bei Drupal gelandet zu sein. Mich würde es jedoch brennend interessieren, wie Joomla von der Developer Seite her ausschaut. Wie sieht es bezüglich Modularisierung usw. aus. Falls jemand Erfahrungen mit Joomla 1.5 hat, dann schreibt doch bitte einen kleinen Kommentar.

Update 12.2.08 – Endlich einen ersten Erfahrungsbericht mit Joomla 1.5

Im 1. Post dieser Serie habe ich mich ein wenig zu GNU GPL ausgelassen. Da es bisher keine Kommentare zu diesem Post gegeben hat, nehme ich an, dass die Dinge korrekt waren. Creative Common sind eigentlich einfacher als die GPL Lizenzen. Hier eine super Übersicht, welche die Rechte und Pflichten sehr gut zusammenfasst und doch sehr verständlich macht.

Diese Grafik klärt nicht ganze alle Fragen, aber die Symbole sind doch leicht zu merken und ermöglichen es schnell den Kern einer Lizen zu erfassen.

[Screenshot von creativecommons.org]

Ich werde an dieser Stelle auf die Erläuterung von Details verzichten. Wer es nämlich genua wissen möchte, kann lediglich auf die oben genannte Seite gehen und auf Details klicken und schon kommen die Details dazu, welche übrigens auch sehr verständlich und kurz geschrieben sind.

Ich persönlich habe noch nie selber mit Creative Common gearbeitet, bzw. Dinge darunter veröffentlich, aber ich muss sagen, dass dieses Lizenzmodell sehr vertrauenserweckend aussieht, da es die wichtigen Dinge auf den Punkt bringt und auch für Laien verständlich macht.

So, nachdem ich ziemlich lange herumgesucht habe und auch bereits ein wenig an diversen Modulen rumgeschraubt habe, habe ich jetzt doch noch die "fast" perfekte Lösung gefunden, welche ich hier kurz beschreiben will.

Ausgangslage:

Ziel ist es, Beiträge intern verlinken zu können. Oft kommt es vor, dass ein Blogeintrag als Serie geschrieben wird. Wie leitet man jetzt den Benutzer am Besten zu nächsten Teil der Blogserie weiter? Ja, von Hand den Link einfügen, doch das bringt zum Problem, dass auf dem alten Eintrag kein Link vorhanden ist. Daher muss man die ganzen Beiträge zusammensuchen, findet diese sowieso nicht mehr und zudem ist es einfach viel zu aufwändig. -> Ein Modul muss her.

Anforderungen:

1. Einfaches einfügen von internen Links, am Besten über ein AJAX Eingabefeld, so dass man die Beiträge gut suchen kann.
2. Bi-direktionale links
3. Sekundär: Eine Checkbox welche erlaubt zu spezifizieren, ob der Link Bidirektional oder unidirektional ist.

Umsetzung:

Folgende Module werden dafür benötigt.

• CCK
• nodereference (im CCK mit dabei)
• nodeferrer

Alle Module installieren. Im gewünschten Inhaltstyp ein CCK Feld nodereference hinzufügen und am Besten auf multiple value setzen. Bei Widget würde ich "Autocomplete Text Field" setzen. Ist ein bisschen bequemer. Natürlich geht auch ein Dropdown. Dann müssen noch alle Inhaltstypen selektiert werden, welche im Widget dargestellt werden. Bei den advanced settings habe ich nichts eingestellt. Oky, jetzt ist schon mal ein unidirektionaler Link möglich.

Um die Bidirektionalen Links zu ermöglichen sind noch folgende Schritte notwendig: Dem Inhaltstypen wieder ein Feld hinzufügen, und zwar bei Node Referrers und dort auf Read only. Dann müssen wieder die Inhaltstypen selektiert werden, welche überhaupt in Frage kommen (wahrscheinlich am Besten die, welche bereits beim Node Reference gewählt wurden und das Node Reference Field. Hier sollte jetzt lediglich eines sein, aber falls mehrere gebraucht werden, kann hier sozusagen das Feld, welches für die Verknüpfung gebraucht werden soll ausgewählt werden.

Zum Schluss kann man noch angeben, ob die Anzahl beschränkt werden soll. Ich habe dies bei mir einfach auf 0 gelassen. So, das wäre es dann schon.

Vorteile:

Es stellt sich natürlich die Frage, was für Vorteile das bringt. Viele:

1. Internes Wissensmanagement. Man findet die eigenen Sachen leichter.
2. Der Benutzer wird länger auf der Seite gehalten. Offensichtlich hat er den aktuellen Artikel interessant gefunden, es ist also Wahrscheinlich, dass er einen verwandten Artikel auch lesen wird.
3. Bessere Ranking bei Google. Obwohl ich keine SEO Experte bin, glaube ich, dass ein intensives internes Linking ein besseres Ranking bei Google gibt.
4. Weniger Arbeit, beim Erstellen von internen Links, d.h. mehr Zeit um Blogeinträge zu schreiben.

Ich denke, das sind doch eingie Gute Gründe, welche dafür sprechen. Feature Nummer 3 (Checkbox, ob ein Bidrektionaler Link erstellt werden kann, ist leider nicht möglich -> kommt vielleicht aber noch dazu?). Aber alles in Allem. Drupal bietet auch hier mal wieder eine sehr saubere Lösung. Es lebe Drupal.

Falls dieser Beitrag nützlich war, bitte ein Rating abgeben, damit andere Besucher nützliche Artikel auf finden.

Eigentlich habe ich schon beim "Pager mit AJAX" gedacht, dass es sich um so ein Modul handelt, aber das war wohl nicht so. Jetzt habe ich aber gefunden, was ich eigentlich schon lange gesucht habe: Dynamic Views. Und es gibt dazu auch eine super Demo (ober der Szenenfilter -> Pager ist normal). Das macht das Ganze natürlich schon viel angenehmer und würde auch die Möglichkeit erlauben Filter und alles mögliche so zu machen. Kommt ganz nach oben auf meine "Ausprobierliste".

Nachdem das erste Treffen für Schweizer Drupalianer von einem guten halben Jahr gescheitert ist, findet es jetzt doch statt:

OpenSource Software ist nicht gleich Software wo man alles machen kann. Auch hier gibt es entsprechende Lizenzen und Bedingungen, welche eingehalten werden müssen, wobei diese zugegebener Massen ein bisschen offener sind. In diesem kleinen Artikel möchte ich mich mit den beiden Lizenzarten rund um Drupal befassen. Das sind vor allem GNU General Public License (GPL) und Creative Common (CC). Ich möchte zudem an dieser Stelle auch noch erwähnen, dass ich kein Anwalt bin und dass dies keine Rechtsberatung ist! Falls jemand Fehler findet oder Ergänzungen zu machen hat, soll er doch freundlicherweise das Kommentarfeld benutzen.

GNU General Public License

Ist wohl die am meist benutzte rund um Drupal. Drupal Core untersteht der GPL Version 2. Neuerdings gibt es auch noch eine Version 3. Die GPL Version 2 räumt dem Entwickler folgende "Freiheiten" ein (aus Wikipedia):

1. die Freiheit, ein Programm für jeden Zweck zu nutzen
2. die Freiheit, Kopien des Programms umsonst oder gegen eine Gebühr zu verteilen (wobei der Quellcode mitverteilt werden oder öffentlich verfügbar sein muss)
3. die Freiheit, ein Programm den eigenen Bedürfnissen entsprechend zu ändern (die Verfügbarkeit des Quellcodes ist ja garantiert).
4. die Freiheit, veränderte Versionen des Programms beliebig zu verteilen (wobei der Quellcode mitverteilt werden oder öffentlich verfügbar sein muss)

Software unter der GPL Lizenz darf also für jeden Zweck benutzt werden, Kommerziell, NGO, Privat, Alles. Auch darf der Code bliebig weiterverteilt bzw. verändert werden.

Es gibt jedoch auch Einschränkungen:

1. Werden veränderungen gemacht, müssen diese klar ausgewiesen werden (Datum und Author).
2. Änderunge müssen unter der gleichen Lizenz stehen. Dies führt oftmals dazu, dass in Drupal Editoren und Skripte von einer anderen Seite runtergeladen werden müssen, da diese unter einer anderen Lizenz stehen. Mix geht nicht für den Vertrieb -> für den Antwender natürlich schon.
3. Es dürfen keine Lizenzgebühren anfallen.

Oftmals taucht die Frage auf, ob und wie man mit Drupal Geld verdienen kann, daher: Lizenzgebühren sind nicht erlaubt. Lizenzgebühren beziehen sich jedoch ausschliesslich auf die eigentlich Nutzung einer Software. Dies bezieht sich jedoch nicht auf die Entwicklung von neuen Modulen, Installation und Konfiguration. Hierbei handelt es sich um eine Tätigkeit, welche bezahlt wird und nicht um das Produkt selbst.

Wird also ein neues Modul entwickelt, so kann dies dem Kunden in Rechnung gestellt werden (für die Arbeit), es kann jedoch nciht später als Software verkauft werden -> also z.B. über einen Shop auf der eigenen Seite. Zudem muss das neu Entwickelte Modul unter der gleichen Lizenz wie Drupal stehen.

Sie dürfen für den eigentlichen Kopiervorgang eine Gebühr verlangen. Wenn Sie es wünschen, dürfen Sie auch gegen Entgelt eine Garantie für das Programm anbieten.

Jedoch keine Lizenzgebühren!

Themes, welche von irgendwelchen OpenSource Plattformen portiert werden, beinhalten oftmals ein kleines "Designed by xyz". Es stellt sich also die Frage, ob dieser Vermerk drin bleiben muss, oder ob er entfernt werden darf. Meiner Meinung nach, muss dieser Verweis drin bleiben:

§1. Sie dürfen auf beliebigen Medien unveränderte Kopien des Quelltextes des Programms, wie sie ihn erhalten haben, anfertigen und verbreiten. Voraussetzung hierfür ist, daß Sie mit jeder Kopie einen entsprechenden Copyright-Vermerk sowie einen Haftungsausschluß veröffentlichen, alle Vermerke, die sich auf diese Lizenz und das Fehlen einer Garantie beziehen, unverändert lassen und desweiteren allen anderen Empfängern des Programms zusammen mit dem Programm eine Kopie dieser Lizenz zukommen lassen.

Im Zweifelsfall kann man immer noch den Author fragen. Im Nächsten Teil werde ich mich den Creative Common Lizenzen widmen. Diese sind meiner Meinung nach noch ein bisschen einfacher, da es hier vor allem schöne Symbole gibt 🙂

Links:

• GPL in Deutsch
• Wikipedia

Durch Zufall bin ich auf diese Seite gestossen. Es ist eine Sammlung und besteht Momentan aus 45 Screencasts für Drupal, die Themen sind:

• Installation
• Node System
• Block System
• Roles und Permission
• Navigation, menu
• Themeing
• CCK & Views
• Actions and Workflows
• und noch ein paar mehr

Super Übersicht. -> Hier geht es zu den Screencasts.

Drupal ist manchmal ein bisschen langsam. Mir wird das immer wieder bewusst, wenn ich an einen von meinen statischen Seiten arbeite. Da macht es einfach pop und dann ist die Seite da. Bei Drupal ist das ein bisschen anders. Wenn eine Seite geladen wird, laufen einige andere Prozesse im Hintergrund ab: Inhalt aus der Datenbank holen, hooks abfragen, Seite zusammenbauen, und dabei die benötigten CSS und Javascript Dateien laden. Hier ist auch bereits ein erster wunder Punkt.

Wenn eine Datei (css und js) geladen wird, dann muss der Browser jedes mal eine entsprechende Anfrage an den Server stellen, worauf der Server dem Browser die angefragte Datei zur Verfügung stellt. Wenn man 10 Javascript Dateien hat, kann das schon zu ein Verzögerungen führen, denn es geht nicht nur um die reine Downloadzeit, sondern eben auch noch um die Zeit für die eigentliche Anfrage.

Für CSS gibt es schon lange einen Aggregator, dieser ist Standardmässig dabei und kann unter "admin/settings/performance" konfiguriert werden (entweder an oder aus). Seit einigen Tagen gibt es auch einen Javascript Aggregator: Dieser fasst alle Javascript Dateien in eine Datei zusammen, wie das bei den CSS Dateien schon lange ging.

Einstieg:

Folgenden Code Schnippsel in der Datei page.tpl.php einfügen:

Dieser Schnippsel muss VOR dem Einfügen der Scripts kommen, also:

Jetzt einfach das Modul installieren und sodann erscheinen neue Optionen unter "admin/settings/performance" [Bild 1].

• Aggregate Javascript: Alle .js Dateien werden zu einer Datei zusammengf
• Optimize JavaScript files: Alle / / Kommentare werden entfernt.

Falls jemand am Entwickeln ist und Sachen mit Javascript macht, so würde ich empfehlen, diese Optionen zu deaktivieren (sowohl CSS Aggregator als auch Javascript Aggregator), da Fehler viel einfacher zu finden sind. Die Bugs von denen ich in meinem ersten Post bezüglich dem Javascript Aggregator berichtet habe, sind mittlerweile behoben, und es sollte stabil funktionieren.

Von der Performance her, ist es doch merklich spürbar:

• 3.7 Sekunden Ladezeit mit Javascript Aggregator und CSS Aggregator
• 4.3 Sekunden Ladezeit ohne Javascript Aggregator, aber mit CSS Aggregator
•  6.5 Sekunden Ladezeit ohne Javascript Aggregator und CSS Aggregator

 Diese beiden Module sind einfache Wege, um die Performance zu verbessern, ohne sich in irgendwelche komplizierte Servergeschichten vertiefen zu müssen.

Da sich immer wieder Leute beklagen, dass es für Drupal nicht genügend gute Themes gibt, habe ich mich ein wenig damit beschäftigt. Ich muss sagen, die Leute haben zum Teil recht, aber nur beklagen nützt ja auch nicht, daher hier eine Liste mit Open Source HTML Vorlagen, welche nur darauf warten, endlich portiert zu werden:

• oswd.org
• openwebdesign.org
• opendesign.org
• freecsstemplats.org
• solucija.com

oswd.org scheint irgendwie tot zu sein. Dort gab es schon seit einer Ewigkeit nichts neues mehr. openwebdesign.org hat ein furchtbares Design, aber sonst ein paar brauchbare Vorlagen und opendesign.org sieht sehr hübsch aus und scheint auch gute Vorlagen zu haben.

Besonders die Startseite beschäftigt mich und ich bin zum Schluss gekommen, dass man hier out-of-the-box nichts hübsches machen kann. Hier muss man einfach mit einer View dahinter um entsprechend hübsche Effekte hinzubekommen, aber am Theme kann das nicht liegen. Aber es gibt ja hier viele verschiedene Views, welche uns Developper tatkräftig unterstützen. Leider geschieht dies viel zu wenig oft (ich gehörte auch dazu, aber das werde ich noch ändern).

Gibt es eine möglichkeit Views einem Theme beizulegen?

Endlich, endlich habe ich mich durchgerungen und mir mal ganz schnell die Version 6 von Drupal installiert. Ich bin echt begeistert. Ich habe zwar nur 5 Minuten rumgespielt, aber D6 ist cool:

• Hübsch, hübsch sieht das Installationsinterface aus -> Die Gutzeichen am linken Rand gefallen mir besonders.
• Administrator wird gleich mit der Installation erzeugt.
• Die neuen Module im Core haben mich beeindruckt.
• OpenID Integration ist cool. Habe es ganz kurz mit meinem www.myopenid.com Account ausprobiert und hat super geklappt.
• Bei den Blöcken das Drag'n'Drop ist Balsam 🙂
• Menu Erstellung war in D5 echt mühsam -> vor allem gab es diese riesen lange Liste -> Es lebe Drupal 6!
• Triggers und Actions sehen ganz nützlich aus, leider noch nicht im Detail angeschaut.

Jo, das war so was mir in den ersten 5 Minuten aufgefallen ist. Auf den ersten Blick hat sich eigentlich nicht viel geändert, aber in den Detail erlebt man so oft ein kleines Freudelein. Schön, schön… jetzt müssen nur noch die Module portiert werden, und dann werde ich meine erste Drupal 6 Seite launchen, vielleicht schon in ein paar Wochen 🙂