WordPress & Webwork - perun.net

Nehmen wir mal an du arbeitest gerade an einem fremden Rechner, dieser ist spartansich eingerichtet und du musst auf die schnelle PHP-Code testen. Oder ein Kollege hat eine Frage zu einem Perl-Skript und du brauchst etwas wo man das Skript testen kann und worauf ihr beide zugreifen könnt. Für solche Fälle gibt es so Dienste wie codepad:

Man gibt in die Textbox seinen Code ein, neben PHP und Perl werden noch u.a. noch C, C++, Python und Ruby unterstützt. Man hat die Möglichkeit das Code-Beispiel als privat zu markieren und dieser ist nur dann erreichbar wenn man den Permalink zu dem Beispiel kennt. Nach dem du auf Submit klickst wird der Code ausgeführt und auch der Permalink zu dem Beispiel generiert:

Nützliches Webwork-Tool.

Dieser Gastartikel stammt von Matthias Mees. Vielen Dank dafür.

Die PHP-Templateengine Smarty polarisiert. Entwickler, die an Projekten, die Smarty einsetzen, beteiligt sind, schwören auf die Vorteile – andere Entwickler argumentieren üblicherweise (technisch absolut zu Recht), PHP selbst sei bereits eine Templatenengine und ein zusätzlicher "Aufsatz" somit unnötiger Ballast.

Was ist Smarty überhaupt?

Smarty ist eine Art "Basic-PHP für Designer". Die verwendeten Templatedateien sind im Wesentlichen HTML-Dateien, die mehr oder weniger komplexe Platzhalter enthalten, welche durch dynamische Inhalte ersetzt werden. Ergänzend stellt Smarty zudem komplexere Strukturen wie Schleifen, if-Abfragen oder Funktionen bereit und ermöglicht das Einbinden externer Dateien ebenso wie die Definition eigener Konstanten. Die Smarty-Syntax ist an PHP angelehnt, aber vereinfacht. (weiterlesen…)

Dieser Gastartikel stammt von Christian Schaefer aka derSchepp.

Wer kennt das nicht: Bei jedem neuen Webprojekt beginnt man von Neuem, sich sein bewährtes projektübergreifendes Basis-Stylesheet zu schnappen, um sich im weiteren Verlauf der Stylesshet-Programmierung an allerlei langatmigen Selektoren, doppelten und dreifachen Vendor-spezifischen Eigenschaften, IE-Hacks, sowie an syntaktischem Füllmatarial ({};…) abzuarbeiten.

Deshalb kommt es meist so, dass sich das, was in der eigenen Vorstellung umsetzungsmäßig schnell erledigt scheint, am Ende doch immer überraschend lange hinzieht. Und immer wieder flammt auch danach Arbeit in Form von Nachbesserungen auf. (weiterlesen…)

Bei vielen Websites steht entweder im Fußbereich oder in der Seitenleiste ein Copyright-Hinweis samt dem Jahr, als das Projekt gestartet wurde und dem aktuellen Jahr. Weil aber viele auch das aktuelle Jahr hardcoden bzw. manuell eingeben steht jetzt dort immer noch z. B.:

© 2002-2009 Max Müller

daher sollte man die ganzen manuell eingetragenen Jahreszahlen aktualisieren oder stattdessen einfach das aktuelle Jahr dynamisch eintragen:

© 2002-<?php echo date('Y'); ?> Max Müller

Erinnert via @smashingmag.

Das die Version 2.8.3 von WordPress veröffentlicht wurde, dürfte sich mittlerweile herumgesprochen haben. Ich hoffe, ihr habt alle fleißig aktualisiert, weil die Version eine Sicherheitslücke schließt. So weit so gut.

Ich habe auch in der vorletzten Nacht unsere Projekte manuell upgedatet und bei einem Projekt ist mir was komisches passiert. Nach dem ich das Paket hochgeladen habe, brachte mich der Aufruf der Seite zum ersten Installationschritt … so als ob dort keinen WordPress-Installation wäre. Ich checkte die Datenbank: soweit alles in Ordnung. Ich lud noch einmal das Paket hoch und es änderte sich nichts … es hätte ja sein können, dass bei der Übertragung vi FTP etwas schiefgegangen sei. Das hochladen wiederholte ich noch einmal … ohne Ergebnis.

PHPMyAdmin: Tabellen reparieren

Erst als ich in PHPMyAdmin die Funktion "Repariere Tabelle" auf die Datenbank-Tabellen von WordPress angewendet habe, war alles wieder in Ordnung. Da ich kein Datenbank-Spezi bin, kann ich nur vermuten was da abgelaufen ist. Na ja, die Hauptsache ist, dass es mir geholfen hat und vielleicht hilft es einem oder anderem da draußen.

Nun bin ich wieder komplett gesund, nach dem mich die letzte Woche eine ordentliche Erkältung (Fieber, Schnupfen und hartnäckiger Husten) für gut vier Tage KO geschlagen hat. Anschließend gab es drei Tage heftige Rückenschmerzen, weil ich mich verlegen habe und in der Zeit konnte ich weder sitzen noch stehen sondern nur liegen.

Ich habe gedacht das der Giftkelch an mir vorbeigehen würde. Nach und nach wurden die Leute um mich krank, ich blieb gesund und dachte, mich erwischt es nicht … Pustekuchen. So ist es halt wenn man Kinder hat, aus irgendeiner Krabbelgruppe wird das Zeugs eingeschleppt … Widerstand ist zwecklos.

So eine lange aufgezwungene Auszeit kommt nie erwünscht, aber muss die denn immer dann kommen wenn man sehr viel zu tun hat? Der Murphy ist schon eine dumme Sau. Na ja, schade ist das ich dadurch das 5-jährige Bestehen dieses Weblogs verpasst habe. Am 15. Januar 2004 habe ich hier den ersten offiziellen Blog-Beitrag gepostet.

Am 21. Januar ist Version 2.09 des PHP-Magazins erschienen. Dort haben meine Holde und ich einen Artikel über WordPress 2.7 beigesteuert. Wir arbeiten uns langsam voran. Nach der iX und der c't haben wir uns auch im PHP-Magazin ausgetobt. Mal schauen wo uns noch so die Reise hinführt, es bleibt spannend.

Nun geht es darum dieses Weblog hier mit frischem Inhalt zu füllen.

Heute Nacht hat all-inkl.com meinen kompletten Account auf einen anderen Server umgezogen. Zum einen weil der alte Server richtig in die Knie ging und zum anderen weil ich PHP und MySQL in aktueller Version haben wollte. Das ging recht schnell und ohne größere Probleme. Jetzt habe ich auf dem Server PHP 5.2.6 und MySQL 5.0.51a im Einsatz … vorher war es PHP 4.4.8 und MySQL 4.0.23.

Ich hatte Sorge, wie ich es in einem früheren Beitrag beschrieben habe, wegen dem Zeichensatz-Wirrwarr (iso-8859-1 vs. utf-8). Zum einen weil ich von vielen gehört habe das es Probleme gibt beim Upgrade von alten MySQL-Versionen und speziell dann wenn vorher iso im Einsatz war. Deswegen hatte ich auch Sorge wegen perun.net, weil es schon von Anfang an mit iso kodiert wird.

Nun musste ich heute Nacht ein bisschen lachen. Alle Weblogs die auf utf-8 waren, hatten demolierte Umlaute und perun.net nicht. Ich schaute mir die Datenbanken an und überall war latin1_swedish voreingestellt … daher war es nicht verwunderlich das die Sonderzeichen kaputt sind.

Was machen? Als erstes stellte ich perun.net auf utf-8 um. Dadurch das die Umlaute korrekt waren, war dies an sich kein Problem. Ich habe die Datenbank exportiert in einem Texteditor aufgemacht und so wie Monika es beschreibt habe ich nach CHARSET=latin1 gesucht und diese durch CHARSET=utf8 ersetzt. Das ging vorher mit der alten MySQL-Version (kleiner 4.1) leider nicht.

Danach die Datenbank importiert und im Weblog im Admin-Bereich auf utf-8 umgestellt … das war's! Das war mein Weg, ich bin allerdings zuversichtlich das es noch mind. 2-3 weitere Vorgehensweisen gibt.

Bei den zerschossenen Umlauten war das einen kleinen Tick zeitintensiver. Entweder man hat ein Datenbank-Backup, dann muss man es neu importieren – damit man die Sonderzeichen und Umlaute wiederherstellt – und dann so vorgehen wie ich es bereits oben beschrieben habe.

Ich hatte vorher in PHPMyAdmin versucht die Zeichensätze umzustellen und auch in der wp-config.php die Kollation umzustellen, die Datenbank hat sich davon nicht beeindrucken lassen. Deswegen habe ich auch hier den Umweg über den Texteditor die Zeichensätze einstellen müssen.

Hat man kein Backup, dann ist es auch kein Problem. Dann exportiert man die Datenbank, öffnet sie in einem Texteditor und ersetzt zuerst die kaputten Sonderzeichen und anschließend die Zeichensatz-Angaben und importiert das ganze.

Und wie schauen die kaputten Sonderzeichen aus die man durch "Search & Destroy" (aka Suchen und Ersetzen) umwandeln muss? Gute Frage, ü ist z.B ü und ß steht für ß usw. Auf konzentrat.org gibt es eine vollständigere Liste. Dort wird auch beschrieben, wie man im PHPMyAdmin anstatt im Texteditor den Ersetz-Vorgang durchführt.

So jetzt habe ich ein bisschen die Nase voll von verschiedenen MySQL-Versionen und Zeichensätzen und hoffe das ich für eine sehr lange Zeit nicht mehr mit dem Problem konfrontiert werde.

Übrigens hatte ich als Texteditor PSPad benutzt, weil mein eigentlicher HTML-Editor (WeBuilder) bei MySQL-Dateien dir größer als 350-400 KByte waren sich verabschiedet hat.