Für einen Softwareentwickler gehört das berufliche “am Ball bleiben” nach meiner Meinung zum täglichen Pflichtprogramm. Wer das vernachlässigt, bekommt sehr schnell die Quittung, hält man das womöglich über eine längere Zeit so, disqualifiziert man sich im wahrsten Sinne des Wortes selbst. Damit ein möglicher Arbeitgeber (oder auch Kunde) überhaupt einschätzen kann, wie es um unsere Kenntnisse und Erfahrungen bestellt ist, ist es von großem Vorteil, wenn man auch einige aktuelle Qualifizierungen vorzeigen kann.

Eine Vielzahl der IT-Zertifikate kann man in einem speziellen Testcenter absolvieren. Hier fallen mir spontan die Einrichtungen von Pearson ein. Wer weitere kennt, den bitte ich um einen Hinweis in den Kommentaren. Wer sich auf so eine Prüfung vorbereitet und bereits über Erfahrungen im entsprechenden Fachgebiet verfügt, hat ganz sicher einen großen Vorteil. Man sollte aber nicht zu überheblich an die Vorbereitung herangehen. Die Kosten für einige Examen können recht hoch sein und es wäre doch schade, wenn man für die eigene Überheblichkeit mit einer zusätzlichen Gebühr für eine nun notwendig gewordene Nachprüfung bezahlen muss.

Wie man die Vorbereitung gestaltet, ist vermutlich eine Frage des persönlichen Geschmacks. Eine interessante Möglichkeit bietet das E-Learning. Vor einigen Tagen ist eine Mitarbeiterin der Firma uCertify an mich herangetreten, um mich zu fragen, ob ich daran interessiert sei, etwas über deren Learning Platform zu schreiben. Nach meiner Zusage sind mir in nur wenigen Minuten alle notwendigen Informationen zugeschickt worden, um mich direkt in Vorbereitungen zur Zend Framework Certification stürzen zu können. Hier zeigte sich dann auch wieder der Vorteil, den nur eine Internetlösung bieten kann und an der kein Anbieter scheitern sollte, der Trainings für IT-Zertifikate anbietet: Problemfreie Unterstützung für alle gängigen Desktop-Betriebssysteme

Die Prep Engine ist das Vorzeigeprodukt von uCertify.  Auf dieser interaktiven E-Learning-Plattform findet man – in einer recht übersichtlich gehaltenen Weise – Materialien, Übungseinheiten, fast realistisch anmutende Testsimulationen und einiges mehr. Eine Analyse kann auch jederzeit abgerufen werden. So weiß man genau, wo man steht und was besser noch einmal geübt werden muss. Der Slogan LEARN SMARTER, NOT HARDER beschreibt ganz gut, was sich der interessierte IT unter dem Alleinstellungsmerkmal des Services vorstellen soll. Mehr als 100 uCertify-Produkte versuchen dieser Philosophie gerecht zu werden und passen so auch ganz gut in den immer aktuellen Trend des LEAN-Thinking.

Wie gut dieser Service hilft, werde ich dann in einigen Wochen herausfinden, wenn ich das Examen tatsächlich gemacht habe. Immerhin 98% der Kunden sollen in den vergangenen 15 Jahren erfolgreich bei den Zertifizierungen gewesen sein. Um diese Aussage zu unterstreichen will uCertify ohne Wenn-und-Aber die Kosten für die hauseigenen Produkte zurückerstatteten, falls man nicht erfolgreich und deshalb vermutlich insgesamt unzufrieden mit der von der Firma erbrachten Leistung ist.

Eine der Eigenschaften von Custom Post Types ist, dass sie sich auch automatisch an die Permalink-Struktur der WordPress-Installation anpassen. Allerdings funktioniert das Ganze erst dann reibungslos, nachdem man die Rewrite-Regeln zurückgesetzt hat. Als einfacher Workaround wird hierfür oft empfohlen, unter “Einstellungen › Permalinks” im Adminbereich die bereits definierten Regeln noch einmal abzuspeichern. Für Entwickler wird gibt es die Möglichkeit, die Funktion flush_rewrite_rules() jeweils bei der Aktivierung eines Plugins auszuführen, wenn dort Custom Post Types zum Einsatz kommen.

Bei einer Multisite, wo ein derartiges Plugin vielleicht global aktiviert ist, wird die ganze Sache allerdings weitaus unsympathischer. Auch hier steht mir die Möglichkeit offen, in jedem Blog die Einstellungen neu abzuspeichern, was aber auch lästig werden kann.  Für den  Entwickler des Plugins wird die vorher genannte Lösung allerdings nicht mehr zielführend sein, weil hier globale Variablen mit der Funktionalität kollidieren, die das Wechseln zu den verschiedenen Blogs innerhalb des Plugins ermöglichen.

Arbeitet man mit einer Versionsnummer kann sich den Schritt ersparen, von den Benutzern unseres Plugins nach einem Update immer wieder das Deaktivieren/Aktivieren zu verlangen. Wird beispielsweise ein Custom Prost Type mit einem Action angelegt, der mit einer normalen Priorität (per Definition 10) in die Warteschlange geschoben wird, so kann man mit einem weiteren Action niedrigerer Priorität (beispielsweise 11 oder höher) dafür sorgen, das die Funktion flush_rewrite_rules() erst nach der Erstellung des Custom Post Types ausgeführt wird.

Have fun!

Die großen Jobbörsen, wie Stepstone oder Monster, haben über 50.000 Stellenangebote in ihren Datenbanken und das ein oder andere Mal findet man dort bestimmt eine gute Stelle. Doch das Problem ist die viele Zeit die in so eine Suche investiert werden muss. Zeit die einem manchmal an anderen Stellen fehlt. Zu ungenau sind teilweise die Ausschreibungen oder es werden zusätzlich Dinge verlangt, auf die der Freelancer nicht spezialisiert ist. Die ersten Schritte in die Selbstständigkeit werden oft stark erschwert und viele entscheiden sich um.

SogenannteProjektvermittlungsplattformen bieten da zusätzliche Möglichkeiten und Optionen im Vergleich zu den klassischen Jobbörsen, was die Suche um einiges erleichtert. Kurz zum Ablauf dieser Plattformen: Viele Unternehmen haben bestimmt Abteilungen outgesourct, was soviel bedeutet, dass sie die dort verübten Aufgaben nun von einem externen Experten machen lassen. Zu solchen „ausgelagerten“ Aufgaben zählen beispielsweise der Relaunch des hauseigenen Logos oder Aktualisierung der Webseite. Größtenteils werden IT-Projekte, Design, Texten oder Übersetzen mittels solcher Projektvermittlungsplattformen ausgeschrieben.

Freelancer die sich speziell auf solche Arten von Projekten auf ihren Profilen eingestellt haben, bekommen dann eine Benachrichtigung über das ausgeschriebene Projekt. Sollte ihnen die Stelle bzw. das Projekt zusagen, dann bewerben sie sich auf die Ausschreibung und geben ihr Angebot ab. Das Unternehmen bekommt nun alle Bewerbungen per Email zugeschickt und kann sich in Ruhe die Bewerber ansehen. Sollte jemand passendes dabei sein, wird dieser benachrichtigt und die Kontaktdaten und Details werden ausgetauscht.

Auf beiden Seiten entstehen dadurch große Vorteile. Für das Unternehmen werden viel Zeit und mögliche Kosten gespart. Zudem kann international, national und regional nach dem passenden Freelancer gesucht werden. Der Freelancer hingegen bekommt die Projekte, die auf seine Skills passen. Er muss demnach nicht groß nach neuen Aufträgen suchen. Besonders Freelancer-Neulingen wird somit der schnelle Einstieg ermöglicht.

Ein weiterer Vorteil dieser Projektvermittlungsplattformen ist die internationale Ausrichtung. Sprich als Freelancer besteht auch die Möglichkeit neue Kunden in Übersee zu finden und sich international auszurichten. Das ermöglicht völlig neue Wege der Kundengewinnung und das ganz unkompliziert vom Internet aus.

Autorenbeschreibung:

Jennifer ist bei der Projektvermittlungsplattform twago im Online-Marketing tätig. twago ist der größte pan-europäische Marktplatz für Online-Arbeit und vermittelt online Freiberufler aus den Bereichen Programmierung, (Web-)Design und Unternehmensservices – Dienstleistungen, die von jedem Ort der Welt ausgeführt werden können. Über twago haben Auftraggeber Zugriff auf 138.000 Experten aus 177 Ländern.

Ich kann bereits die Beschwerden derjenigen hören, die mich davon überzeugen wollen, welch ein Verlust dies für die Besucher der entsprechenden Websites darstellt und/oder wie Klasse gTranslate ist bzw. war. Falls es sich jedoch um ernst gemeinte Argumente handeln sollte, will ich vorsorglich auf die Google Web Elements verweisen. Der Unterschied zur Translation API besteht hier einfach darin, dass die Seiten, welche mit dieser Funktionalität “bereichert” werden, tatsächlich “on-the-fly” übersetzt werden und das Generieren unzähliger Versionen der Inhalte in alle nur möglichen Sprachen endlich aufhört.

Ich kann mir vorstellen, dass es aus der Sicht eines verantwortungsvollen SEO auch wesentlich sicherer ist, eigene (optimierte) Inhalte in weiteren Sprachen (der – für den Kunden – möglicherweise interessanten Märkte) zu erstellen bzw. erstellen zu lassen, als sich auf eine maschinelle Übersetzung zu verlassen, die einen Google Quality Rater eventuell noch dazu veranlassen, Teile der Website aus dem Google Index zu kicken. Aus der Sicht des Klienten stellt sich zuerst vermutlich nur die Kostenfrage. Auf den zweiten Blick sollte man hier jedoch auch die Chancen sehen.

Ich denke dabei nicht unbedingt an die Chancen für mich bzw. an den Erfolg meines Multisite Language Switcher (auch wenn ich den Gedanken sehr sympathisch finde). Vielmehr glaube ich, trennt sich hier wahrscheinlich die Spreu vom Weizen, wenn die Konkurrenz aus heiterem Himmel die Kosten scheut, weiterhin ins Ausland zu investieren und nun eben keine Übersetzungen der Webseiten mehr anbietet. Hier bietet sich endlich die Gelegenheit, Kundengruppen fremder Sprachräume mit einer professionellen Übersetzung viel gezielter anzusprechen.

Mit der Version 0.7 habe ich vor einigen Tagen bereits die neueste Version des PHP Simple HTML DOM Parser in das Plugin integriert. myLCO benutzt diesen Parser, um die Links recht sicher und auch etwas fehlertoleranter festzustellen. Es gibt einfach zu viele Webseiten mit zu vielen Fehlern, so dass man den in PHP enthaltenen DOM-Parser als Lösung ausschließen muss.

Allerdings war dies nur als ein Anfang zu verstehen, um die in der letzten Zeit signalisierten Probleme bei der Erkennung von Links beheben zu können. Heute habe ich die Version 0.8 in das WordPress Plugin Directory übertragen. Diese Version enthält neben zahlreichen Fixes einige Verbesserungen, welche die Art und Weise, wie der PR der eingetragenen Seiten festgestellt wird, betreffen.

myLCO setzt für das Ermitteln des Google PageRanks auf den Service von WebInfoDB. Inzwischen braucht es einen API-Key, um den Service nutzen zu können. Diesen Schlüssel erhält man kostenfrei nach der Registrierung. Bis zu 500 Abfragen am Tag kann man damit ausführen. Sollte die Anzahl der erlaubten Requests zu knapp bemessen sein, kann man Credits erwerben, die ein größeres Volumen ermöglichen.

Have fun!

Dass ich zudem von den Google Code Servern zu GitHub gewechselt bin, ist nicht unbedingt eine folgerichtige bzw. zwingende Entscheidung gewesen. Google bietet Entwicklern durchaus die Wahl. Neben SVN können die eigenen Repositories auch mit Mercurial oder eben auch git verwaltet werden. GitHub bietet Entwicklern neben dem auch bei Google präsenten Wiki und den Statistiken, einen Issue-Tracker und eine soziale Komponente an, die nicht so uninteressant ist, wenn man an die hohe Zahl der WordPress-Plugins denkt, welche allein über das offizielle Plugin Directory verfügbar gemacht werden.

Zu Anfang war ich von der Idee begeistert, git und SVN gemeinsam nutzen zu können. Schließlich muss man Subversion nutzen, wenn man seinen Code in das WordPress Plugin Directory übertragen will. Wer sich dafür interessiert, sollte sich den Artikel git und WordPress-Entwicklung von Nicolas Kuttler genauer anschauen, der einen guten Ausgangspunkt bietet. Ich selbst habe aber Abstand von dieser Idee genommen und benutze bei meiner täglichen Arbeit fast ausschließlich git bzw. GitHub für meine Projekte. Und in das SVN von WordPress übertrage ich dann nur noch die finalen Versionen.

Have fun!

Standardmäßig sucht das Plugin alle Blogs im Netzwerk der Multisite-Installation, die dem Administrator des aktuellen Blogs zugeordnet sind. Es kontrolliert, ob eine Konfiguration vorliegt und ob das Blog nicht etwa durch die entsprechende Einstellung in den Optionen ausgeschlossen worden ist. In einigen Setups kann dieses Verhalten durchaus verwirrend oder sogar stöhrend sein.

Vor ein paar Tagen hat mir Peter geschrieben, ob es nicht möglich sei, hier mit einem Filter zu arbeiten, damit man das Verhalten bei Bedarf ändern kann. Wem dieses Konzept noch nicht so geläufig ist, der sollte sich den Abschnitt Hooks, Actions and Filters der WordPress-Dokumentation zur Plugin-API ansehen.

Diese Funktionalität steht nun also auch im Multisite Language Switcher bereit. Allerdings, möchte ich noch einschränkend hinzufügen, ist sie noch als experimentell zu betrachten. Folgender Code soll jedoch schon einmal für etwas mehr Klarheit sorgen, wenn ihr euch nun fragt, wie sich der Filter nun genau nutzen lässt:

In meinem Beispiel wird das Array, welches ursprünglich bereits MslsBlog-Objekte enthält, komplett überschrieben. Das wirkt vielleicht etwas drastisch, erklärt aber die Funktionsweise viel besser. Der Konstruktor der MslsBlog-Klasse erwartet übrigens ein Objekt – wie es beispielsweise von get_blog_details geliefert wird – und die Beschreibung, die normalerweise aus der Konfiguration des entsprechenden Blogs stammt.

Have fun!

Zusätzlich zu den schon vorhandenen Übersetzungen auf Deutsch, Italienisch und Niederländisch gibt es nun auch Spanisch, Französisch und Brasilianisch. Mein Dank dafür geht an Victor und Andreas. Von Andreas habe ich übrigens auch zahlreiche Hinweise zu Ungereimtheiten bzw. Bugs bekommen. Zudem hat er unglaublich viel getestet und so einige Vorschläge für Verbesserungen gemacht.

Die neuen Funktionalitäten bestehen im Wesentlichen aus 4 Punkten:

Die Flaggen in der Box auf der rechten Seite, wenn man einen Post bearbeitet, sind nun anklickbar. Man kann so viel schneller zur Übersetzung wechseln (Danke, Thelonius!). Zudem gibt es neben der Funktion the_msls nun auch ein die Funktion get_the_msls, um die Ausgabe als String aufnehmen zu können (der Tipp kam von Latz). Weiterhin kann man nun auch einstellen, ob die aktuelle Sprache ebenfalls in der Ausgabe erscheinen soll und es läßt sich einrichten, dass ein Blog ausgeschlossen werden soll.

Für die folgende Version (0.8) habe ich auch schon ein paar neue Ideen geliefert bekommen:

Im Edit Post-Modus wird es hinter der Auswahl für vorhandene Übersetzungen, einen Link geben, über den man eine neue Übersetzung schnell hinzufügen kann. Zudem wird es die Möglichkeit geben, einen eigenen Pfad für die Flaggen zu definieren und die Ausgabe der Links wird sortierbar sein. Und zu guter Letzt werde ich mir auch die Links im Plugin-Menü noch einmal genauer anschauen.

In dem Sinne … Have fun!

Eine WordPress Multisite läßt sich lokal nicht bzw. nur sehr umständlich installieren.

Bei einigen Fehlern, die sich in meinen Tests ergaben, konnte ich nicht auch vollständig ausschließen, dass sie eventuell genau durch dieses Manko hervorgerufen wurden, was leider die Installation einer Testumgebung auf einem meiner Webserver für mich unumgänglich machte.

Andererseits ist dies eine prima Gelegenheit für die folgende Anleitung.

In der vorher schon genannten englischsprachigen Anleitung wird auf die verschieden Möglichkeiten verwiesen, wie eine Multisite aufgesetzt werden kann, was ich mir hier erspare, weil ich eine mehrsprachige Website mit WordPress einsetzen möchte, in der die einzelnen Übersetzungen in Unterverzeichnissen residieren.

Zu diesem Zeitpunkt ist es für Websites, welche bereits länger mit WordPress laufen, nicht möglich eine derartige Installation durchzuführen. Hier bleibt nur der Modus, die ganze Geschichte über Subdomains oder mit einem entsprechenden Plugin mit verschiedenen Domains zu lösen.

Step 1

Der erste Schritt besteht darin, dass erst einmal eine ganz normale WordPress-Installation durchgeführt wird.

Es gibt jedoch bereits hier eine weitere Einschränkung, weil für eine WordPress-Multisite keine Installation in einem Unterverzeichnis möglich ist.

Ihr holt euch – wie immer – die aktuellste Installation eurer bevorzugten Quelle (beispielsweise direkt von der WordPress-Download-Seite), packt die Installation aus und übertragt diese dann mittels FTP oder SCP (je nachdem, was euer Hoster hier vorgibt) in das DocumentRoot eures Webservers. Danach muss die Datei wp-config-sample.php nach wp-config.php kopiert und bearbeitet werden. Hier tragt ihr einfach nur die Verbindungsdaten der Datenbank und einige Sicherheitsschlüssel eurer Wahl ein, speichert diese Datei, öffnet die Hauptseite eures Servers mit dem Browser, füllt die Daten im dort angezeigten Formular aus und klickt dann zum Beenden des ganzen Vorgangs auf den Button unter dem Formular. Und das war’s schon!

Damit nicht bereits hier schon die Show zu Ende ist, hier noch der Link zum Artikel WordPress in 5 Minuten installieren auf der WordPress-Deutschland-Website.

Step 2

Im nächsten Schritt muss das Multisite-Feature in der Konfiguration “erlaubt” und das Netzwerk in der Administrationsoberfläche installiert werden.

Dafür muss zuerst eine weitere Zeile in die Datei wp-config.php hinzugefügt werden. Die Anweisung

define('WP_ALLOW_MULTISITE', true);

fügt ihr am besten gleich nach der Zeile

define('WP_DEBUG', false);

des Konfigurationsfiles ein und aktiviert so den neuen Menüpunkt Tools -> Network Setup bzw. Werkzeuge -> Netzwerk-Einstellungen, falls ihr die deutsche Version installiert habt. Dieser Menüpunkt erscheint allerdings nur, nachdem ihr euch erneut im Administrationsbereich angemeldet habt. Hier nehmt ihr dann die für euch passenden Einstellungen vor und bestätigt diese durch einen Klick auf den Button unter dem Formular.

Achtet auch darauf, falls ihr der Anleitung hier treu bleiben wollt, dass ihr die Option auswählt, welche die verschiedenen Blogs über Unterverzeichnisse publiziert.

Step 3

Der dritte Schritt sieht einige kleinere Tätigkeiten bzw. Einstellungen vor, welche die grundlegende Installation einer WordPress Multisite abschließen.

Zuerst muss ein neues Unterverzeichnis namens blogs.dir im Verzeichnis wp-content angelegt werden. Zudem muss dieses Verzeichnis auch für den Webserver beschreibbar gemacht werden, was sich auch mit einem FTP-Client bequem bewerkstelligen lässt, indem man das Recht in das Verzeichnis zu schreiben für alle hinzufügt (chmod 777 blogs.dir).

Ist das erledigt muss ein Block mit Anweisungen in die Datei wp-config.php eingefügt werden, welchen man gleich unter der letzten Änderung in diesem File platzieren kann.

Danach muss eine Datei mit dem Namen .htaccess (bei einer Neuinstallation) im Hauptverzeichnis angelegt werden, in die der Code aus dem Block eingefügt wird, der mit 3. nummeriert ist.

Zum Abschließen dieses Steps müsst ihr euch wieder neu in die Administrationsoberfläche einloggen.

Step 4

Im nächsten Schritt werden wir uns die notwendigen Sprachfiles besorgen für unserer mehrsprachigen Multisite einrichten.

Wenn ihr euch fragt, wie ihr am leichtesten an die gettext-Files kommt, die für die Übersetzung notwendig sind: Im SVN von Automattic gibt es das komplette Angebot. Jede Sprache hat dort ihr eigenes Verzeichnis. Für die deutschen Sprachfiles klickt ihr einfach auf de_DE, dann auf tags, auf 3.2 (oder eben die aktuellste Version) und auf messages. Die .po- und .mo-Files ladet ihr einfach auf euren Computer und schickt sie dann in das Verzeichnis /wp-content/languages, welches ihr einfach erstellt, falls es noch nicht vorhanden ist.

Im selben Verzeichnis (des Automattic-Servers), wo ihr die Sprachfiles geladen habt, findet ihr auch Unterverzeichnisse für die Übersetzungen der Standard-Templates. Diese Files gehören in das Verzeichnis languages des Theme-Ordners, also /wp-content/themes/twentyeleven/languages (ausgehend vom DocumentRoot eures Webservers), wenn ihr das neue Thema benutzt.

Für alle weiteren Sprachen geht ihr gleichermaßen vor.

Step 5

Nun können wir endlich die zusätzlichen Blogs einrichten, die für die Inhalte in den verschieden Sprachen zuständig sein werden.

Klickt man in der Administrationsoberfläche oben rechts auf die Begrüßung klappt ein Menü auf, welches den Punkt Network-Admin (bzw. Netzwerkadministrator bei einer deutschen Installation enthält. Nach einem Klick gelangt man in den Bereich, wo sich die Blogs nun endlich anlegen lassen.

Im Menu auf der linken Seite befindet sich der Punkt Sites (oder auch Blogs), unter dem sich der Punkt verbirgt, der uns im Augenblick interessiert. Sind dann endlich alle benötigten Blogs angelegt, gibt es nur drei wichtige Punkte zu beachten:

Jedes Blog muss einzeln im eigenen Dashboard und Einstellungen konfiguriert werden. Bereits die allgemeinen Einstellungen sind hierbei wichtig und hier findet sich auch die Einstellung der Sprache. Wer sich daran stört, dass das primäre Blog im URL im ein /blog vorangestellt wird, kann dies ändern, indem er/sie im Bereich des Netzwerkadmins die Permalink-Struktur des Blog bearbeitet (URL/wp-admin/network/site-settings.php?id=1). Nach dieser Änderung sind die Beispieldaten dieses Blogs nicht mehr erreichbar und sollten gelöscht werden, neue Inhalte werden aber von nun an mit eurer neuen korrekten Adresse ausgeliefert.

Step 6

Optional installiert ihr euch nun den Multisite Language Switcher, um die ganze Sache rund zu machen.

Ich lasse die komplette Installation auf dem Testblog vorerst stehen, sodass ihr das Ergebnis auch direkt sehen könnt. Ich habe zwei zusätzliche Blogs (deutsch und italienisch) angelegt, das primäre Blog als englischsprachige Website so bestehen lassen und für jedes dieser Blogs eine Beispielseite und einen Beispielartikel erstellt. Außerdem habe ich die Standardkategorien geändert und jeweils ein Schlagwort hingefügt.

Das Ganze ist natürlich kein starres Konstrukt, ganz im Gegenteil! An diesem Punkt sind der Fantasie keine Grenzen mehr gesetzt. Der Multisite Language Switcher fügt sich in diese Struktur ohne allzu großen Mehraufwand ein. Ist die grundlegende Konfiguration einmal gemacht, ist der spätere Aufwand kaum spürbar.

Have fun!

Mit der Version 0.6 des Multisite Language Switcher ist nun endlich möglich, auch Kategorien und (wer sich die Arbeit machen möchte) Schlagwörter mit den fremdsprachigen Blogs der eigenen Multisite zu verbinden. Momentan verzichte ich noch ganz bewusst auf die Linkkategorien und die Custom-Post-Types. Falls mir jemand ein paar Beispiele für einen möglichen Nutzen liefert, baue ich die aber gern noch mit ein.

Have fun!