Landkarten in Blogposts einzubinden ist eigentlich keine Hexerei, mit Google Maps und Fusion Tables lassen sich nette Dinge anstellen. Aber was tun, wenn man lieber freies Kartenmaterial, wie das von OpenStreetMap einsetzen will?
Für Dokuwiki gibt es  das Plugin openlayersmap, hier am Beispiel einer Karte der Kindergärten in Schwabmünchen und Umgebung. Für WordPress existiert das OpenStreetMap Plugin, das ich schon einmal erwähnt habe.
Eine universellere Lösung ist es, eine Karte als iframe in die Seite oder den Artikel einzubinden. Dazu wird eine HTML-Seite erzeugt, in der die Karte mit Hilfe von OpenLayers dargestellt wird, im Wiki von OpenLayers finden sich ein paar schöne Beispiele dazu. Auch wenn da viel mit copy-paste zu machen ist, setzt es immerhin den Willen voraus, sich mit JavaScript auseinanderzusetzen. Mit dem OSM SlippyMap Generator geht es auch ohne Programmierkenntnisse. Auschnitt und Zoom auswählen, dazu noch evtl. ein paar Marker oder ein Polygon und das Skript liefert einem die notwendigen Dateien. Die lädt man dann auf seinen Server und bindest die HTML-Datei als iframe ein.

Drüben im Singold Boten gleich mal ausprobiert, weil da ein Stadtplan für Schwabmünchen schon lange überfällig ist. Die HTML-Datei dazu ist jene hier und in die Seite eingebunden ist sie so:

<iframe src=”http://cdn.remtene.net/sb/stadtplan/schwabmuenchen.html” width=”650px” height=”488px” frameborder=”0″ name=”Stadtplan Schwabmünchen”>
<p>Ihr Browser kann leider keine eingebetteten Frames anzeigen: Sie können die eingebettete Seite &uuml;ber den folgenden Verweis aufrufen:
<a href=”http://cdn.remtene.net/sb/stadtplan/schwabmuenchen.html”>Stadtplan Schwabmünchen</a></p></iframe>

Damit das iframe nicht vom WYSIWYG-Editor rausgeworfen wird, kommt der HTML-Code dafür in ein benutzerdefinitiertes Feld und wird mittels des Simple Code Plugin automatisch eingebunden. Das ist bisher die eleganteste Lösung die mir dazu untergekommen ist und kann auch für die iframe von youtube, vimeo etc. verwendet werden.

• Fluglärm veranschaulicht
• GM 511
• Vergleich Stromspeicher
• Landkarten in Blogartikel einfügen
• Picasa als Galerie für WordPress

Kann mir mal jemand eine deutsche Übersetzung für “Writing Environment” sagen. Wie auch immer, es geht darum wie man aus einem Wiki heraus Dokumente erstellt, die eigenständig, z.B. gedruckt, verteilt werden sollen. Das hört sich vielleicht einfacher an als es ist und hat auch Potential für Grundsatzdebatten.

In meiner Arbeit mit Wikis ist der Fall jedenfalls ein häufiger, dass Einträge aus einem Wiki, zusätzlich auch auf Papier verteilt und archiviert werden sollen. Gerade bei der Einführung von Wikis in Unternehmen wird meiner Erfahrung nach oft die parallele Papiervariante gefordert. Die Einführung eines Wiki ist eine Sache, alle Prozesse pappierlos zu gestalten eine ganz andere. Das Nebenher ergibt damit zwangsläufig.  Scott Nesbitt beschreibt in einem Blogbeitrag, wie er das mit DokuWiki unter einen Hut bringt und welche Plugins dabei zum Einsatz kommen.

• Dokuwiki Upgrade
• Arduino: The Documentary
• Abstimmung über beste Web 2.0 Plattform für Weltretter
• Lighttpd vs. Apache – Teil 2
• Dokuwiki und die Frage nach dem Webserver

Was wären Feiertage, wenn sie uns nicht Zeit verschaffen würden, um längst fällige Aufräumaktionen zu starten. Was für ein Glück, wenn es mittendrin auch noch ein Update gibt, das eingespielt werden will. Seit dem ersten Weihnachtstag gibt es Dokuwiki in einer neuen Version. Die Updates, auf neun Systemen, sind so weit ich es nach einem Tag Betrieb sagen kann, ohne grössere Probleme abgelaufen. Scheinbar zahlt es sich aus, um Monobook als Design einen Bogen zu machen, auch wenn es teils Energie kostet, meinen Kunden klar zu machen, dass ein Wiki nicht automatisch wie die Wikipedia aussehen muss.

Beim Schockwellenreiter ist zu lesen, dass sich die Geschwindigkeit mit der neuen Version verbessert hat. Da der letzte Dokuwiki-Benchmark ja schon wieder ein paar Wochen her ist, musste ich das unbedingt testen. Das Ergebnis war leider nicht so euphorisch. In dem konkreten Testfall ist die neue Version im Schnitt 4,4% langsamer, als der Vorgänger. Das soll die im Changelog angekündigten “performance optimizations” nicht in Abrede stellen und schon gar niemanden von einem Upgrade abhalten (ausser natürlich man setzt Monobook als Template ein).

• Lighttpd vs. Apache – Teil 2
• DokuWiki als Plattform zum Schreiben
• Dokuwiki und die Frage nach dem Webserver
• Mal eben schnell ‘ne Karte einbinden
• Gwibber sprachlos

Als ich kürzlich das Wiki für diese Webseite konfiguriert habe, ist mir aufgefallen, dass ich diverse Dokuwiki-Instanzen mit unterschiedlich konfigurierten Webservern betreibe. Eine Nachlässig, über deren Ursache sich längst der Schleier des Vergessens gelegt hat. Und weil Winter immer auch die Zeit fürBenchmarks ist, habe ich mich daran gemacht herauszufinden, ob es evtl. Unterschiede in der Performance gibt.

Konkret geht es darum, mit welcher Webserver-Software (lighttpd oder Apache) Dokuwiki performanter ist. Performanter im Sinne, dass mehr Seiten, an mehr Betrachter ausgeliefert werden können. Eine Frage, die sich mir immer wieder mal stellt und bisher immer mit “kommt darauf an” beantwortet werden durfte. Ausserdem steht ein Wechsel der Hardware bei mehreren Servern meiner Kunden an und da interessiert es mich natürlich, welche Leistungssteigerung zu erwarten ist. Und überhaupt wollte ich das Dokuwiki-Plugin charter ausprobieren.

Lange Rede, kurzer Sinn: Das reine Zahlenwerk, inkl. der charter-Grafiken gibt es im Wiki nachzulesen.  Das Ergebnis auf den Punkt gebracht: Rein von der Geschwindigkeit geben sich lighttpd und Apache nicht viel. lighttpd spielt seine Vorteile vor allem unter Last aus und liefert noch mit ansehnlicher Geschwindigkeit Seiten aus, während Apache bereits seinen Dienst eingestellt hat. Die Steigerung der Rechenleistung wirkt sich, wie ja zu erwarten war, auch auf die Leistung aus. Signifikant aber nur im Bereich vieler gleichzeitiger Zugriffe. Ohne großartige Veränderungen an der Serverkonfiguration, macht der PHP-Opcode-Cache XCache den Servern Beine.

Praktisch gesehen heisst das und gilt selbstverständlich nur für die Fälle, da man die volle Kontrolle über den Server hat, dass bei Performanceproblemen mit PHP-Software, der erste Schritt zur Lösung, die Installation eines PHP-Opcode-Caches sein sollte. Das setzt natürlich ausreichend Speicher voraus, i.d.R. lässt sich RAM aber schneller nachrüsten, als es dauern würde, einen komplett neuen Server aufzusetzen.  Apache durch lighttpd zu ersetzen macht nur dann Sinn, wenn viele parallele Zugriffe auf den Webserver erfolgen. Geht geht der Server bereits bei wenigen simultanen Zugriffen in die Knie, liegt es wohl eher an mangelnder Rechenleistung. In dem Fall sollte man sich aber nicht nur über einen schnelleren Server Gedanken machen, sondern auch überlegen, ob es für den konkreten Einsatz auch Software gibt, die weniger hohe Ansprüche an den Server stellt.

Die Auswertung für WordPress und Serendipity folgt noch, wenn ich Ordnung in den Zahlenverhau gebracht habe. Achja, charter gefällt mir sehr gut.

• Dokuwiki Upgrade
• Lighttpd vs. Apache – Teil 2
• DokuWiki als Plattform zum Schreiben
• Reverse Proxy in der Cloud
• Mal eben schnell ‘ne Karte einbinden