Artikel mit dem Tag php
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 >>
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!
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!
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:
Wenn man PHP-Code bzw. bestehende oder neue PHP-Dateien in WordPress einbinden möchte, macht man das am besten im aktuellen Theme von WordPress. Man legt ein sogenanntes Seiten-Template an, welches man bei der Bearbeitung der Seite in WordPress wählen kann. In diesem Template befindet sich dann das gewünschte PHP-Script.
Weiterlesen >>
Wenn sich die Domain oder Url einer Website geändert hat, empfiehlt sich eine Weiterleitung auf die neue Adresse mit dem HTTP-Statuscode 301 (Moved Permanently). Der Code 301 deshalb, damit auch Suchmaschinen wie Google wissen, das sich die Adresse für immer geändert hat und nur die neue Url verwendet werden soll. Google berücksichtigt hier auch den Pagerank und ordnet diesen der neuen URL zu.
Die Technik
Technisch gesehen werden vom Webserver im HTTP 2 Zeilen an den Client (Nutzer mit Browser, Suchmaschine) gesendet. Eine mit dem Statscode und eine mit dem Ziel der Weiterleitung:
HTTP/1.1 301 Moved Permanently
Location: http://www.neue-url.de/pfad/zur/datei.htm
Eine HTTP-Sitzung per Telnet auf Port 80 sieht dann zum Beispiel so aus:
# telnet alte-domain.de 80
Trying 12.34.56.78...
Connected to alte-domain.de.
Escape character is '^]'.
GET / HTTP/1.1
Host: alte-domain.de
HTTP/1.1 301 Moved Permanently
Date: Thu, 25 Feb 2009 20:06:55 GMT
Server: Apache/2.2.11
Location: http://neue-domain.de/
Content-Length: 225
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://neue-domain.de/">here</a>.</p>
</body></html>
Connection closed by foreign host.
mod_rewrite – die Lösung
Um dies mit Hilfe des Webservers Apache zu lösen, hilft uns das Modul Rewrite, kurz mod_rewrite. Hat man Zugriff auf die Konfigurationsdatei des Webservers, kann man die Rewrite-Weiterleitung im VirtualHost, in der Directory- oder Location-Direktive vornehmen. Anonsten erstellt man eine .htaccess-Datei und nimmt die Konfiguration hier vor.
Um mod_rewrite zu aktivieren, benötigen wir folgende zwei Zeilen:
RewriteEngine on
RewriteBase /
Weiterlesen >>
Ich habe gestern mit einem Kollegen versucht, eine Selectbox mit dem Javascript-Framework Prototype per Ajax zu füllen. Mit jQuery – was wir in letzter Zeit mehr einsetzen – keine grössere Sache. Mit Prototype aber mussten wir etwas grübeln. Da ich in Google nicht wirklich fündig geworden bin, gibt es hier nun ein Beispiel. (Und ich kann gleich das Syntax-Highlighting in WordPress testen :-)
Weiterlesen >>
Hola! Ich bin Nico und du liest gerade meinen Blog über Webentwicklung, Webdesign, Linux und alles was mit dem Internet zu tun hat. Seit 1997 entwickle ich Websites und habe in dieser Zeit in den verschiedensten Bereichen gearbeitet. Ob nun Webdesign, Software-Entwicklung, Server-Administration, Marketing und SEO, alles macht Spaß und ergänzt sich wunderbar. Neben diesem Blog betreibe ich noch diverse andere Projekte wie zum Beispiel die