Kategorie: Uncategorized

JQuery ist in jeder Drupal Installation vorhanden und ist eine sehr mächtige Bibliothek… ich persönlich habe vor langer Zeit auch mal mit prototyp gemacht, arbeite jedoch viel lieber mit Jquery. Man kann echt coole Sachen machen 🙂

Leider kann es zu Performanceproblemen führen, wenn zu viele Funktionen an Objekte gebunden werden. Die neuste JQueryversion ist ein Schritt, die Performance zu erhöhen, doch darauf hat man mit Drupal nur wenig Einfluss (ausser man Entwickelt für Drupal 6).

Daher ein kleiner Tipp:

Wenn Funktionen an ids oder Klassen gebunden werden, wo immer möglich IDs verwenden:

Jetzt hat man hier grundsätzlich zwei Möglichkeiten:


$('.test').click(function(){
alert('hallo welt');
});

oder

$('#header').click(function(){
alert('hallo welt');
});


Falls möglich so ist die Version über die ID auf jeden Fall vorzuziehen. Die ID kann direkt angesprungen werden, wogegen bei der Klasse das Dokumente geparst werden muss.

Die neue Seite Drupal Module ist gestartet. Die Seite enhält alle Drupal Module zum Download, stellt jedoch die Möglichkeit bereit, Reviews und Bewertungen zu modulen zu geben.

DrupalModules.com is a community powered rating and review service focused on helping you find the Drupal modules you need for your project. In addition to ratings and reviews, you'll find a complete module catalog, top module lists, a related module finder, and more!

Ich muss ehrlich sagen, dass ich bezüglich numerischen Bewertungen eher skeptisch bin. Problem ist: Es ist sehr subjektiv. Problematisch kann zudem auch sein, dass lediglich extrem zufriedene bzw. extrem unzufriedene Leute eine Stimme abgeben.

Nichts desto trotz finde ich die Seite super, da sie doch ein bisschen schneller läuft als drupal.org. An dieser Stelle vielleicht auch die Frage, ob dies bewusst gemacht wurde, um die Last auf Drupal.org zu reduzieren?

Ich denke, das könnte noch eine durchaus interessante .po (Übersetzungsdatei) für Drupal werden. Ich bin gerade dran, eine kleine E-Commerce Seite einzurichten. Da sind folgende Module drin:

• Administration Menu
• CCK
• Content Template
• Fieldgroup
• Image
• Node Reference
• Node Referrer
• Option Widgets
• Text
• Drupal Core Module (sind eigentlich schon übersetzt)
• Tables API
• FCKEditor
• Taxonomy Manger
• Thickbox
• Token
• uBrowser
• Cart (ubercart)
• Order
• Product
• Store
• Catalogue
• Payment
• Shipping Quotes
• Flaterate
• Paypal
• Views
• Views UI
• Workflow-ng

Das werden wohl so die wichtigsten Module sein, um einen E-Shop zu bauen. Daher werden wohl auch immer wieder Übersetzungen gebraucht. Ich bin wie gesagt immer ein wenig am Übersetzen und bin bis jetzt bei 86% angelangt… 🙂 immerhin schon etwas. Besonders bei Views und CCK gibt es noch viel zu machen. Meine Vision ist, dass man, wenn man eine E-Commerceseite mit Ubercart einrichtet, einfach noch die po Datei importieren muss und schon hat meine eine Deutsche Übersetzungen.

Das war nämlich eines meiner Probleme bei Joomla. Da war das Backend nur Englisch und ein Gemixe und es war nich schön. Mir ist es egal, aber meine Kunden mögen es oftmals schon lieber in Deutsch.

Falls jemand interessiert ist… hier melden, oder gleich runterladen und übersetzen… Datei dann möglichst schnell wieder an mich schicken, damit es keine Überschneidungen gibt.

[file:unlike2.de.rar=Download po Datei]

Drupal ist ein CMS. Das heisst, eine Seite wird dynamisch mit Daten aus einer Datenbank generiert. Der traditionalle oder statische Weg zum Erstellen einer Seite verläuft meistens wie folgt: Pro Seite wird eine html Datei erstellt und diese wird mit Inhalt gefüllt. Dann wird das ganze auf einen Webserver hochgeladen und die Leute können sich die Sachen anschauen.

Ein CMS verfolgt einen anderen Ansatz: Das Grundgerüst wird erstellt: Layout und Verhalten. Inhalt wird dann direkt via Webinterface erstellt und in einer Datenbank gespeichert. Es gibt also keine lokalen Dateien.

Plötzlich schmiert der Server ab und die Daten sind weg. Bei der statischen Seite kann man ganz einfach die Seiten wieder hochladen, falls jedoch die Datenbank gelöscht ist, dann ist sie gelöscht… Daher empfiehlt sich ein regelmässiges Backup der Datenbank.

Dazu gibt es ein sehr praktisch Modul: Backup. Das Modul hat jedoch noch einen kleinen Fehler, es ist standardmässig nicht in einen Cronjob einbinden. Daher können Backups nur manuell gemacht werden -> das vergisst man sowieso immer und wenn man dann mal ein Backup braucht, dann hat man sicher keines. Daher patched man das Modul am Besten noch. Der nötige Code. Mit dem Patch wird dann pro Cronjob ein Backup gemacht. Backups werden 8 Tage gespeichert und danach wieder gelöscht.

An dieser Stelle noch eine Warnung: In den Kommentaren wurde über Inkonsistenz der Datenbank diskutiert. Ich habe es nicht ins Detail nachverfolgt, aber könnte schon etwas haben. Das Problem ist, dass die Seite nicht im Wartungsmodus ist. Es könnte also vorkommen, dass die DB gespeichert wird und dass während dem Backup neue Einträge in die DB gemacht werden. Ist wohl eher für High Traffic Seiten ein Problem.

Geschafft. Soeben habe ich mein erstes Modul ins Drupal CVS Repository eingefügt. War gar nicht so einfach, aber auch nicht so kompliziert. Ich habe dazu einfach das Tutorial unter http://drupal.org/node/188985 befolgt. Hat wunderbar geklappt.

Das Modul findet sich unter http://drupal.org/project/comment_og.

Was tut es? Das Modul integriert Kommentare in die OGs. Folgendes Szenario ist dann möglich:

Besucher A gehört zu Gruppe 1 und 2. Besucher B Gehört zu Gruppe 2 und 3. Besucher A schreibt einen Kommentar zu Node x und setzt die Sichtbarkeit für Gruppe 1. Kommt Besucher B vorbei so sieht er keinen Kommentar. Besucher B schreibt einen Kommentar zu Node y und setzt die Sichtbarkeit auf Public. Besucher A kann den lesen. Besucher A geht auf Node z und schreibt einen Kommentar mit Sichtbarkeit für Gruppe 2. Besucher B kommt auf Node z und kann den Kommentar von A lesen.

Ziemlich simpel. Einziger Wehrmutstropfen: Das Kommentarmodul muss zuerst gepatched werden…

[inline:screenshot_comment_og.jpg=Screenshot Comment OG]

Dieser Post ist doch ziemlich in die Jahre gekommen. Die Informationen müssen nicht mehr zwingend stimmen.

Drupal hat ein ziemlich cooles Multisprachen System: Locale. Bis anhin habe ich es gar nicht wirklich geschätzt. Ich habe mich zwar aufgeregt, wenn etwas in Englisch ist und der Kunde etwas in Deutsch wollte, aber ich habe mich nie darum bemüht der Sache auf den Grund zu gehen. Das hat sich jetzt geändert.

Voraussetzungen zum Übersetzen

• Locale Module aktivieren (aus Drupal Core)
• Einen po Editor z.B. poedit

So, jetzt geht man wie folgt vor:

• «admin/settings/locale» ist die Übersicht über die vorhandenen Sprachen. Dabei handelt es sich lediglich um Sprachen des Interfaces und nicht von Inhalt! Hat man Deutsch installiert, so sieht es wie folgt aus:

Hat man Deutsch noch nicht installiert, so muss dies noch gemacht werden. Dazu einfach auf Sprache hinzufügen und dann dort die entsprechende Sprache auswählen. Jetzt ist jedoch noch keine Sprachdatei integriert. Diese muss jetzt via import geholt werden. Diese kann auf http://drupal.org/project/Translations geholt werden. Das Packet runterladen und dann über import diese .po Datei importieren.

Unvollständige Übersetzung:

Leider sind viele Module noch nicht vollständig übersetzt. Für mich persönlich spielt das eigentlich keine so grosse Rolle, aber für Kunden sollte das Front-end schon komplett Deutsch sein, wenn es sich um eine Deutsche Seite handelt. Aber das geht ganz einfach:

Zeichenkette exportieren anklicken.

Jetzt kann man sich eine vollständige .po Datei der eigenen Seite runterladen. Dort werden dann alle Strings, welche noch nicht übersetzt sind markiert. Jetzt kann diese von Hand übersetzt werden und dann über den importer wieder eingepflegt werden. Es ist wirklich ganz trivial.

Ich habe mal ein wenig übersetzt und dabei ein bisschen Views, CCK und Thickbox übersetzt. Dazu ist auch noch einiges vom Ubercart an Übersetzung drin, welches in der Standard Deutsch .po Datei nicht drin ist.

Einfach [file:unlike2.de.rar=Datei] runterladen und auf deiner Seite über den Importer importieren und schon hast du ein bisschen mehr Deutsch drin. Wer aktiv an der Deutschen Übersetzung mithelfen will, kann sich auf dem deutschen Übersetzungserver anmelden (http://kkaefer.com/). Ich weiss noch nicht genau, wie das läuft, aber werde mich wohl dort mal ein wenig schlau machen.

Das i18n Modul ist sehr mächtig, es hat jedoch meiner Meinung auch noch ein paar Macken. Ich habe vor einiger Zeit ein paar Kleinigkeiten in einer bestehenden Seite mit Übersetzung gebastelt und fand einige Dinge ein bisschen verwirrend.

In Drupal 6 soll es ja sowiel ich weiss zum Teil im Core drin sein. Da freue ich mich 🙂

Das i18n Modul besteht grundsätzlich aus 2 Teilen:

Internationalization Modul und translation Modul und dann gibt es auch noch das locale Modul, was jedoch im Core drin ist (auf jeden Fall in der 5er Version). Die Einsatzgebiete dieser Module sind klar abgegränzt:

Local: Übersetzung des Interfaces. So kann man Drupal in Deutsch, Englisch, Französisch usw haben. Dies hat jedoch noch nichts mit dem eigentlich Inhalt zu tun!

Internationalization: Ermöglicht mehrsprachige Inhalte. Wenn ein Node erstellt wird, so kann dieser einer bestimmten Sprache zugeordnet werden.

Translation: Wenn man eine Firmenseite hat, so will man einen Inhalt in mehrere Sprachen haben. Zudem will man zwischen den verschiedenen Sprachen hin und her Switchen. Das Translation Modul verknüpft Nodes in verschiedenen Sprachen miteinander und unterstützt den Admin mit dem Übersetzungsworkflow. Zum Beispiel: node 324 ist ein Inhalt in Deutsch. Jetzt übersetze ich diesen Node einige Tage später -> (wird zum node 354).  Je nach dem in welcher Sprache ich mich befinde wird entweder 324 oder 354 angezeigt.

Allerdings habe ich ein paar Problemchen gehabt:

1. Ich hatte einmal ein wenig mit einer zweisprachigen Seite gewerkelt. Da war jedoch das Problem, dass wenn man von einer Sprache auf die andere wechselte, dass man auf dem gleichen Node sitzen blieb -> sprich, die Sprache des Inhalts blieb in der alten Sprache, da man nachwievor auf node/xxx blieb.

2. "Dann wurden diese Terms noch gegenseitig als Übersetzung gekennzeichnet." Wie machst du das? 

niebegeg.net hat freundlicherweise eine Antwort darauf parat 🙂 Danke an dieser Stelle nochmals.

Antwort:

Zu 1.: Die i18N-Module bringen zwei "Language Switcher"-Blöcke mit, der eine heißt ebenso, der andere heißt "Translations" bzw. "Übersetzungen" und ist aus dem translations.module. Der arbeitet kontext-sensitiv und generiert korrekte Links auf die zugeordnete Seite in der anderen Sprache. Wenn das Modul aktiviert ist und man zwei Beiträge als "Translation" zueinander definiert hat, dann klappt das Umschalten und die Anzeige wechselt von node/123 auf node/124 (Beispiel ). Außerdem bietet das translations.module an, im Fußbereich (im Links-Bereich?) eines Beitrags den Link zur Übersetzung des Beitrags einzufügen. Das kann man auch abschalten.

Zu 2.: Auch mit dem translations.module: Im Adminbereich findest Du in admin/content/taxonomy im Term Listing zu einem Vokabular auch den Tab "Translations". Dort kannst Du jeweils Begriffe aus beiden Sprachen als Übersetzung gegenüberstellen. Zuvor muss man jedoch zwei Begriffe jeweils als Begriff der einen und der anderen Sprache definieren, zum beispiel den Begriff "Sichtung" als "deutsch" und "Review" als "englisch". Im Tab "Translations" werden nur die Terms angezeigt, die als sprachabhängig markiert sind.
Allerdings hatte das Ganze bei mir nur Einfluss auf die Vorschlagswerte beim Freetagging: es wurden nur Werte ohne Sprachkennzeichnung und in der aktuellen Sprache vorgeschlagen. Die Tags wurden beim Umsachalten der Sprache an einem vorhandene Artikel nicht übersetzt :-/

Dies hat somit auch meine Meinung vom i18n Modul massiv verbessert. Es ist wirklich ein geniales Modul…

Das Book Modul in Drupal 5 hat einige Einschränkungen, welche im Outline Module behoben wurden. So kann das Outline Modul verschiedene Inhaltstypen integrieren und es gibt zudem ein paar zusätzliche Features.

Das Problem (sowohl beim Book als auch beim Outline) ist jedoch der Navigationsblock. Dieser ist sehr statisch. Es ist nicht möglich, einfach nur ein wenig im Inhaltsverzeichnis herumzuschnüffeln, ohne gleich immer die ganze Seite neu laden zu müssen -> sehr mühsam. Daher dieses Modul, welches dies vereinfacht.

Im Moment ist es noch in Betaphase und ich hoffe, dass ich endlich mal mit dem Outlinemaintainer in Kontakt treten kann, damit das Modul dort ins Projekt hinzugefügt werden kann.

Eine Demo ist unter: http://www.mwst-institut.ch/node/1777 zu finden. Module Downloaden.

Das Drupal Themeingsystem ist recht einfach aufgebaut, aber man muss es einfach wissen 😉

'hallo welt'));}

function theme_mymodule_ausgabe($array){
//hier kann etwas gemacht werden. also das ganze in html verpacken.
}
?>

Der Vorteil dabei ist, dass man diese Theme Funktion überschreiben lässt. Zudem ist dies eine erster Schritt in Richtung Trennung von Logik und Präsentation -> Model View Controler (MVC)