Ich Schätze das ist um 2004 entstanden und lieferte Termine bzw. Events von einem bestimmten Tag, das ganze für einen Webkalender ala Google-Calendar. Was ich noch erwähnen sollte…. die Funktion wurde für jeden sichtbaren Kalendertag aufgerufen!

 function getevents($year,$month,$day){
   global $SELF;
   $month = (strlen($month) < 2) ? '0'.$month : $month;
   $day = (strlen($day) < 2) ? '0'.$day : $day;
   $str = "$year-$month-$day";
   $strx = "$month-$day";
   $sql = "
           SELECT e.name as ename,
                                                e.description as edescr,
                                                e.id as eid,
                                                t.color as tcolor,
                                                e.time_start as time_start,
                                                e.time_end as time_end,
                                                e.remember as rem,
                                        e.date_start as date_start,
                                                e.date_end as date_end,
                                                t.description as tdescription,
                                                t.showtime as showtime
           FROM cal_entry e, cal_types t
           WHERE e.types_id = t.id
             AND (e.date_start <= '$str'
                           AND ( e.date_end >= '$str' AND e.date_end IS NOT NULL OR e.date_start = '$str' AND e.date_end IS NULL )
         OR(t.id = 1 AND right(e.date_start,5) = '$strx')
                         )
                        ORDER BY e.time_start, t.prio
         ";
   $res = mysql_query($sql);
   $out = "<u><a href=\"$SELF?show=new&date=$year-$month-$day\">$day.$month.</a></u>";
   while($row = mysql_fetch_array($res)){
     $tmp = "<a href=\"$SELF?show=edit&eid=".$row["eid"]."&ym=$year-$month\">";
 
                 $tmp .= "<font class=\"entry\" color=\"".$row["tcolor"]."\"><li>";
                 $tmp .= $row["ename"];
                 $starta = explode("-",$row["date_start"]);
                 $outstart = $starta[2].".".$starta[1].".".$starta[0];
                 $enda = explode("-",$row["date_end"]);
                 $outend = $enda[2].".".$enda[1].".".$enda[0];
                 $divbody = "<table border=0 class=entry><tr>";
                 if($row["date_end"] != '' && $row["date_start"] != $row["date_end"]){
                   $divbody .= "<td>Von:</td><td>$outstart</td></tr><tr><td>Bis:</td><td>$outend</td></tr>";
                 }else{
                   $divbody .= "<td>Am:</td><td>$outstart</td></tr>";
                 }
                 if($row["showtime"]) {
                     if(($row["date_end"] == $row["date_start"] || $row["date_end"] == '') && $row["time_end"] != ''){
                       $divbody .= "<tr><td>Von:</td><td>".$row["time_start"]." Uhr</td></tr>";
                             $divbody .= "<tr><td>Bis:</td><td>".$row["time_end"]." Uhr</td></tr>";
                     }elseif($row["date_start"] < $row["date_end"] && $row["date_start"] == $str && $row["time_start"] != ''){
                           $divbody .= "<tr><td>Ab:</td><td>".$row["time_start"]." Uhr</td></tr>";
                     }elseif($row["date_start"] < $row["date_end"] && $row["date_end"] == $str && $row["time_end"] != ''){
                       $divbody .= "<tr><td>Bis:</td><td>".$row["time_end"]." Uhr</td></tr>";
                     }elseif(($row["date_end"] == $row["date_start"] || $row["date_end"] == '') && $row["time_end"] == ''){
                       $divbody .= "<tr><td>Ab:</td><td>".$row["time_start"]." Uhr</td></tr>";
                     }
                 }
                 $rem = ($row["rem"] == true) ? "<font color=green>EMail Erinnerung aktiv</font>" : "<font color=red>EMail Erinnerung inaktiv</font>";
                 $divbody .= "</table>";
                 #$div = "<div title=\"header=[".$row["ename"]."] body=[".$row["edescr"].$divbody"]\">";
                 $div = '<div title="header=['.$row["ename"].'] body=['.nl2br($row["edescr"]).$divbody.$rem.']">';
                 $tmp .= "</div></li></font></a>";
                 $out .= $div.$tmp;
         }
 
   return $out;
 }

Aus Googlesicht ist das gut, weil so doppelter Inhalt vermieden wird und für den Benutzer ist es einfach schöner.

Im Internet habe ich einige Beispiele gefunden, wie man www.example.com auf example.com und umgekehrt umleitet, aber keine generelle Lösung. Die Hostdefinition matcht *example.com und *.example.de, weitere sind ohne weiteres möglich.

$HTTP["host"] =~ "^(.*example\.(com|de)$" {
        server.document-root = "/var/www/example.com"
        server.error-handler-404 = "/index.php"
 
        $HTTP["host"] !~ "^(www\.(.*)\.(.*))$"{  #nur wenn es nicht schon www. ist
                $HTTP["host"] =~ "^(.*)\.(.*)\.(.*)$" {   #falls es sich um xxx.*.* handelt
                        url.redirect = ( ".*" => "http://www.%2.%3" )
                }
                $HTTP["host"] =~ "^([^.]*)\.([^.]*)$" {    #falls es sich um *.* handelt (ohne Subdomain)
                        url.redirect = ( ".*" => "http://www.%1.%2" )
                }
 
        }
}

Will man nun noch forum.example.de (nur die .de Variante) erlauben, muss man diese Expression “^(www\.(.*)\.(.*))$” auf “^(www\.(.*)|forum\.example\.de)$” abändern.

Das Tool nutzt Webkit im internen Backend und kann sogar CSS3 rendern. Die Installation unter MaxOSX und Linux ist absolut simpel: runterladen, ablegen, fertig. Unter Windows wird hier noch ein Installationsprozess durchgeführt, über den ich aktuell leider nichts sagen kann (bisher nicht getestet).

Um das Tool auf einer Webseite zu nutzen, habe ich mir ne kleine Klasse geschrieben, die HTML-Code als Input akzeptiert und mir den Pfad der fertigen PDF-Datei zurückliefert.

class HtmlToPdf {
	const TMP = '/tmp/';
	const EXEC = '/usr/local/bin/wkhtmltopdf-amd64'; //anpassen!
	private $executable;
	private $htmlcode;
	private $tmphtmlfile;
	private $targetFilename;
 
	private $options = array(
		'--ignore-load-errors'
	); //Kommandozeilenoptionen für wkhtmltopdf
 
	public function __construct($targetFilename = ''){
		$this->targetFilename = $targetFilename;
	}
 
	public function setHtmlCode($htmlcode){
		$this->htmlcode = $htmlcode;
	}
 
	public function setTargetFilename($targetFilename){
		$this->targetFilename = $targetFilename;
	}
 
	public function generate(){
		$this->createTempHtmlFile();
		$this->convertHtmlfileToPdf();
		return self::TMP.$this->targetFilename;
	}
 
	private function createTempHtmlFile(){
		$filename = tempnam(self::TMP);
		File::move($filename, $filename.'.html'); //nötig, damit die Datei als Input akzeptiert wird
		$filename .= '.html';
		file_put_contents($filename, $this->htmlcode);
		$this->tmphtmlfile = $filename;
	}
 
	private function convertHtmlfileToPdf(){
		if(!$this->targetFilename){
			$this->generateTargetFilename();
		}
		$cmd = self::EXEC.' '.implode(' ', $this->options).' '.$this->tmphtmlfile.' '.self::TMP.$this->targetFilename;
		shell_exec($cmd);
		File::delete($this->tmphtmlfile);
	}
 
	private function generateTargetFilename(){
		$this->targetFilename = uniqueid().'.pdf';
	}
}

Und so nutzt man das Ganze:

$converter = new HtmlToPdf('output.pdf');
$converter->setHtmlCode($htmlcodeWithCSS);
$pdfFile = $converter->generate()

Sehr praktisch ist es, wenn man eine Templateengine (z.B. Smarty) nutzt, hier kann man erst den kompletten Code generieren und ihn dann via $smarty->fetch() in den Konverter übergeben. Über einen Parameter kann man dann noch dafür sorgen, dass der CSS Style nicht ausgelagert, sondern im head-Block ausgegeben wird, da das Tool sonst nicht damit klarkommt.

Reproduzierbar ist er folgendermaßen:

$from = new DateTime();
$from->setTime(0, 0, 0);
$from->setISODate(2010, 28, 1); //Montag der 28ten Woche 2010
 
echo $from->format('d.m.Y H:i'); //A
echo $from->getTimestamp(); //B
echo date('Y-m-d H:i', $from->getTimestamp()); //C

A: das ausgegeben Datum stimmt, es ist der 12.07.2010
B: der Timestamp ist viel zu hoch: 1291849200
C: der Beweis, der Timestamp gehört zum 29.05.2011 00:00

Wir haben lange versucht herauszufinden, warum dies passiert. Ein hässlicher Workaround ist dieser:

$from->add(new DateInterval('P0D'));

Wir fügen also ein Interval von 0 Tagen (oder Stunden, Minuten etc) hinzu, wodurch sich eigentlich nichts ändern sollte. Danach stimmt das Ergebnis von ->getTimestamp() allerdings, nämlich 1278885600.

Nachdem wir absolut keinen Grund feststellen konnten, haben wir das Vertrauen verloren und nutzen seitdem Zend_Date, welches, meiner Meinung nach, besser und einfacher zu bedienen ist. Das ZendFramework ist sowieso schon im aktuellen Projekt eingebunden (nicht als Framework an sich, eher als Klassensammlung), als sprach es auch nicht dagegen, einen riesen Klotz an Dateien/Klassen zu integrieren, um nur eine Klasse zu nutzen.

$date = new Zend_Date();
$date->setWeek(28)->setYear(2010)->setWeekday(1);
$date->setHour(0)->setMinute(0)->setSecond(0);
echo $date->getTimestamp();

Liefert das erwartete Ergebnis: 1278885600

Ist das nun wirklich ein riesen DateTime Bug oder liegt ein Denkfehler unsererseits vor?

class MyClass implements Interator {
  private $array;
}
 
$obj = new MyClass();
foreach($obj as $key => $val){
  ...
}

Damit dieses Konstrukt funktioniert, benötigt die Klasse “MyClass” ein paar weitere Methoden und ein Attribut, welche vom Interface vorgeschrieben werden:

public function rewind(){
  $this->pointer = 0;
}
public function current(){
  return $this->array[$this->pointer];
}
public function key(){
  return $this->pointer;
}
public function next(){
  $this->pointer++;
}
public function valid(){
  return isset($this->array[$this->pointer]);
}

Nun geht das ganze aber auch viel einfacher und mit saubererem Code, mit dem IteratorAggregate Interface und einem schon vorhandenem Iterator (wie dem ArrayIterator). Das Interface ist ziemlich Ähnlich und implementiert ebenfalls Traversable.

class MyClass implements IteratorAggregate {
  private $array;
  public function getIterator(){
    return new ArrayIterator($this->array);
  }
}
 
$obj = new MyClass();
foreach($obj as $key => $value){
  ...
}

Da auf meinem Websever lighttpd und nicht apache läuft, konnte ich mich nicht 100%ig an die Anleitung auf der WP MU Seite halten.

In lighttpd gibt es kein .htaccess, also müssen die Rewriteregeln (ich nutze Subdomains, keine Unterverzeichnisse), in die lighttpd-config. Das ganze sieht so aus:

$HTTP["host"] =~ "^((.*).?example\.de)$" {
  server.document-root = "/var/www/.../wp3/"
  server.error-handler-404 = "/index.php"  #hierdurch erspart man sich rewrite regeln für schöne permalinks
  url.rewrite-once = (
    "^/(.*/)?files/$" => "/index.php",
   "^/(.*/)?files/(.*)" => "/wp-content/blogs.php?file=$2",
    "^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "/$2",
    "^/([_0-9a-zA-Z-]+/)?(.*\.php)$" => "/$2",
  )
}

Der Rest lief einwandfrei nach offizieller Anleitung, da in einigen der anderen Blogs allerdings recht viele Bilder sind, viel mir sofort die mangelnde Performance diesbezüglich auf. Der Grund war schnell gefunden, gab es 40 Bilder auf einer Seite, bedeutete dies, aufgrund der zweiten Rewriteregel, jeweils einen Aufruf eines PHP Skriptes, welches einen ganzen Schweif an includes inkl. Datenbankverbindungen und Queries mit sich bringt.

Die Lösung war, mit ein wenig Linuxwissen, aber schnell gefunden: Symlinks für jeden einzelnen Blog. Erfordert zwar ein wenig mehr Verwaltungsaufwand, spart aber das Umleiten über ein PHP Skript, um Bilder anzuzeigen. Die Regel muss dann so aussehen:

    "^/(.*/)?files/(.*)$" => "/wp-content/blogs.dir/%0/files/$2",

Das %0 funktioniert so nur, weil die Hostdefinition (Zeile 1 im oberen Code) als Pattern definiert ist!

Im, laut Anleitung angelegten, blogs.dir Verzeichnis müssen nun Symlinks angelegt werden:

ln -s /var/www/.../wp3/wp-content/blogs.dir/[BlogID] /var/www/.../wp3/wp-content/blogs.dir/[subdomain].example.de

Falls jemand eine elegantere Lösung kennt, als für jeden Blog einen Symlink anzulegen, als her damit!

Zuerst sollte erwähnt werden, dass MySQL im Normalfall pro Query nur EINEN pro Tabelle Index auf einmal nutzen kann (es gibt Ausnahmen, merged-index, aber nur unter bestimmten Umständen in bestimmten Queries).

Ein Beispiel für den Einsatz eines Index über mehrere Spalten, wäre z.B. das folgende:

Eine Tabelle, in welcher Nachrichten zwischen Benutzern aufbewahrt werden, folgende Spalten sind vorhanden:

ID (int), receiverUserID(int), senderUserID(int), subject(varchar), text(text), time(int)

Wollen wir nun alle Nachrichten finden, die User 123 an User 234 geschickt hat und das Ergebnis noch nach Zeit sortieren, brauchen wir folgendes Query:

SELECT ID, subject, text, time
FROM message
WHERE receiverUserID = 234 AND senderUserID = 123
ORDER BY time ASC

Zuerst fällt auf, dass man die Nachrichten nach ID sortieren kann, was im Normalfall besser ist, als nach time, da wir davon ausgehen, dass die ID sich von Nachricht zu Nachricht um eins erhöht und die neusten somit die höchsten IDs haben.

Ohne das Wissen, dass es mehrspaltige Indizes gibt, würde man einen Index auf receiverUserID oder senderUserID legen, alternativ sogar beides, allerdings würde MySQL dann nur einen von beiden nutzen.
Also legt man einen über beide an, was bei großen Datenmengen einen extremen Geschwindigkeitsschub bringen kann.

Um die Sortierung nun auch noch über den Index zu regeln, könnten man als dritte Spalte nun noch die ID in den Index aufnehmen, was allerdings nur sinnig ist, wenn man davon ausgeht, dass das Ergebnis wirklich viele Ergebnisse erzielen wird.

Es gibt definitiv keine Konfiguration, die allgemeingültig ist, aber ich versuche hiermit eine Hilfestellung zu geben, wie man die besten Werte für die eigenen Bedürfnisse findet.

Nicht nur der Server spielt eine Rolle, auch die Storage-Engine, um sich viel Stress zu ersparen, sollte man im vorraus planen, was man braucht und für welche Engine man sich entscheidet. Auch hier gibt es keine Universallösung, jede hat ihre Vor- und Nachteile, aber darauf will ich in diesem Eintrag nicht eingehen.

Da ich für das aktuell laufende Projekt nur InnoDB einsetze, beziehen sich die Ratschläge auf eine reine InnoDB Konfiguration und sollten ab MySQL Version 5.0 funktionieren.

“innodb_dirty_pages_pct”
Gibt an, wie viele  InnoDB-Buffer-Pages im RAM vorhanden sein dürfen, ohne auf Festplatte geschrieben worden zu sein. Standard ist 90%, was für die meisten Umgebungen absolut OK sein sollte.

“thread_cache_size”
Wie viele Threads dürfen sich im Cache befinden? Jede Verbindung zum Server braucht einen eigenen Thread, ist die Verbindung beendet, kann der Thread im Cache gelagert werden und steht der nächsten Verbindung zur Verfügung. Threads zu erstellen ist unnötiger Overhead, “SHOW GLOBAL STATUS” auf der MySQL Konsole gibt in der Variable “threads_created” aus, wie viele Threads erstellt werden. Dieser Wert sollte um maximal 10 pro Sekunde steigen, steigt er schneller, kann der Thread-cache vergrößert werden.

“table_definition_cache”
Sollte größer oder gleich der Anzahl der vorhandenen Tabellen sein um unnötigen I/O Overhead zu ersparen.

“innodb_open_files”
Sollte größer oder gleich der Anzahl der vorhandenen .ibd Dateien im MySQL-Datenverzeichnis sein (bei Debian meistens /var/lib/mysql).

“innodb_log_buffer_size”
Die globale Variable “innodb_os_log_written” hilft hier bei der Ermittlung eines sinnvollen Wertes, der Wert sollte nicht zu schnell steigen, hier kann I/O Performance gewonnen werden.

“skip_name_resolve”
Sollte aktiv sein, damit nicht für jeden Client 2 DNS-Lookups stattfinden, gleichzeitig bedeutet dies, dass Berechtigungen nur noch auf IP und nicht auf Hostnamen-Ebene verteilt werden können.

“innodb_flush_method”
Falls ein Hardware-Raid mit ordentlichem Cache und Battery-Backup genutzt wird, sollte hier 0_direct eingestellt werden, um zu verhindern, dass OS-Buffer genutzt werden, welche das Logfile unbrauchbar machen könnten, wenn der Server abstürzt.

“innodb_flush_log_at_trx”
Sollte auf 1 gestellt werden, damit jede beendete Transaktion sofort im Binarylog landet, um Datenverlust zu verhindern, falls der Server abstürzt. Der Wert 1 ist der beste Kompromiss zwischen Performance und Datensicherheit!

Diverse Key-Buffers und andere Caches (ausgenommen dem Query-Cache) können sehr klein gehalten werden (nicht abschalten, MySQL nutzt MyISAM für die Metatabellen). Hier würde nur sinnlos RAM belegt werden!

Auf Linux-Systemen sollte die swappiness noch auf 0 oder 1 gestellt werden, um zu verhindern, dass der Kernel MySQL Buffers in den SWAP-Space verschiebt, falls diese länger nicht genutzt werden. Swap-I/O ist weitaus schlimmer als normaler HDD-I/O, da MySQL “denkt” es würde mit schnellem RAM arbeiten, welcher in Wirklichkeit aber auf der HDD im Swap zu finden ist. Auf Debian-Systemen kann man diesen Wert mittels /etc/sysctl.conf setzen (vm.swappiness = 0) und danach “sysctl -p” ausführen.

Der restlich verfügbare Arbeitsspeicher sollte dem InnoDB-Buffer-Pool zur Verfügung gestellt werden, ist dieser groß genug, kann auf nahezu alle HDD-Leseabfragen verzichtet werden und es entsteht nahezu nur noch Schreib-I/O.

Es gibt noch weitere Einstellungen bezüglich des InnoDB-Tablespace und allgemeinen Einstellungen, falls hier noch Intresse besteht, hinterlasst nen Kommentar, werde dann versuchen zeitnah einen weiteren Beitrag zu schreiben.