Jumi für Joomla 1.6.x

Jumi ist ein Modul, welches es ermöglicht, auch Code in einen Artikel einzufügen, der sonst vom Joomla eigenen Editor nach dem abspeichern „weggeschnitten“ wird. Man kann mit Jumi auch ein Modul mit Code (PHP, HTML, JAVA…) erstellen, dass dann an beliebigen Modulpositionen erscheint.

Für Joomla 1.6 wurde die Jumiversion schon angepasst und lässt sich sehr einfach über die Erweiterungen installieren. Beim Erstellen des Modules und einfügen des notwendigen Quelltextes in das Jumi Codefenster scheint noch alles glatt zu laufen. Klickt man nun aber auf speichern, verschwindet alles bis auf einen eventuell vorhandenen Klartext aus dem Codefenster.

Jumi macht also genau das nicht, wofür es eigentlich da ist. Warum? Es handelt sich hierbei eventuell um einen Bug.

Google beförderte mich schließlich auf http://edo.webmaster.am/forum/jumi/joomla-jumi-module-problem-t107-10.html. Hier wird ein Workaround angeboten. In der Datei /modules/mod_jumi/mod_jumi.xml ist  bei Zeile 35 folgendes zu ergänzen (fett):

<field name=“code_written“ type=“textarea“ filter=“raw“ default=““ label=“Code written“ description=“PARAMCODEWRITTEN“ cols=“60″ rows=“17″ />

Danach Jumi erneut aufrufen, Quelltext einfügen und speichern. Bei mir hats jedenfalls funktioniert 🙂

Quelle Jumi: http://extensions.joomla.org/

 

Update: Von Joomla 1.5.22 auf Joomla 1.6

Sachlage: Was hat es mit der Version 1.6 auf sich

Nach meinem letzten gescheiterten Versuch einen Joomla 1.0.x Webauftritt auf 1.5.22 zu bringen, hoffte ich, dass dies zumindest beim Versionssprung von 1.5.x auf 1.6.x einfacher gestaltet wird. Kurz gesagt: Ich hoffte auf ein „einfaches“ Update, wie man es auch von WordPress kennt.

Wie ich nun aber mehrfach bereits gelesen habe, ist wieder nix mit update. Nein, es ist wieder eine Migration nötig. Was heißt das nun? Tja, wieder kann man bangen, ob das Design (Template) übernommen wird, weiter gehts dann mit diversen Plugins und Modulen usw.

Ich finde es sehr schade, dass es nicht möglich ist, ein unproblematisches Update zu realisieren. Vielleicht mag es an der Komplexität von Joomla liegen, dass es eben nicht „einfach mal so“ läuft und man die Installation auf den neuesten Stand bringen kann.

Ich frage mich gerade auch was nun dem Webmaster übrig bleibt? Vielleicht bleibe ich auf 1.5.22, was mir natürlich im Moment ein herumgemurkste erspart? Im Endeffekt bleibt es so oder so egal! Irgendwann wird man den Schritt tun müssen, wenn man eine gewartete Joomlainstallation betreiben und möglichst alle Securityfixes zeitnah einspielen will.

Joomla 1.6 wird es 6 Monate lang geben, danach erscheint die Version 1.7 die ebenfalls nur 6 Monate „aktiv“ sein wird. Nach dieser Zeit, also ungefähr Anfang des Jahres 2012 kommt dann die Version 1.8 heraus. Dieses Release wird – wie Joomla 1.5 – ein Long Term Release sein. D.h. diese Version wird länger die „aktuelle“ Version von Joomla bleiben.

Bis zum Release von Joomla 1.8 wird Joomla 1.5.x noch gewartet. D.h. nun auch, dass man als 1.5er User / Admin bis Anfang nächsten Jahres (2012) noch auf 1.5.22 „bauen“ kann.

Templates von 1.5

Templates von Joomla 1.5 laufen unter 1.6 definitiv NICHT mehr, ohne größere Anpassungen. Hierbei sollte jedoch erwähnt werden, dass es auch aufs Template ankommt, wieviel Arbeit es ist, es auf 1.6 umzubauen. Soviel ich jetzt (nach einigem testen und fragen im IRC) sagen kann, gibt es vor allem bei den Modulpositionen Unterschiede in der Benennung zwischen Templates der Version 1.5 und 1.6.

Templates können ausserdem nicht mehr per FTP überspielt werden, sie müssen über das „Menü Erweiterungen / Erweiterungen installieren“ als ZIP Paket eingespielt werden. Wichtig hierbei ist, dass die Datei TemplateDetails.xml angepasst wird, wenn man ein Template der Jommlaversion 1.5 in Joomla 1.6 importieren will. Die Bennenung der Modulpositionen in der index.php des Template muss mit der Bennenung der Modulpositionen der Datei TemplateDetail.xml identisch sein! Wenn der Import des Templates erfolgreich war, gilt es noch die im Template verwendeten Modulpositionen zu prüfen. Wird einem Modul (zb. Main Menu) eine falsche Position zugeordnet, erscheint es NICHT auf der Website!

Weitere Infos dazu auf:

Modulpositionen Joomla 1.6.x


Testinstallation

Testhalber installiere ich Joomla 1.5.22 und stelle mir als Aufgabe, diese Installation auf Joomla 1.6.1 upzudaten. Dank der einfachen Installationsroutine läuft Joomla 1.5.22 nach ein paar Minuten einwandfrei.

Eine weitere Recherche im Internet brachte schließlich zu Tage, dass man das Migrationstool Jupgrade verwenden soll, um in den Genuß der neuen Joomlaversion zu kommen. Jupgrade wird als ZIP Datei heruntergeladen und über den Joomlainstaller (Erweiterungen >> Installieren / Deinstallieren und anschließender Auswahl der heruntergeladenen Zipdatei) installiert.

Gut!

Im Menü Komponenten gibt es nun Jupgrade.

Unter Erweiterungen / Plugins soll man anschließend das Mootools Upgrade Plugin (genauer System Mootools-Upgrade) aktivieren, was ich auch mache.

Ich starte Jupgrade, indem ich es unter Komponenten / Jupgrade auswähle:

Ok, klicken wir mal auf Upgrade starten… und klatsch… Fehlermeldung: 406:cURL not loaded

Google sagt mir: http://www.php.net/manual/en/book.curl.php

Offenbar ist bei meiner lokalen Installation des XAMP (zwangsweise momentan unter Windows) Curl für PHP nicht aktiv. Das kontrolliere ich, indem ich mir die Datei php.ini genauer anschaue und CURL suche.

Gesucht gefunden! Der Eintrag extension=php_curl.dll ist mittels vorgestelltem ; auskommentiert. Also weg mit dem ; und restart des Apache Webserver… Erneut rufe ich Jupgrade auf und klicke auf Upgrade starten und:

Es läuft. Joomla 1.6 wird heruntergeladen…  tja… und obwohl der Download eigentlich fertig sein sollte 8021058 von 8021058 bytes heruntergeladen, steht die Sache still…

Vielleicht liegt es an meinen WAMP Servereinstellungen. Wie ich zufällig sehe, gibts es – nachdem man Jupgrade unter Komponenten / Jupgrade gewählt hat – rechts einen Menüeintrag „Einstellungen“ für Jupgrade. Dort aktiviere ich „Download überspringen“, da das Programm ja meiner Meinung nach den Download bereits erfolgreich abgeschlossen hat und speichere das Ganze.

Ich starte Jupgrade nochmals, der Download wird übersprungen und es geht mit dem Entpacken weiter… und ja, es läuft erfolgreich durch!

Aha, anscheinend hat Jupgrade die Joomla 1.6 Version in den Ordner /jupgrade gepackt. Der URL für die Seite lautet nämlich: http://localhost/joomla15/jupgrade/ bzw. für die Adminseite: http://localhost/joomla15/jupgrade/administrator/

Schauen wir mal, ob die Seite überhaupt funktioniert:

Ja, es hat geklappt. Wie schaut eigentlich die Adminseite aus (Backend) und funktioniert die überhaupt?

Ja, sie funktioniert und es wurde sogar der Adminuser (vor allem das Kennwort übernommen).

Fazit

Wenn man als Ausgangsbasis eine „reine“ Joomla 1.5.22 Version verwendet, funktioniert die Migration mit Hilfe von Jupgrade recht einfach. Es bleibt natürlich abzuwarten, wie sich das Tool verhält, wenn es sich um eine Joomla 1.5.22 Webpräsenz handelt, die im Produktiveinsatz ist. Ich denke, dass vor allem  Webauftritte, bei denen viele Plugins und Module verwendet werden, die nicht zum Joomla – Core gehören, Probleme bei der Migration haben werden, solange es diverse Plugins und Module nicht für die 1.6er Version von Joomla gibt.

Mein nächster Versuch wird dann wohl der Einsatz von Jupgrade in Verbindung mit einer aktiven Webpräsenz – Joomla 1.5.22 – (die ich mir in meine Testumgebung „hole“) sein.

Ich rate allen Migrationswilligen 🙂 dazu, immer vorher in einer Testumgebung zu üben und wenn es dann ans Eingemachte geht (Produktivserver) ein Backup zu ziehen. (Datenbank  und Dateistruktur / Dateien)

Update: Nach dem Installieren meiner „Produktivwebsite“ in einer Testumgebung kann ich mittlerweile bestätigen, dass Templates der Version 1.5 nicht mit Joomla 1.6 kompatibel sind. Zum Einsatz kam auf Joomla 1.5 das Beez Template, welches etwas modifiziert wurde. Selbst nach löschen der Overrides, gibt es hier Probleme mit den Menüs. Dies wird dadurch hervorgerufen, dass die Modulpositionen unter Joomla 1.6 umbenannt wurden und ich Anfangs das Template einfach in den Template Ordner kopiert habe, was ja -wie oben erwähnt – unter Joomla 1.6 nicht mehr funktioniert.

Auch mit der Anpassung der TemplateDetails.xml + Erstellung der ZIP und ordnungsgemäßer Installation des Templates über die Erweiterungen (Joomla 1.6), hatte ich kein Glück. Die Menüs blieben weiter verschwunden.

Nach der Prüfung der Modulpositionen und ggf. Neuzuordnung der Modulpositionen erscheinen die Menüs. Es ist aber in jedem Fall mehr oder weniger Handarbeit zu leisten, um den Webauftreitt auf die Version 1.6 umzubauen.

Als Betreuer eines Joomla 1.5 Webauftrittes bin ich der Meinung, dass man auf die Version 1.8 warten sollte, bevor man einen Umstieg auf die neue Version in Erwägung zieht. Will man einen neuen Webauftritt gestalten, sollte man gleich auf die Version 1.6 bauen, um sich Migrationsprobleme zu ersparen. Angeblich werden die Unterschiede zwischen 1.6, 1.7 und 1.8 nicht so gravierend sein wie zwischen 1.5 und 1.6.

Viel Glück!

 

Postfix will Outlook 2010 nicht

ACHTUNG unbedingt nach der Anpassung prüfen, ob Postfix nicht zum Open Relay geworden ist!

Durch Zufall bin ich heute mit einem Problem zwischen Outlook 2010 und Postfix (unter Debian Lenny) konfrontiert worden.

Postfix veweigerte Outlook 2010 das Versenden von Emails. Die konkrete Fehlermeldung ,die man von Postfix retour bekam lautete „Relay Access Denied“.

Komisch, da das Mailen mit Thunderbird und Outlook bis 2007 funktioniert.

Analyse der Logdateien

Folgende Fehler werden mitprotokolliert:

  • www postfix/smtpd[20869]: warning: unknown[x.x.x.x]: SASL     NTLM authentication aborted
  • www postfix/smtpd[20869]: warning: SASL authentication failure:    required parameters missing
  • www postfix/master[20847]: warning: process /usr/lib/postfix/smt    pd pid 20869 killed by signal 11

Die (anscheinende) Lösung des Problemes

Man öffne die Datei /etc/postfix/sasl/smtpd.conf und füge folgenden Eintrag hinzu:

  • mech_list: plain login

Wenn die Datei smtpd.conf nicht existiert einfach anlegen und oben genannten Parameter einfügen.

Danach startet man postfix neu mit:

  • /etc/init.d/postfix restart

So hat es dann jedenfalls bei mir geklappt.

Jedoch will ich jetzt mal wissen, was mech_list eigentlich macht. Also starte ich google und:

Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when using saslauthd! It can only handle these two mechanisms, and authentication will fail if clients are allowed to choose other mechanisms.
Man setzt diesen Parameter also um den Authentifizierungstyp für den Saslautd zu definieren.

Komisch, warum ist dann allerdings die Datei smtpd.conf komplett leer? Auf der andren Seite finden sich folgende Parameter in der main.cf:

  • smtpd_sasl_auth_enable       = yes
  • smtpd_sasl_security_options  = noanonymous
  • smtpd_sasl_local_domain      =
  • broken_sasl_auth_clients     = yes

Sasl ist aktiv, jedoch ist der Daemon nicht konfiguriert?

Ghostery „Gefällt mir!“

Genau so schnell wie ich mir testhalber das „FB – Gefällt mir Plugin“ für meinen Blog installiert habe, ist er auch schon wieder raus geflogen. Funktioniert, aber da ich ohnehin kein FB Fan bin, sag ich da mal „good bye“.

Im Gegenzug dazu möchte ich auf ein Firefox Addon verweisen, welches genau diesem „Gefällt mir“ Humbug entgegen wirkt und auch noch auf andre Art und Weise die Privatsphäre schützt.

Das Addon heißt Ghostery http://www.ghostery.com/.

Nach Installation und Konfiguration wird im Firefox immer oben rechts kurz eingeblendet was gerade geblockt wurde.

Im Falle eines FB Gefällt mir Links erscheint: Facebook Connect

Tolles Addon 🙂

Joomla 1.015 auf Joomla 1.5

Das Problem

Immerwieder scheint es Webmaster zu geben, die sich einen feuchten … darum scheren, ihre genutzten CMS Systeme auf dem aktuellen Stand zu halten. Wird schon nichts passieren, weil wenn dann passiert das „den anderen“.

Ich habe wirklich den Eindruck, dass in so einem Fall in die Richtung „Fire and forget“ gearbeitet wird. Schießen wir die Webpräsenz schnell online, jedoch vergessen wir das regelmäßige Aktualisieren der PHP Maschinerie im Hintergrund. Ist ja nur lästig!

Alles neu

So und genau da komme ich ins Spiel. Bin ich doch damit beschäftigt, eine Joomla 1.0.13 Installation auf die aktuelle Version 1.5 zu aktualisieren. Das alles ohne die Möglichkeit parallel eine zweite Datenbank zu installlieren. Ich muss also eine MySQL Datenbank für beide Installationen verwenden, OHNE die bereits in der Datenbank vorhandenen Daten der 1.0.13er Version zu beeinträchtigen.

Natürlich hab ich zu allererst mal rumgegoogelt und auch etliches dazu gefunden.

Fakt ist: Das ganze läuft nur über eine Migration. Mit drüberbügeln erreicht man nur eines… nämlich, dass mit Sicherheit nichts mehr funktioniert!

Wichtig ist ausserdem, die Version 1.0.13 auf 1.0.15 zu aktualisieren!Gut!

Testumgebung

Was mache ich,  wenn ich mir bei einer Sache nicht so sicher bin… Richtig! Es ist Zeit für die Installation eines lokalen LAMP-Server (LinuxApacheMySqlPhp). Ich gehe hier nicht auf die Installation eines solchen ein, sondern verweise in diesem Zusammenhang auf (Lamp@debian Quick and Dirty).

Ich installiere Joomla 1.0.15 im Document-Root meines lokalen Webserver und durchlaufe die notwendigen Schritte für die Installation. Ein Aufruf der Webseite mittels http://localhost sollte nach erfolgreicher Installation zu folgendem Screen führen:

Gut, das alte Joomla läuft also. Bislang kein Kunststück, finde ich.

Nun lade ich mir die letzte aktuelle Joomlaversion herunter (1.5.22) erstelle in meinem Documentroot in dem Joomla 1.0.15 liegt ein neues Verzeichnis mit Namen  joomla1522 und rufe http://localhost/joomla1522 auf. Auch hier startet die Installation.

Es ist die gleiche Datenbankinformation (Name, User, Passwort) anzugeben, wie bei der Installation von Joomla 1.0.15. Aber STOP! In Schritt Nr. 4 nicht auf Weiter klicken, es MUSS noch der Datenbankpräfix geändert werden, da sonst der gleiche Präfix wie für 1.0.15 verwendet wird, was zu einem Überschreiben von gleichnahmigen Feldern führt. Die Änderung des Präfix sieht so aus:

Ich habe hier einfach jos15_ als Präfix genommen So sieht man klar, dass es sich um Joomla 1.5 handelt. Nun führt man die Installation einfach wie gewohnt zum Ende und sollte nach Aufruf von http://locahost/joomla1522 auch die Startseite der 1.5.22 Version zu Gesicht bekommen. (Ich erspare mir hier den Screenshot).

Aber, sind nun wirklich beide Versionen in einer DB gespeichert? Check per PhpMyadmin:

Ja! Es gibt sowohl Tables mit jos15_ (Joomla 1.5.22) und nur jos (Joomla 1.5.15).  Das hat also mal geklappt.

Cut!

War die Freude Anfangs doch groß, musste ich später feststellen, dass leider zwar mittles des Migrationsassistenten, den man sich in Joomla 1.0.15 laden kann, die Inhalte soweit in der DB vorhanden waren, es aber offenbar Probleme mit der Verlinkung der einzelnen Menüpunkte und dem Inhalt gibt. Selbst ein neu verlinken des gesamten Inhaltes beförderte mich letztendlich auf einen 404 Fehler (Seite/Beitrag nicht gefunden).

Nach mehrfachen Versuchen und stundenlanger Arbeit hab ich es dann aufgegeben. Wer weiß, in welche Fehler man noch läuft, wenn dann alles soweit läuft.

Um dem zu entgehen gibts dann jetzt halt ne Neuinstallation + Copy und Pase Action inklusive Redesign auf Joomla 1.5.x

Und das alles nur, weil beim Erstellen der Website trotz vorhanden sein von Joomla 1.5 die Version 1.0.x vewendet worden ist!

BRAVO!