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?

Installation von PHP5-CGI

Zuallererst benötigen wir nun die CGI-Version von PHP. Falls sie noch nicht installiert ist, können wir sie entweder selbst kompilieren oder verwenden von der Linux-Distribution bestehende Pakete. Für Ubuntu ist die Installation hier mit einer Zeile erledigt:

# apt-get install php5-cgi

Sofern man für WordPress zum Beispiel noch mehr Module wie MySQL oder GD benötigt, könnte die Zeile auch so aussehen:

# apt-get install php5-cgi php5-dev php5-gd php5-mysql

Die Verbindung zu nginx: Sockets für PHP

Damit wir PHP mit nginx nutzen können, benötigen wir sogenannte Sockets unter denen das PHP auf Anfragen von nginx wartet, wahlweisse als TCP- oder UNIX-Domain-Socket. Da ein Socket ständig auf neue Verbindungen wartet, muß ein neuer Prozess erzeugt werden, der diese Arbeit übernimmt. Dieser Prozess erzeugt weitere Unterprozesse und leitet die PHP-Anfragen dann an diese weiter.

Es gibt nun mehrere Möglichkeiten die PHP-Prozesse zu starten. Die Aufgabe ist hier, die Prozesse als Daemon und unter einem anderen User laufen zu lassen, sowie die Standard- und Fehler-Ausgaben umzuleiten.
Zwei Möglichkeiten möchte ich hier aufzeigen: Zum einen kann man die Prozesse ganz normal per Startscript starten, auf Ubuntu zum Beispiel mit dem start-stop-daemon. Zum anderen gibt es Tools wie spawn-fcgi, mit dem ich jedoch nicht so gute Erfahrungen gemacht habe, da es bei mir öfters, teilweisse sogar mit Segfaults, unter Last abstürzte. Da ich aber keine Zeit hatte, dem Grund auf die Spur zu gehen und PHP mit dem start-stop-daemon bei mir ziemlich gut läuft, möchte ich euch spawn-fcgi der Vollständigkeithalber nicht vorenthalten. Sicher auch hilfreich für andere Linux-Distributionen.

PHP im FASTCGI-Modus mit Startscript

Die in PHP mitgelieferte CGI-Version php5-cgi erledigt im FastCGI-Modus die Socketbindung und das Erzeugen von neuen Prozessen selbstständig und sehr zuverlässig. Zum Starten benötigen wir ein Startscript, welches wir unter /etc/init.d/fastcgi anlegen:

# vi /etc/init.d/fastcgi

Inhalt:

#!/bin/bash
BIND=127.0.0.1:8088
USER=www
PHP_FCGI_CHILDREN=15
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php5-cgi

PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0

start() {
    echo -n "Starting PHP FastCGI: "
    start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
    RETVAL=$?
    echo "$PHP_CGI_NAME."
}
stop() {
    echo -n "Stopping PHP FastCGI: "
    killall -q -w -u $USER $PHP_CGI
    RETVAL=$?
    echo "$PHP_CGI_NAME."
}

case "$1" in
   start)
    start
;;
   stop)
    stop
;;
   restart)
    stop
    start
;;
   *)
    echo "Usage: php-fastcgi {start|stop|restart}"
    exit 1
;;
esac
exit $RETVAL


Die ersten fünf Variablen werden zur Konfiguration benötigt und bedeuten folgendes:

BIND: IP-Adresse und Port, unter denen auf Verbindungen gewartet wird
USER: Benutzer, unter dem die Prozesse laufen
PHP_FCGI_CHILDREN: Anzahl der zu forkenden bzw. erstellenden Prozesse
PHP_FCGI_MAX_REQUESTS: Anzahl von Requests, nach denen der Prozess stirbt (neue werden automatisch erstellt)
PHP_CGI: Pfad zu php5-cgi

Evtl. muß nun noch der Pfad zu php5-cgi und der Benutzer angepasst werden und wir können das Script nach einem chmod ausführen:

# chmod 700 /etc/init.d/fastcgi
# /etc/init.d/fastcgi start


Mit dem Befehl “ps ax” sollten wir nun in der Prozessliste unsere PHP-Prozesse laufen sehen und gehen jetzt zur nginx-Konfiguration über.

Fast-CGI mit spawn-fcgi

spawn-fcgi macht eigentlich auch nichts anderes als das Startscript unter Ubuntu. Es erstellt einen TCP/Unix-Domain-Socket und die gewünschte Anzahl von Prozessen unter einem bestimmten Benutzer und leitet die Ausgaben ensprechend um. Zur Installation benötigen wir natürlich die aktuellen Sourcen von spawn-fcgi, deren Link wir auf der News-Seite des Projektes erhalten. Download, Entpacken und ins Verzeichnis wechseln:

# wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
# tar -xvzf spawn-fcgi-1.6.3.tar.gz
# cd spawn-fcgi-1.6.3


Nun folgt das bekannte Zweiergespann zum Kompilieren. spawn-fcgi besitzt keine Install-Routine, weshalb wir dies selbst vornehmen müssen:

# ./configure
# make
# cp ./src/spawn-fcgi /usr/bin/spawn-fcgi


Nun können wir das Tool das erste mal starten.

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 8088 -F 3 -u www -f /usr/bin/php5-cgi

Die Bedeutung der Optionen:

-a    IP-Adresse, an der auf Verbindungen gewartet wird
-p    Port, an dem auf Verbindungen gewartet wird
-w    User unter dem die Prozesse laufen sollen
-f    Pfad zum PHP-CGI
-F    Anzahl der Prozesse, die geforkt werden sollen

Konfiguration des nginx für PHP mit Fast-CGI

Wenn wir bereits einen fertigen nginx am Laufen haben, sind nur wenige Zeilen in der Konfiguration zu ergänzen. Ansonsten lies bitte zuerst meine Anleitung zur Installation und Konfiguration des nginx.

Innerhalb des Vhosts, also innerhalb von server {} fügen wir eine neue Location-Direktive für PHP-Files hinzu:

   location ~ .*\.php$ {
    root /var/www/meinedomain.de/htdocs;
    fastcgi_pass 127.0.0.1:8088;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
   }


Hier darauf achten, das die Angaben in fastcgi_pass mit denen der vorhin konfigurierten übereinstimmen. include fastcgi_params inkludiert eine Datei, die bei der nginx-Installation enthalten ist, möchte Sie hier jedoch abbilden für den Fall das…

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;


Damit nginx auch beim Aufruf der Domain ohne Dateiname in der URL die Startseite als PHP ausführt, müssen wir zwei Parts in der bestehenden Konfiguration unter server {} anpassen bzw neu einsetzen:

Als erstes machen wir die Datei index.php zur ersten Wahl beim Aufruf ohne Dateiname:

index index.php index.html index.htm;


Alles andere was nicht gefunden wird, leiten wir ebenfalls auf index.php weiter:

# this sends all non-existing file or directory requests to index.php
if (!-e $request_filename) {
rewrite . /index.php last;
}


Das komplett Konfigfile könnte nun so aussehen:

server {
        # IP-Adresse und Port, an denen für Web-Zugriffe gelauscht wird
        listen     1.2.3.4:80;

        # Domains, auf die dieser Server hören soll
        server_name www.meinedomain.de meinedomain.de;

        # Hauptverzeichnis für Dokumente
        root         /var/www/meinedomain.de/htdocs;

        # Ort des Access-Logfiles
        access_log /var/www/meinedomain.de/logs/access_log vhosts;

        # Definition des Index-Files (Startseite, für Anfragen ohne Dateiname)
        index index.php index.html index.htm;;

        # Wenn Zugriff auf andere als Standarddomain,
        # auf diese per 301 permanent weiterleiten
        if ($host != 'www.meinedomain.de' ) {
         rewrite ^/(.*)$ http://www.meinedomain.de/$1 permanent;
        }

        # Für Bilder und einige andere Dateitypen Access-Log ausschalten und
        # Expire-Zeit auf 7 Tage erhöhen (sendet den entspr. Expire-Header)
        location ~* ^.+\.(js|css|jpg|jpeg|gif|png|pdf|zip|rar)$ {
         access_log off;
         expires     7d;
        }

        location / {
         # Nützlich für SSL und evtl. später hinzukommende Scriptsprachen
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_redirect off;

         # Wenn die angeforderete statische Datei existiert, diese ausliefern
         # ohne die anderen Regeln weiter unten zu beachten
         if (-f $request_filename) {
            break;
         }

         # this sends all non-existing file or directory requests to index.php
         if (!-e $request_filename) {
            rewrite . /index.php last;
         }
        }

        location ~ .*.php$ {
         root /var/www/meinedomain.de/htdocs;
         fastcgi_pass 127.0.0.1:8088;
         fastcgi_index index.php;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
         }
}


Jetzt heißt es den nginx mit /etc/init.d/nginx restart neu starten und PHP ist einsatzbereit.

WordPress kann nun ganz normal installiert und verwendet werden.

Insofern man ein Cache-Modul wie WP-Super-Cache nutzt, sollte man noch die entsprechenden RewriteRules für die statischen HTML-Dateien setzen. Für WP-Super-Cache beispielsweisse einfach folgende Zeilen innerhalb location / {} und vor der Einstellung für die .php-Dateien kopieren:

if (-f $document_root/cache$fastcgi_script_name) {
rewrite (.*) /cache$1 break;
}
if (-f $document_root/cache/$fastcgi_script_name/index.html) {
rewrite (.*) /cache/$1/index.html break;
}
if (-f $document_root/cache$fastcgi_script_name.html) {
rewrite (.*) /cache$1.html break;
}


Geschafft! Jetzt haben wir nginx mit PHP laufen und können uns über die bessere Performance freuen. Wenn du noch weitere Beispiele für Konfigurationen, auch für andere Sprachen und Einsatzmöglichkeiten suchst, empfiehlt sich ein Blick auf die Configuration-Seite von nginx.

Sicher folgen noch einige Artikel mehr über den nginx, um meine Begeisterung kund zu tun ;-) Solltest Du also Fragen, Wünsche, Vorschläge oder sonstiges haben, ab damit in die Kommentare, ich freue mich!

Credits:

Original-Foto Strap-On Video Rocket unter Creative Commons von jurvetson auf Flickr. Danke!

No related posts.

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!

No related posts.

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!

No related posts.

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

No related posts.

Seiten-Template mit PHP-Code im Theme Ordner von WordPress anlegen

Lege eine neue Datei im Theme-Ordner unter wp-content/theme/<themename>/deintemplate.php mit folgendem Inhalt an:

<?
/*
Template Name: DeinTemplate-Name
*/
?>
<?php get_header(); ?>

<?php if (have_posts()) : ?>
<?php while (have_posts()) : the_post(); ?>

<div class="post page">
<h2><?php the_title(); ?></h2>
<?php the_content(); ?>
</div>

<?php endwhile; ?>
<?php endif; ?>

<?php echo "Hier kommt mein tolles PHP-Script bzw. der PHP-Code rein!"; ?>

<?php get_footer(); ?>


Wichtig hierbei ist der Kommentar, der unbedingt enhalten sein muss. WordPress erkennt anhand des Strings "Template Name", das es sich um ein Template handelt. Die Funktion get_header bindet das Header Template ein (wie gewohnt) und die Funktion get_footer das Footer-Template. Nach dem Header wird mit den Post-Funktionen der Inhalt der Seite, also die Headline und der Text, ausgelesen.
Anstelle des echo-Befehles (Hier kommt mein…) kann jetzt gewünschter PHP-Code eingefügt werden.

Seiten-Template auswählen und Seite mit PHP-Code anlegen

Jetzt kannst du im WordPress-Admin in der Seiten-Verwaltung unter "Seiten" ganz normal eine Seite anlegen und auf der rechten Seite neben dem Formular das erstellte Seiten-Template mit dem Namen aus dem Kommentar auswählen. Seite veröffentlichen und schon wird der Code (der hoffentlich fehlerfrei ist) auf der erstellten Seite ausgeführt.

Das Verfahren kann man natürlich beliebig weiterführen und komplexere Anwendungen in das Template einbinden. Das kurze Tutorial hier soll lediglich als Einstieg in dieses Thema dienen.

Mehr Info bei WordPress: Theme-Page-Templates

No related posts.

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 /

Die erste Zeile aktiviert das Modul und die zweite setzt den Basis-Pfad, für den die folgende Rewrite-Konfiguration dienen soll. Möchten wir beispielsweise nur für das Verzeichnis /homepage/blog/ eine Weiterleitung erstellen, benötigen wir folgende Einstellung:

RewriteEngine on
RewriteBase /homepage/blog/


Als nächstes definieren wir unsere Regel für die Weiterleitung. Diese beinhaltet das Suchmuster und den Ersatz, d.h. die Original-Url und die neue Adresse der URL-Weiterleitung. Das tolle ist, das hier Reguläre Ausdrücke verwendet werden können. Die Syntax ist wie folgt:

RewriteRule <suchmuster> <ersatz>


Eine Domain-Weiterleitung mit mod_rewrite würde zum Beispiel so aussehen:

RewriteRule ^(.*)$ http://www.neuedomain.de/$1 [R=301,L]


Eine Weiterleitung eines Verzeichnisses so:

RewriteRule ^homepage/blog(.*)$ http://www.neuedomain.de/homepage/blog$1 [R=301,L]


Das mit dem Modul Rewrite noch mehr Möglichkeiten z.B. dynamischer Weiterleitungen bestehen, verdeutlicht folgendes Beispiel:

RewriteRule ^([a-z\-]+)/([a-z\-]+)/(.*)$ http://www.neuedomain.de/$3?site=$1&sub=$2 [R=301,L]


Jede Regel ist aber vorher gut zu durchdenken, da bei Fehlkonfiguration die Performance des Apache in Mitleidenschaft gezogen oder sogar zum Absturz, z.B. durch Endlosschleifen, gebracht werden kann. Mehr Informationen und viele Möglichkeiten mehr gibt es in der mod_rewrite Apache-Doku.

Andere Möglichkeiten einer Weiterleitung

Ist mod_rewrite nicht installiert, oder keine Berechtigung zur Benutzung gegeben, müssen andere Lösungen her.

Weiterleitung mit PHP

Mit PHP könnte man oben beschriebene Weiterleitungen mit Hilfe der header-Funktion lösen.

<?php
header('HTTP/1.1 301 Moved Permanently', true);
header('Location: http://www.neue-url.de/pfad/zur/datei.htm', true);
?>

Weiterleitung mit Perl / CGI

Auch mit Perl könnte man die Weiterleitung mit Hilfe eines Headers direkt per print lösen:

#!/usr/bin/perl

print "HTTP/1.1 301 Moved Permanently\n";
print "Location: http://www.neue-url.de/pfad/zur/datei.htm\n";

Weiterleitung mit Ruby

In Ruby kann man dies zum Beispiel so realisieren:

#!/usr/bin/env ruby

require 'cgi'
cgi.header({'HTTP/1.1 301 Moved Permanently','Location'=>'http://www.neue-url.de/pfad/zur/datei.htm'})

Clientseitig ohne 301-Status: Javascript

Eine clientseitige Weiterleitung könnte mit Javascript realisiert werden. Nachteil ist hier, das bei deaktiviertem Javascript die Weiterleitung nicht funktioniert.

<script type="text/javascript">
<!--
window.location.replace("http://www.neue-url.de/pfad/zur/datei.htm");
// -->
</script>

Clientseitig ohne 301-Status: Weiterleitung per Meta-Tag

Hierfür wird im Head Bereich des HTML-Codes ein Meta-Tag eingefügt, der durch Semikolon getrennt die Zeit angibt, die der Browser bis zur Weiterleitung warten soll und die URL des Ziels der Weiterleitung. Auch diese methode empfehle ich nicht, da dies wie auch Javascript Interpretationssache des Browsers ist, diesen tag zu beachten (Wobei alle Standard-Browser dies tun).

<head>
<meta http-equiv="refresh" content="3; url=http://www.neue-url.de/pfad/zur/datei.htm">
<!-- andere Tags im Header -->
</head>

Meine Empfehlung: Immer mod-rewrite nutzen, da serverseitig, gut konfigurierbar und vielseitig einsetzbar. Sollte dies nicht vorhanden oder möglich sein, können die anderen genannten Möglichkeiten einer Weiterleitung (PHP oder andere serverseitige Script- bzw. Programmiersprache, Javascript, Meta-Tag – in der Reihenfolge) weiterhelfen.

Happy Redirecting!

No related posts.

Es soll anhand des Wertes einer Select-Box Daten per Ajax von einem PHP-Script geladen und in eine zweite Select-Box als Optionen hinzugefügt werden.

Zuerst benötigen wir zwei Select-Boxen:

Kategorie

Bitte wählen
Bücher
Elektronik
Spielwaren


Artikel

Das Javascript (Prototype muss eingebunden sein):

Und hier noch das PHP-Script als Beispiel:

/**
 * Artikel-Array, wuerde im echten Leben aus
 * einer Datenbank kommen.
 */
$artikel_data = array
(
  1 => array
      (
        array("id" => 1, "name" => "Artikel Nummer 1"),
        array("id" => 2, "name" => "Artikel Nummer 2"),
        array("id" => 3, "name" => "Artikel Nummer 3"),
      ),
  2 => array
      (
        array("id" => 4, "name" => "Artikel Nummer 4"),
        array("id" => 5, "name" => "Artikel Nummer 5"),
        array("id" => 6, "name" => "Artikel Nummer 6"),
      ),
  3 => array
      (
        array("id" => 7, "name" => "Artikel Nummer 7"),
        array("id" => 8, "name" => "Artikel Nummer 8"),
        array("id" => 9, "name" => "Artikel Nummer 9"),
      ),
);

/**
 * Als Json ausgeben
 */
if($_GET['kategorie'])
{
  echo json_encode($artikel_data[$_GET['kategorie']]);
}

Hier das gesamte Beispiel. Viel Spass! Wenn jemand eine schnellere Lösung hat, nur her damit.

No related posts.