Alle Neuerungen und Änderungen und Migrations-Guide gibt es bei php.net http://www.php.net/archive/2009.php#id2009-06-30-1.

Eine beschleunigung nach dem Update konnte ich persönlich nicht 100%ig feststellen.

Probleme nach dem Update? Skripte laufen nicht mehr und man sieht nur noch eine weiße Seite?
Dann liegt das vermutlich an Einstellungen in der php.ini. Diese wurde in PHP 5.3 neu strukturiert und kann somit leider nicht einfach durch die bestehende php.ini ersetzt werden. Wer glaubt er habe alle markanten Einstellungen in die neue php.ini übertragen dem rate ich zu einem Dateivergleichprogramm wie ExamDiff.
Dieses zeigt einem alle unterschieder von der alten php.ini gegenüber der neuen php.ini an damit man auch ja nichts vergisst ;). Ich hatte z.B. vergessen short_open_tag wieder auf on zu stellen. Dies ermöglicht das coden mit <? … statt nur mit <?php …!

Das Problem war, dass wenn mehrere Benutzer commited haben die Benutzerrechte manchmal nicht gestimmt haben und deswegen das Update im Hook nicht ausgeführt werden konnte.

svn: Kann Datei "public/debug/.svn/lock" nicht öffnen: Keine Berechtigung

Die Lösung ist das Passwort und den Benutzernamen hart einzucodieren. Ist zwar nicht die schönste Lösung, aber funktioniert super. In der “post-commit” Datei steht also:

svn update 'Pfad zu Repository'  --username 'Benutzer'  --password 'Passwort'

Es gibt also nur einen Benutzer, der immer alle Dateien updated. Stellt dementsprechen den Benuzter des Ordners eurer Dateien um. Funktioniert perfekt bei mir.

cp post-commit.tmpl post-commit
chmod +x post-commit

Solltet ihr das Hookscript noch nicht ausführbar geschaltet haben.

VON: http://www.fractalcenter.de/?p=11

Bevor ich bei meiner jetzigen Firma angestellt war, habe ich mir eingebildet etwas über SQL (MySQL) zu wissen. Dann habe ich jedoch den Microsoft-SQL-Server kennen gelernt. Ich bin generell kein Microsoft Fan, der SQL-Server ist aber schon ein sehr leistungsfähiger Server. Durch die bereits vorhandenen Strukturen musste ich mich erst einmal durchfitzen unter anderem auch durch Sichten und Prozeduren. Aus heutiger Sicht weiß ich nicht, wie ich ohne diese SQL Werkzeuge auskommen konnte.

Kommen wir als erstes zu den Sichten (Views):

Um den Sinn einer Sicht zu verstehen, versuche ich es einmal mit einem Beispiel. (dies ist ein MySQL-Code in anderen SQL-Sprachen weicht dieser aber nicht allzu sehr ab)

CREATE VIEW terms AS
SELECT term.term_id, name, slug, term_group,
taxonomy, description, parent, count
FROM wp_terms AS term
INNER JOIN wp_term_taxonomy AS tax
ON term.term_id = tax.term_id

Mit CREATE VIEW * AS wird eine Sicht eingeleitet. Ich habe hier mal als Beispiel die Wordpress Datenbank genommen um einen JOIN über die Tabellen wp_term_taxonomy und wp_terms zu erstellen. Die Frage die ich mir am Anfang gestellt habe war: “Wozu soll ich das so umständlich machen?”. Man kann die SQL ja auch direkt in den PHP-Quellcode schreiben. Das mag zwar fürs erste stimmen, wenn man das Ganze aber etwas weiter spinnt, wird es vielleicht deutlicher. In Wordpress ist es prinzipiell möglich den Tabellenpräfix zu ändern. Wenn ich das im Nachhinein ändere, wird das in der Wordpress-Programmierung automatisch erledigt, nehmen wir jetzt aber weiter an, dass ich mir ein Plugin oder eine eigene Seite mit SQL-Abfragen geschrieben habe. Ich müsste jetzt manuell durch alle Abfragen durchgehen und die Tabellen umbenennen. Wenn ich aber Sichten einsetzte muss ich dies nur einmalig zentral ändern und alle Scripte die auf die Sicht zugreifen funktionieren weiterhin. Sichten helfen Redundanz zu vermeiden. Ich muss den SQL-Code nicht mehrmals hinterlegen, sondern kann ihn an einer Stelle ändern. Für Webmaster, die sich bis jetzt nur mit “kleinen” Seiten auseinander gesetzt haben, ist der Sinn vielleicht nicht offensichtlich, wenn man jedoch eine Webanwendung mit dutzenden von Tabellen hat, lernt man Views sehr schnell zu schätzen.

Als zweites möchte  ich Prozeduren vorstellen.

Eine Prozedur ist ein universelle Werkzeug in der täglichen Arbeit mit SQL. Eine Prozedur ermöglicht es viele SQL-Anweisungen in einer Anweisung zusammen zu fassen. Nehmen wir an, dass ich den Umsatz pro Kunde und Monat ermitteln will. Das geht sicherlich recht einfach mit einigen JOINS und einer GROUP BY Klausel. Jedoch müsste ich diese Werte bei jeder Abfrage erneut generieren. Bei 10.000 Kunden mag das vielleicht noch gehen. Bei 1.000.00 Kunden wird es schon recht aufwendig für den SQL-Server. Die Last ist auf jeden Fall enorm hoch. Am einfachsten wäre es doch, diese Zahlen einmal in der Woche (oder täglich) in eine gesonderte Tabelle weg zu schreiben. Genau dass kann man mit Hilfe einer Prozedur und eines Cronjobs machen.

DELIMITER $$
DROP PROCEDURE IF EXISTS `proc_umsatz_monatlich`$$
CREATE PROCEDURE `proc_umsatz_monatlich` ()
BEGIN
INSERT INTO umsatz_monatlich
SELECT kunde_id, umsatz
FROM rechnungen
GROUP BY YEAR(datum), MONTH(datum), kunde_id
END$$
DELIMITER ;

Der Vorteil von Prozeduren liegt auf der Hand. Man kann sie mit Variablen füttern und somit das Ergebnis beeinflussen (In einer Prozedur kann man z.B. auch IF Abfragen verwenden). Die Prozedur selbst kann beliebig verwandelt und an neue Gegebenheiten angepasst werden, ohne dass sämtlicher SQL-Code umgeschrieben werden muss. Das hat vor allem Vorteile für z.B. die Suche einer Seite. Diese wir normalerweise mit wenigen Parametern angesprochen (Suchbegriff und ggf. Einschränkungen wie Zeitraum o.ä.) und gibt als Ergebnis eine Tabelle zurück. Ich musste in unsere Suche eine Tabelle zusätzlich einbinden. Das ging ohne eine Zeile im PHP-Quellcode zu verändern, nur indem ich die Prozedur verändert habe. Es gibt Programmierer, vor allem in der professionellen Programmierung, die der Meinung sind, dass ein Client (das Clientprogramm) keinen direkten Zugriff auf die Datenbank haben darf. Das ist ein recht radikaler Ansatz, dem ich mich nicht anschließen möchte. Sinnvoll wäre es aber z.B. dass man dem Client, im Falle der Webprogrammierung dürfte das zumeist “www-data” sein, nur SELECT oder UPDATE Befehle erlaubt. DROP und DELETE sind nur Prozeduren vorbehalten. Das würde dem Schutz vor SQL-Injection einigen Vorschub leisten. Wenn man sogar soweit geht, die Einschränkung auf UPDATE Befehle auszuweiten, wäre das ein großer Sicherheitsgewinn.
Eine weitere wichtige Funktion von Prozeduren soll das nachfolgende Beispiel verdeutlichen:

CREATE PROCEDURE curdemo()
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE a CHAR(16);
DECLARE b,c INT;
DECLARE cur CURSOR FOR SELECT id,DATA FROM test.t1;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur1;
REPEAT
FETCH cur1 INTO a, b;
IF NOT done THEN
IF b < c THEN
INSERT INTO test.t3 VALUES (a,b);
ELSE
INSERT INTO test.t3 VALUES (a,c);
END IF;
END IF;
UNTIL done END REPEAT;
CLOSE cur;
END

Man kann in einer Prozedur durch ein Ergebnis einer SQL, Zeile für Zeile durchgehen und die Datenwerte für Bedingungen, INSERT, DELETE oder UPDATE Befehle nutzen. Man kann einen CURSOR ähnlich einer while Schleife benutzen. Das zu den Vorteilen. Der Entscheidende Nachteil ist, die Geschwindigkeit. Wenn ich ein UPDATE Befehle ausführe, selbst wenn es zehntausende Zeilen betrifft, ist der Server in meist weniger als einer Sekunde fertig (Abhängig von der Tabelle, dem Index und weiterer Faktoren). Mit einer CURSOR Operation kann ich prinzipiell die gleiche Funktion ausführen, wie mit dem UPDATE Befehl, diese würde jedoch erheblich länger Dauern. Deshalb ein Wort der Warnung. CURSOR Operationen nur mit Bedacht einsetzen und alle Alternativen vorher ausschöpfen. Als bewährtes Mittel um diesen SQL Befehl zu vermeiden, haben sich für mich temporäre Tabellen erwiesen. Man kann das Ergebnis einer SELECT Anweisung in eine Tabelle speichern und diese dann für weiter gehende Aktionen benutzen.
Dazu fällt mir wieder meine Suche ein. Als erstes erstelle ich eine Temporäre Tabelle mit bestimmten IDs die ich aus den Einschränkungen Zeitraum bzw. Thema gewinne. Diese IDs benutze ich dann als Grundlage für die weitere Recherche nach dem Suchwort. Anfänglich hat die Ausführung ca. 30 Sekunden gedauert.

Das ist auch noch ein wichtiger Punkt, den ich ansprechen möchte, obwohl es die meisten Programmierer wissen sollten. Man sollte erst seinen Code schreiben, so dass er einfach zu warten ist und den Anforderungen entspricht. Erst dann sollte man sich auf den Weg von Flaschenhälsen machen, sprich optimieren. Ein gutes Beispiel ist eine Webseite, die mehrere Zehntausend Zugriffe pro Stunde hat. Wenn man diese versucht von Anfang an zu optimieren ohne eine entsprechende Serverlast zum Testen zu haben, ist das bestenfalls verschwendete Zeit, schlimmsten Falls hat man sich auf eine falsche Annahme verlassen und die Optimierung kostet mehr Ausführungszeit als der eigentlich Code.

Zurück zur SQL. Durch schrittweises optimieren, z.B. einen zusätzlichen Index auf die durchsuchten Tabellen und dem Einsatz von temporären Tabellen konnte ich die Ausführung auf, je nach Aufruf, 0.7 - 1.5 Sekunden herunterschrauben. Die Suche geht dabei über 14 Tabellen, von denen 7 durchsucht und 7 für die Ausgabe (z.B. Bilder, Titel, Sortierung etc.) ausgewertet werden.

VON: http://www.strassenprogrammierer.de/mysql-stored-procedures-trigger_tipp_469.html

Mit der Version 5 ist MySQL den großen Datenbanken wie MS-SQL oder Oracle wieder ein Stück näher gerückt. Die wichtigsten neuen Fähigkeiten sollten Sie kennen, denn sie machen Ihre Programme sicherer und effizienter.
Mit den Stored Procedures von MySQL können Sie Programmcode innerhalb des Datenbankservers ausführen lassen. Das macht MySQL um einiges mächtiger. Ein typisches Beispiel: Bislang erforderte der Umgang mit hierarchischen Datenstrukturen, etwa dem Seitenbaum einer Website, einigen Aufwand in der verwendeten Skriptsprache.
So ist etwa die Abfrage “gib mir den Pfad von einer bestimmten Inhaltsseite hoch bis zur Startseite” in SQL nicht auszudrücken. Denn zur Beantwortung müsste eine variable Anzahl von Joins eingesetzt werden - je nachdem, wie viele Ebenen über der gewünschten Seite existieren.
Mit der Hilfe der Stored Procedures kann man ein kleines Programm schreiben, das das Problem elegant löst. Es geht von der angegebenen Seite aus immer einen Schritt nach oben, bis der Wurzelknoten erreicht ist. Die Id-Nummern der dabei durchlaufenen Seiten werden als String zurückgeliefert. Das aufrufende Programm kann diese Information dann für weitere Auswertungen nutzen, etwa für die Anzeige des Seitenpfades (”Breadcrumbs”) in der Navigation.
Angenommen, der Seitenbaum liegt in der Tabelle pages vor. Alle Seiten besitzen im Feld uid eine eindeutige Id und im Feld pid ist die Id ihrer übergeordneten Seite vermerkt. Die Wurzelseite hat die pid 0. Dann erledigt folgende Funktion die gestellte Aufgabe:

DELIMITER '$';
CREATE FUNCTION f_rootpath (param_id INT) RETURNS
CHAR(255)
BEGIN
DECLARE retval CHAR(255);
DECLARE father_id INT;
SET retval=param_id;
SET father_id=param_id;
WHILE father_id<>0 DO
SELECT pid INTO father_id
FROM pages WHERE uid=father_id;
SET retval =
CONCAT(retval,'-',father_id);
END WHILE;
RETURN retval;
END$
DELIMITER ;

Die Funktion führt in einer Schleife solange die Ermittlung der übergeordneten Seite durch, bis sie an der Wurzel angekommen ist und baut dabei in der Variablen retval nach und nach das Ergebnis auf. Das Ganze ließe sich eleganter über eine Rekursion lösen, aber die unterstützt MySQL in der aktuellen Version noch nicht. Ein Trost: Diese iterative Variante ist schneller als eine Rekursion.
Die Änderung des Delimiters vom standardmäßigen Semikolon zu einem Dollarzeichen ist notwendig, sonst würden die trennenden Strichpunkte innerhalb der Funktion von MySQL als Endemarke für den aktuellen Befehl angesehen. Der letzte Befehl stellt wieder den normalen Zustand her.
Um nun beispielsweise den Pfad für die Seite mit der id 11 zu ermitteln, geben Sie ein:
SELECT f_rootpath(11);
Ein Ergebnis könnte dann so aussehen:

+-----------------+
| f_rootpath(11)  |
+-----------------+
| 11-2-1-0        |
+-----------------+
1 row IN SET (0.00 sec)

Trigger arbeiten automatisch

Wie Stored Procedures sind auch Trigger sind serverseitige Routinen, werden aber nicht vom Programmierer aufgerufen, sondern von einem Event angestoßen, etwa dem Löschen oder Ändern eines Datensatzes.
Ein Beispiel für den Einsatzzweck: Bei einer Kundenverwaltung möchte der Anwender jede Änderung im Datenbestand nachvollziehen können. Sobald also jemand in der Tabelle kunden ein Feld ändert, sollen die vorherigen Feldwerte in der Tabelle kunden_changes vermerkt werden, die denselben Satz an Feldern aufweist und zusätzlich ein Feld für den Zeitpunkt der Änderung besitzt.
Beschränken wir uns bei den Kundendaten auf die Felder id, strasse und
name, dann würde der dazu notwendige Befehl so aussehen:

CREATE TRIGGER kunden_change
AFTER UPDATE ON kunden
FOR EACH ROW
INSERT INTO kunden_changes
( id, name, strasse, datechanged)
VALUES
(old.id, old.name, old.strasse, NOW())
;

Sobald nun bestehende Kunden-Einträge geändert werden, startet die Trigger-Prozedur. Für jeden geänderten Satz wird in der Tabelle kunden_changes der Zustand vor der Änderung als neuer Datensatz abgespeichert. Um die Werte vor dem UPDATE zu referenzieren, dient der vordefinierte Präfix old bei den Feldbezeichnern.
Sie könnten sich mit dieser Methode zu jedem Kunden eine Änderungshistorie ausgeben lassen, die auflistet, welche Überarbeitungen in seinen Daten stattgefunden haben.

Andere Einsatzgebiete für Trigger sind das Behandeln von in einer anderen Tabelle gespeicherten Detaildaten. So könnten Sie damit beispielsweise beim Deaktivieren eines Lieferanten automatisch alle seine Artikel im eigenen Sortiment ausblenden lassen.
Views vereinfachen und schotten ab
Views sind eine weitere Neuerung in MySQL 5. Ein View benimmt sich wie ein Tabelle, tatsächlich steckt dahinter aber eine von Ihnen definierte Abfrage, die ihre Ergebnisse nur wie eine neue Tabelle darstellt.
Ein einfaches Beispiel bei einem Content-Management-System wäre ein
View, der alle derzeit gültigen Artikel ausgibt, also gelöschte oder zeitlich eingeschränkte Artikel unterdrückt. Er könnte so aussehen:

CREATE VIEW v_akt_artikel AS
SELECT * FROM artikel
WHERE deleted=0 AND
publish_until < NOW();

Weil der View sich wie eine Tabelle einsetzen lässt, könnten Sie beispielsweise schreiben:

SELECT * FROM v_akt_artikel WHERE stichwort='Heimwerken';

Auch das Rechtesystem von MySQL behandelt Views wie Tabellen, und erlaubt deshalb eine Freigabe auf View-Ebene. Das ermöglicht zum Beispiel folgendes Szenario: Sie haben geschäftliche Kundendaten in Ihrer Datenbank und möchten die einem Geschäftspartner zugänglich machen. Allerdings soll er manche Felder nicht sehen dürfen, etwa die Umsatzdaten.
Um den eingeschränkten Zugriff zu ermöglichen, definieren Sie einen View, der nur die notwendigen Felder ausgibt und erlauben dem Partner lediglich darauf den Zugriff:

CREATE VIEW v_kunden_restr AS SELECT
kundennr,name,plz,strasse,ort FROM kunden;
GRANT SELECT ON v_kunden TO 'kunde'@'%' IDENTIFIED BY
'geheim';

Stored Procedures als Abstraktionsebene
Bei Applikationen im großen Stil sichern Stored Procedures die Integrität von Daten. Betrachten Sie beispielsweise das Verarbeiten von Bestellungen in einem Online-Shop. Der Kunde soll eine Bestellung stornieren dürfen, solange sie noch nicht ausgeführt ist. Ein Weg wäre, die Freigabe der bestellten Artikel und die Deaktivierung des Datensatzes in der BestellungsTabelle einzeln in der ShopApplikation zu lösen.
Würde man diese Aktionen aber in einer Stored Procedure zusammenfassen, die alle Validierungen durchführt und die Teilaspekte des Stornos erledigt, ergäben sich einige Vorteile. Ein Zugriff von einer anderen Plattform als dem Webshop könnte sich auch dieser existierenden Prozedur bedienen. Man würde sich also ersparen, alle Tabellenoperationen nochmals in einem anderen Kontext zu programmieren.
Varianten serverseitiger Routinen
Genau genommen handelt es sich bei der im Artikel gezeigten Routine f_rootpath() gar nicht um eine Stored Procedure, sondern um eine Stored Function. Diese Variante wurde verwendet, weil für die Aufgabenstellung ein Rückgabewert benötigt wird.
Die echten Procedures werden im Gegensatz dazu mit CREATE PROCEDURE definiert und haben einen leicht abweichenden Aufbau. So verzichten sie beispielsweise auf das RETURN, das bei den Funktionen den Rücksprung zum Aufrufer und die Übermittlung des Funktionswerts bewirkt.
Ein weiterer wichtiger Unterschied: Stored Procedures werden nicht per SELECT sondern über CALL aufgerufen
Rückgabewerte sind hier prinzipiell auch vorgesehen. Dann allerdings müssen Sie SQL-Variablen als Rückgabeparameter einsetzen. Die Verwendung einer als Stored Procedure realisierten sp_rootpath() mit einem zusätzlichen Parameter zur Rückgabe würde dann so aussehen:
CALL sp_rootpath(11,@pfad);
SELECT @pfad; Stored

Procedures mit phpMyAdmin
Mit phpMyAdmin klappt die Definition einer Stored Procedure in der Grundkonfiguration nicht. Erst, wenn Sie vom aktiviertem mysql-Interface auf die neuere Variante mysqli umschalten, lässt sich phpMyAdmin einsetzen.
Dazu ändern Sie in der Datei config.inc.php die Zeile, die die “Server-Extension” definiert. Fügen Sie dort ein “i” hinzu, so dass dort steht:

$cfg['Servers'][$i] ['extension']='mysqli'

Noch besser geeignet ist der Query-Browser von MySQL, der Stored Procedures mit Funktionen wie Syntax-Highlighting unterstützt. Dieses kostenlose Programm können Sie einfach von der MySQL-Homepage als Teil des Pakets “GUI-Tools” herunterladen.

Ausgangslage ist ein Windows 2003 Server mit Apache 2.2.

Das mod_deflate wird standardmässig beim Apache 2.x mitgeliefert und muss in der http.conf nur aktiviert werden.
Also so sollte es sein:

LoadModule deflate_module modules/mod_deflate.so

Zusätzlich benötigt man dann noch folgendes in der http.conf

<IfModule mod_deflate>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml text/javascript
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 
  deflate.enabled = "enable" 
  deflate.compression-level = 9
  deflate.mem-level = 9
  deflate.window-size = 15
  # deflate.bzip2 only in patch for 1.4.x
  deflate.bzip2 = "enable" 
  # deflate.allowed_encodings only in 1.5.x
  deflate.allowed_encodings = ( "bzip2", "gzip", "deflate" )
  deflate.min-compress-size = 200
  #deflate.sync-flush = "enable" 
  #deflate.output-buffer-size = 8192
  deflate.work-block-size = 512
  deflate.mimetypes = ("text/html", "text/plain", "text/css", "text/javascript", "application/javascript", "application/x-javascript", "application/x-httpd-php", "text/xml")
  #deflate.debug = "enable" 
</IfModule>

Nun werden werden die Inhalte die den oben genannten Typen und Größe entsprechen komprimiert ausgegeben. Da ältere Browser gzip nicht entschlüsseln können ist zusätzlich eine Browserweiche am werk.

Genaue Infos zu den Einstellmöglichkeiten gibt es bei
http://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_Deflate
und bei
http://blog.netways.de/2009/04/21/serie-high-performance-websites-teil-4-komprimierung-der-seiten/

Performance Rules von Yahoo Developer –> http://developer.yahoo.com/performance/rules.html
Performance Rules von Google Code –> http://code.google.com/intl/de-DE/speed/page-speed/docs/rules_intro.html

Beides ist recht umfangreich und auf englisch. Ein paar der behandelten Punkte werde ich deshalb auf Deutsch etwas zusammenfassend zu einem späteren Zeitpunkt erläutern. Zunächst aber kommen wir zu den Add On’s die auf die Performance Rules aufbauen. Wer nämlich keine Lust hat sich die ganzen Performance Rules durchzulesen ist mit den Add On’s letztlich schneller am Ziel:

Es gibt 2 Firefox Add On’s welche die Website analysiert und untersucht uns anschließend sagt was man gut bzw. schlecht gelöst hat. Zusätzlich wird über weiterführende Texte (auf englisch) gut erklärt wie man es besser macht bzw. die Fehler behebt. Beide Add On’s sind ein zusätzlicher Aufsatz für das benötigte und sehr bekannte Add On “Firebug”. Falls sie das nicht kennen wird es höchste Zeit: https://addons.mozilla.org/de/firefox/addon/1843

1.) YSlow (aktuelle Version 2.0.0b3) Entwicker ist Yahoo! https://addons.mozilla.org/de/firefox/addon/5369
Analyse, Tipps und weiterführende Hilfen(http://developer.yahoo.com/) kommen von keinen geringeren als von der Yahoo! inc.

2.) Page-Speed Entwicker ist Google! http://code.google.com/intl/de-DE/speed/page-speed/
Analysiert und testet prinzipiell die gleichen Punkte wie YSlow.
Ich persönlich nutzte alle der genannten Add On’s.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
...

Nun kann man auch ein Default-Charset für diverse Dateien schon in der Apache-Conf oder in einer seperaten .htaccess angeben. Dieses zieht aber meistens nur dann wenn man sonst kaum angaben gemacht hat.

<files "*.*">
AddDefaultCharset iso-8859-1
</files>

Wer mit PHP arbeitet und immernoch Probleme hat der sollte einmal diese Zeile direkt zu Begin der Seite (or dieser Funktion kann keine andere Ausgabe gemacht werden) einfügen!

header('Content-Type: text/html; charset=iso-8859-1');

Manchmal bekommt man Text, z.B. aus der Datenbank oder aus einer anderen Datei, welcher in UTF-8 geschrieben wurde und man ihn nun aber in einer ISO-8859-1 Seite ausgeben möchte. In diesem Fall kann man den Text konvertieren. Dazu sollte man sich einmal diese Funktionen genauer anschauen.

echo iconv("UTF-8","ISO-8859-1","Dies ist ein Test üöä."); 
// ODER
echo utf8_decode("Dies ist ein Test üöä.")

Zu iconv gibt es eine ganze Reihe von Funktionen und zu utf8_decode gibt es auch das gegenstück utf8_encode.

Viel Erfolg!

<?php global $wp_filter;
echo '<!-- <pre>';
var_dump($wp_filter['wp_head']);
echo "\n ############################################# \n";
/* Um einfach nur zu schauen welche Funktionen aufgerufen werden ist die ausgabe mit print_r übersichtlicher: */
print_r($wp_filter['wp_head']);
echo '</pre > -->'; ?>

Wozu muss man das wissen? Unter anderem ist es nützlich wenn man sein Wordpress schneller machen möchte und nachschauen will welche Funktionen alles die Geschwindigkeit ausbremsen weil sie bei jedem aufruf geladen werden.

Project-URI: http://github.com/mojombo/clippy/tree/master/

Wenn man mit dem Standard-Layout zufrieden ist reicht es die Datei clippy.swf herunterzuladen und mittels folgendem Code an die entsprechenden Stellen einzubauen:

<p>http://www.meinLinktoClipboard.de/
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" class="clippy" id="clippy" width="110" height="14">
<param name="movie" value="clippy.swf">
<param name="allowScriptAccess" value="always">
<param name="quality" value="high">
<param name="scale" value="noscale">
<param name="FlashVars" value="text=http://www.meinLinktoClipboard.de/">
<param name="bgcolor" value="#FFF">
<param name="wmode" value="opaque"> <embed src="clippy.swf" name="clippy" quality="high" allowscriptaccess="always" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" flashvars="text=http://www.meinLinktoClipboard.de/" bgcolor="#FFF" wmode="opaque" width="110" height="14">
</object>
Zeilen-Ende</p>

Nachtrag:
Wer seinen Button lieber selbst gestalltet oder einfach nur die funtkion auf einen Link setzen möchte der sollte sie diese Methode einmal anschauen:
http://code.mavrickdesign.com.au/mootools/cross-browser-copy-to-clipboard.htm
Funktioniert letztlich auch über Flash, aber man kann die Funktion via js irgendwo anhängen.

Statt z.B. diese Methode:

<?php /* codestuff */ ?>
<p>Mein Text</p>
<?php /* more code */ ?>


kann man es auch so machen:

<?php /* codestuff */ echo
<<<EOF
<p>Mein Text</p>
EOF;
/* more code */ ?>

Hier der Abschnitt:

- String und Variable in einen echo-Befehl mit doppelten Anführungszeichen packen und den fixen Teil mit der Variable zu mischen, etwa

<?php
$teststring = "Erde";
echo "Hallo $teststring";
?>


Das ist die meiner Ansicht nach bequemste Methode, Strings mit variablen Inhalten zu schreiben. Aber ist das auch die schnellste? Es gibt noch andere Möglichkeiten:

<?php
$teststring = "Erde";
echo 'Hallo '.$teststring;
?>

Hier haben wir es mit einfachen Anführungszeichen zu tun. Das bedeutet für PHP: Variablen innerhalb der einfachen Anführungszeichen werden nicht interpretiert. Also muss die Variable mit einem Punkt hinten angehängt werden.

Oder wie wäre es mit dieser Variante:

<?php
$teststring = "Erde";
?>
Hallo <?=$teststring?>

Hier wird “Hallo” allein von HTML ausgegeben, nur für die Ausgabe der Variablen macht sich der PHP-Interpreter an die Arbeit.

Zuletzt hätten wir noch diese Variante:

<?php
$teststring = "Erde";
printf("Hallo %s", $teststring);
?>

Für die formatierte Ausgabe von Strings.

Welche Methode ist also die schnellste? Ausprobieren. Vom Gefühl her würde man printf und echo”" die schlechtesten Prognosen geben.

Damit der Benchmark mit so einer simplen Programmzeile messbare Ergebnisse liefert, packen wir die Ausgabe noch in eine Schleife. Jede Zeile soll 5000mal ausgegeben werden. Das sieht dann im ersten Beispiel so aus:

<?php
$teststring = "Erde";
for ($i=0; $i < 5000; $i++)
{
echo "Hallo $teststring";
}
?>

Auch die anderen Testdateien müssen mit der Schleife ausgestattet sein.

Das Ergebnis meines kleinen Tests: Wie erwartet belegt printf den letzten Platz mit rund 78 Millisekunden pro Abruf auf einem P450 mit Suse Linux und 192 MByte Speicher. Kein Wunder: printf ist zu mächtig und vollkommen fehl am Platze, um einfach nur einen Text und eine Variable zu mixen.

Auf dem dritten Platz liegt echo mit den doppelten Anführungszeichen. Etwas schneller als printf braucht es dennoch satte 71 Millisekunden pro Abruf.

Deutlich schneller ist schon der Echo-Befehl mit einfachen Anführungszeichen. Er schafft die Seite in durchschnittlich 32 Millisekunden.

Die Mischung aus HTML mit der eingebetteten PHP-Variablen erweist sich aber als schnellste Lösung. Nur 25 Millisekunden brauchte der Server für den Abruf des PHP-Dokuments mit seinem 5000fachen “Hallo Erde”. Alle Angaben ohne Gewähr – probieren Sie es einfach mal selbst aus.

Übrigens: Führen Sie solche Benchmarks nur zu Hause oder einem Testserver durch. Ihr Produktiv-Server sollte nicht mit solchen Versuchen belastet werden.

Hier der Link zum vollen Artikel:
http://www.goldmann.de/apache-benchmark-misst-geschwindigkeit-von-php-programm_tipp_98.html