Erst begrüßt mich die Loginseite des Strato-Webhostig mit dieser Meldung.
Na gut denke ich, kann ich ja mal schnell mein Profilbild bei Twitter ändern. Ich finde ja eigentlich die Schwarz-Rot-Gelben-M&Ms schöner als die Pusteblume. Aber denkste:
Bei Strato kann ich mich mittlerweile wieder einloggen, die Wartungsarbeiten bei Twitter dauern aber noch an.
Nachtrag 11:15 Uhr:
Zu früh gefreut, Strato geht immer noch nicht:
Mut zur Lücke, könnte man sagen, aber das war so nicht beabsichtigt. Vielleicht hat es ja einer der vielen Beobachter beim iPhone4Spiel-Diagramm schon bemerkt. Seit etwa einer Woche stimmt da was nicht. Es gibt seit dem 13. Juli eine datentechnische Lücke für Plätze großer als 10 bei der normalen Suche bzw. größer Platz 20 bei der Bildersuche. Da ist gewissermaßen ein Daten-Sommerloch entstanden.
Solche „Aussetzer“ können zwar auch entstehen, wenn sich die Platzierung jenseits der 100 befindet, denn dort endet die Darstellung des Diagramms (nicht aber die Datenerfassung), aber eine so auffällige Lücke erschien mir doch verdächtig. Es ist recht unwahrscheinlich, wenn auch nicht ausgeschlossen, daß z.B. geld-im-internet mit seinem iPhone4Spiel-Beitrag der in letzter Zeit immer in den Top-20 war, plötzlich auf Plätze über 100 abfällt.
Was war passiert? Ich hole mir die Daten dirket aus den SERPs, parse also die HTML-Seite und extrahiere die Links und Positionen. Zudem habe ich eine Next-Page-Erkennung eingebaut um festzustellen, ob es von der aktuellen Seite aus gesehen jeweils noch eine weitere Ergebnisseite gibt. Genau diese Erkennung hatte versagt und nach der ersten Seite das Einlesen abgebrochen.
Ich habe die Funktion nun etwas robuster ausgelegt und hoffe, daß sie in Zukunft die weiteren Ergebnisseiten zuverlässig erkennt. Verlassen kann ich mich darauf aber leider nicht, also muß ich immer die Daten nach Auffälligkeiten im Auge behalten.
Seit es Twitter und anderen Kurznachrichtendienste gibt, sind kurze URLs sehr wichtig geworden. Bei Wordperess sind Shortlinks schon lange quasi „ab Werk“ eingebaut. Man muße einfach nur die Artikel-ID als Parameter p mit der Seite aufrufen (putzlowitsch.de/?p=1649).
Das funktioniert auch für Attachments wie Bilder, Sounds und sonstige Dateien, die über WordPress hochgeladen und mit der Mediathek verwaltet werden. Allerdings wird hier nicht auf die Datei selbst, sondern auf die Attachment-Seite weitergeleitet (putzlowitsch.de/?p=1650).
Um nun auch direkt auf Dateien shortlinken zu können, sind nur ein paar Zeilen PHP-Code notwendig. Ich habe dafür als Alternative zum Parameter p wie Post den neuen Parameter a wie Attachment eingeführt. Der Aufruf erfolgt dann mit putzlowitsch.de/?a=1650. Die Funktionen habe ich in ein kleines Plugin gepackt, wem zu viele Plugins nicht gefallen, kann auch einfach den Quelltext in der Datei functions.php seines Themes einfügen:
function plw123as_redirect_canonical( $redirect_url, $requested_url ) {
global $wp_query;
if( isset($wp_query->query_vars['a']) ) {
$id = intval( $wp_query->query_vars['a'] );
$url = wp_get_attachment_url( $id );
if( '' == $url ) {
$wp_query->set_404();
status_header( 404 );
$redirect_url = false;
}
else
$redirect_url = $url;
}
return $redirect_url;
}
function plw123as_init() {
global $wp;
// Variable bekannt machen
$wp->add_query_var( 'a' );
add_filter( 'redirect_canonical', 'plw123as_redirect_canonical', 10, 2 );
}
add_action( 'init', 'plw123as_init' );
Download: 123 Attachment Shortlink 0.10
Ich wurde übrigens so ein bißchen von der Statusupdate mit Bildern-Sache zu diesem kleinen PHP-Code angeregt. Kann ja nicht sein, das ich für direkte Links auf Bilder elendig lange URLs verwenden muß. :-)
Nachtrag 16:30 Uhr
Leider wertet die Googlesuche nach Statusupdates eine Weiterleitung auf ein Bild nicht als Bild selbst. Die Bild-URL wird zwar aufgelöst, das Bild aber nicht angezeigt. Schade! Vielleicht ändert sich das ja noch…
Nachtrag 17:45 Uhr
Hmmm, scheint doch mit den weitergeleiteten Bildern bei Google-Statusupdates zu funktionieren, aber nicht immer oder nur manchmal, keine Ahnung…
Google-Statusupdates mit Bildern
Vor ein paar Tagen schrieb ich noch etwas zur (neuen) Timeline bei Google-Social und zu den Profilbildern ebendort und schon gibt es etwas zumindest für mich neues zu entdecken.
Die spezielle Google-Suche nach Meldungen aus sozialen Netzwerken heißt jetzt Statusupdates und man kann dort gezielt nach „Statusupdates mit Bildern“ suchen.
Ich konnte mir einen kleinen Test nicht verkneifen und tatsächlich erscheint zu dem Statusupdate auch das von mir verlinkte Bild in Echtzeit. Es funktioniert scheinbar mit allen Bildern, nicht nur welchen von Twitpic und ähnlichen Diensten, wie ich zunächst vermutet hatte.
Die Echtzeit-Bilder werden genau wie die Profilbilder aber nicht direkt angezeigt, sondern aus einem Google-Cache geladen. Im Unterschied zu den Profilbildern landen sie aber nicht im „normalen“ Server der Bildersuche, sondern auf speziellen Serveren, die unter ggpht.com angesiedelt sind. Das steht vermutlich für Google-Photo oder soetwas in der Art.
Schon erstaunlich, was sich in den letzen Tagen mit den Bildern so getan hat (z.B. Anzeigen). Nun mußte nur noch mal der große Schub mit neuen Bildern kommen und idealerweise auch die Bilderfassung und -verarbeitung für alle Bilder in Echtzeit erfolgen. Na oder zumindest nicht erst nach mehreren Wochen bzw. Monaten.
Wenn jemand meine Schnurpsel-Seite besuchen will, gibt er einfach in der Adresszeile des Browers schnurpsel.de ein. Das Internet funktioniert aber mit IP-Adressen, so ist Schnurpsel z.B. unter der Adresse 81.169.145.149 zu erreichen. Damit der Name in eine IP-Adresse umgesetzt werden kann, gibt es das DNS (Domain Name System) und entsprechende Server, die die Auflösung der Namen übernehmen.
Damit nun der Server nicht jedesmal neu befragt werden muß, werden bereits aufgelöste Namen zwischengespeichert. Einerseits verfügen viele Beriebssysteme über so einen DNS-Cache, teilweise sogar die Browser selbst und auch mein nigelnagelneuer DSL-ISDN-WLAN-Router hat einen solchen DNS-Cache.
Normalerweise bin ich nicht ständig im DNS-Cache zugange, aber so einem neuen Router schaue ich anfangs gern mal auf die Finger. Im Systemprotokoll wird auch brav vermerkt, was der Router gerade so treibt. Etwas verwundert war ich über die zahlreichen Einträge „dnsd: cache add…“.
Da tauchten plötzlich Seiten wie Nerdcore, Stefan Niggemeier, BILDblog, netzwertig.com, CARTA und weitere auf, die ich in den letzten Minuten garantiert nicht besucht hatte. Aber irgendwie kam mir die Liste bekannt vor.
Und richtig, ich hatte kurz vorher bei zusammen.gerech.net einen Blick auf die aktuelle Blog-Top-100 geworfen. Da stehen sie alle in der Liste, nur hatte ich keinen der Links dort angeklickt. Sollte etwa der Firefox…
Seit Firefox 3.5 gibt es ein sogenanntes DNS-Prefetching, der Firefox macht also für alle auf der Seite gefunden Links eine DNS-Abfrage für die verlinkten Seiten. Das soll etwas mehr Geschwindigkeit bringen. Falls der Nutzer einen der Links anklickt, ist die IP-Adresse schon bekannt und es kann sofort losgehen.
Wenn der Nutzer aber keinen der 100 Links anklickt, wurden 100 unnütze DNS-Abfragen getätigt und 100 Einträge im DNS-Cache belegt, die keiner braucht. Der DNS-Cache meines Routers faßt in der Standardeinstellung übrigens genau 100 Einträge. Alles einmal mit Quark gefüllt.
Netterweise kann man im Firefox das DNS-Prefetching abschalten, aber nicht etwa in den Konfigurations-Dialogen, sondern durch einen beherzten Systemeingriff mittels about:config. Wie es geht und viele weitere Einstellmöglichkeiten findet man z.B. bei mozillaZine.
Beim aktuellen Webmaster-Friday geht es um „Kreativ und originell bloggen: was inspiriert Euch?„. Das kann ich für schnurpsel.de recht einfach beantworten. Dieses Blog wird von Beobachtungen, Betrachtungen und Problemen rund um die Themen Internet, Technik, Suchmaschinen, WordPress, Webhoster und ähnlichen getrieben. Das gab, gibt und wird es sicher noch lange geben (siehe oben :-)).