Sie sind zwar nur noch selten anzutreffen, halten sich aber hartnäckig, die Javascript-Rechtsklicksperren. Dabei sind sie praktisch wirkungslos, nur noch absolute Computerlaien lassen sich damit verblüffen. Und dann will da jemand auch noch Sachen damit „schützen“, die er selbst nur von einer anderen Seite „geklaut“ hat. *tststs*
Eine neue WordPressinstallation enthält üblicherweise bereits ein paar Beispieldaten. So sind schon eine Seite und ein Artikel mit einem Kommentar vorhanden, etwa wie dieser hier. Die Blogrolle ist auch schon mit ein paar Links gefüllt.
Wenn man das nicht möchte, weil man beispielsweise einen WordPress-Export (per WP-Export als xml) importieren möchte und die IDs der Artikel und Seiten erhalten bleiben sollen, kann man eine benutzerdefinierte Installation verwenden.
WordPress lädt am Anfang der Installation die Datei wp-content/install.php, falls sie vorhanden ist. In dieser kann man einige Installationsfunktionen „überschreiben“. Das funktioniert so wie bei den Funktionen aus der pluggable.php im Verzeichnis wp-includes. WordPress prüft, ob eine Funktion bereits vorhanden ist:
if ( !function_exists('wp_install') ) :
...
endif;
Falls nicht, wird die WordPress-Funktion „installiert“, andernfalls wird die bereits vorhandene verwendet. Die wordpresseigenen Installationsfunktionen findet man in wp-admin/includes/upgrade.php, diese kann man sich als Vorlage für eigene Modifikationen hernehmen.
Um nun eine leere WordPress-Installation zu erhalten, wird die Funktion wp_install_defaults in der Datei wp-content/install.php neu definiert:
<?php
function wp_install_defaults($user_id) {
}
?>
Es ist einfach eine leere Funktion, dadurch wird aber auch keine Default-Kategorie für Artikel und Links erstellt. Möchte man die Standardkategorien trotzdem haben, nimmt man den oberen Teil aus der originalen WP-Funktion (bis // Now drop in some default links) in die eigene Funktion mit rein. Dabei das global $wpdb nicht vergessen.
Wie man auf diese Weise bereits Plugins bei der Installation aktivieren kann, hatte ich früher schon mal beschrieben.
Nachdem die Anpassungen in der install.php vorgenommen wurden und diese in das WordPress-Content-Verzeichnis kopiert wurde, kann man die WordPressinstallation wie gewohnt starten.
WordPress habe ich seit Oktober 2006 in Benutzung (1&1 Fertigblog), mein erstes selbstinstalliertes WordPress im November 2006 hatte die Version 2.0.4. Seitdem ist einige Zeit ins Land gegangen und mittlerweile sind wir bei WordPress Version 2.9.1 angekommen, die Version 3.0 ist schon angekündigt und soll im März erscheinen.
Mit jeder neuen WordPress-Version gab es meist neue Funktionen, manchmal war eine neue Ausgabe aber auch nur ein Sicherheits-Release, um bekannt gewordene Sicherheitslöcher zu stopfen. Damit sind Sicherheitslücken und deren Ausnutzbarkeit immer von der WordPress-Version abhängig, wodurch die Versions-Information für einen Angreifer durchaus interessant ist.
WordPress liefert in der Standardinstallation die Versionsinformationen gleich an drei Stellen mit. Zwar sind diese für den normalen Besucher üblicherweise nicht sichtbar, aber in der Seite vorhanden.
Im Header der Seite
Wen man sich den HTML-Quelltext einer Seite ansieht, findet man dort möglicherweise im Header einen Eintrag wie <meta name=“generator“ content=“WordPress 2.9.1″ />
Im Feed
Wen man sich den XML-Quelltext eines Feeds (RSS, Atom) ansieht, findet man dort möglicherweise am Anfang (channel) einen Eintrag wie <generator>http://wordpress.org/?v=2.9.1</generator>
In der readme.html
Mit jeder WordPress-Version wird eine Datei readme.html und in der deutschen Version auch liesmich.html mitgeliefert bzw. installiert. Diese findet man im WordPress-Wurzelverzeichnis. Da steht die WordPress-Version ebenso drin:
Man mag darüber streiten, ob es sinnvoll ist, die Versionsnummer vor Bots oder wem auch immer zu verbergen. Für die Unterdrückung der Ausgabe in den Seiten und Feeds gibt es diverse Lösungen. Wenn man nun aber so großen Wert darauf legt, die WP-Version zu verstecken, sollte man unbedingt auch die readme.html (liesmich.html) löschen. Aber Achtung, beim nächtens (automatischen) Update ist sie wieder da.
Eigentlich wollte ich ja einen Beitrag zum letzten Webmaster-Friday-Thema schreiben, aber erstens verwende ich Google-Analytics nicht, zweitens habe ich Piwik gerade mal vor einer Woche testweise installiert, kann also dazu noch nicht wirklich was sagen, drittens interessieren meine LogfileauswertePHPSkripts eh niemanden und schlußendlich bin ich keine SEO.
Da kommt mir so ein Experiment mit Bilderdateinamen wie Mohakenox gerade recht. Denn oder gerade weil noch keine Testbilder in der Bildersuche zu finden sind, bleibt genug Spielraum für die Betrachtung anderer Bilder. Wurden vor einigen Tagen noch vorwiegend hunderte Bilder von prometeo gefunden, sind diese fast alle wieder verschwunden.
Dafür machen sich jetzt Schnurpsel-Bilder breit, wie z.B. auf der zweiten Trefferseite. Dort findet man auch ein Brötchen. Das ist allerdings kein Schnurpsel-Brötchen, sondern ein Putzlowitsch-Brötchen, welches derzeit auf Platz 4 der Bildersuche zum Stichwort Brötchen zu finden ist. Auf dem ersten Platz liegt immer noch das häßliche MKB-Brötchen, aber bereits auf Platz 2 folgt ein SEO-Brötchen.
Es gibt aber nicht nur Brötchenfotos, sondern auch Brötchen-Grafiken. Die findet man aber erst auf der zweiten Trefferseite. Bisher haben allerdings alle Brötchen-SEO-Maßnahmen noch nicht ausgereicht, um den begehrten 1. Platz zu erreichen. Auf die erste Trefferseite zu kommen, ist nicht besonders schwer. Aber am ersten Platz beißen sich bisher alle die Zähne aus, das Brötchen da ist einfach zu hart und vertrocknet.
Es gab zwar mal zeitweise einige Verschiebungen auch mit der Top-Position, die aber leider nicht von großer Nachhaltigkeit geprägt waren. So muß ich resümieren, daß Brötchen-SEO auch mit einem SEO-Brötchen derzeit noch brotlose Kunst ist.
Bananen und Orange
