Der falsche Weg

Auf die Nachfrage, wie er es denn umbenannt hätte, musste er dann zugeben, dass er die originale Datei überschrieben hat. Oder er hatte sie komplett kopiert und dann den einen String geändert, das weiß ich nicht mehr so genau. Aber auf jeden Fall waren wir uns alle einige, dass dies eine sehr schlechte Lösung des Problems ist. Spätestens beim nächsten großen Update, wie z.B. bald auf Version 3.4, wird auch die Übersetzungsdatei wohl wieder überschrieben werden müssen. Alle geänderten Übersetzungen sind somit verloren und müssen erneut überschrieben werden. Ich war mit aber sehr sicher, dass es dafür eine bessere Lösung gibt.

Der richtige Weg

Vor einiger Zeit habe ich dem Artikel Lokalisierung für Child Themes am Beispiel von Thematic beschrieben, wie man in einem Child-Theme die Übersetzungen für Strings im Parent Theme überschreiben kann. Ich war mir sehr sicher, dass dies auch für die WordPress Core Strings funktionieren muss. Bei Core-Übersetzungen wird ja in den Übersetzungsfunktionen keine Domain angegeben. Daher war die erste Vermutung, dass man einfach einen leeren String für das Einbinden der Übersetzungsdatei verwenden muss. Aber das war nicht ganz korrekt. Man muss den String “default” als Parameter verwenden. Damit ist es dann möglich, eine eigene Übersetzungsdatei zu laden. In dieser Datei müssen aber nicht alle Strings enthalten sein. Es reicht aus, wenn man nur die zu überschreibenden aufführt. Die Einbindung dieser mo-Datei geschieht dann wie folgt:

load_textdomain( 'default', dirname( __FILE__ ).'/'.get_locale().'.mo' );

In diesem Beispiel befindet sich dann z.B: die Datei de_DE.mo im selben Verzeichnis wie die Datei, in die diese Zeile eingefügt wurde. Dies kann in eurem Theme aber auch in einem Plugin geschehen. Im Falle von Capsar ist es sogar am sinnvollsten, das ganze als “must-use” Plugin im Ordner /wp-contents/mu-plugins/ abzulegen. Ich habe das ganze natürlich auch mal für euch fertig vorbereitet und ihr könnt es hier herunterladen und einfach als Plugin installieren:

Download

Fazit

Auch hier hat sich wieder gezeigt, wie flexibel WordPress ist. Auch mein Grundsatz “Don’t hack the core, never!” (auf Deutsch würde man wohl sagen “Nur gucken, nicht anfassen!”) wurde dadurch mal wieder bestätigt. Ich habe bisher wirklich noch kein Problem gefunden, dass ich nicht durch ein paar Zeilen Code in der functions.php Datei oder durch ein kleines Plugin lösen konnte, ohne den Core anfassen zu müssen. Das einizige, was einem hier noch passieren könnte ist eine Änderung des zu übersetzenden Strings in einer neuen Version. Dann müsste natürlich auch die Übersetzungsdatei angepasst werden. Aber eben auch nur die wenigen Strings darin und auch nur die, die sich geändert haben.

Was haltet ihr von meiner Lösung? Hättet ihr gedacht, dass so etwas mit nur einer Zeile Code möglich ist? Habt ihr vielleicht auch ähnlich tolle Fixes parat? Über Kommentare würde ich mich wie immer sehr freuen.

Zur Zeit hat aber Dropbox eine Aktion. In einer neue Beta-Version kann man eine Funktion zum automatischen synchroniseren von Fotos auf einer Speicherkarte testen. Wer an dem Beta-Test teilnimmt erhält automatisch 500MB zusätzlich. Nachdem ich die Beta jetzt gestestet habe sieht es so aus, als bekommt man die ersten 500MB auch erst nach dem Upload des ersten Bildes. Die insgesamt zusätzlichen 5GB erhält man, indem man Bilder hochlädt. Pro 500MB an Bildern, die man hochlädt, bekommt man weitere 500MB zusätzlich gutgeschrieben. Der Zusatzspeicher kann auch nach Ablauf der Aktion weiter genutzt werden.

Wer also auch seinen Speicherplatz erhöhen möchte, findet in diesem Forum Post die Downloads der Beta-Versionen für Windows, Linux und Mac: Experimental Forum Build – 1.3.14. Weitere Informationen gibt es auf den Hilfeseiten von Dropbox.

Wer noch kein Dropbox-Konto hat und gleich mit 250MB mehr starten möchte, kann diesen Link benutzen: Bei Dropbox anmelden.

Am Mittwoch hat es mich also vor die Tore der Hauptstadt gezogen und trotz langer Anreise hat es sich gelohnt. Einen Bereicht über die Teilnehmer inkl. Foto findet ihr in dem Beitrag von Caspar, der einer der beiden Initiatoren des Potsdamer WP Meetups ist. Es gibt auch eine Facebook Seite sowie eine Google+ Seite zum Potsdamer WP Meetup. Dort könnt ihr immer nachlesen, wass das nächste WP Meetup stattfindet und was dort als Thema vorgeschlagen wird. Das nächste findet am 14. Februar 2012 statt und so wie es im Moment aussieht werde ich wohl zum Thema “Grundlagen der Plugin-Programmierung” einen kleinen Vortrag halten. Wer mich also mal im “real life” treffen möchte und noch dazu etwas zur Plugin-Programmierung erfahren möchte, der muss nur noch seiner Freundin oder seinem Freund erklären, wieso er am Valentinstag nicht da ist

Crawler: Plage oder Segen?

Jeder von uns, der eine Website hat freut sich wohl, wenn den Google Crawler regelmäßig vorbeischaut und dabei möglichst alle neuen schon nach wenigen Minuten in den Index befördert. Da der Google Crawler dabei auch automatisch auf die Performance einer Website achtet um kleine Seiten nicht zu überlasten, fällt es auch nicht weiter auf, wenn er gerade am Werk ist.

Aber leider gibt es nicht nur den Google Crawler sondern mittlerweile eine unüberschaubar große Anzahl davon. Heute hat sich also ein neuer Crawler ans Werk gemacht und meine Website im Turbogang mit Anfragen beschossen. Das ist für den kleinen V-Server dann doch etwas zu viel geworden und er hatte innerhalb kürzester Zeit eine Auslastung von 4500%!

Aber wie kann man sich nun vor solchen Crawlern schützen und möchte man das auch. Wenn man nämlich einen Crawler blockiert, dann kann der Dienst dahinter die Website nicht mehr indizieren und man verliert eventuell neue Nutzer, die auf die eigene Website über diesen Dienst aufmerksam geworden wären. Daher habe ich bei meiner Website nicht kategorisch alle Crawler außer denen der großen Suchmaschinen ausgeschlossen.

Einzelne Crawler sperren

Um Crawler den Zugriff auf die eigene Website zu verweigern setzt man eine Datei mit dem Namen robots.txt ein. Nachdem ich also den Namen des Crawlers über die Logfiles meines Servers rausgefunden hatte, konnte ich ihn zukünftig ausschließen, indem ich folgende Zeilen zur robots.txt Datei hinzugefügt habe:

User-agent: 008
Disallow: /

Das Problem an der Sache ich nur, dass der Crawler diese Änderung nicht sofort bemerkt. Eventuell prüft er die Datei ja nur einmal pro Stunde oder sogar nur einmal am Tag oder in der Woche. Bis er also aufhört die Website mit Anfragen zu überfluten müssen andere Maßnahmen getroffen werden.

Zugriffe von einer IP-Adresse blockieren

Ich musste also nun den Zugriff durch den Crawler anhand seiner IP-Adresse blockieren. Das geht am einfachsten über die Datei .htaccess die sich meistens im Wurzelverzeichnis der Website befindet. Dort habe ich folgende Zeilen eingefügt:

# block potentially harming clients
order allow,deny
deny from 77.45.136.22
deny from 91.218.229.49
allow from all
# END: block potentially harming clients

Ich habe hier in diesem Beispiel zwei IP-Adressen blockiert. Was es mit der zweiten auf sich hat erkläre ich euch gleich. Ihr könnt hier also auch mehrere IP-Adressen blockieren, müsste aber pro Adresse eine Zeile verwenden. Damit verhindert ihr zwar die Anfrage selbst nicht (was auch nicht möglich ist) aber die Anfrage wird hierbei vom Apache-Server direkt zurückgewiesen, ohne dass beispielsweise WordPress etwas davon mitbekommt und anfängt die angeforderte Seite zu generieren. Wenn der Crawler intelligent ist, hört er auch recht bald auf eure Seite zu lesen und schaut sich vielleicht gleich mein eure veränderte robots.txt Datei an.

Hilfe gegen die bösen Jungs da draußen

Leider ist die robots.txt Datei nur eine Bitte an einen Crawler, was sie mit eurer Website tun soll. Er kann diese Information aber natürlich auch einfach ignorieren und eure Website trotzdem auslesen. Dann sollte das Blockieren mittels .htaccess Datei funktionieren, solange es ein Crawler ist, hinter dem keine bösen Absichten stecken. Denn sobald ihr den Crawler blockiert, bekommt er das natürlich mit. Er könnte dann einfach die IP-Adresse wechseln und erneut eure Seite belagern. Damit er das aber nicht so schnell mitbekommt, könnt ihr einen kleinen Trick anwenden. Oft werden solche Crawler von Programmieren eingesetzt, die den gesamten Inhalt eurer Website lesen wollen. Sie prüfen dabei vermutlich auch, ob die Seite erfolgreich angefordert werden konnte (Status Code 200) oder ob es eine erfolgreiche Weiterleitung gab (Status Code 301/302). Wieso also nicht dem Crawler einfach eine Seite zurückliefern, die Inhalt enthält, nicht aber den, den er wollte. Oder ihn einfach auf eine andere Seite weiterleiten.

Ich leite solche Angreifer gerne auf “Das Ende des Internets” um. Das ist eine witzige Seite, die wie eine typische Internet Explorer-Fehlerseite aussieht und andeutet, dass man das Ende des Internet erreicht hat. Um das zu tun fügt ihr einfach folgende Zeilen in eure .htaccess Datei ein:

# rewrite unwanted clients to the end of the internet
RewriteCond %{REMOTE_ADDR} ^77\.45\.136\.22 [OR]
RewriteCond %{REMOTE_ADDR} ^91\.218\.229\.49
RewriteRule ^(.*)$ http://www.weirdity.com/internet/eoti.html [L]
# END: rewrite unwanted clients to the end of the internet

Wenn ihr hier mehrere IP-Adressen angeben möchtet, dann müsst ihr hinter jeder Zeile, außer der letzten, noch [OR] einfügen. Außerdem müssten die Punkte mit einem vorangestellten Backslash markiert werden.

Wenn ihr zuvor schon den vorherigen Code zum Blockieren einer IP-Adresse eingefügt habt, dann müsst ihr diesen auskommentieren (indem ihr vor jede Zeile ein # Zeichen einfügt), damit die Zugriffe nicht mehr blockiert, sondern stattdessen umgeleitet werden.

Der Nutzer des Crawlers merkt im Optimalfall davon nichts. Wenn er sich dann aber im Nachhinein die gecrawlten Seiten ansieht, wird er sich über deren Inhalt wohl sehr ärgern.

Fazit

Ich habe mit den hier beschriebenen schon eingie Angriffe bzw. unbeabsichtigte Überlastungen durch Crawler abwenden können. Auch mein Server läuft gerade wieder mit gemächlichen 5% Auslastung vor sich hin. Diese Maßnahmen schützen einen zwar nicht vor professionellen oder gut organisierten Angriffen, aber gegen die oft genannten “Script-Kiddies” sollten sie ausreichen. Die suchen sich dann einfach eine Website, die sie einfacher angreifen können.

Ach ja und jetzt noch zu der zweite IP-Adresse. Diese stammt wirklich von einem Angreifer. Der wollte aber nicht meinen Server durch viele Anfragen überlasten, sondern viel schlimmer noch, er wollte Schadcode auf meinen Server laden. Dazu hat er versucht die Sicherheitslücke in der TimThumb Funktion auszunutzen, auf die ich auch weiter unten in meinem Artikel Plugins und Sicherheit: Sicherheitslücke in Filedownload Plugin geschlossen kurz eingegangen bin. Aber zum Glück verwende ich kein Plugin oder Theme, das diese Funktion nutzt bzw. eine unsichere Version von TimThumb verwendet.

Die Rettung meines Handys

Zum Glück hatte ich mir vor langer Zeit mal genau für einen solchen Fall eine App auf meinem Android installiert: die App Android Lost. Diese ist recht einfach einzurichten und bietet einem später über das Online-Portal www.androidlost.com sehr viele Möglichkeiten zur Rettung seines geliebten Handys.

Keine drei Minuten, nachdem ich den Verlust bemerkt hatte, saß ich zu Hause auch schon am Rechner und schickte meinem Handy erst einmal einen Alarm. Dieser wird auch dann abgespielt, wenn das Handy eigentlich auf Lautlos oder wie bei mir auf Vibration eingestellt ist. Wie mir der Taxifahrer später mitteilte, hat es ihn total erschreckt, da das Handy ja direkt hinter ihm auf dem Sitz lag. Anschließend schickte ich dann eine Textnachricht an das Handy, welche sofort angezeigt wird. Darin hinterließ ich meine Festnetznummer und ein paar Sekunden später klingelte auch schon das Telefon. Nach ungefähr 10min war der Spuck dann auch schon vorbei, ich hatte mein Smartphone zurück und der Taxifahrer eine weitere Fahrt und ein dickes Trinkgeld

Das ganze ging deshalb auch so schnell, weil ich noch UMTS aktiviert hatte. Aber selbst wenn es ausgeschaltet ist, hat man gute Chancen, denn man kann über ein anderes Handy Kommandos per SMS an das Handy schicken. Mit diesen kann man dann z.B. UMTS, GPS oder ähnliches aktivieren. Wenn man mal einen nicht so ehrlichen Finder erwischt hat, kann man auch den Speicher löschen oder Foto- oder Tonaufnahmen machen lassen und sich schicken lassen.

Fazit

Diese App ist für mich eine absolute Must-Have-App, die wirklich jeder Android-Besitzer installieren sollte. Sie ist kostenlos und auch die Nutzung des Service kostet nichts. Für iPhone gab es eine solche App lange nicht, da sie sehr viele Rechte benötigt, was auch klar ist, da sie ja auch den Speicher löschen kann. Da Apple hier aber Apps solche Rechte nicht einräumt, war man als iPhone-Besitzer nicht so gut geschützt. Jetzt gibt es die Funktion Mein iPhone suchen, die einige Funktionen von Android Lost auch beherrscht, aber längst nicht alle.

Falls jemand von euch Erfahrungen mit der iPhone App hat oder vielleicht auch eine solche App für Windows Phone oder Blackberry kennt, dann würde ich mich über einen Kommentar sehr freuen.

P.S. Für die Bestellung des Taxis konnte ich auch zum ersten Mal die App myTaxi ausprobieren, die wirklich super funktioniert. Das Taxi ist schneller da als man eine Telefonnummer für die Taxizentrale der Stadt rausgesucht hat und denen per Anruf den Standort mitgeteilt hat, den man, vielleicht auch nicht mehr ganz nüchtern, gar nicht kennt.

Heute musste ich dann leider feststellen, dass der Server erneut down war. Da das Monitoring über Pingdom mir leider keine Nachricht auf mein Handy schickte, bemerkte ich es erst nach über 7 Stunden! Hiermit möchte ich mich auch bei allen Entschuldigen, die in dieser Zeit vergeblich versucht haben meinen Blog zu erreichen.

Ich weiß leider noch immer nicht, was genau zu den beiden Ausfällen geführt hat. Die einzige größere Änderung der letzten Tage war die Installation des WP Super Cache Plugins. Falls jemand von euch weiß, ob es damit zu Abstürzen des Apache Prozesses kommen kann, dann wäre ich ihm für einen Kommentar sehr dankbar.

Ich werde jetzt meinen Server ein bisschen besser im Auge behalten. Sobald ich den Fehler gefunden habe, werde ich euch natürlich sofort berichten, woran es lag. In diesem Sinne noch ein schönes Wochenende!

Es ist immer sehr aufwändig diese Liste zu pflegen, da ich erst einmal feststellen muss, was sich hinter dem ISO 639 Code verbirgt. Ich konnte aber bis auf einen Code alle finden. Wenn also jemand von euch weiß, welche Sprache sich hinter me_ME verbirgt, dann würde ich mich über einen Kommentar dazu sehr freuen.

Was man aber auch sehr gut an dieser Liste sehen kann ist die schnelle Verbreitung von WordPress in viele Regionen der Welt. Insgesamt enthält das offizielle Sprachdateien-Repository von WordPress mittlerweile 94 Sprachcodes. Hier ist aber z.B. für Deutschland nur die “Du-Version” enthalten. Die eigentliche Anzahl an unterschiedlichen “Sprachen” liegt also vermutlich noch um einiges höher.

Funktion des Plugins

Die Sicherheitslücke steckte in dem Plugin Filedownload. Dieses Plugin wird eingesetzt um eine in WordPress hochgeladene Datei direkt zum Download anzubieten. In der Regel öffnet ein Browser ja eine Datei, die er direkt anzeigen kann, wie z.B. ein Bild oder eine PDF-Datei. Dieses Plugin gibt aber nun die angeforderte Datei so an den Browser zurück, dass dieser das Download-Dialogfenster öffnet und den Benutzer zum Download der Datei auffordert.

Die Sicherheitslücke

Die Sicherheitslücke bestand darin, dass das Plugin auch relative Verzeichnispfade akzeptierte. So konnte ohne weiteres die „wp-config.php“ Datei angefordert werden. Da hier alle Zugangsdaten in Klartext gespeichert sind und der Blog zusätzlich auch noch für den FTP-Account die gleichen Zugangsdaten nutzte, konnte der Angreifer ohne Probleme eigene Dateien hochladen. Ein böser Hacker hätte das ausnutzen und beliebigen Schadcode ausführen können (allerdings wohl nicht mit Administrationsrechten).

Der Autor des Plugins hat den Fehler mittlerweile behoben. Es gibt aber leider noch sehr viele Blog, die noch die unsichere Version verwenden. Diejenigen von euch, die auch dieses Plugin einsetzen, sollten also sofort auf die neueste Version updaten.

Weitere Beispiele für bekannte Sicherheitslücken

Im August wurde ein Sicherheitsproblem in der Funktion timthumb bekannt. Dabei war es einem Angreifer möglich eine beliebige Datei in ein System einzuschleusen. Damit konnte der Angreifer dann beliebigen Schadcode auf dem infizierten System ausführen. Da die timthumb Funktion von sehr vielen Themes verwendet wird, waren sehr viele Blogs angreifbar. Hier kommt erschwerend hinzu, dass für jedes Theme ein eigenes Sicherheitsupdate notwendig war, da fast alle Themes die Funktion direkt in das Theme integriert haben und somit auch die Sicherheitslücke nicht zentral für alle Themes geschlossen werden konnte. Im WordPress Repository findet man daher das Plugin Timthumb Vulnerability Scanner, mit dem man seinem Blog auf die noch offene Sicherheitslücke hin untersuchen kann. Damals wurde glücklicherweise von WordPress Deutschland Team und auch bei heise.de davon berichtet, so dass viele auf die Sicherheitslücke aufmerksam wurden.

Fazit

Es ist durch Plugins sehr einfach möglich die Funktionalität seines Blogs zu erweitern. Aber es ist leider auch sehr einfach möglich, seinen Blog dadurch einem erhöhten Sicherheitsrisiko auszusetzen. Es sollte nun niemand in Panik verfallen und alle Plugins deinstallieren. Es soll nur ein Appell sein die Updates, die für die diversen Plugins ständig im Backend angeboten werden auch zu installieren. Die meisten Plugin-Autoren pflegen auch ein Changelog, in dem man nachlesen kann, welche Änderungen die neue Version enthält. Aber in der Regel werden dadurch Fehler oder eben Sicherheitslücken geschlossen. Als zusätzliche Maßnahme sollte man eine regelmäßige Sicherung seines Blogs durchführen. Dazu teste ich seit ein paar Wochen BackWPup. Ich werde euch demnächst ausführlich darüber berichten.

Das Problem

Man kann nun aber dem Plugin nicht wirklich einen Vorwurf machen. Nachdem ich den Quellcode des Plugin sowie die Ausgabe der Blogroll im WordPress Core untersucht habe, konnte ich auch keine bessere Einbindung finden als die im Plugin verwendete. Es fehlt leider ein Filter, mit dem man den Link Tags zusätzliche Attribute anhängen kann. Da aber bei aktivierten Outlink-Tracking noch ein “onclick” Attribut notwendig ist, wurde es vom Plugin-Entwickler eben an das “target” Attribut angehängt. Damit war denn der Inhalt des selbigen nicht mehr leer und es wurde ausgegeben, auch wenn der Link für die Blogroll im Backend auf “none” gestellt war.

Die Lösung

Es gibt glücklicherweise eine recht einfache Lösung für das Problem. Da es einen Filter für die gesamte Ausgabe der Blogroll gibt, können wir hier ansetzen. Wir entfernen einfach sämtliche leere “target” Attribute im Ausgabestring mit folgendem Snippet:

function remove_empty_target($content){
        return str_replace('target="" ', '', $content);
} add_action('wp_list_bookmarks', 'remove_empty_target');

Das Snippet fügt ihr einfach in die functions.php Datei eures Themes an einer beliebigen Stelle ein. Wer für seine Seite ein Theme verwendet, das als Doctpye HTML5 nutzt, der kann diesen Tipp getrost ignorieren. Denn in HTML5 ist das “target” Attribut wieder enthalten. Trotzdem halte ich noch immer die Angewohnheit externe Links mit einem target="_blank" in einem neuen Tab/Fenster zu öffnen für eine Todsünde der Usabilty. Aber im Zusammenhang mit Formularen und JavaScript kann ein “target” Attribut durchaus Sinn machen und notwendig sein.

Dennoch habe ich Steve Jobs für seine Arbeit und seine Visionen sehr geschätzt. Nicht nur Apple Fans weltweit verlieren mit seinem Tod einen wichtigen Vordenker unserer Zeit. Es wird schwierig die Lücke, die er hinterlässt zu füllen.

“Your time is limited, so don’t waste it living someone else’s life.” (Steve Jobs)

Bei den Milliarden Webseiten die man im World Wide Web finden kann, gibt es Seiten, die einen wahren optischen Genuss darstellen und auf denen man gern verweilt. Jedoch gibt es auch Millionen Seite, die man nicht gern besucht und schnell wieder vergisst. Es gibt unzählige Fehlerquellen bei der Erstellung einer Webseite. Hier werden im folgenden 10 vorgestellt.

1. Worum geht es hier?
   Innerhalb von ein paar Sekunden sollte dem Besucher bewusst sein, worum es auf der Seite geht. Schnell sollte für den Leser klar sein, warum er auf der Seite Zeit verbringen sollte.
2. Texte mich nicht zu!
   Versuchen Sie unbedingt große Textblöcke zu vermeiden. Leser möchten sich zwar informieren, aber sie möchten auch unterhalten werden. Die Seite sollte scannbar sein, für alle die nur nach einzelnen Informationen suchen.
3. Was steht da?
   Die Wahl der Schriftart, aber auch die Schriftgröße sollten wohl durchdacht sein und vor allem lesbar. Natürlich gibt es sehr viele Schriftarten, die ordentlich was her machen, jedoch hilft es nicht, wenn diese nicht komfortable für den Leser sind. Eine gute Lösung für das Problem der passenden Schriftgröße ist, wenn der Besucher die passende Größe selbst bestimmen kann.
4. Autsch! Das tut ja weh…
   Meiden Sie weitestgehend besonders grelle und scharfe Farben. Die gewählten Farbkombinationen sollten auch nach 10 Minuten noch keine Kopfschmerzen verursachen. Das Farbkonzept sollte sich an der Farbwirkung und der Stimmung, die sie dem Leser vermitteln möchten, orientieren.
5. Wo ist denn nur?
   Neben einem ansprechenden Design, muss eine gute und übersichtliche Navigationsstruktur den Leser auch zur gewünschten Seite führen und nicht verwirren. Spielen Sie nicht mit der Geduld des Besuchers.
6. Ach nein, nicht das auch noch!
   Gehen Sie vorsichtig mit Flash-Elementen um. Nicht jeder Besucher mag Intros und die damit verbundenen Ladezeiten. Gekoppelt mit Musik, kann das zu einem Schreckmoment beim Besucher führen, der vielleicht nicht in der passenden Umgebung ist, um diese Mühe wertzuschätzen. Sollten Sie dem Leser doch etwas für seine Ohren bieten wollen, lassen Sie ihm dennoch die Wahl, durch das Klicken des „Play“-Buttons.
7. Das sieht ja komisch aus!
   Stellen Sie frühzeitig sicher, dass Ihre Webseite auch mit allen gängigen Browsern richtig anzeigt wird. Nicht alle Browser können alle CSS Elemente oder Programmiersprachen in der neusten Version wie gewünscht und erhofft darstellen. Optimieren Sie die Webseite für die am meist genutzten Browser.
8. Hört das den gar nicht mehr auf?
   Vermeiden Sie zu lange Seiten. Leser scrollen nicht gern auf endlosen Seiten um nach den gewünschten Inhalten zu suchen. Die Seiten sollten kurz gefasst und gut strukturiert sein.
9. Ich find das einfach nicht!
   Machen Sie es dem Besucher leicht und ermöglichen Sie es ihm, mit Hilfe eines Suchfensters auf der ganzen Seite nach Inhalten suchen zu können.
10. Nicht noch mehr Werbung!
    Vorsicht ist geboten, bei der Anzahl der Werbeschaltungen auf der eigenen Seite. Ihre Leser werden den ganzen Tag mit Werbung konfrontiert, von daher sollten Sie die Nerven Ihrer Besucher nicht überstrapazieren. Zu viele Werbeflächen wirken abschreckend und verärgern den Besucher.

Natürlich könnte man diese Liste noch um einige Fehlerquellen erweitern. Doch viel wichtiger ist, dass man mit wenigen Schritten viele Dinge auf einer Webseite wesentlich verbessern kann.

Ich hoffe der Artikel hat euch gefallen. Wenn ihr auch mal ein Thema für einen Artikel habt, den ihr gerne schreiben möchtet, aber selbst keinen Blog habt, auf dem ihr ihn veröffentlichen könnt, dann her damit. Wenn es thematisch passt werde ich ihn gerne für euch veröffentlichen.

Ankunft und Location

Nachdem ich endlich das richtige Gebäude gefunden hatte und mich angemeldet hatte, gab es wie auch im letzten Jahr ein sehr tolles T-Shirt. Vor der ersten Session wollte ich mich noch schnell mit einem Cappuccino stärken. Das hätte ich lieber gelassen, denn er war ein löslicher, der mit viel zu wenig Wasser aufgegossen eigentlich ungenießbar war und mir noch 5 Stunden später einen unangenehmen Nachgeschmack bescherte. Die Räume der Uni, die für das WordCamp gebucht waren, hatten eine recht gute Einrichtung. Nur an die wippenden Stühle konnten sich so manche Teilnehmer nicht gewöhnen. Ich fand sie super bequem.

Die ersten Sessions

Meine erste besuchte Session hatte das Thema „Ecommerce Lösungen für WordPress“ die ich vor Allem deshalb besucht habe, um mal von Experten zu erfahren, ob es wirklich keine guten Shop-Plugins für WordPress gibt. Diese Annahme wurde im Großen und Ganzen bestätigt, da viele der Plugins einfach nicht optimal an das deutsche Rechtssystem angepasst sind. Aber als Nischenprodukte für Kleinunternehmen war schon was dabei. Ansonsten nutzt man eher eine ausgewachsene Shop-Software und versucht diese einfach soweit es geht an das Layout des eigenen WordPress-Blogs anzupassen.

Anschließend ging es in die Session „Hook me!“ die hoffnungslos überfüllt war. Nicht ganz ohne Grund, stellen doch Filter und Actions die mächtigsten Waffen im Umgang mit WordPress da. Dort wurden auch einige meiner ewig offenen Fragen beantwortet. Aber sehr ins Detail ging er Referent leider nicht um nicht mit einem Beispiel die Verwendungsmöglichkeiten zu stark einzuschränken. Im Grunde kann man mit Hooks (fast) alles anstellen und das konnte er auch gut vermitteln.

Die letzte Session vor der Mittagspause drehte sich um das Thema „Kundenprojekte mit WordPress als CMS“. Dies beinhaltete einen fast einstündigen Vortrag über Projektmanagement und den richtigen Umgang mit Kunden. Aber die Fallbeispiele am Ende der Session haben meine erste Enttäuschung doch noch gemildert.

Mittagspause

Da es vormittags nur Obst und Süßigkeiten gab war ich praktisch ohne echtes Frühstück in den Tag gestartet. Umso schöner war es dann, zum Mittag eine große Auswahl an belegten Brötchen vorzufinden. Jeder, der sich über die 10€ Gebühr aufregt (die komplett an eine gemeinnützige Organisation gespendet werden), der hat wohl spätestens jetzt keine Argumente mehr gefunden. Da das Wetter auch mitspielte machten es sich einige Teilnehmer draußen auf der Wiese bequem. Gut gestärkt konnte ich mich also in die zweite Hälfte des WordCamp stürzen.

Die improvisierte zweite Hälfte

Die erste Session „Formular-Plugins im Vergleich“ war schon eine viertel Stunde vorher sehr gut gefüllt. Leider konnten selbst Suchaufrufe über Twitter den Referenten nicht beibringen. Jeder Teilnehmer der rein kam wurde gleich als möglicher Referent gefeiert. Die Leitung las wohl auch die Twitter Posts und teilte uns dann mit, dass der Referent leider krank sei und nicht abgesagt hatte. Ganz spontan meldete sich dann aber ein Teilnehmer als Moderator für eine offene Diskussion, bei der verschiedene Teilnehmer ihre Erfahrungen zu den diversen Plugins vorstellten. Die Plugins mit cformsII und Formidable Forms bekamen dabei den größten Zuspruch der Teilnehmer. Aber auch Fast Secure Contact Form bekam gute Kritiken, nicht nur als Kontaktformular.

Anschließend besuchte ich die Session „Was kann man mit WordPress machen?“ von den Jungs von inpsyde. Sie stellten ein paar Lösungen vor, die sie mit WordPress umgesetzt haben. Was BuddyPress angeht haben sie echt ein paar super coole Features entwickelt. Bei der Vorstellung einer komplett „ajaxifizierten“ Seite war ich dann aber doch an ein Projekt erinnert, das bei dem ich selbst eine ähnliche oder sogar noch erweiterte Funktion umgesetzt habe. Zuletzt konnte man ihnen Fragen stellen, die einem schon lange im Kopf rumschwirren. Aber auf meine Frage, ob man innerhalb von THE LOOP erkennen könne, den wievielten Post man gerade ausgibt, hatten sie auch nur eine ähnlich unbefriedigende Lösung wie ich selbst parat: Mit einer externen globalen Zählvaribalen.

Im Anschluss an diese sehr interessante Session zog es mich in die „Übersetzerrunde“, die allerdings nur aus vier Personen bestand. Also unterheilten wir uns fast eine Stunde lang um die Problematik der deutschen Community. Zuletzt lernten wir dann aber doch alle noch etwas dazu, und zwar, dass man Übersetzungen auch auf einen Kontext beziehen kann. Das wird in WordPress mit der Funktion _x() realisiert.

Zum Abschluss des WordCamp besuchte ich die Session „Geld verdienen mit WordPress“, die auch wieder zu einer Diskussionsrunde erklärt wurde, da auch hier der Referent nicht anwesend war. Ich habe hier aber einige sehr interessante Möglichkeiten kennengelernt, die mir früher noch nie in den Sinn gekommen sind. So habe ich mich gestern bei der VG Wort angemeldet. Somit erhalte ich bei ausreichend Aufrufen eines Artikels Tantiemen als Autor von der VG Wort. Dass so etwas mit Blogs überhaupt möglich ist und man nur 1500 Aufrufe pro Jahr und Artikel benötigt, hätte ich nicht gedacht. Andere Tipps, abgesehen von klassischer Werbung, waren der Verkauf von Link oder auch Support-Leistungen wie Video-Trainings, Schulungen, Wartung von Blogs und ähnliches. Für den seit einiger Zeit bei mir zu findenden Flattr-Button gab es aber keine Zustimmung. Er scheint wohl im deutschen Markt wirklich noch nicht angekommen zu sein. Daher werde ich ihn wohl bald wieder entfernen und dadurch das Laden meines Blogs wieder beschleunigen.

Fazit

Damit endete dann auch schon das diesjährige WordCamp. Es waren zwar nicht wirklich viele WordPress-Entwickler-Themen dabei, aber so konnten auch Einsteiger oder Blog-Autoren auf einem angenehmen Niveau neues lernen. Ich habe trotzdem einige neue Tricks gelernt und kann damit nur sagen, dass ich auch im nächsten Jahr wieder teilnehmen werde, wenn es sich zeitlich einrichten lässt. Leider wurde noch nicht gesagt, wo es im nächsten Jahr stattfinden wird.

Ich hoffe euch hat die kleine Zusammenfassung einen guten Eindruck zum WordCamp vermitteln können. Wenn ihr zu einer bestimmten Session noch mehr Informationen haben möchtet, dann hinterlasst doch einfach einen kurzen Kommentar.

Ach ja, fast hätte ich es vergessen: Meine Rückfahrt von Köln verlief leider auch nicht wie geplant. Dieses Mal fiel aber gleich der ganze ICE aus, da ein Defekt am Triebwagen vorlag. So kam ich auch bei der Rückfahrt über eine Stunde zu spät in Berlin an. Aber immerhin gab es so insgesamt 25% des Fahrpreises zurückerstattet. Trotzdem hoffe ich, dass es im nächsten Jahr mal wieder reibungslos verläuft

Dann ging es nur noch darum eine günstige Verbindung nach Köln zu bekommen. Und nun sitze ich im Zug Richtung Köln und freue mich schon auf viele spannende Themen rund um WordPress.

Sollte wie auch im letzten Jahr der ein oder andere von euch auch mit dabei sein, dann treffen wir uns ja morgen wieder. Alle anderen kann ich nur damit vertrösten, dass ich auch dieses Mal wieder meine Eindrücke mit euch teilen und die besten Tipps nochmals hier vorstellen werde.

Aber ich war mit dieser Lösung überhaupt nicht zufrieden. Bei meiner Arbeit mit WordPress arbeite ich NIE im Core. Sollte es zu einem Problem mal wirklich keinen HOOK geben, dann versuche ich nach Möglichkeit die Funktionalität aus dem Core zu kopieren um bei einem Update ohne Gefahr dieses einspielen zu können. Bei der Anpassung von Übersetzungen eines Themes ist das aber wieder eine andere Sache. Das geht leider nicht ohne weiteres. Verwendet man allerdings ein Theme-Framework wie Thematic, für das man ein Child-Theme erstellen kann, dann gibt es dazu eine recht einfache Lösung.

Die Problemstellung

Für den Blog wollten wir den String “Tag Archives:” in “Schlagwort:” übersetzen. Die normale Übersetzung hierfür in Thematic ist “Tag-Archiv:”. Der erste Anstz war wie schon erwähnt das Bearbeiten der originalen Übersetzungsdatei, was aber zu dem beschriebenen Update Problem führt.

Die Lösung

Seit der Einführung von Child-Themes gibt es die Möglichkeit auch eine Übersetzungsdatei für ein Child-Theme zu laden. Dazu wird die Funktion load_child_theme_textdomain() verwendet, die allerdings noch nicht in Codex dokumentiert ist. Als ersten Parameter erwartet die Funktion eine Domain, also einen String, der auch in den Übersetzungsfunktionen verwendet wird. Sehen wir uns dazu folgendes Beispiel an:

$content = __('Tag Archives:', 'thematic');

In diesem Beispiel ist der zu übersetzende String “Tag Archives:” und die Domain ist “thematic”. Normalerweise verwendet man für sein Child-Theme eine eigene Domain, aber man kann auch die Domain “thematic” verwenden. Genau das ist auch der Trick, um eine Übersetzung von Thematic zu überschreiben. Wir verwenden einfach eine eigene Child-Theme Übersetzungsdatei zum überschreiben bestehender Strings.

Der zweite Parameter der Funktion load_child_theme_textdomain() ist optional und gibt den Pfad zur Übersetzungsdatei an. Wenn sich diese direkt in eurem Child-Theme-Ordner befindet, dann müsst ihr ihn nicht angeben. In unserem Blog haben wir aber einen Ordner “languages” erzeugt, in dem die Übersetzungen liegen. Wir müssen daher den absoluten Dateipfad zu diesem Ordner angeben. Den absoluten Pfad zum Child-Theme Ordner liefert uns die Funktion get_stylesheet_directory(). Das einbinden unserer Übersetzungsdatei sieht also wie folgt aus:

load_child_theme_textdomain('thematic', get_stylesheet_directory() . '/languages' );

Das ist auch schon alles. Mit dieser einem Zeile in der Datei “functions.php” eures Child-Themes könnt ihr eure eigene Übersetzungsdatei einbinden. Wie ihr seht verwende ich hier die Domain “thematic” um auch die Übersetzungen von Thematic überschreiben zu können. Ihr müsst dazu auch nicht den gesamten Inhalt der Übersetzungsdatei aus Thematic in eure kopieren. Es reicht aus, wenn ihr nur die zu ändernden Strings einfügt. Ihr könnt selbstverständlich auch eigene Strings einfügen, die ihr eventuell in eurem Child-Theme verwendet. Dabei müsst ihr dann nur in der Übersetzungsfunktion ebenfalls “thematic” als Domain angeben.

Ich hoffe, der Tipp konnte euch zeigen, was man mit Child-Themes alles machen kann und wieso die Verwendung eines Thema-Frameworks die Individualisierung eures Themes nicht unbedingt einschränkt. Mein Blog wir eventuell im Laufe des Jahres auch ein neues Design bekommen und mit den bisher gesammelten Erfahrungen zu Thematic, werde ich wohl auch hierfür auf ein Child-Theme setzen und nicht auf ein komplett eigenes Theme. Über Kritik und Kommentare würde ich mich wie immer sehr freuen.

Ich hatte mein schönes neues HTC Sensation noch keine Woche so richtig in Betrieb, da wurde mir schon per Benachrichtigung ein Update auf Android 2.3.4 angeboten. Das ging super einfach direkt per WLAN und war in wenigen Minuten runtergeladen und installiert. Ich könnte aber selbst keine großen Änderungen feststellen.

Heute habe ich dann in einer alten Nachricht auf Golem.de gelesen, dass eine wirklichsehr nützliche Funktion mit den Update mitgeliefert wurde: Systemweite Screenshots.

Um einen Screenshot anzufertigen muss der Ein/Aus-Taster und die Home-Taste gleichzeitig gedrückt werden. Dabei zuerst den Ein/Aus-Taster gedrückt halten und dann die Home-Taste drücken. Der Screenshot wird dann im Album “Kameraaufnahmen” gespeichert.

Ich finde diese Funktion wirklich sehr nützlich. Vor allem bei Fehlern kann es sehr hilfreich sein einen Screenshots zu machen um ihn dann dem Entwickler der App zu schicken oder in einem Forum zu posten.

Kennt ihr vielleicht auch noch tolle versteckte Funktionen oder Shortcuts in Android? Ich entdecke erst so langsam die vielen Funktionen und würde mich über den ein oder anderen Tipp in einem Kommentar sehr freuen.

Nachtrag

Da mein Artikel anscheinend sehr interessant für viele Android-Nutzer ist, habe ich mich mal schlau gemacht, ob es diese Screenshot Funktoin auch für andere Android Smartphones gibt. Leider gab es bisher nur wenige Möglichkeiten überhaupt Screenshots zu erstellen. Ein Möglichkeit ist wohl das Android SDK, wobei hier wohl nur von dem Android Emulator Screenshots gemacht werden konnten, nicht aber von eurem eigenen Smartphone. Die zweite Möglichkeit bietet die Software MyPhoneExplorer. Aber ich habe kein gutes Gefühl dabei einer App so viele Rechte auf mein Smartphone zu geben. Daher habe ich den Einsatz dieser Software bisher vermieden. Die dritte Möglichkeit, die ich gefunden habe, ist die App ShootME, die aber anscheindend nicht mehr offiziell verfügbar ist. Um sie einsetzen zu können muss dass Smartphone aber “gerootet” werden. Danach lassen sich dann aber sogar Screencats (also Videos) aufnehmen. Das wäre auch eine geniale Standard-Funktion für Android.

Da es mit Gingerbread nun anscheindend möglich ist, dass Apps direkt auf den Bildschirminhalt zugreifen können (die Berechtigung durch den Benutzer vorausgesetzt), könnte es in Zukunft von weiteren Herstellern eine Funktion für Screenshots geben. Denkbar ist aber auch eine Standard-Funktion in einer der nächsten Android Versionen. Oder es gibt dann Apps wie ShootME, die ohne Root-Rechte funktionieren.

Mittags habe ich dann bei Golem.de erfahren, wieso WPtouch aktualisiert wurde. Bei drei bekannten Plugins (neben WPtouch waren es AddThis und W3 Total Cache) wurde Schadcode in das SVN Repository eingeschleust. Wie genau es dazu kam ist nicht bekannt. Es ist aber zu vermuten, dass die Passwörter der Plugin-Autoren geknackt wurden. Details zu den Schäden, die der Schadcode hätte anrichten können, wird zur Zeit vom WordPress Team geprüft.

Die Folgen

Wie bei Golem.de nachzulesen war, wurden die Passwörter zurückgesetzt. Ich ging zuerst davon aus, dass es sich nur auf die Passwörter der drei Plugins bezieht. Bei einer kleinen Überarbeitung einer meiner Plugins musste ich dann aber feststellen, dass die Passwörter aller WordPress Nutzer zurückgesetzt wurden. Ich habe also auch meines zurückgesetzt und dabei auf ein sichereres geändert.

Nachdem ich mit meinen Änderungen fertig war und diese per Commit in das SVN Repository gestellt habe wurde ich dann natürlich erst einmal nach dem neuen Passwort gefragt. Ein paar Sekunden später hatte ich auch schon eine Mail von WordPress in meinem Postfach. Darin war der Commit inklusive des Changelogs zu finden. Mit dieser Maßnahme wird zwar nicht verhindert, dass Schadcode ins Repository eingeschleust wird. Aber da es ca. 10min dauert, bis eine neue Version auch den Nutzern zum Download angeboten wird, sollte es dem Plugin-Autoren möglich sein, den Code wieder raus zu nehmen.

Fazit

Niemand darf blind einem Plugin vertrauen, auch wenn es von einem seriösen Entwickler stammt. Aber es ist vorbildlich, wie WordPress auf diesen “Einbruch” reagiert hat. WordPress ist noch immer eine der sichersten CMS- und Blogging-Systeme, wie verschiedene Test immer wieder zeigen. Auch durch die sehr aktive Community werden solche Sicherheitslücken in Zukunft vermutlich sehr schnell gefunden und behoben.

Neben den 100 Artikeln kamen 273 Kommentare (105 davon von mir) zusammengekommen. Das sind mit 134 im Vergleich zum letzten Jahr fast gleich viele, wie im ersten Jahr. Dazu haben sich aber seit letztem Jahr ca. 10550 Spam-Kommentare gesellt. Meine Hoffnung diese Quote etwas zu verbessern hat sich also nicht erfüllt.

Der Besucherrekord wurde im letzten Jahr am 18.06.2010 mit 185 Aufrufen aufgestellt. Es besteht aber noch die Hoffnung, dass heute zum 2. Geburtstag dieser Wert noch getoppt wird. Ich schreibe daher den Artikel auch so spät. Es sind aber im Moment nur 184 Aufrufe. Aber vielleicht bekomme ich ja gleich nach dem Veröffentlichen dieses Post noch die fehlenden 2 für den neuen Rekord.
Es hat gereicht! Es sind gestern doch noch 192 Aufrufe zusammengekommen. Somit ist der 21.06.2011 nun der Tag mit den meisten Besuchern. Ich habe aber kein Problem damit, wenn der neue Rekord nicht wieder fast ein Jahr benötigt

Die drei erfolgreichsten Artikel insgesamt waren:

1. Internet Explorer 6 unter Windows 7 nutzen mit dem Windows XP Mode
2. VeriFace – Die Zukunft der Computersicherheit oder nur eine tolle Spielerei?
3. Google Maps Suggest – Adress-Autovervollständigung mit Scriptaculous

Letztes Jahr habe ich euch ja an dieser Stelle als kleines Geschenk das Video Gimme Hope Joachim präsentiert. Aber obwohl am Sonntag die Frauen zu ihrer WM starten, gibt es kein Video dazu. Also zeige ich euch eines meiner Absoluten Favoriten aus YouTube. Auch wenn ich kein Schwabe bin, schmeiß ich mich jedes Mal vor Lachen weg:

Jetzt bleibt mir nur noch euch viel Spaß im kommenden Jahr mit meinem Blog zu wünschen. Vielleicht erfüllt sich ja noch einer meiner Wünsche in diesem Jahr.

Euer
Kau-Boy

Das Problem ist aber meistens, das genau die Nutzer, die noch den IE6 verwenden, in einem Unternehmen sitzen. Diese können oft nicht selbst auf einen neuen Internet Explorer wechseln und da sie auch keine Berechtigung haben, Software zu installieren, können sie auch das Plugin nicht verwenden. Wie heute unter anderem bei Golem nachzulesen war, hat Google dieses Problem jetzt lösen können.

Mit der aktuellen Entwicklerversion ist kann jeder Nutzer, der nur über eingeschränkt Rechte verfügt Google Chrome Frame verwenden. Somit können Anwendungen, die noch den IE6 voraussetzen weiter genutzt werden und der Nutzer profitiert auf modernen Seiten gleichzeitig von den neuen Funktionen von HTML5, sofern die notwendigen Angaben im HTML-Quellcode gemacht wurden.

Es bliebt zu hoffen, dass möglichst viele Nutzer von dieser Möglichkeit erfahren und wir somit dem überfälligen Ende des IE6 vielleicht etwas näher kommen. Ich überlege zumindest, allen meinen IE6 Nutzern demnächst einen dezenten Hinweis zu geben, was ihnen mit dem Internet Explorer 6 entgeht, und was sie stattdessen sehen könnten.

Um SOAP nutzen zu können, muss es über die php.ini Datei aktiviert werden oder in das Verzeichnis für die Erweiterungen (z.B. unter /usr/lib64/php5/extensions). Was aber, wenn die SOAP Bibliothek nicht installiert ist? Dann muss man es je nach Betriebssystem nachinstallieren. Unter Linux geht das über die Paketmanager oft am einfachsten.

Für openSUSE könnt ihr hierfür den Paketmanager YAST verwenden. Der Befehl dazu lautet wie folgt:

yast -i php5-soap

Der Vorteil bei der Installation über den Paketmanager: Die Bibliothek wird auch gleich in die bestehende Konfiguration eingetragen. Somit könnt ihr direkt nach der Ausführung des Befehls loslegen. Solltet ihr noch nie mit Webservices gearbeitet haben, dann findet ihr in der PHP Doku die wichtigsten Funktionen von SOAP in PHP.

Jetzt viel Spaß oder auch viel Ärger mit SOAP

Die Grundlegenge Ordnerstruktur

Es gibt keine fest vorgegebene Struktur für ein Repository. Es hat sich aber eine Struktur herausgebildet, die von den meisten Projekten, die Subversion einsetzen benutzt wird. Diese wird auch in der SVN-Referenz (deutsche Übersetzung) beschrieben. Dazu werden im Hauptverzeichnis folgende drei Ordner erstellt:

/
	trunk/
	branches/
	tags/

Solltet ihr mehrere Projekte in einem Repository verwalten, dann macht es Sinn für jeder eine solche Ordnerstruktur anzulegen:

/
	projekt1/
		trunk/
		branches/
		tags/
	projekt2/
		trunk/
		branches/
		tags/

Neues Repository mit dieser Ordnerstruktur erzeugen

Am besten erzeugen wir also gleich zu Beginn eines neuen Projekts eine solche Struktur. Gehen wir einfach mal von einem einfachen Repository mit nur einem Projekt aus. Ich möchte euch kurz die notwendigen Befehle aufzeigen um ein Repository für nur ein Projekt mit einer solchen Ordnerstruktur zu erzeugen.

Zuerst einmal erstellen wir in einem beliebigen Ordner ein neues Repository um dieses anschließend verwenden zu können:

svnadmin create /var/svn/public/myproject

Um nun die notwendigen Verzeichnisse zu erzeugen gibt es zwei Möglichkeiten:

1. Auschecken des Repositories, erzeugen der Ordner und commit der Ordnerstruktur
2. Direktes erzeugen der Ordner im Repository

Die erste Variante bietet sich an, wenn man gleich mehrere Projekte mit der Ordnerstruktur erzeugen möchte. Ich zeige euch hier kurz, welche Befehle dabei in Unix-Systemen notwendig wären:

cd ~
mkdir project
cd project/
svn checkout http://kau-boys.de/svn/myproject
cd myproject/
mkdir trunk tags branches

Jetzt müssen wir die Ordner zum Hinzufügen in das Repository markieren mit dem Befehl svn add:

svn add trunk tags branches

A         trunk
A         tags
A         branches

Jetzt können wir diese Ordnerstruktur in das Repository commiten:

svn commit -m "Import der initialen Ordnerstruktur"

Adding         branches
Adding         tags
Adding         trunk

Committed revision 1.

Die andere Möglichkeit ist wesentlich einfacher und erfordert nur einen einzigen Befehl. Dieser erzeugt die Ordnerstruktur direkt im Repository. Auch hier wäre es möglich die Ordner gleich für mehrere Projekte anzulegen (was ihr am besten mit mehreren Befehlen macht):

svn mkdir -m "Import der initialen Ordnerstruktur" \
	file:///var/svn/myproject/trunk \
	file:///var/svn/myproject/tags \
	file:///var/svn/myproject/branches

Committed revision 1.

Wie ihr seht ist diese Variante sehr viel einfacher. Gerade für den Administrator eines Repositories ist er praktischer. Man könnte den z.B. den gesamten Prozess zur Erzeugung eines Repositories und der Ordnerstruktur in einem Skript zusammenfassen, dass alle notwendigen Befehle automatisch hintereinander ausführt.

Das richtige Verzeichnis auschecken

Ganz wichtig ist es nun aber, dass ihr auch das richtige Verzeichnis benutzt um euer Projekt zu starten. Solltet ihr die Ordnerstruktur wie in der ersten Variante erzeugt haben, wechselt in eure Working Copy und benutzt dort den Befehl svn switch um auf das trunk Verzeichnis zu wechseln:

cd ~/myproject
svn switch http://kau-boys.de/svn/myproject/trunk

D    trunk
D    branches
D    tags

Wie ihr sehen könnt, wurden die Ordner gelöscht, da ihr euch nun “im Ordner trunk” befindet. In diesem könnt ihr nun eure Dateien des Projekts commiten.

Wenn ihr die Ordnerstruktur wie in Variante 2 erzeugt habt, dann müsst ihr lediglich das richtige Verzeichnis auschecken. Gebt also direkt den trunk Ordner bei auschecken an:

cd ~
svn checkout http://kau-boys.de/svn/myproject/trunk myproject

Checked out revision 1.

Damit der Ordner aber dabei nicht trunk heißt geben wir beim checkout Befehl gleich den Namen des Ordners an, den unser Projekt nachher haben soll, also in diesem Fall myproject.

Fazit

Ihr habt nun also gesehen, wie man eine gute Ordnerstruktur für Subversion-Projekte anlegt. Falls ihr euch aber fragt, wieso das so wichtig ist, dann seht euch mal Kapitel 4 der SVN-Referenz (deutsche Übersetzung) an. Ich mal bei einem Projekt zwar einen Ordner trunk erzeugt aber diesen als Root-Verzeichnis meines Repositories benutzt. Als ich dann (ca. 10000 Commits später) dann doch mal branches einsetzen wollte, bekam ich natürlich Probleme, da ich dann erst die Unterverzeichnisse erzeugt habe und alle anderen Order und Dateien per svn move in den Ordner trunk verschieben musste. Dabei bleibt zwar die History aller Dateien erhalten, aber jeder Benutzer musste den Pfad zum Repository aktualisieren und dann in den neuen trunk Ordner wechseln.

Wenn ihr euch also schon immer zu Beginn eines neuen Projekts die Ordner erzeugt spart ihr euch nachher viel Arbeit. Selbst wenn ihr denkt, niemals so komplex zu werden, dann seht mal in der SVN-Referenz unter dem Stichpunkt Feature-Release nach. So etwas könnte auch euch mal passieren. Also spart nicht an dem einen Befehl und den drei Ordnern