ek

Beiträge zum Thema JS, HTML, CSS & anderem Kram

Github – herschel666 – Drop-a-Site

“Drop-a-Site” auf GitHub | Download

Hin und wieder kommt man in die Verlegenheit, eine kleine statische Seite aufsetzen zu müssen. Diese ist vom Umfang her so dünn, dass es sich nicht lohnt, eine Datenbank anzulegen und das Standard-CMS/-Framework der Wahl zu strapazieren. Andererseits hat man aber auch keine Lust, mit einem Haufen statischer HTML-Dateien rum zu hantieren.

Das ist der Punkt, wo so genannte “Static Site Generators” ins Spiel kommen. Ein Vertreter dieser Gattung möchte “Drop-a-Site” sein – einfachste Bereitstellung statischer Inhalte mithilfe von URL-Rewriting. Dabei habe ich Wert auf Simplizität gelegt. Man definiert die Pfade zu seinen Seiten sowie die zugehörigen Seitentitel, und “Drop-a-Site” liefert aus. Auf weiterführende Features habe ich bewusst verzichtet.

Die Einrichtung von “Drop-a-Site” ist denkbar einfach:

1. Seiten-URL definieren

Die nötigen Anpassungen müssen in der config.php vorgenommen werden. In der SITE_URL-Konstante wird der vollständige URL der Seite gespeichert. Liegt die Seite nicht im Wurzelverzeichnis sondern in einem Unterordner, muss das mit eingetragen werden.

2. Unterseitepfade und -titel definieren

Im $pages-Array werden die Pfade zu den Unterseiten sowie deren Titel gespeichert. Das URL-Rewriting sorgt dafür, dass die Seiten über den eingetragenen Pfaden erreichbar sind. Unter- und Unter-Unterseiten stellen kein Problem dar.

3. Anpassung für den Fall, dass die Seite nicht in der Wurzelebene liegt

Liegt deine Seite in der Wurzelebene, kannst du diesen Punkt getrost überspingen.

Liegt die zu erstellende Seite jedoch in einem Unterordner, muss die Deklaration der $req-Variable angepasst werden. Genauer gesagt, muss der Pfad zur Unterseite aus dem Request-String entfernt werden. Ist die Seite bspw. über die Adresse http://example.com/foo/bar/ erreichbar, muss die Deklaration der $req-Variablen folgendermaßen aussehen:

PHP

$req = trim(str_replace('/foo/bar/', '', $_SERVER['REQUEST_URI']), '/');

4. Anpassen der .htaccess-Datei

Auch diesen Punkt kannst du überspringen, wenn deine Seite in der Wurzeleben liegt.

Andernfalls musst du dem mod_rewrite mitteilen, in welchem Unterordner die Seite liegt, damit es fehlerfrei funktionieren kann. Dafür gibt es in der .htaccess den Wert RewriteBase. Ausgehend von der Annahme, die Adresse deiner Seite ist http://example.com/foo/bar/, muss der Eintrag in der .htaccess so aussehen:

PHP

RewriteBase /foo/bar/

5. Einstellen der Inhalte

Schlussendlich müssen nur noch die Inhalte eingetütet werden. Diese werden im Ordner “inc” gelagert und nach den entsprechenden Seiten benannt. Zur Seite “about” gehört also die Datei “about.inc.php”. Für Unterseiten müssen entsprechende Ordner innerhalb von “inc” angelegt werden.

Zusätzlich gibt es innerhalb von “inc” den “components”-Ordner - in diesem können Template-Parts wie Header, Footer, Navigation, etc. ablegt werden.


Das ist auch schon alles, was es zu tun gibt, um “Drop-a-Site” in Betrieb zu nehmen. Natürlich kann das System nach Belieben erweitert und ausgebaut werden. Allerdings muss man dabei abwägen, ob es den Aufwand wert ist.

Bei Fragen oder Anregungen sei an die Kommentarfunktion verwiesen.

“Drop-a-Site” auf GitHub | Download

"Backboned" · AJAX-powered WordPress-Theme · Screenshot

Check out Backboned v2!!

Um mir gelegentlich etwas Zerstreuung vom Lernen zu geben, habe ich einen lange gehegten Plan in die Tat umgesetzt: Ein AJAX-betriebenes WordPress-Theme mit Backbone.js zu bauen. Und zwar keine auf “Graceful Degradation” setzende Kompromisslösung. Alle Inhalte werden asynchron geladen und sind per Hashbang URIs ansteuerbar. Ein Blick in den Quellcode offenbart, was ich meine: Ein JSON-Objekt mit allen grundlegenden Daten, eine Handvoll jQuery-Templates und das HTML-Grundgerüst. Das war es an statischem Content - die Darstellung des Inhalts geschieht über Backbone.js.

Damit Suchmaschinen nicht außen vor bleiben und man sich nicht die Mühe machen muss, einen “Headless Browser” à la HtmlUnit auf seinem Server zum laufen bringen zu müssen, werden grundsätzlich alle Inhalte als GET-Anfrage mit dem Parameter “_escaped_fragment_” abgehandelt - die Ausgabe variiert dann je nachdem zwischen statischem HTML oder einem nackten JSON-Objekt. So ist sichergestellt, dass die Inhalte trotzdem indiziert werden können. Die einzigen, die in die Röhre schauen, sind Besucher ohne JavaScript.

Um diesen Workaround zu realisieren, war jedoch ein hohes Maß an Improvisation vonnöten. Mit WordPress-Bordmitteln habe ich es nicht geschafft, das Frontend-seitige URL-Routing von Backbone.js server-seitig abzubilden und entsprechend zu bearbeiten. Ich habe deshalb auf ein simples MVC-Pattern zurück gegriffen und in das eigentliche Theme eine Art Child-Theme integriert. Das ist insgesamt kein Ansatz der mir - besonders in meiner Umsetzung - gefällt. Des weiteren muss man für einen störungsfreien Betrieb des Themes das URL-Rewriting in den WordPress-Einstellungen deaktivieren.

Darüber hinaus bleibt anzumerken, dass das Theme insgesamt eher rudimentär ist. Ich würde von einem Produktiveinsatz abraten. Allerdings bin ich grundsätzlich von der Idee des Themes überzeugt und freue mich natürlich, wenn jemand sich ebenfalls dafür begeistern kann und daran weiterarbeitet. Gerne auch in Kollaboration mit mir. Zu tun gibt es unter anderem noch:

  1. die grundsätzliche Verbesserung des PHP-Codes (sicherer machen, besser in das WordPress-Environment integrieren,…)
  2. den Funktionsumfang erhöhen (Neueste Kommentare, Tags, Suchfunktion, Sidebar-Widgets(?),…)
  3. das JavaScript straffen (Performance, geschmeidigere GUI-Abläufe,…)

…um ein paar Aspekte zu nennen.

Ansonsten freue ich mich wie immer über Anregungen und Verbesserungsvorschläge - gerade bei einem Vorhaben dieser Größenordnung hat man als Entwickler nicht wirklich einen umfassenden Überblick.

PS: Wahrscheinlich werde ich das Teil zeitnah bei GitHub reinladen. Muss mich da aber erst noch anschlauen.

Update: Okay, die Geschichte ist jetzt auch auf GitHub - https://github.com/herschel666/Backboned. Viel Spaß.

Semi-transparente Navigation in WordPress mit CSS

Heute geht es um eine horizontale Reiternavigation in WordPress, deren inaktive Reiter dank CSS Browser-übergreifend semi-transparent sind. Dafür muss als erstes ein span-Element innerhalb der Listen-Elemente der Navigation eingefügt werden. Dies geschieht über folgenden PHP-Code-Schnipsel:

HTML/PHP
<div id="header">
   <ul>
      <li<?php if (is_home() || is_paged() ) echo " class=\"current_page_item\""; ?>>
         <span></span>
         <a href="<?php bloginfo( 'url' ); ?>" title="Back to Main    Page">Home</a>
      </li>
      <?php
         echo preg_replace('@\<li([^>]*)>\<a([^>]*)>(.*?)\<\/a>@i', '<li$1><span></span><a$2>$3</a>', wp_list_pages('echo=0&title_li=&depth=1'));
      ?>
   </ul>
   <div class="hr"><hr /></div>
</div>

Das span-Element bekommt in diesem Fall die Transparenz. Würde man die Transparenz auf das a-Element anwenden, würde auch die darin liegende Schrift transparent werden und das soll vermieden werden. Außerdem wird vor der Funktion zur Ausgabe der Seiten noch ein Listenelement mit dem Link zur Startseite eingesetzt. Der ist optional und kann auch entfernt werden, wenn man z.B. den Blog-Titel auf die Startseite verlinkt. Schlussendlich befindet sich unterhalb der Navigation noch ein von einem div-Element umschlossenes hr-Element. Unter diesem werden die inaktiven Listenelemente verschwinden.

Kommen wir nun zum CSS:

CSS
#header ul {
   height: 60px;
   position: relative;
   clear: left;
}

   #header ul li {
      width: auto;
      _width: 140px; /* IE6 needs a fixed width */
      height: 60px;
      margin-left: 20px;
      float: left;
      display: inline;
      position: relative;
   }

      #header ul li span {
         display: block;
         width: 100%;
         _width: 140px; /* IE6 needs a fixed width */
         height: 60px;
         position: absolute;
         top: 10px;
         left: 0;
         z-index: 1000;
         background-color: #FFF;
         background: -moz-linear-gradient( top, #c7e0ed, #fff );
         background: -webkit-gradient( linear, left top, left bottom, from(#c7e0ed), to(#fff) );
         opacity: 0.7;
         filter: alpha(opacity=70);
         -moz-opacity: 0.7;
         filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=70);
         -khtml-opacity: 0.7;
         -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=70)";
      }

      #header ul li a:link,
      #header ul li a:visited {
         display: block;
         width: auto;
         height: 24px;
         padding: 13px 20px 23px 20px;
         line-height: 24px;
         position: relative;
         bottom: -10px;
         z-index: 2000;
         color: #0660cf;
         text-decoration: none;
         text-shadow: #FFF 0 1px 2px;
      }

      #header ul li a:hover,
      #header ul li.current_page_item a {
         background-color: #FFF;
         background: -moz-linear-gradient( top, #c7e0ed, #fff ); /* gradient for firefox */
         background: -webkit-gradient( linear, left top, left bottom, from(#c7e0ed), to(#fff) ); /* gradient for chrome and safari */
         position: relative;
         bottom: 0;
         _top: 0; /* special invite for IE6 to get goin' */
      }

      #header ul li a:hover {
         color: #c41604;
      }

      #header ul li a:active {
         color: #0059ce;
         position: relative;
         bottom: -1px;
         _top: 1px; /* special invite for IE6 to get goin' */
      }

.hr {
   height: 30px;
   background-color: #333;
   background: -moz-linear-gradient( top, #333, #555 ); /* gradient for firefox */
   background: -webkit-gradient( linear, left top, left bottom, from(#333), to(#555) ); /* gradient for chrome and safari */
   position: relative;
   z-index: 3000;
}

   .hr hr {
      display: none; /* hiding hr because of the IE. quel surprise! */
   }

Am meisten Platz nehmen hier die Angaben für die Transparenz ein. Das liegt daran, dass alle Eventualitäten - sprich "Browser" - berücksichtigt werden müssen. Dafür lässt sich diese Navigation aber auch mit reinem CSS und ohne PNG-Grafiken umsetzen, die ja im IE6 für Ärger sorgen würden.

Trotzdem funktioniert auch das hier nicht ohne dem ein oder anderen Mätzchen unserer Lieblings-Browser aus Redmond - den Internet Explorern. Der IE6 benötigt eine feste Breite für die Listenelemente. Hier ist also etwas Anpassung nötig, je nachdem wie lang die Beschriftung der Reiter ist. Der IE7 hingegen hat Probleme mit den Hover-Zuständen, so dass die Reiter hier nicht nach oben fahren und intransparent werden, wenn man mit dem Cursor rüberfährt. Das ist ärgerlich, schränkt jedoch die Benutzbarkeit der Seite nicht ein.

Des weiteren habe ich noch etwas CSS3 verwendet. Mit den aktuellen Versionen von Firefox, Safari und Chrome bekommt man deshalb einen Farbverlauf bei den Reitern serviert. In den gleichen Browsern sowie der aktuellen Version von Opera gibt es außerdem noch einen leichten Schlagschatten bei der Link-Beschriftung.

Das ist auch schon alles. Und natürlich ist diese Navigation nichts WordPress-spezifisches. In der Demo gibt es eine statische Variante, die in jeder anderen Seite auch verwendet werden kann.

Ansonsten mein übliches Mantra an dieser Stelle: Wenn ihr Fragen habt oder etwas nicht so funktioniert, wie es soll, nutzt die Kommentar-Funktion. Und wenn euch das Tutorial gefallen hat, würde ich mich freuen, wenn ihr es bookmarked oder twittert. Vielen Dank :-)

Seit ich diesen Blog gestartet habe, zeige ich meine drei aktuellsten Twitter-Updates mit "Twitter for WordPress" in der Sidebar an. Und seitdem werden die Umlaute zerschossen. Das ist nicht sehr schön und endlich habe ich eine Lösung gefunden, das Problem zu beheben.

Und zwar mithilfe des Plug-Ins "WP-RSS Import" von Frank Bueltge. Dieses setzt genau wie das Plug-In "Twitter for WordPress" auf die WordPress-eigene Funktion fetch_rss(), welche wiederum die Probleme verursacht.

Die Lösung besteht nun aus zwei Arrays aus Franks Plug-In:

PHP
$umlaute = array('&#8211;', '&#8212;',…);
$htmlcode = array('&ndash;', '&mdash;',…);

Die kompletten Arrays kann ich hier nicht angeben, da sie viel zu umfangreich sind. Ihr findet sie aber im SVN-System des Plug-In Directory von WordPress. Die beiden gesuchten Arrays befinden sich in der Mitte und sind eigentlich nicht zu übersehen.

Diese kopiert ihr bspw. in Zeile 70 der Datei twitter.php von "Twitter for WordPress", vor die foreach-Schleife. Als nächstes kommt die Funktion, die dafür sorgt, dass alle Umlaute, die im Array $umlaute stehen, durch die entsprechenden Entitäten aus dem Array $htmlcode ersetzt werden:

PHP
$msg = str_replace($umlaute, $htmlcode, $msg);

Das tragt ihr in Zeile 76 der twitter.php ein und schon seid ihr fertig. Von nun an werden alle mit "Twitter for WordPress" eigebundenen Tweets sauber dargestellt.

An dieser Stelle noch einmal ein Dank an Frank Bueltge für das Erstellen dieser beiden monströsen Arrays. Wer genauso wie ich nach langer, erfolgloser Suche darin endlich die Lösung für das Umlaute-Problem gefunden hat, dem möchte ich den Spenden-Button auf seiner Seite nahelegen. Einen Euro oder mehr für gute Programmier-Arbeit zu spenden ist eine schöne Geste und sorgt dafür, dass die Entwicklung im Open-Source-Bereich weiter geht.