dierck & meyer mediengestaltung

Schwarz auf Weiß. Drucksachen und mehr. Online seit 1999.

By

Wieder drin

Computer-Wudu! Einige Wochen hindurch war kein Zugriff auf die Admin-Oberfläche möglich. Stets kam man immer wieder auf der Startseite raus. Auch das Prüfen und Rumbasteln an den einzelnen Installationsdateien über den FTP-Zugang war ergebnislos. Schließlich fing WordPress an, nur noch 404-Meldungen abzusondern, nachdem wir zu viel an den Dateien rumgespielt hatten. Leise weinend und beschämt schlichen wir uns vom Acker. Was konnte das nur sein? Auch die entsprechenden Foren lieferten zwar jede Menge Tips – Cookies seien die Ursache, man solle bestimmte interne Links neu definieren, an der .htaccess rumschrauben usw. –, aber es tat nicht, wie ihm geheißen wurde.

Heute dann: ein Versuch, wieder ins Adminmenü zu gelangen, geboren mehr aus hoffnungsloser Langeweile als aus echtem Reparaturwunsch (wir hatten uns schon damit abgefunden, dass das ganze WordPress völlig neu zu installieren wäre) – und kuckuck! Überraschung! – Alles funktioniert anscheinend wieder.

Versteht man das? Kann uns das jemand erklären? Wir sind ratlos. Die Spezialistengemeinde meint nur: Kommt halt vor. Für uns bestätigt das nur wieder zwei unser Axiome:

1. Informatik ist keine exakte Wissenschaft, sondern Zauberei.

und

2. Technik ist durch Menschen nicht beherrschbar.

Sapere aude!

By

Kleine WordPress-Bonbons, Teil 4: Webfonts benutzen

Im Frühjahr hatten wir uns ja schon einmal an dieser Stelle mit Webfonts beschäftigt. Nur kurz zur Wiederholung: Warum soll man sie benutzen? Hauptsächlich deshalb, damit Text Text bleibt, mit allen Vorteilen – wie an erster Stelle dem, daß man danach suchen kann. Es war ja – und ist es sehr oft immer noch – üblich, etwas ausgefallene Typographie in einem Bildbearbeitungsprogramm unseres Vertrauens zurechtzubasteln und sie dann als Bild, teilweise im Frameset (nach HTML 5 technisch veraltet), teilweise in einer Tabelle in die Seite so einzubauen, daß sie rutschfest und standsicher von jedem Browser verdaut wird.

Wie das geht, hatten wir schon damals in groben Zügen erklärt: Eine CSS-Datei muß auf dem Server liegen und die Schriften bestimmten Stilen zuweisen. Das sieht dann beispielsweise so aus, wenn man eine Schrift namens »Abilene« einbinden will:

@font-face {
font-family: 'Abilene';
src: url('abilene-webfont.eot');
src: url('abilene-webfont.eot?#iefix') format('embedded-opentype'),
url('abilene-webfont.woff') format('woff'),
url('abilene-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}

Och nö, wieso ist das denn wieder so kompliziert, rufen jetzt alle, und sie haben recht, meinen wir, aber darauf kommen wir gleich noch.

Die erwähnte CSS-Datei muß mit den Fontdateien auf dem Webserver liegen, am besten im gleichen Ordner. Das ist analog zum heimischen Rechner, wo ja auch Fontdateien an definierter Stelle liegen, damit das Schreibprogramm sie sehen kann. Damit der Browser erkennt, wo die CSS-Datei mit den Stildefinitionen und Zeichensatzzuweisungen liegt, braucht es in jeder HTML-Datei einen Verweis auf die CSS-Datei. Der steht irgendwo bei den anderen CSS-Anweisungen und sieht zum Beispiel so aus:

<link rel="stylesheet" href="ordner/cssdatei.css" type="text/css" charset="utf-8" />

In dieser HTML-Seite ist eine Reihe von Schriften beispielhaft aufgeführt. Das Laden kann etwas länger dauern, denn zur Darstellung muß der Browser nicht nur zuerst die HTML-Datei herunterladen und interpretieren, sondern sich danach auch noch alle benötigten Zeichensätze herunterladen, auslesen und auf die HTML-Datei anwenden. Diese Verzögerung ist aus unserer Sicht auch der Hauptnachteil der Webfont-Verwendung.

Warum nun sehen die Angaben in der CSS-Stildefinition so kompliziert aus?

Das liegt vor allem daran, daß die Browser nach verschiedenen Methoden vorgehen, um Webfonts darzustellen. Außerdem gibt es drei verschiedene Fontformate (.eot, .woff und .ttf), von denen keines von allen Browsern interpretiert werden kann. Man muß also für jede Schrift die drei verschiedenen Dateiformate vorhalten, wenn man will, daß alle gebräuchlichen Browser ein hinreichend ähnliches Ergebnis hervorbringen. TTF-Dateien, so viel sei noch angemerkt, sind zwar Truetype-Fonts, aber nicht mit den aus der Windowswelt bekannten Schriften zu verwechseln. Die hier in Rede stehenden lassen sich nicht auf dem Arbeitsplatzrechner einsetzen.

Das beste daran ist: Alles funktioniert auch in WordPress! Im Eingabefeld dieses Textes haben wir ganz am Anfang den entsprechenden Link zur CSS-Datei eingefügt. Wenn wir nun hier einen der Stile aufrufen, dann ergibt sich zum Beispiel so etwas hier:

Noch ein Wort zu den Nutzungsrechten:

Der Browser muß, damit er Schriften darstellen kann, diese auf dem heimischen Rechner, wie gesagt, auch finden. Meistens handelt es sich ja um Allerweltsschriften wie Arial, Helvetica, Garamond usw., die auf nahezu jedem Rechner des Universums installiert sind. Ausgefallene Schriften muß er sich erst einmal besorgen. Würde man nun die normalen Rechnerschriften ins Netz stellen, käme dies einer krassen Verletzung der Nutzungsrechte gleich, die genau das in aller Regel verbieten. Die Schriften- und Browserhersteller haben deshalb eigens für den Gebrauch im Netz die Webfonts entwickelt, deren Einsatz direkt auf dem Rechner nicht möglich ist. [Wir warten allerdings auf den ersten Hacker, der genau das möglich machen wird, wetten?]

Und warum (quengel!, pienz!) dann drei verschiedene?

Na, wie üblich: Weil man sich wieder einmal nicht auf einen gemeinsamen Standard einigen konnte.

Nachtrag:

Wer keine eigenen Webfonts hat, kann sich – sofern er mit WordPress arbeitet – auch des Plugins „Font“ bedienen, das viele kostenlose Schriften zugänglich macht. Die sind allerdings auf dem Server des Plugin-Autors, was bedeutet, daß es keinen direkten Zugriff gibt und keine Garantie, daß das Angebot unverändert bestehen bleibt.

Sapere aude!

By

Kleine WordPress-Bonbons, Teil 3: Videos in Artikel einbinden

Ein Erfahrungsbericht vom Dazulernen: Manche Dinge gehen eben nicht so einfach.

Das unten gaaanz am Ende folgende Video wollte ich zu Versuchszwecken „mal eben“ von unterwegs aus publizieren. Denkste!

Wie gewohnt, sollte es erst in die Mediathek geladen und dann in einen Artikel hinein verknüpft werden. Das Hochladen in die Mediathek, so viel war schnell klar, beschränkt sich allerdings auf Bilder. Videos: isnich!

Nach einigem Rumprobieren, mit diversen anderen Apps die Datei auf den Server zu bekommen, kam ich dann endlich drauf: Direkt in einen Artikel einbinden, das geht – jedenfalls bietet sich dort das entsprechende Upload-Menü.

Hier wäre nun also das Filmchen zum Test gewesen.

Mannheim. Der Paradeplatz morgens um neun.

(Mit mehreren atemberaubenden Schwenks, den Straßenbahnen folgend. – Hm … ist Gähnen eigentlich auch „atemberaubend“?)

Tja, wäre!

Leider zeigte sich meine Ausrüstung (iPhone 4S, iOS 6.0, WordPress.app 3.1.4) außerstande, das MOV auch tatsächlich hochzuladen, obwohl ein Menüpunkt der WordPress-App. für iOS den Video-Upload eindeutig vorsieht. Blieb einstweilen zu klären, warum das so ist. Bei erreichen von 100 % brach der Upload mit einer ungenauen Fehlermeldung ab.

Wieder zu Hause, ging es dann auf dem Mac weiter. Hier bot sich das neue Problem, den Film – von beträchtlicher Dateigröße selbstverständlich – runter vom iPhone und rauf auf den Rechner zu kriegen. Das funktionierte einfach mit einer iTunes-Synchronisation. Von da auf den Manitu-Server ist dann kein Problem mehr – nach Umwandlung vom unkomprimiert 633 MB großen MOV in ein hochladbares MP4 bzw. M4V. Das ist nun auf gerade mal 22,4 MB heruntergerechnet und damit beherrschbar.

Nächster Schritt: Einbindung in diesen Artikel. Auch das ging nicht so einfach wie bei einem Bild. Ein bloßer Link zu der Filmdatei wie hier bringt kein Ergebnis in WordPress. Nur einen Download der Datei kann ich damit anstoßen. Will ich aber nicht. Eine Suche im Internet bringt dann zutage, daß man nicht die Datei, sondern einen Player verlinken muß, der den Datenstrom auf den Bildschirm des abfragenden Rechners streamt.

Nach einiger Suche fiel meine Wahl dann auf den JW-Player. Der wird als Plugin in WordPress installiert und streamt den Clip wahlweise als Flash oder nach dem HTML-5-Standard. Die Bedienung ist dabei relativ einfach: Über den Knopf „Dateien hinzufügen“ über dem WordPress-Eingabefenster geht man wie üblich in die Mediathek, wählt die hochgeladene Filmdatei aus und findet dann unten neben dem bekannten Knopf „In Artikel einfügen“ einen weiteren, „Insert JW Player“. Der fügt dann für diesen Film z.B. den Code [jwplayer mediaid="716"] ein. Das Ergebnis sieht – endlich! – so aus:

Sapere aude!

Unsere Seiten sind gehostet bei manitu. Wir empfehlen Safari oder Firefox oder einen anderen Browser Ihres Vertrauens.