Heute hat Marc bei sich über die vielen Werbeposts im Wikio-Friends Feed geschrieben und auch darüber, dass er ja den Feed kaum noch liest weil eben so viel Werbung drin ist. Als ich daraufhin in den Kommentaren erwähnte, dass ich ein entsprechendes Script für mich geschrieben habe, mit dem man sich die Werbung ersparen kann, war er offensichtlich recht interessiert an der Lösung. Darum möchte ich sie auch für alle Leser hier noch einmal vorstellen.

Das Script ist vom prinzipiellen Aufbau recht einfach: Es liest den normalen Feed für die Aktion aus und extrahiert daraus die im Feed enthaltenen Adressen der eigentlichen Quellen. Also aus meinen Artikeln im Wikio-Friends-Feed kann es halt meinen Blog-Feed erkennen und auslesen. Das mache ich mir zu Nutze und lasse das Script die Feeds automatisch meinem Google Reader mit einem bestimmten Tag hinzufügen.

Zusätzlich speichere ich alle gefundenen Feed-URLs, damit sie nicht erneut abonniert werden, wenn ich den Feed aus dem Reader werfe weil er mir aus irgend einem Grund nicht gefiel. Das Script muss dafür regelmäßig ausgeführt werden, da im Feed leider immer nur eine kleine Anzahl Posts enthalten ist und somit nur die Blog-Feeds dieser wenigen Posts ausgelesen werden können.

Das Script habe ich als Gist unter folgender URL veröffentlicht: http://gist.github.com/443479

Um das Script zu nutzen wird ein Linux-System (evtl. geht es auch unter Windows) oder ein Mac OSX benötigt. Da ich es selber unter Linux betreibe hier eine kurze Anleitung wie man es einrichtet:

Wenn Ruby schon installiert ist und das JSON-Gem vorhanden ist, entfallen wahrscheinlich die folgenden Schritte aber für alle anderen sind sie nötig:

$ sudo aptitude install ruby libopenssl-ruby rubygems ruby-dev build-essential
$ sudo gem install json

Damit wird Ruby, eine SSL-Erweiterung und das Gem-System installiert. Der zweite Befehl installiert das JSON-Gem, was für die Kommunikation mit dem Google Server benötigt wird.

Danach müssen nur noch im Script-Kopf einige Dinge angepasst werden, die aber im Script selber dokumentiert sind und das Script hin und wieder (ich nehme ein stündliches Interval) ausgeführt werden und schon kommen die Quell-Feeds automatisch in eueren Feedreader, lassen sich aber auch selektiv aus diesem werfen.

Was meint Ihr dazu? Nützliches Script oder doch eher unnötig? Verfolgt Ihr die Aktion überhaupt noch oder habt Ihr es schon aufgegeben?

Update: Bitte nicht den Fix aus dem Post selber nutzen. Der hilft zwar in einigen Fällen aber leider nicht in allen. Nähere Infos zur Lösung, die ich im Twitter angesprochen habe, gibt es im Kommentar von Ocean90 und den darauf folgenden Kommentaren.

Ich mag es schon gar nicht mehr schreiben, da so viele Blogs schon vermeldet haben, dass WordPress 2.9 heute herausgekommen ist. Auch ich habe mich wie üblich dran gemacht das Update zu ziehen und zu installieren. Lief prima das Update und bisher hab ich in 5 Blogs erst ein zerschossenes Plugin gesehen. Also alles in allem kann man recht zufrieden sein.

Aber wenn ich den Titel schon so wähle muss es ja einen Haken geben:

Dieser Tweet von Gilly hat mich dazu gebracht wieder einmal einen Blick in die cron.php zu schauen und was erblicke ich? Richtig! Die Entwickler bleiben auf ihrem Standpunkt, dass 0.01 Sekunden völlig ausreichend sind um andere Blogs zu informieren… *sigh*

Also wie üblich der gleiche Kram mal wieder. In der Datei “wp-include/cron.php” steht in Zeile 229 mal wieder diese nette Anweisung (Alles in einer Zeile!):

wp_remote_post(
    $cron_url,
    array(
        'timeout' => 0.01,
        'blocking' => false,
        'sslverify' => apply_filters('https_local_ssl_verify', true)
    )
);

Daraus macht Ihr weil es ja so schön ist diese Änderung dauernd wieder zu machen folgendes: (Auch wieder alles in eine Zeile, Änderung in rot!):

wp_remote_post(
    $cron_url,
    array(
        'timeout' => 1.00,
        'blocking' => false,
        'sslverify' => apply_filters('https_local_ssl_verify', true)
    )
);

Damit haben wir zumindest mal wieder 1000ms Zeit die anderen Blogs zu informieren und nicht 10ms. (Welcher Blog schafft eigentlich eine Reaktion in 10ms?)

Viel Spaß mit der neuen (alten) Änderung.

Achtung: Diese Anleitung funktioniert nur für das iPhone-SDK 3.0! Im 3.1 scheinen einige Schritte wieder vollkommen anders zu sein. Das konnte ich allerdings noch nicht testen, da ich weder das iPhone-OS-3.1 noch das entsprechende SDK einsetze.

Wie der Titel schon sagt, beschäftigt sich dieser Artikel mit der Entwicklung von Software für ein iPhone mit iPhone-OS-3.0 und installiertem Jailbreak. Das unterscheidet sich in so fern von der normalen Entwicklung, da Apple uns dabei ein paar Steine in den Weg legt, die es zu umgehen gilt. Die Basis, auf der dieser Artikel basiert ist, dass kein Apple-Developer-Account besteht. Also Ihr zwar an das SDK herankommt, allerdings die 99 Euro nicht ausgebt um Software für den App-Store zu entwickeln. In dem Fall würden diverse Schritte wegfallen.

Vorausgesetztes Wissen für die Anleitung:

• Ihr wisst, wie man eine Anwendung für den iPhone-Simulator entwickelt
• Ihr wisst, wo XCode welche Dateien im Projektverzeichnis anlegt
• Ihr könnt mit dem Terminal umgehen
• SSH ist euch ein Begriff

Ich gehe an dieser Stelle davon aus, dass Ihr eine im iPhone-Simulator lauffähige Anwendung mit der Entwicklungsumgebung für das iPhone-OS-3.0 fertiggestellt habt. Diese Anwendung nehmen wir jetzt als Basis für alle weiteren Aktionen. Einige davon müssen einmalig durchgeführt werden, einige für jede Anwendung erneut.

Als erstes stellen wir in der Anwendung, die ich gerade angesprochen habe im Menü “Project” die SDK-Umgebung auf das iPhone um, da die Simulator-Anwendungen leider nicht auf dem iPhone laufen:

Wenn wir an dieser Stelle die Anwendung versuchen zu kompilieren, bekommen wir den Fehler “CodeSign error: Code Signing Identity ‘iPhone Developer’ does not match any code-signing certificate in your keychain. Once added to the keychain, touch a file or clean the project to continue.” – Das ist kein großes Problem, da uns XCode nur mitteilen möchte, dass wir kein Zertifikat haben. Lästig aber sehr schnell behoben:

1. Öffnet die “Schlüsselbundverwaltung”
2. Wählt den Menüpunkt “Zertifikat erstellen” aus dem Zertifikatsassistenten im Hauptmenü
3. Als Namen gebt Ihr den Namen “iPhone Developer” ein, der Typ bleibt auf Root, der Haken für “Standardwerte überschreiben” muss gesetzt werden. (Fortfahren klicken, Warnung mit Fortfahren bestätigen)
4. Die Seriennummer muss immer so erhöht werden, dass sie nicht doppelt vorhanden ist. Da Ihr noch kein Zertifikat habt, sollte es hier die “1″ tun. Im Zertifikatstyp wählt Ihr “Code-Signierung” aus. (Fortfahren)
5. Die Zertifikatsinformationen füllt Ihr einfach aus. (Namen bitte nicht ändern, dann fortfahren)
6. Alles weitere wird einfach mit “Fortfahren” bestätigt und nicht weiter verändert.

Damit wäre das erste Problem erschlagen und nach einem Neustart von XCode dürfte der Fehler nicht wieder auftauchen. Dafür haben wir jetzt Probleme mit dem nächsten Fehler: “CodeSign error: a valid provisioning profile is required for product type ‘Application’ in SDK’ Device – iPhone OS 3.0′“. Der Fix für dieses Problem ist – gelinde ausgedrückt – ekelhaft, funktioniert aber.

Im “iPhone Dev SDK Forum” wird ein Script bereit gestellt, welches Ihr als root (sudo -s als Admin und Ihr habt eine root-Shell) ausführen müsst:

#!/bin/bash
cd /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneOS\ Build\ System\ Support.xcplugin/Contents/MacOS/

dd if=iPhoneOS\ Build\ System\ Support of=working bs=500 count=255
printf "\x8f\x2a\x00\x00" >> working
dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=127504 seek=127504
/bin/mv -n iPhoneOS\ Build\ System\ Support iPhoneOS\ Build\ System\ Support.original
/bin/mv working iPhoneOS\ Build\ System\ Support
chmod a+x iPhoneOS\ Build\ System\ Support

Diese Script verändert eine Datei des XCode-iPhone-Build-Systems, speichert aber die Originaldatei zusätzlich zur Sicherheit ab. Auch diese Änderung erfordert wiederum einen Neustart von XCode.

An dieser Stelle sollte es jetzt problemlos möglich sein die Anwendung für das iPhone SDK 3.0 zu kompilieren. Zumindest war das der Fall hier bei mir.

Der nächste Schritt ist, dass XCode sich weigert die Signatur für die Anwendung zu erstellen. Somit haben wir zwar eine theoretisch lauffähige Anwendung für das iPhone, allerdings wird das iPhone diese Anwendung sofort nach dem Start unweigerlich vom Kernel beenden lassen, da sie nicht signiert ist. Ohne einen Jailbreak würden wir an dieser Stelle verzweifeln, da der Jailbreak allerdings die Signaturüberprüfung verändert, können wir mit jedem beliebigen Zertifikat die Signierung durchführen.

1. Öffnet ein Terminal und begebt euch in den Ordner, in dem XCode die build-Datei eurer Anwendung erstellt hat
2. Führt an dieser Stelle die folgenden Befehle aus: (Program.app natürlich durch euer Programm ersetzen!)

   platform=/Developer/Platforms/iPhoneOS.platform
   allocate=${platform}/Developer/usr/bin/codesign_allocate
   export CODESIGN_ALLOCATE=${allocate}
   
   codesign -fs "iPhone Developer" Program.app

Damit ist das Programm signiert und kann auf das iPhone (z.B. via SSH) kopiert werden. Die Anwendung sollte somit normal starten und wir freuen uns. Dieser letzte Schritt – das Signieren – muss jedes mal erneut durchgeführt werden, wenn Ihr das Programm neu kompiliert. XCode ersetzt die Dateien einfach und übernimmt wie oben gesagt keine Signatur.

Wie Ihr euer Programm mit Cydia installieren könnt, damit beschäftige ich mich in einem anderen Artikel, der später erscheinen wird.

Nachdem die Version 0.2 meines Plugins doch einen recht guten Anklang gefunden hat und ich von mehreren Leuten gefragt wurde, ob es möglich ist das Plugin auch ohne Widget-fähige Themes zu nutzen habe ich mich daran gemacht schnellstmöglich – also jetzt – eine Funktion für die Nutzung ohne Widgets nachzuschieben.

Die Anleitung hier gilt für alle Nutzer, die keine Widgets nutzen können. Alle anderen halten sich auch in dieser Version bitte an die Anleitung für Version 0.2, da sich für sie nichts geändert hat.

Um die Bilder im Theme anzeigen zu lassen ohne auf die Widgets zurück zu greifen muss einfach an der gewünschten Stelle im Theme folgende Zeile eingebunden werden, nachdem das Plugin aktiviert wurde:

<?php WPPixelpostJSONOutput(<url begin>, <number of images>); ?>

Dabei müssen die spitzen Klammern durch die entsprechenden Parameter ersetzt werden. Der URL-Beginn ist wie im Widget auch die URL eures Fotoblogs ohne das abschließende “/”. Die Anzahl der Bilder wie gehabt.

Für mein Fotoblog unter “http://fotos.knut.me/” mit 3 Bildern wäre also der Funktionaufruf der folgende:

<?php WPPixelpostJSONOutput('http://fotos.knut.me', 3); ?>

Wie auch bei der Version mit Widgets: Fehler, Anmerkungen und Lob bitte einfach in die Kommentare schreiben.

Download letzte Version von GitHub
Changelog der letzten Version

Nachdem ich seit kurzem ein eigenes Fotoblog für meine Bilder habe, war auch eine Möglichkeit gesucht, wie ich die letzten Bilder meines Fotoblogs hier im Blog anzeigen lassen kann. Da mir die vorhandenen Möglichkeiten dazu nicht gefielen, habe ich mich kurzerhand entschlossen ein kleines WordPress-Plugin zu schreiben, welches ein konfigurierbares Widget zur Verfügung stellt um die neusten Bilder anzuzeigen.

Als Voraussetzung für dieses Widget ist im Pixelpost-Fotoblog das Plugin “JSON Output for Pixelpost” erforderlich. Ansonsten müsst Ihr nur die PHP-Datei, die Ihr unter dem unten stehenden Link findet in euer WordPress-Plugin-Verzeichnis kopieren, das Plugin aktivieren und im Widget zwei Einstellungen konfigurieren.

Hier auf dem Screenshot ist die Konfiguration für mein Fotoblog zu sehen. Wenn das Blog also unter der URL “http://fotos.knut.me/” erreichbar ist würde die Konfiguration wie oben aussehen. Wenn das Blog unter “http://www.domain.tld/fotos/” erreichbar ist, müsste in das obere Feld entsprechend “http://www.domain.tld/fotos” eingetragen werden. Nachdem Ihr das konfiguriert habt, klickt Ihr einfach nur noch auf “Save” und schon seht Ihr in der Sidebar eure Bilder.

Wenn Ihr das Plugin nutzt würde ich mich sehr über einen kleinen Blogpost freuen, in dem Ihr erwähnt wo das Plugin her kommt. Ansonsten schaltet das Plugin keinerlei Werbung oder sonstiges.

Updates über neue Versionen des Plugins könnt Ihr hier bei mir im Blog finden. Das Plugin wird vorerst noch nicht im WordPress-Plugin-Directory gelistet sein. Sollte die Nachfrage stark steigen, werde ich allerdings über ein Listing dort nachdenken.

Kritik, Anmerkungen und Lob zum Plugin nehme ich gerne hier in den Kommentaren entgegen.

Download letzte Version von GitHub
Changelog der letzten Version