In der letzten Zeit sind mir viele neue und nützliche Tools aufgefallen, die man als Webentwickler und Webdesigner bei der täglichen Arbeit gut gebrauchen kann und die einem diese um einiges erleichtern. Ich möchte mich mit dieser Liste bei den Entwicklern der Tools bedanken und jedes einzelne natürlich vorstellen und weiterempfehlen. Wirklich interessant, was mittlerweile alles möglich ist und welche Ideen die Entwickler dieser Tools haben. Aber legen wir los mit der Liste der 15 nützlichen Tools für Webdesigner und Webentwickler. Es sind sowohl neue als auch schon länger bestehende dabei:

(weiterlesen …)

Das der nginx-Webserver schneller und performanter als z.B. der Apache ist, hatte ich in meinem letzten Blogbeitrag zur Installation und Konfiguration von nginx bereits geschrieben. Wenn WordPress oder PHP auf dem Apache mit mod_php generell zu langsam werden, macht auch hier die Überlegung Sinn, auf einen anderen Webserver umzusteigen. In Sachen Performance und Performance-Optimierung nicht nur für WordPress und PHP ist nginx aktuell die erste Wahl.

Bei den meisten Installationen unter Apache läuft PHP als Modul. Das heisst, für das Ausführen von PHP muß kein neuer Prozess gestartet werden, sondern die Verarbeitung bzw. Parsen der PHP-Dateien übernimmt das beim Start des Apachen geladene PHP-Modul. Für nginx gibt es solch ein Modul nicht, weshalb wir auf die CGI-Version von PHP zurückgreifen müssen. Dies ist nicht weiter tragisch, da die Performance – eine halbwegs schnelle CPU vorausgesetzt – aus Erfahrung nicht darunter leidet. Doch wie konfiguriert man nginx, um ihn für das Ausliefern von dynamischen PHP-Scripts vorzubereiten?

(weiterlesen …)

Der Apache-Webserver ist das Non Plus Ultra in Sachen Webserver-Software. Seit mehr als 15 Jahren führt der Platzhirsch die Liste der meist genutzen Webserver an. Aktuell, im Februar 2011, werden bei Netcraft 171,195,554 Hostnamen mit Installationen des Apachen gemessen. Das sind 60.10% aller Webserver-Installationen weltweit.

Marktanteile Top-Server über alle Domains Aug. 1995 – Feb. 2011. Quelle: netcraft.com

Seine weite Verbreitung, immerhin ist der Apache fast bei jedem Betriebssystem außer Windows dabei, die Anzahl der erhältlichen Erweiterungen und Module und die relativ leichte Konfiguration, auch in Massenhosting-Umgebungen, machen den Apache auch für Einsteiger zu einem Webserver der ersten Wahl. Wer jedoch mit viel Traffic zu tun hat und dabei eine serverseitige Skriptsprache wie PHP, Perl, Ruby oder ähnliches einsetzt, wird mit dem Apachen früher oder später an seine Grenzen stossen. Es ist mit Hilfe von Reduzierung auf wesentliche Module, Performance-Tuning und Tuning des Linux Systems natürlich sehr viel raus zu holen, doch irgendwann steht die Frage nach einer Alternative im Raum.

(weiterlesen …)

Ich liebe Einzeiler und in einer Zeile Code das zu machen, wofür andere oder man selbst vorher ganze 20 Zeilen oder mehr benötigte. Um sich diese Einzeiler zu merken, fange ich hier einfach mal eine Liste an, die ich ständig erweitern werde.

Auch wenn die Zeichen aufgrund mangelnder Breite in meinem Layout umbrechen, sind dies alles Einzeiler ;-)

Zufallsstring mit PHP – Einzeiler

Variante 1

echo substr(str_shuffle("23456789abcdefghjkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"), 0, 8);

Ja, ich kann zählen und das Alphabet auch. Unnötige und für Passwörter ungeeignete Zeichen habe ich hier weg gelassen.

Variante 2

Wer es noch kürzer braucht, kann auch md5 nehmen. Danke an Jonathan für den Hinweis. Aber Achtung, hier sind nur die Zeichen 0-9 und a-f enthalten.
echo substr(md5(time()),0,8);
Du hast auch schöne Einzeiler, die richtig Sinn und das PHP-Entwickler-Leben leichter machen? Bitte ab damit in die Kommentare oder per E-Mail an mich. Danke!

Da drüben macht sich Robert gerade nackig und erzählt uns, welche WordPress-Plugins er als Must Have’s erachtet und man unbedingt in seinem WordPress-Blog installiert haben sollte. Natürlich gibt es solche Listen schon wie Sand am Meer, ist mir aber egal, ich finde solche Listen nämlich super interessant, da man hier das ein oder andere Plugin entdeckt, welches man selbst noch nicht installiert oder entdeckt hat. Zum anderen ist bei Roberts Erfahrung natürlich interessant zu sehen was er so bevorzugt. Das Plugin Gurken Subscribe to Comments hab ich mir zum Beispiel schon mal installiert, danke! Deshalb zieh ich hier auch mal blank und schreib euch mal meine Liste der 10+1 Must Have WordPress-Plugins nieder. Das Ganze in alphabetischer Reihenfolge, damit sich kein Plugin benachteiligt vorkommt und nachher Amok läuft ;-) (Das Redirection-Plugin hat das gestern übrigens getan und die Startseite beim Posten eines neuen Artikels immer auf diesen Artikel weitergeleitet. Nett, sowas kann bei Plugins auch passieren!) Auf die Liste los:

1. .html on PAGES

Ich finde wichtig, das man alle Dateiendungen – sofern man welche nutzt – auf einer Webseite einheitlich hat. Da ich bei Posts die Endung .html bevorzuge, sollten auch die Seiten diese Endung haben dürfen. Man sagt es sei auch wichtig für Google.

2. All in One SEO Pack

Das ultimative SEO-Plugin. Hier kann man eigentlich alles einstellen, was man an SEO benötigt. Es gibt sicher einige andere oder bessere, hab mich aber auf dieses eingeschossen.

3. Antispam Bee

Verhindert Spam in Kommentaren und Pings sehr zuverlässig. Ziehe ich Askimet unbedingt vor, da es dem deutsche Datenschutz gerecht wird (falls das möglich ist:) und man hier keinen API-Key benötigt und es genauso gut wenn nicht besser läuft als Askimett.

4. Delete-Revision

WordPress legt bei jedem Speichern eine Version das Posts an, d.h. pro Speichern ein Datensatz in der Datenbank. Das wird natürlich bei vielen Artikeln auch ohne akutem Zucken auf den Speichern-Button eine Menge an Daten, die später so nicht mehr benötigt werden. Das Löschen der nicht benötigten Versionen bzw. Revisionen erledigt dieses Müllschlucker-Plugin “Delete-Revision” zuverlässig. Yamyam!

5. Permalink Redirect

Noch ein SEO-Plugin. Entfernt alle unnötigen GET-Parameter bzw. Attribute und URL-Parts (the whole Crap!) von der URL und leitet auf die eigentliche URL weiter. Verhindert Duplicate Content. Wichtig für Google und SEO, also ein Muss.

6. Permalinks Moved Permanently

Ändert man mal den Permalink, also die URL eines Posts, muß die alte natürlich auf die neue weitergelietet werden. Das erledigt dieses nette Plugin.

7. Robots Meta

Ermöglicht pro Artikel oder Seite die Einstellung des Robots-Meta-Tag’s. Hiermit lässt sich bestimmen, welche Seiten oder Artikel im Google-Index indexiert werden sollen und wo Links verfolgt werden dürfen. Sehr nützlich für den SEO-Steuermann.

8. SEO Friendly Images

Fügt automatische Alt- und Title-Attribute zu Bildern hinzu. Genial, wenn man mit Bildern in Google gefunden werden will. Spart ‘ne Menge Arbeit.

9. WordPress Database Backup

Hier kann man sich das Backup der WP-Datenbank in einem bestimmten Interval, beispielsweisse täglich, per Mail zusenden lassen, auf einem Rechner oder in einem Verzeichnis speichern lassen. Security first!

10. WP Super Cache

Cached alle Inhalte als statische HTML-Seiten, was die Ladezeit um einiges veringert. Dauer und Regeln lassen sich beliebig anpassen.

11. Yet Another Related Posts Plugin

Verlinkt passende Artikel untereinander. Klasse Plugin und Algorithmus! Bringt nicht nur dem benutzer viel Komfort, sondern auch Google und SEO.

Das ist sie also, meine Liste der Plugins die ich aktuell und aus den letzten 6 Jahren Erfahrung am wichtigsten erachte.

Nein, ein Plugin zur Integration von Twitter oder Facebook hab ich nicht, das hab ich bisher lieber selbst gemacht, da die meissten das Design zerschossen haben und das Fixing zu aufwendig gewesen wäre oder mir eben benötigte Features fehlten. Vielleicht findet sich aber noch ein brauchbares.

Wie sieht es bei euch aus, was habt Ihr unter der Haube? Oder haltet Ihr das ein oder andere Plugin für Käse?

Aktuell stelle ich mir oft die Frage, ob ich Software für WordPress entwickle oder eine eigene Anwendung in Ruby on Rails schreibe. Beides hat seine Vor- und Nachteile. Ich entwickle seit 10 Jahren Software in PHP, seit etwa 5 Jahren auch in Ruby on Rails, was ich aufgrund seiner vielen bekannten positiven Eigenschaften bei komplett neuen Anwendungen auf jeden Fall vorziehen würde. Aus diesem Grund stellt sich mir diese Frage, obwohl Rails und WordPress auf den ersten Blick ja nicht unbedingt in der gleichen Kategorie von Tools anzusiedeln sind, auf den zweiten aber beides Frameworks mit ähnlichen Voraussetzungen sind.

WordPress hat eine riesige Community, viele Nutzer und einen hohen Bekanntheitsgrad. Wenn man beispielsweisse ein WordPress-Plugin schreiben möchte, kann man sich durch schon vorhandene Plugins wuseln und von bestehendem Code Anregungen holen und evtl. sogar Teile verwenden – natürlich nur unter Einhaltung des Copyrights. Möchte man dieses Plugin verkaufen, hat man mit WordPress eine sehr große und täglich wachsende Menge an potenziellen Kunden. Ein weiterer Vorteil ist die große Menge an Einsatzgebieten von WordPress. WordPress kann als Blog verwendet werden, als normale Webseite mit oder ohne CMS, als Forum, als Gallery, als Community und und und. Das meiste natürlich mit fertigen Plugins. Warum also etwas eigenes entwickeln, wenn es alles schon gibt? Zumal ja fast jede Webseite sowieso einen Blog und somit auch WordPress hat und benötigt. Die Nachteile bei WordPress liegen ganz klar bei der mangelnden Performance und – für mich persönlich – an der etwas veralteten Scriptsprache PHP. Logisch kann man die Performance mit ein paar Tricks, passenden Plugins und besserer Server-Hardware tunen, dennoch ist WordPress den eigenen Lösungen in PHP oder Ruby On Rails klar unterlegen. Gerade wenn der Content in der Datenbank wächst – und ich meine hiermit eine Menge von 1000+ Artikeln – wird WordPress zur Slow-Motion-Bremse.

Ruby on Rails ist hingegen, wenn man es richtig anstellt, ein richtiger Turbo und Spaßfaktor. Das Coden in Ruby macht einfach einen Riesenspaß, was die Produktivität um einiges steigert. Das DRY-Prinzip richtig angewendet, muß hier bei gleicher Funktionalität auch weniger Code geschrieben werden. Man kann also sagen, das mit Rails einfacher in hoher Qualität Software entwickelt werden kann. Ebenso gibt es für fast alle Belange fertige Plugins und Librarys, die man beliebig erweitern und verwenden kann. Die Menge der Entwickler ist zwar hoch und wird immer höher, aber es gibt lange noch nicht so viele wie für WordPress. Ruby On Rails wird eher von Profis eingesetzt, Hobby-Entwickler hingegen greifen schnell zu PHP und WordPress. Desweiteren benötigt man für Rails immer eine gesonderte Server-Konfiguration, weshalb die meisten bekannten Webhoster hier ausscheiden. Noch ein negativer Punkt ist, das es für Rails keine gute Blog-Software gibt. Zwar sind einige wenige Versuche vorhanden, die an WordPress jedoch bei weitem nicht heranreichen. Schade eigentlich, eine gute Blog-Software in Ruby wär was feines und sicher ein schönes Projekt.

Also bleibt ganz klar eines zu sagen. Möchte man Software vielen Millionen Menschen verfügbar machen oder womöglich verkaufen, empfiehlt sich der Einsatz von WordPress. Legt man jedoch Wert auf Performance, Spaß beim Coden und hat Profis zur Hand, ist Rails eine gute Wahl. Also ist meine erste Überlegung in der Richtung ab jetzt: “Möchte ich die Software nur für mich oder auserwählte Kunden nutzen oder an tausende Kunden verkaufen?”.

Was meint Ihr dazu? Lieber WordPress oder Rails bzw. anderen Sprachen oder Frameworks? Freu mich über Kommentare!

Oft kommt es vor, das man zwei oder mehr Elemente, sei es nun ein Layer, Bild oder was auch immer, mit gleicher Höhe darstellen will. Das stellt bei statischen Inhalten überhaupt kein Problem dar, gibt es doch die schöne CSS-Eigenschaft height.

Was aber, wenn wir dynamische Inhalte darstellen wollen und gar nicht wissen wieviel Inhalt wir pro Element bekommen. Bei Texten, längeren Namen or whatever aus einer Datenbank ist dies oft der Fall. Durch den unterschiedlich langen Inhalt werden die Elemente nun dementsprechend anders hoch dargestellt. Das sieht bei Elementen die wir nebeneinander zeigen möchten meistens ziemlich doof aus.

Hier kann das Javascript-Framework jQuery helfen. jQuery bietet eine Funktion mit dem Namen .height(), die uns die Höhe eines Elements setzen oder auslesen kann. Hier wird nicht einfach die CSS-Eigenschaft height ausgelesen, sondern die fertig gerenderte Höhe des Elements. So braucht man mit jQuery nicht viel Mühe, um alle gewünschten Elemente zu durchlaufen, das höchste zu bestimmen und alle Elemente auf eben diese Höhe anzupassen.

(weiterlesen …)

Oft kommt es als Webmaster vor, das man eine Liste mit URL’s auf Fehler prüfen muß. Um zum Beispiel eine Liste mit URL’s auf tote Links bzw. 404 Not Found Fehler zu prüfen, kann man folgendes in Ruby geschriebene Script zu Hilfe nehmen. Das Script fällt in die Kategorie Quick Hack und ist unbedingt ausbaufähig.

require 'net/http'

def check_for_notfound(url)
  uri = URI.parse(url)
  response = Net::HTTP.get_response(uri)

  case response
    when Net::HTTPNotFound:
      return true
    when Net::HTTPRedirection:
      puts check_for_notfound('http://' + uri.host + response['location'])
    else
      return nil
  end
end

File.open(ARGV[0]) do |f|
  f.each do |line|
    result = check_for_notfound(line)
    if !result.nil? and result == true
     puts line
    end
  end
end

Wer ein besseres Script hat oder etwa eine Möglichkeit weiß, wie man dies mit wget lösen kann, bitte einen Kommentar hinterlassen. Danke!

Update:

Wie ich Dank eines anderen Blogs erfahren konnte, ist das mit wget natürlich auch schnell und sogar mit einem Einzeiler lösbar:

wget -r -nd --delete-after --no-parent --no-cookies --input-file=urls.txt

Ob man nun Ruby oder wget nutzt, hängt ganz davon ab, ob man es in eine Software integrieren möchte oder ob es nur einem schnellen administrativen Todo dienen soll.

Sinatra hat offiziell den Landmark Release 1.0 erreicht. Das schmale Web Application Framework ist eine echte Alternative zu Ruby On Rails, insbesondere wenn man kleinere und schnellere Projekte erstellen möchte.
Ich selbst habe es einige Male getestet, aber aus Zeitmangel für’s Lernen leider noch nicht im Einsatz.

Eine einfache Webseite ist in Sinatra leicht geschrieben:

require 'rubygems'
require 'sinatra'

get '/hi' do
"Hello World!"
end

Mehr Infos unter http://www.rubyinside.com/sinatra-1-0-released-3162.html.

Eben entdeckt: Bei Ubuntu und Debian ist in PHP standardmässig die Garbage Collection deaktiviert. Diese sorgt dafür, das die Sessionfiles für abgelaufene Sessions automatisiert gelöscht werden. Bei Ubuntu und Debian löst ein Cronjob diesen Löschvorgang.

Ein Problem entsteht allerdings, wenn man eigene Verzeichnisse für die Sessionfiles definiert. Hier werden die Files dann nicht gelöscht und bleiben bestehen, was das Verzeichnis – je nach Traffic – schnell auf ein paar Tausende Dateien anwachsen lassen kann.

Um die Garbage Collection in PHP zu aktivieren, muss folgender Eintrag in der php.ini (für Apache unter /etc/php5/apache2/php.ini) geändert werden:

VORHER

;session.gc_probability = 0
session.gc_divisor = 100

NACHHER

session.gc_probability = 1
session.gc_divisor = 100

Diese Änderung bewirkt, das bei jedem hundertsten Start einer Session die Sessionfiles gelöscht werden.

Zusätzlich muss dann noch der Cronjob deaktiviert werden. Hierzu einfach /etc/cron.d/php5 mit dem Editor deiner Wahl bearbeiten und die letzte Zeile auskommentieren:

# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
#09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm


Was der Grund für diese Deaktivierung bei Ubuntu oder Debian war konnte ich auf die Schnelle nicht herausfinden, werde es aber in einem Update nachliefern.

Wenn in Linux-Distributionen solche Änderungen vorgenommen werden, sollte man aber passende Toolsets liefern, um alle Variationen abzufangen. So ist das nur eine halbe Sache, wenn ich nichts übersehen habe. Der Bug wurde auch schon im Ubuntu-Bugtracker aufgenommen, aber noch keinem zugeordnet.

Weiterführende Links:

• PHP Dokumenation: session.gc-probability
• Bug bei Ubuntu