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*
Also irgendwas mache ich falsch!? Bei der Suche nach „Ob Mehrzad oder Menowin ist sowas von Banane“ findet man nicht etwa meinen DSDS-Artikel bei Putzlowitsch, sondern die Seite vom TagSEOBlog, wo ein Trackback von mir steht und außerdem Wikio (siehe Bild). Das sollte mir zu denken geben… Aber woran liegt das eigentlich?
So ein Schreck kurz vorm Wochenende. Da melde ich mich bei meinem Strato-Webhosting-Kundenbereich an und bekomme so eine Meldung angezeigt. Weiter unten steht dann noch:
„… bedauerlicherweise sind für Ihr Kundenkonto Zahlungsschwierigkeiten aufgetreten. Aus diesem Grund sehen wir uns leider gezwungen, einige Dienste einzuschränken.
Möglicherweise haben wir nicht Ihre aktuellen Daten und konnten daher die Lastschrift nicht durchführen. Bitte überprüfen Sie unter Kundenbetreuung – Ihre Kundendaten Ihre Bankverbindung, Ihre Anschrift und Ihre E-Mail-Adresse …“
Nur habe ich keine Daten geändert, das Konto ist auch nicht leer und die Abbuchung hat in den letzten Jahren immer problemlos geklappt. Allerdings konnte ich auch auf die Schnelle keine Einschränkungen bei den Diensten feststellen, wie im Text angemerkt wird. Meine Webseite ist normal erreichbar. Wäre aber auch ein Unding, wenn gleich beim ersten Zahlungsproblem elementare Funktionen eingeschränkt wären.
Aber da ich schon mal vor Jahren bei 1&1 bis zur dritten Mahnung mit Androhung von Inkasso bzw. Rechtsanwalt gekommen war, wollte ich die Sache nicht auf sich beruhen lassen, auch wenn das Problem offensichtlich nicht bei mir liegt. Ein kurzer Anruf beim Strato-Kundenservice bestätigt dann auch meine Vermutung, daß es sich um ein technisches Problem in der Buchhaltung handelt.
Bei 1&1 war es damals auch ein firmeninternes Problem. Ich hatte 2001 meine neue Bankverbindung ordnungsgemäß im Kundenmenü eingetragen und die Abbuchung der monatliche Beträge funktionierte auch ohne Probleme vom neuen Konto. Etwa ein Jahr später habe ich dann das Webhosting-Paket gewechselt und mir für 6 Euro Versandkosten die dazugehörige Software zuschicken lassen. Allerdings versuchte 1&1 nun, warum auch immer, diesen Betrag von meinem alten Konto abzubuchen, was natürlich fehl schlug.
Nach einigen Telefonaten und weiteren Mahnungen habe ich dann die 6 Euro selbst überwiesen, da die das mit der Abbuchung nicht auf die Reihe bekommen haben. Vermutlich steht in meinem Versandkonto oder wo auch immer jetzt noch meine alte Bankverbindung drin. Naja, diese Softwarezugaben braucht man auch nicht wirklich, da kann ich auch drauf verzichten.
Oft kommt es ja nicht vor, aber hin und wieder kommen Besucher mit einer falschen URL hier zu Schnurpsel oder etwas häufiger drüben zu Putzlowitsch. Bei beiden Blogs habe ich es so konfiguriert, das am Ende einer normalen URL zu einem Artikel, einer Seite, den Kategorien und Tags ein Schrägstrich (slash) steht. Das sieht dann etwa so aus:
http://example.com/name-des-artikels/
Manche Besucher, teilweise auch irgendwelche Bots, versuchen eine Seite hingegen so aufzurufen:
http://example.com/name-des-artikels
WordPress ist nun seit Version 2.3 so nett, und leitet die Besucher und Bots per Redirect auf die richtige Seite weiter. Nur warum rufen Besucher überhaupt die falsche URL auf, wo haben die diese her? Von mir bestimmt nicht, bei mir steht da immer ein / am Ende.
Ich habe im Serverlogfile nachgesehen, die normalen Besucher mit der URL ohne Schrägstrich am Ende kommen fast ausnahmslos von der Yahoo-Bildersuche.
Dort wird für einen Treffer die URL der Zielseite immer ohne Slash am Ende angezeigt und auch der Link so gesetzt. Damit klickt der Suchende auf diese falsche URL und muß nun jedesmal von WordPress auf den richtigen Pfad der Tugend gebracht werden. Das beansprucht den Server damit quasi doppelt.
Ab sofort gibt es bei mir keine Weiterleitung mehr. Wer eine falsche URL aufruft, also ohne Schrägstrich am Ende, wenn da aber einer sein sollte, muß halt die Konsequenzen tragen. :-)
Deshalb gibt es nur noch einen schlichten 404er-Fehler. Ist zwar schade für die Besucher, soviele sind das allerdings auch wieder nicht. Gerade die komischen Bots werden damit aber auch ferngehalten. Ist schließlich nicht mein Problem, wenn die falsche URLs verwenden.
Siehe Kommentare.
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.