Über meinen Job kann ich derzeit auch nicht wirklich was schreiben, da das meiste als Customer Confidential eingestuft ist. Mal sehen in wie fern sich das durch neue Aufgabenfelder ändern könnte. Aber mehr dazu, wenn es soweit ist.

Ich bin allerdings erfreut, das mein WordPress Plugin New Tag Cloud guten Anklang findet. Hier haben Anwender schon einige neue Features gebastelt und mir den Code zur Verfügung gestellt. Dazu wird es bald auch ein neues Release geben, in dem ich diese dann offiziell machen werde.

Ich hoffe aber trotz allem, das der ein oder andere meinen Feed noch verfolgt und einige Infos, die ich hier in die breite Masse streue, auch für hilfreich/informativ hält

Nun ist mir irgendwann bewusst geworden, dass zwischen dem Zeitpunkt des Sharing und dem erstellen des Posts sehr viel Zeit vergehen kann (bis zu 24 Stunden). Daher habe ich das Konzept dahin gehenden geändert, dass nun 3x täglich (12:00, 16:00 und 22:00)  diese Beiträge erstellt werden. Da dies nun keinen Bezug mehr auf den Tag hat, ist der Name von Empfohlene Artikel vom xx.xx.xxxx in Links #x abgeändert worden.

Das Ganze läuft nun auch endlich als WordPress Plugin und so kann ich auch auf die API zugreifen um den Post zu erstellen (vorher schrieb das PHP-Script die Daten immer direkt in die Datenbank, wodurch WordPress interne Funktionen und Plugins natürlich umgangen wurden). Mit dem neuen Weg über wp_insert_post() hat dies ein Ende. Schön finde ich auch, dass nun die Trackbacks automatisch mit raus geschickt werden.

Ach ja, die Links sind alle mit rel=”nofollow” versehen. Das Konstrukt soll auf keinen Fall irgendwelchen Einfluss auf PageRankings haben.

Sollte also jemand ab und an in meine empfohlenen Artikel rein schauen, sollte es nun mal manuell machen.

Aus verschiedenen Gründen hatte ich weder Zeit noch Lust mich hier blicken zu lassen, aber ich hoffe, dass sich das bald wieder gibt.

Viel Spaß damit!

Nun fehlt eigentlich nur noch ein kleines Script, dass diesen Feed einmal täglich scannt und zu allen neuen Artikeln einen Link als Beitrag in meinem Blog erstellt.

http://login.funnydingo.de/

Sollte es noch irgendwelche Probleme damit geben, könnt ihr euch gerne bei mir melden.

Ist auch ganz easy. Dank meiner Library tsqlib (die sollte ich unbedingt mal überarbeiten und veröffentlichen) ist das auslesen der Daten schnell erledigt. Die meiste arbeit steckte in der Erweiterung der tsqlib für die Sortierung der Channels und User.

Ich wollte den Output nämlich so sortiert haben, wie der TeamSpeak-Client ihn anzeigt. Zu der Sortierung nach Namen kommt bei den Channels noch ein Order-Flag und bei den Benutzern eine Rechte-Bitmask dazu (ServerAdmins werden vor normalen Benutzern eingeordnet). Das war für mich das erste mal, dass ich eine eigene Sortierungfunktion geschrieben habe.

Das war mal wieder eine spannende Sache und ich habe die Lust gewonnen, die tsqlib zu überarbeiten und dann hoffentlich bald mal zu veröffentlichen.

Ein paar kleine Anpassungen muss noch machen, dazu zählen Punkte wie eigene IP für den Mail-Server, Backup “verschönern”, Logging anpassen, Chat-Server einrichten, etc. Das sind alles keine Punkte die nicht warten könnten.

Für heute ist Feierabend.

Leider kann ich nicht genau sagen, ob die anhalten wird, bis der neue Server da ist. Ich hoffe es einfach mal.

Wichtig!
Nutzer der Systeme yac, inms, POA/SRT und I23 müssen leider vorerst ohne diese Services auskommen (I23 Monitoring und Alarmierung funktionieren weiterhin). Falls es wichtige I23-Requests geben sollte, können diese gerne direkt an mich gerichtet werden. Nutzt dazu bitte das Kontaktformular.

Es fängt alles mit einem einfachen Login-Script an. Ich nehme hier mal ein PHP-Script:

Zeile 2: get_login_data() ist hier nur ein Beispiel. Hier soll verdeutlich werden, dass es völlig egal ist, von wo die Daten kommen, wichtig ist nur, dass der Request-String zusammen gebaut werden kann.
Zeile 3: Und genau das passiert hier. Der Request-String enthält alle nötigen Daten wie Nick, Raum, Farbe, Rechte und die IP des Clients.
Zeile 4ff: Nun der fopen() + lesen. Der Chat analysiert nun die Parameter des Request-Strings. Ist die Anfrage gültig, wird die yacsid + ISS erzeugt und diese zusammen mit den anderen Daten temporär gespeichert. Die yacsid und der ISS im Format "yacsid|ISS" wird zurück gegeben und steht im PHP-Script in $buffer zur Verfügung. Ist die Anfrage ungültig (weil die IP von der die Anfrage kommt keine Zugriffserlaubnis hat oder der LOGINKEY ungültig ist) gibt der Chat "ERROR: " + den Grund zurück.
Zeile 11: Prüfen wir noch schnell, ob der Chat einen Fehler gemeldet hat.
Zeile 13: Kein Fehler. Wir splitten die Ausgabe noch in $yacsid und $iss auf.

Bisher haben wir aber noch keinen echten Login, sondern nur die Login-Anfrage. Dies erfolgt mit dem IFrame:

Zeile 6: Hier folgt der Aufruf des Output-Streams des Chats. Genau hier wird von dem Chat die temporär gespeicherte Login-Anfrage zu einem echten Login.
Zeile 7: Hier wird noch eine input.php aufgerufen.

input.php

Warum ist dieses Vorgehen nun besser als bei Chats, die den Login selbst durchführen? Nun ja, ob es wirklich besser ist, will ich nicht behaupt, aber ich finde es macht mehr Sinn. Durch dieses Verfahren bleibt es dem Betreiber völlig offen, wie die Authentifizierung aussehen soll. Beispiel: ich habe für meinen Blog das OpenID-Plugin installiert, so dass man sich mit diesem Authentifizieren kann. Würde der yac die Authentifizierung nun selber machen, könnten sich diese User nicht am yac anmelden (btw: ich sollte den Demo Chat mal wieder zum laufen bringen, damit man genau das sehen kann).

Wenn ihr bereits einen Account in meinem Blog angelegt habt, könnt ihr diesen unter Your Identity URLs mit beliebig vielen OpenIDs verknüpfen. Wird ein neuer Account angelegt, müsst ihr darauf achten, einen Spitzenamen anzugeben und diesen unter Name im Blog auszwählen, da bei euren Kommentaren sonst eure OpenID URL angezeigt wird.

Bisher bin ich ja immer her gegangen und habe den Code in comments-template.php direkt editiert. Das hat zwar sehr gut funktioniert, aber dies geht natürlich bei jedem Update verloren. Das Plugin + entsprechende Anpassungen im Theme geben ein genau so gutes Ergebnis und überleben auch das Update.

It's done! Now New Tag Cloud supports multiple configurations. I call this feature "Instances". After installing the plugin, a instances "Default" will be created (if you do an update, this first instance is called "Imported pre v0.5 configuration" and includes your "old" configuration). Every output of New Tag Cloud will use this configuration by default.

Now comes the magic: you are able to create new instances and use them in different places. An example: create a new instances called "Tag Page", change the settings for this instance like you want and set the global setting "Default instance for filter" to the new instance. Now create a new page and place <!--new-tag-cloud--> on it. Voila: the page uses the settings of the new instance while the widget in your sidebar uses your "old" configuration.

You need a second tag page? Now problem: create a new instance again, change the settings and put <!--new-tag-cloud-*--> on it. Replace * with the ID of the new instance (e.g. <!--new-tag-cloud-2--> and this tag cloud will use the settings given by the instance with ID 2.

And last but not least: if you use New Tag Cloud directly from your theme you can call it with an ID:

This would create a tag cloud with the settings given by instance with ID 6. If you call newtagcloud() without an ID the instance 0 will be used.

Oh, I forgot it: also you are able to change the sort: by name or by usage count.

I hope you like this new feature If you've found a bug, or want to tell me, that it works fine for you, please write a comment on the project page!