Willkommen

Im Web findet man eine Menge von veralteten Informationen, mit der neue PHP-Anwender in die Irre geführt werden und die schlechte Methoden und schlechten Code verbreiten. Das kann nicht so weitergehen. PHP: Der richtige Weg ist eine einfach lesbare Schnellreferenz für PHP und enthält die besten Verfahren, anerkannte Code-Standards und Links zu maßgeblichen Anleitungen im Web.

There is no canonical way to use PHP. This website aims to introduce new PHP developers to some topics which they may not discover until it is too late, and aims to give seasoned pros some fresh ideas on those topics they’ve been doing for years without ever reconsidering. This website will also not tell you which tools to use, but instead offer suggestions for multiple options, when possible explaining the differences in approach and use-case.

This is a living document and will continue to be updated with more helpful information and examples as they become available.

Übersetzungen

PHP: Der richtige Weg wurde (oder wird demnächst) in viele verschiedene Spachen übersetzt:

Book

The most recent version of PHP: The Right Way is also available in PDF, EPUB and MOBI formats. Go to Leanpub

Mitarbeiten

Hilf mit, diese Website zur besten Informationsquelle für PHP-Programmierer zu machen! Arbeite auf GitHub mit

Zurück zum Start{.top}

Erste Schritte

Verwende die aktuelle stabile Version (7.3)

Wenn du gerade diene ersten Schritte mit PHP machst, stelle sicher, dass du mit der aktuellen stabilen Version von PHP 7.3 beginnst. PHP 7.x adds many new features over the older 5.x versions. The engine has been largely re-written, and PHP is now even quicker than older versions.

You should try to upgrade to the latest stable version quickly - PHP 5.6 is already End of Life. Upgrading is easy, as there are not many backwards compatibility breaks. If you are not sure which version a function or feature is in, you can check the PHP documentation on the php.net website.

Eingebauter Webserver

Du kannst mit dem Erlernen von PHP beginnen, ohne einen vollwertigen Webserver zu installieren und zu konfigurieren (erfordert PHP 5.4+). Gib diesen Befehl auf der Konsole im Web-Wurzelverzeichnis deines Projekts ein, um den Server zu starten:

> php -S localhost:8000

Installation auf dem Mac

macOS comes prepackaged with PHP but it is normally a little behind the latest stable release. There are multiple ways to install the latest PHP version on macOS.

Install PHP via Homebrew

Homebrew is a package manager for macOS that helps you easily install PHP and various extensions. The Homebrew core repository provides “formulae” for PHP 5.6, 7.0, 7.1, 7.2 and 7.3. Install the latest version with this command:

brew install php@7.3

You can switch between Homebrew PHP versions by modifying your PATH variable. Alternatively, you can use brew-php-switcher to switch PHP versions automatically.

Install PHP via Macports

The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the OS X operating system.

MacPorts supports pre-compiled binaries, so you don’t need to recompile every dependency from the source tarball files, it saves your life if you don’t have any package installed on your system.

At this point, you can install php54, php55, php56, php70, php71, php72 or php73 using the port install command, for example:

sudo port install php56
sudo port install php73

And you can run select command to switch your active PHP:

sudo port select --set php php73

Install PHP via phpbrew

phpbrew is a tool for installing and managing multiple PHP versions. This can be really useful if two different applications/projects require different versions of PHP, and you are not using virtual machines.

Install PHP via Liip’s binary installer

Another popular option is php-osx.liip.ch which provides one liner installation methods for versions 5.3 through 7.3. It doesn’t overwrite the PHP binaries installed by Apple, but installs everything in a separate location (/usr/local/php5).

Compile from Source

Another option that gives you control over the version of PHP you install, is to compile it yourself. In that case be sure to have installed either Xcode or Apple’s substitute “Command Line Tools for XCode” downloadable from Apple’s Mac Developer Center.

All-in-One Installers

The solutions listed above mainly handle PHP itself, and do not supply things like Apache, Nginx or a SQL server. “All-in-one” solutions such as MAMP and XAMPP will install these other bits of software for you and tie them all together, but ease of setup comes with a trade-off of flexibility.

Installation unter Windows

You can download the binaries from windows.php.net/download. After the extraction of PHP, it is recommended to set the PATH to the root of your PHP folder (where php.exe is located) so you can execute PHP from anywhere.

For learning and local development, you can use the built in webserver with PHP 5.4+ so you don’t need to worry about configuring it. If you would like an “all-in-one” which includes a full-blown webserver and MySQL too then tools such as the Web Platform Installer, XAMPP, EasyPHP, OpenServer and WAMP will help get a Windows development environment up and running fast. That said, these tools will be a little different from production so be careful of environment differences if you are working on Windows and deploying to Linux.

If you need to run your production system on Windows, then IIS7 will give you the most stable and best performance. You can use phpmanager (a GUI plugin for IIS7) to make configuring and managing PHP simple. IIS7 comes with FastCGI built in and ready to go, you just need to configure PHP as a handler. For support and additional resources there is a dedicated area on iis.net for PHP.

Generally running your application on different environment in development and production can lead to strange bugs popping up when you go live. If you are developing on Windows and deploying to Linux (or anything non-Windows) then you should consider using a Virtual Machine.

Chris Tankersley has a very helpful blog post on what tools he uses to do PHP development using Windows.

Common Directory structure

A common question among those starting out with writing programs for the web is, “where do I put my stuff?” Over the years, this answer has consistently been “where the DocumentRoot is.” Although this answer is not complete, it’s a great place to start.

For security reasons, configuration files should not be accessible by a site’s visitors; therefore, public scripts are kept in a public directory and private configurations and data are kept outside of that directory.

For each team, CMS, or framework one works in, a standard directory structure is used by each of those entities. However, if one is starting a project alone, knowing which filesystem structure to use can be daunting.

Paul M. Jones has done some fantastic research into common practices of tens of thousands of github projects in the realm of PHP. He has compiled a standard file and directory structure, the Standard PHP Package Skeleton, based on this research. In this directory structure, DocumentRoot should point to public/, unit tests should be in the tests/ directory, and third party libraries, as installed by composer, belong in the vendor/ directory. For other files and directories, abiding by the Standard PHP Package Skeleton will make the most sense to contributors of a project.

Vagrant

Der Betrieb einer Anwendung in zwischen Entwicklung und Produktion unterschiedlichen Umgebungen kann zu seltsamen Bugs führen. Ein Team von Entwicklern auf dem selben Versionsstand aller Bibliotheken zu halten, kann ebenfalls umständlich werden.

Du solltest den Einsatz einer virtuellen Maschine erwägen, wenn du unter Windows entwickelst und auf Linux oder ein anderes Nicht-Windows-Betriebssystem ausrollst oder in einem Team entwickelst. Das klingt kompliziert, aber mit Hilfe von Vagrant kannst du eine einfache virtuell Maschine in wenigen Schritten einrichten. Diese Basismaschinen kannst du anschließend manuell aufsetzen oder Software wie Puppet or Chef zur “Provisionierung” einsetzen. Eine Basismaschine zu provisionieren, ist eine gute Methode um sicherzustellen, dass mehrere Maschinen identisch konfiguriert sind und reduziert den Bedarf von komplizierten Checklisten für das Setup. Du kannst eine Basismaschine jederzeit zerstören und ohne viele manuelle Schritte mit einer frischen Installation neu aufsetzen.

Vagrant erstellt geteilte Verzeichnisse, um den Code zwischen dem Host und den virtuellen Maschinen zu verteilen. Damit kannst du den Code auf der Hostmaschine bearbeiten und in den virtuellen Maschinen ablaufen lassen.

Zurück zum Start{.top}

Stilregeln für den Code

Die PHP-Gemeinschaft ist groß und vielfältig und besteht aus unzähligen Bibliotheken, Frameworks und Bausteinen. Üblicherweise wählen PHP-Entwickler mehrere davon aus und kombinieren sie in einem einzelnen Projekt. Es ist wichtig, dass PHP-Code einem gemeinsamen Stil folgt, um Entwicklern die Kombination von verschiedenen Bibliotheken innerhalb ihrer Projekte zu erleichtern.

The Framework Interop Group has proposed and approved a series of style recommendations. Not all of them related to code-style, but those that do are PSR-1, PSR-12 and PSR-4. These recommendations are merely a set of rules that many projects like Drupal, Zend, Symfony, Laravel, CakePHP, phpBB, AWS SDK, FuelPHP, Lithium, etc are adopting. You can use them for your own projects, or continue to use your own personal style.

Ideally, you should write PHP code that adheres to a known standard. This could be any combination of PSRs, or one of the coding standards made by PEAR or Zend. This means other developers can easily read and work with your code, and applications that implement the components can have consistency even when working with lots of third-party code.

You can use PHP_CodeSniffer to check code against any one of these recommendations, and plugins for text editors like Sublime Text to be given real-time feedback.

You can fix the code layout automatically by using one of the following tools:

And you can run phpcs manually from shell:

phpcs -sw --standard=PSR1 file.php

It will show errors and describe how to fix them. It can also be helpful to include this command in a git hook. That way, branches which contain violations against the chosen standard cannot enter the repository until those violations have been fixed.

If you have PHP_CodeSniffer, then you can fix the code layout problems reported by it, automatically, with the PHP Code Beautifier and Fixer.

phpcbf -w --standard=PSR1 file.php

Another option is to use the PHP Coding Standards Fixer. It will show which kind of errors the code structure had before it fixed them.

php-cs-fixer fix -v --rules=@PSR1 file.php

English is preferred for all symbol names and code infrastructure. Comments may be written in any language easily readable by all current and future parties who may be working on the codebase.

Finally, a good supplementary resource for writing clean PHP code is Clean Code PHP.

Zurück zum Start{.top}

Das Beste der Sprache

Programmierparadigmen

PHP ist eine flexible, dynamische Sprache, die unterschiedliche Programmiertechniken unterstützt. Sie hat sich über die Jahre dramatisch entwickelt, speziell mit der Ergänzung um ein solides objektorientiertes Modells in PHP 5.0 (2004), anonyme Funktionen und Namespaces in PHP 5.3 (2009) und Traits in PHP 5.4 (2012).

Objektorientierte Programmierung

PHP besitzt eine weitgehend vollständige Menge von objektorientierten Eigenschaften inklusive der Unterstützung von Klassen, Vererbung, Konstruktoren, Cloning, Exceptions und mehr.

Funktionale Programmierung

PHP unterstützt Funktionen erster Klasse. Das heißt, dass Funktionen an Variablen zugewiesen werden können. Sowohl benutzerdefinierte als auch eingebaute Funktionen können über eine Variable referenziert und dynamisch aufgerufen werden. Funktionen können als Argumente an andere Funktionen übergeben werden.

Rekursion, eine Eigenschaft, die den Aufruf einer Funktion durch sich selbst erlaubt, wird von der Sprache unterstützt, aber der Großteil des PHP-Codes hat den Schwerpunkt auf Iteration.

Neue anonyme Funktionen mit der Unterstützung von Closures sind seit PHP 5.3 (2009) vorhanden.

Mit PHP 5.4 kam die Fähigkeit, Closures an den Gültigkeitsbereich eines Objekts zu binden, und die verbesserte Unterstützung für Callables, die seither gleichberechtigt mit anonymen Funktionen in fast allen Fällen einsetzbar sind.

Meta-Programmierung

PHP unterstützt verschiedene Formen der Meta-Programmiereung über Mechanismen wie das Reflection API und magische Methoden. Die magischen Methoden wie etwa __get(), __set(), __clone(), __toString(), __invoke() etc. erlauben Entwicklern, sich in das Verhalten von Klassen einzuhängen. Ruby-Entwickler behaupten oft, dass in PHP method_missing fehlt, aber diese ist als __call() and __callStatic() vorhanden.

Namespaces

Wie oben erwähnt besteht die PHP-Gemeinschaft aus vielen Entwicklern, die eine Menge Code produzieren. Das bedeutet, dass der PHP-Code aus einer Bibliothek die selben Klassennamen verwenden kann wie der Code einer anderen Bibliothek. Wenn beide Bibliotheken im selben Namensraum verwendet werden, entstehen Kollisionen und verursachen Probleme.

Namespaces lösen dieses Problem. Laut der Beschreibung im PHP-Handbuch können Namespaces mit den Verzeichnissen vom Dateisystemen verglichen werden, die Namensräume für Dateien bilden; zwei Dateien mit dem selben Namen können in unterschiedlichen Verzeichnissen existieren. Ebenso können zwei PHP-Klassen mit dem selben Namen in getrennten PHP-Namespaces koexistieren. So einfach ist das.

Für dich ist wichtig, deinen Code in Namensräumen zu ordnen, damit er von anderen Entwicklern ohne Sorge um mögliche Kollisionen mit anderen Bibliotheken verwendet werden kann.

Ein empfohlene Methode zum Einsatz von Namespaces ist in PSR-4 mit dem Ziel einer standardisierten Datei-, Klassen- und Namespace-Konvention für Plug-and-Play-Code umrissen.

In October 2014 the PHP-FIG deprecated the previous autoloading standard: PSR-0. Both PSR-0 and PSR-4 are still perfectly usable. The latter requires PHP 5.3, so many PHP 5.2-only projects implement PSR-0.

If you’re going to use an autoloader standard for a new application or package, look into PSR-4.

Standard PHP Library

Die “Standard PHP Library” (SPL) ist mit PHP gebündelt und bietet eine Sammlung von Klassen und Schnittstellen. Sie besteht hauptsächlich aus häufig benötigten Klassen für Datenstrukturen wie Stack, Queue oder Heap, sowie Iteratoren, die diese Datenstrukturen oder deine eigenen Klassen, die die SPL-Schnittstellen implementieren, durchlaufen können.

Schnittstelle für die Befehlszeile

PHP wurde primär für die Erstellung von Web-Anwendungen geschaffen, aber es ist auch beim verfassen von Befehlszeilenprogrammen (CLI; command line interface) nützlich. PHP-Programme für die Befehlszeile können dir helfen, allgemeine Aufgaben wie Softwaretests, Ausrollung und Administratives zu automatisieren.

CLI-PHP-Programme sind mächtig, weil sie den Code deiner Anwendung direkt ohne Web-Oberfläche benutzen können. Achte nur darauf, dass deine CLI-Scripts nicht im öffentlichen Webverzeichnis liegen!

Versuche, PHP von der Befehlszeile aus aufzurufen:

> php -i

Die Option -i gibt die PHP-Konfiguration ähnlich wie die Funktion phpinfo() aus.

Die Option -a startet eine interaktive Shell ähnlich wie IRB in Ruby oder Pythons interaktive Shell. Es gibt einige andere nützliche Optionen für die Befehlszeile.

Schreiben wir doch ein CLI-Programm für “Hello, $name”. Erstelle eine Datei hello.php und gib diesen Code in die Datei ein:

<?php
if ($argc !== 2) {
    echo "Usage: php hello.php <name>.\n";
    exit(1);
}
$name = $argv[1];
echo "Hello, $name\n";

PHP erstellt zwei spezielle Variable auf Basis der Argument, mit denen dein Script gestartet wird. $argc ist eine Integer-Variable und enthält die Anzahl der Argumente; $argv ist ein eine Array-Variable, die den Wert jedes Arguments enthält. Das erste Argument ist immer der Name deines PHP-Scripts, in unserem Fall also hello.php.

Der Ausdruck exit() wird mit einer Zahl ungleich Null aufgerufen, um die Shell davon zu informieren, dass der Befehl gescheitert ist. Gebräuchliche Exitcodes findet man hier.

Starte unser Script von der Befehlszeile:

> php hello.php
Usage: php hello.php <name>
> php hello.php world
Hello, world

Xdebug

Eines der nützlichsten Werkzeuge der Softwareentwicklung ist ein guter Debugger. Damit kannst du den Ablauf des Codes verfolgen und den Inhalt des Stacks beobachten. XDebug, der Debugger für PHP, kann in verschiedenen IDEs für Breakpoints und zur Stackinspektion eingesetzt werden. Er ermöglicht auch Werkzeugen wie PHPUnit oder KCacheGrind, die Codeabdeckung zu analysieren und den Code zu profilieren.

If you find yourself in a bind, willing to resort to var_dump()/print_r(), and you still can’t find the solution - maybe you need to use the debugger.

Installing Xdebug can be tricky, but one of its most important features is “Remote Debugging” - if you develop code locally and then test it inside a VM or on another server, Remote Debugging is the feature that you will want to enable right away. Die Installation von Xdebug kann kompliziert sein, aber eine seiner wichtigsten Fähigkeiten ist “Remote Debugging” - wenn du lokal entwickelst und dann in einer anderen VM oder auf einem anderen Server testest, ist Remote Debugging das Feature, das du jedenfalls sofort einschalten willst.

Traditionellerweise ergänzt du den Apache-Vhost oder die Datei .htaccess mit diesen Werten:

php_value xdebug.remote_host 192.168.?.?
php_value xdebug.remote_port 9000

“remote host” “remote port” entsprechen deinem lokalen Computer und Port, wie du ihn in der IDE konfigurierst. Anschließend musst du nur deine IDE in die Betriebsart “listen for connections” bringen und diese URL aufrufen:

http://your-website.example.com/index.php?XDEBUG_SESSION_START=1

Deine IDE wird nun den aktuellen Zustand deines Script während der Ausführung abhören und dir erlauben, Breakpoints zu setzen und die Werte im Speicher zu untersuchen.

Graphical debuggers make it very easy to step through code, inspect variables, and eval code against the live runtime. Many IDE’s have built-in or plugin-based support for graphical debugging with Xdebug. MacGDBp is a free, open-source, stand-alone Xdebug GUI for Mac.

Zurück zum Start{.top}

Verwaltung von Abhängigkeiten

Es gibt eine unüberschaubare Menge von PHP-Bibliotheken, Frameworks und Bausteinen, aus denen man wählen kann. In deinem Projekt wirst du wahrscheinlich mehrere davon einsetzen. Bis vor Kurzem hatte PHP keine Methode um diese Projektabhängigkeiten zu verwalten. Selbst wenn du diese händisch verwaltet hättest, musstest du dich um Autoloading kümmern. Das ist vorbei.

Zur Zeit gibt es zwei große Paketverwaltungssysteme für PHP - Composer und PEAR. Composer is currently the most popular package manager for PHP, however for a long time PEAR was the primary package manager in use. Knowing PEAR’s history is a good idea, since you may still find references to it even if you never use it.

Composer und Packagist

Composer is the recommended dependency manager for PHP. List your project’s dependencies in a composer.json file and, with a few simple commands, Composer will automatically download your project’s dependencies and setup autoloading for you. Composer is analogous to NPM in the node.js world, or Bundler in the Ruby world.

Viele PHP-Bibliotheken sind bereits mit Composer kompatibel und bereit für den Einsatz in deinem Projekt. Diese “Pakete” werden bei Packagist gelistet, dem offiziellen Verzeichnis von mit Composer kompatiblen PHP-Bibliotheken.

Composer installieren

The safest way to download composer is by following the official instructions. This will verify the installer is not corrupt or tampered with. The installer installs a composer.phar binary in your current working directory.

We recommend installing Composer globally (e.g. a single copy in /usr/local/bin). To do so, run this command next:

mv composer.phar /usr/local/bin/composer

Note: If the above fails due to permissions, prefix with sudo.

To run a locally installed Composer you’d use php composer.phar, globally it’s simply composer.

Installing on Windows

For Windows users the easiest way to get up and running is to use the ComposerSetup installer, which performs a global install and sets up your $PATH so that you can just call composer from any directory in your command line.

Abhängigkeiten definieren und installieren

Composer verfolgt die Abhängigkeiten deines Projekts in einer Datei namens composer.json. Du kannst diese Datei händisch oder mit Composer verwalten. Der Befehl composer require fügt eine Projektabhängigkeit hinzu. Wenn die Datei composer.json noch nicht existiert, wird sie erstellt. Im folgenden Beispiel wird Twig als Abhängigkeit zu deinem Projekt hinzugefügt.

composer require twig/twig:^2.0

Alternativ führt dich der Befehl composer init durch die Erstellung einer vollständigen composer.json für dein Projekt. In jedem Fall kannst du nach der Erzeugung der Datei composer.json Composer anweisen, die Abhängigkeiten deines Projekts in das Verzeichnis vendors/ herunterzuladen und zu installieren. Das trifft auch auf heruntergeladene Projekte zu, die selbst bereits eine Datei composer.json bereitstellen:

composer install

Als nächsten Schritt füge die folgende Zeile zur primären PHP-Datei deines Projektes hinzu; damit weist du PHP an, den Autloader von Composer für deine Projektabhängigkeiten einzusetzen.

<?php
require 'vendor/autoload.php';

Du kannst jetzt Projektabhängigkeiten verwenden, und sie werden automatisch heruntergeladen.

Abhängigkeiten aktualisieren

Composer erzeugt eine Datei composer.lock, in der die genauen Versionen jedes Pakets zu dem Zeitpunkt gespeichert sind, an dem du das erste Mal composer install ausgeführt hast. Wenn du dein Projekt mit anderen Programmierern teilst und die Datei composer install in das verteilte Produkt aufnimmst, erhalten sie die selbe Version wie du. Starte composer update, um die Abhängigkeiten zu aktualisieren. Don’t use composer update when deploying, only composer install, otherwise you may end up with different package versions on production.

Das ist auch sehr nützlich, falls du deine Versionsansprüche flexibel definiert hast. Beispielsweise bedeutet eine erforderliche Version von ~1.8 “irgend eine Version, die neuer ist als 1.8, aber niedriger als 2.0.x-dev”. Der Composer-Befehl composer update wird alle Abhängigkeiten auf die neueste Version aktualisieren, welche die definierten Einschränkungen erfüllen.

Update Notifications

To receive notifications about new version releases you can sign up for libraries.io, a web service that can monitor dependencies and send you alerts on updates.

Abhängigkeiten auf Sicherheitsprobleme prüfen

Der Security Advisories Checker ist ein Webdienst und ein Befehlszeilenwerkzeug. Er untersucht die Datei composer.lock und berichtet, ob eine Abhängigkeit aktualisiert werden muss.

Handling global dependencies with Composer

Composer can also handle global dependencies and their binaries. Usage is straight-forward, all you need to do is prefix your command with global. If for example you wanted to install PHPUnit and have it available globally, you’d run the following command:

composer global require phpunit/phpunit

This will create a ~/.composer folder where your global dependencies reside. To have the installed packages’ binaries available everywhere, you’d then add the ~/.composer/vendor/bin folder to your $PATH variable.

PEAR

Ein weiterer altgedienter Paketverwalter für PHP-Programmierer ist PEAR. Er funktioniert weitgehend wie Composer mit ein paar bemerkenswerten Unterschieden.

PEAR erfordert, dass jedes Paket eine bestimmte Struktur einhält. Der Autor eines Pakets muss es also für den Einsatz mit PEAR vorbereiten. Es ist nicht möglich, ein Projekt mit PEAR einzusetzen, das nicht dafür vorgesehen wurde.

PEAR installiert Pakete global. Das heißt, dass Pakete nach einer einmaligen Installation allen Projekten auf dem Server zur Verfügung stehen. Das kann günstig sein, wenn viele Projekte auf dem selben Paket in der selben Version basieren, kann aber zu Versionskonflikten zwischen zwei Paketen führen.

PEAR installieren

You can install PEAR by downloading the .phar installer and executing it. The PEAR documentation has detailed install instructions for every operating system.

If you are using Linux, you can also have a look at your distribution package manager. Debian and Ubuntu, for example, have an apt php-pear package.

Ein Paket installieren

Wenn das Paket in der Paketliste für PEAR geführt wird, kannst du es über seinen offiziellen Namen installieren:

pear install foo

Wird das Paket auf einem anderen Channel angeboten, musst du zuerst discover für den Channel ausführen und ihn auch bei der Installation angeben. Mehr dazu findest du in der Channel-Dokumentation.

Handling PEAR dependencies with Composer

If you are already using Composer and you would like to install some PEAR code too, you can use Composer to handle your PEAR dependencies. This example will install code from pear2.php.net:

{
    "repositories": [
        {
            "type": "pear",
            "url": "https://pear2.php.net"
        }
    ],
    "require": {
        "pear-pear2/PEAR2_Text_Markdown": "*",
        "pear-pear2/PEAR2_HTTP_Request": "*"
    }
}

The first section "repositories" will be used to let Composer know it should “initialize” (or “discover” in PEAR terminology) the pear repo. Then the require section will prefix the package name like this:

pear-channel/Package

The “pear” prefix is hardcoded to avoid any conflicts, as a pear channel could be the same as another packages vendor name for example, then the channel short name (or full URL) can be used to reference which channel the package is in.

When this code is installed it will be available in your vendor directory and automatically available through the Composer autoloader:

vendor/pear-pear2.php.net/PEAR2_HTTP_Request/pear2/HTTP/Request.php

To use this PEAR package simply reference it like so:

<?php
$request = new pear2\HTTP\Request();

Zurück zum Start{.top}

Programmiermethoden

Grundlagen

PHP ist einer umfangreiche Sprache, mit der Programmierer Code schnell und effizient erstellen können. Mit zunehmendem Gebrauch der Sprache vergessen wir oft die Grundlagen im Austausch gegen Abkürzungen und schlechte Gewohnheiten. Dieser Abschnitt dient dazu, Programmierer wieder an grundlegende Programmiermethoden von PHP zu erinnern und dieses Problem zu bekämpfen.

Datum und Zeit

PHP beinhaltet eine Klasse namens DateTime, die beim Lesen, Schreiben, Vergleichen und Berechnen von Datum und Zeit hilft. Es gibt neben DateTime viele weitere Funktionen mit Bezug zu Datum und Zeit in PHP, aber die Klasse bietet eine schöne objektorientierte Schnittstelle für die häufigsten Anwendungsfälle. Sie kann auch Zeitzonen verarbeiten, das ist allerdings nicht Inhalt dieser kurzen Einführung.

Konvertiere einen unformatierten Datums- und Zeitstring mit der Factory-Methode createFromFormat() oder verwende new DateTime für die aktuelle Zeit und das aktuelle Datum, um mit DateTime zu beginnen. Verwende die Methode format(), um ein DateTime-Objeckt wieder in einen String zur Ausgabe zu konvertieren.

<?php
$raw = '22. 11. 1968';
$start = DateTime::createFromFormat('d. m. Y', $raw);

echo 'Start date: ' . $start->format('Y-m-d') . "\n";

Die Klasse DateInterval ermöglicht Berechnungen mit DateTime. DateTime besitzt Methoden wie add() and sub(), die ein DateTime-Intervall als Argument akzeptieren. Schreibe keinen Code der annimmt, dass jeder Tag die selbe Zahl von Sekunden dauert. Sowohl Sommerzeit-/Winterzeitwechsel als auch Zeitzonenwechsel verletzen diese Annahme. Verende stattdessen DateInterval. Verwenden die Methode diff(), um Datumsunterschiede zu berechnen. Das Ergebnis ist ein DateInterval, das sehr einfach anzuzeigen ist.

<?php
// create a copy of $start and add one month and 6 days
$end = clone $start;
$end->add(new DateInterval('P1M6D'));

$diff = $end->diff($start);
echo 'Difference: ' . $diff->format('%m month, %d days (total: %a days)') . "\n";
// Difference: 1 month, 6 days (total: 37 days)

Du kannst herkömmliche Vergleichsoperatoren auf DateTime-Objekte anwenden:

<?php
if ($start < $end) {
    echo "Start is before the end!\n";
}

Ein letztes Beispiel zeigt die Klasse DatePeriod. Sie wird verwendet, um über wiederkehrende Ereignisse zu iterieren. Sie akzeptiert zwei DateTome-Objekt für Beginn und Ende und ein Intervall und gibt alle Ereignisse dazwischen zurück.

<?php
// output all thursdays between $start and $end
$periodInterval = DateInterval::createFromDateString('first thursday');
$periodIterator = new DatePeriod($start, $periodInterval, $end, DatePeriod::EXCLUDE_START_DATE);
foreach ($periodIterator as $date) {
    // output each date in the period
    echo $date->format('Y-m-d') . ' ';
}

A popular PHP API extension is Carbon. It inherits everything in the DateTime class, so involves minimal code alterations, but extra features include Localization support, further ways to add, subtract and format a DateTime object, plus a means to test your code by simulating a date and time of your choosing.

Entwurfsmuster

Beim Entwurf einer Anwendung ist es hilfreich, gebräuchliche Entwurfsmuster für Code und die Gesamtstruktur des Projekts zu verwenden. Bekannte Muster machen die Verwaltung des Codes einfacher und erleichtern anderen Entwicklern, Zusammenhänge zu verstehen.

Wird ein Framework eingesetzt, basiert der Großteil der übergeordneten Code- und Projektstruktur auf diesem Framework, und viele Entscheidungen sind vorweg getroffen. Aber die Verantwortung für die Auswahl der besten Muster für den eigenen Code liegt bei dir. Wenn du andererseits kein Framework einsetzt, musst du selbst Muster finden, die zum Typ und zur Größe der Anwendung passen.

You can learn more about PHP design patterns and see working examples at:

https://designpatternsphp.readthedocs.io/

Exceptions

Exceptions sind ein Standardbestandteil moderner populärer Programmiersprachen, werden aber oft von PHP-Programmierern übersehen. Sprachen wie Ruby legen viel Gewicht auf Exceptions, so dass viele Fehler wie etwa ein erfolgloser HTTP-Request, eine falsche Datenbankabfrage oder eine fehlende Grafikdatei die Anzeige von Exceptions am Bildschirm auslösen und so auf Fehler hinweisen.

PHP selbst ist relativ nachlässig, so dass ein file_get_contents() üblicherweise nur zu einem FALSE und einer Warnung führt. Viele ältere Frameworks wie CodeIgniter geben auch nur FALSE zurück, schreiben eine Nachricht in ihr Fehlerlog und erlauben dir den Aufruf einer Methode wie $this->upload->get_error(), um die Ursache des Fehlers zu finden. Das Problem dabei ist, dass du nach dem Fehler fragen und in der Dokumentation nach der Fehlermethode für diese Klasse suchen musst, statt es äußerst offensichtlich zu machen.

Ein weiteres Problem besteht, wenn Klassen automatisch Fehler auslösen und den Prozess beenden. Wenn du so vorgehst, hinderst du andere Entwickler daran, Fehler dynamisch zu behandeln. Exceptions sollten ausgelöst werden, um Entwickler auf Fehler hinzuweisen und ihnen Gelegenheit zu geben, darauf zu reagieren. Ein Beispiel:

<?php
$email = new Fuel\Email;
$email->subject('My Subject');
$email->body('How the heck are you?');
$email->to('guy@example.com', 'Some Guy');

try
{
    $email->send();
}
catch(Fuel\Email\ValidationFailedException $e)
{
    // The validation failed
}
catch(Fuel\Email\SendingFailedException $e)
{
    // The driver could not send the email
}

SPL Exceptions

Die generische Klasse Exception enthält sehr wenig Kontext für das Debugging durch den Entwickler. Zur Erleichterung kann man über eine Unterklassen der generischen Klasse Exception einen spezialisierten Exception-Typ schaffen:

<?php
class ValidationException extends Exception {}

So kannst du mehrere catch-Blöcke einrichten und unterschiedliche Exceptions auch unterschiedlich behandeln. Das kann zu einer Vielzahl von benutzerdefinierten Exceptions führen, von denen einige durch den Einsatz von SPl Exceptions aus der SPL-Erweiterung vermeidbar sind.

Zum Beispiel könnte die magische Methode __call() beim Aufruf einer ungültigen Methode throw new BadFunctionCallException; aufrufen, statt die Standard-Exception oder eine benutzerdefinierte Exception auszulösen.

Working with UTF-8

This section was originally written by Alex Cabal over at PHP Best Practices and has been used as the basis for our own UTF-8 advice.

There’s no one-liner. Be careful, detailed, and consistent.

Right now PHP does not support Unicode at a low level. There are ways to ensure that UTF-8 strings are processed OK, but it’s not easy, and it requires digging in to almost all levels of the web app, from HTML to SQL to PHP. We’ll aim for a brief, practical summary.

UTF-8 at the PHP level

The basic string operations, like concatenating two strings and assigning strings to variables, don’t need anything special for UTF-8. However, most string functions, like strpos() and strlen(), do need special consideration. These functions often have an mb_* counterpart: for example, mb_strpos() and mb_strlen(). These mb_* strings are made available to you via the Multibyte String Extension, and are specifically designed to operate on Unicode strings.

You must use the mb_* functions whenever you operate on a Unicode string. For example, if you use substr() on a UTF-8 string, there’s a good chance the result will include some garbled half-characters. The correct function to use would be the multibyte counterpart, mb_substr().

The hard part is remembering to use the mb_* functions at all times. If you forget even just once, your Unicode string has a chance of being garbled during further processing.

Not all string functions have an mb_* counterpart. If there isn’t one for what you want to do, then you might be out of luck.

You should use the mb_internal_encoding() function at the top of every PHP script you write (or at the top of your global include script), and the mb_http_output() function right after it if your script is outputting to a browser. Explicitly defining the encoding of your strings in every script will save you a lot of headaches down the road.

Additionally, many PHP functions that operate on strings have an optional parameter letting you specify the character encoding. You should always explicitly indicate UTF-8 when given the option. For example, htmlentities() has an option for character encoding, and you should always specify UTF-8 if dealing with such strings. Note that as of PHP 5.4.0, UTF-8 is the default encoding for htmlentities() and htmlspecialchars().

Finally, If you are building a distributed application and cannot be certain that the mbstring extension will be enabled, then consider using the patchwork/utf8 Composer package. This will use mbstring if it is available, and fall back to non UTF-8 functions if not.

UTF-8 at the Database level

If your PHP script accesses MySQL, there’s a chance your strings could be stored as non-UTF-8 strings in the database even if you follow all of the precautions above.

To make sure your strings go from PHP to MySQL as UTF-8, make sure your database and tables are all set to the utf8mb4 character set and collation, and that you use the utf8mb4 character set in the PDO connection string. See example code below. This is critically important.

Note that you must use the utf8mb4 character set for complete UTF-8 support, not the utf8 character set! See Further Reading for why.

UTF-8 at the browser level

Use the mb_http_output() function to ensure that your PHP script outputs UTF-8 strings to your browser.

The browser will then need to be told by the HTTP response that this page should be considered as UTF-8. Today, it is common to set the character set in the HTTP response header like this:

<?php
header('Content-Type: text/html; charset=UTF-8')

The historic approach to doing that was to include the charset <meta> tag in your page’s <head> tag.

<?php
// Tell PHP that we're using UTF-8 strings until the end of the script
mb_internal_encoding('UTF-8');
$utf_set = ini_set('default_charset', 'utf-8');
if (!$utf_set) {
    throw new Exception('could not set default_charset to utf-8, please ensure it\'s set on your system!');
}

// Tell PHP that we'll be outputting UTF-8 to the browser
mb_http_output('UTF-8');
 
// Our UTF-8 test string
$string = 'Êl síla erin lû e-govaned vîn.';

// Transform the string in some way with a multibyte function
// Note how we cut the string at a non-Ascii character for demonstration purposes
$string = mb_substr($string, 0, 15);

// Connect to a database to store the transformed string
// See the PDO example in this document for more information
// Note the `charset=utf8mb4` in the Data Source Name (DSN)
$link = new PDO(
    'mysql:host=your-hostname;dbname=your-db;charset=utf8mb4',
    'your-username',
    'your-password',
    array(
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_PERSISTENT => false
    )
);

// Store our transformed string as UTF-8 in our database
// Your DB and tables are in the utf8mb4 character set and collation, right?
$handle = $link->prepare('insert into ElvishSentences (Id, Body, Priority) values (default, :body, :priority)');
$handle->bindParam(':body', $string, PDO::PARAM_STR);
$priority = 45;
$handle->bindParam(':priority', $priority, PDO::PARAM_INT); // explicitly tell pdo to expect an int
$handle->execute();

// Retrieve the string we just stored to prove it was stored correctly
$handle = $link->prepare('select * from ElvishSentences where Id = :id');
$id = 7;
$handle->bindParam(':id', $id, PDO::PARAM_INT);
$handle->execute();

// Store the result into an object that we'll output later in our HTML
// This object won't kill your memory because it fetches the data Just-In-Time to
$result = $handle->fetchAll(\PDO::FETCH_OBJ);

// An example wrapper to allow you to escape data to html
function escape_to_html($dirty){
    echo htmlspecialchars($dirty, ENT_QUOTES, 'UTF-8');
}

header('Content-Type: text/html; charset=UTF-8'); // Unnecessary if your default_charset is set to utf-8 already
?><!doctype html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>UTF-8 test page</title>
    </head>
    <body>
        <?php
        foreach($result as $row){
            escape_to_html($row->Body);  // This should correctly output our transformed UTF-8 string to the browser
        }
        ?>
    </body>
</html>

Further reading

Internationalization (i18n) and Localization (l10n)

Disclaimer for newcomers: i18n and l10n are numeronyms, a kind of abbreviation where numbers are used to shorten words - in our case, internationalization becomes i18n and localization, l10n.

First of all, we need to define those two similar concepts and other related things:

Common ways to implement

The easiest way to internationalize PHP software is by using array files and using those strings in templates, such as <h1><?=$TRANS['title_about_page']?></h1>. This way is, however, hardly recommended for serious projects, as it poses some maintenance issues along the road - some might appear in the very beginning, such as pluralization. So, please, don’t try this if your project will contain more than a couple of pages.

The most classic way and often taken as reference for i18n and l10n is a Unix tool called gettext. It dates back to 1995 and is still a complete implementation for translating software. It is easy enough to get running, while still sporting powerful supporting tools. It is about Gettext we will be talking here. Also, to help you not get messy over the command-line, we will be presenting a great GUI application that can be used to easily update your l10n source

Other tools

There are common libraries used that support Gettext and other implementations of i18n. Some of them may seem easier to install or sport additional features or i18n file formats. In this document, we focus on the tools provided with the PHP core, but here we list others for completion:

Other frameworks also include i18n modules, but those are not available outside of their codebases:

If you decide to go for one of the libraries that provide no extractors, you may want to use the gettext formats, so you can use the original gettext toolchain (including Poedit) as described in the rest of the chapter.

Gettext

Installation

You might need to install Gettext and the related PHP library by using your package manager, like apt-get or yum. After installed, enable it by adding extension=gettext.so (Linux/Unix) or extension=php_gettext.dll (Windows) to your php.ini.

Here we will also be using Poedit to create translation files. You will probably find it in your system’s package manager; it is available for Unix, Mac, and Windows, and can be downloaded for free on their website as well.

Structure

Types of files

There are three files you usually deal with while working with gettext. The main ones are PO (Portable Object) and MO (Machine Object) files, the first being a list of readable “translated objects” and the second, the corresponding binary to be interpreted by gettext when doing localization. There’s also a POT (Template) file, which simply contains all existing keys from your source files, and can be used as a guide to generate and update all PO files. Those template files are not mandatory: depending on the tool you are using to do l10n, you can go just fine with only PO/MO files. You will always have one pair of PO/MO files per language and region, but only one POT per domain.

Domains

There are some cases, in big projects, where you might need to separate translations when the same words convey different meaning given a context. In those cases, you split them into different domains. They are, basically, named groups of POT/PO/MO files, where the filename is the said translation domain. Small and medium-sized projects usually, for simplicity, use only one domain; its name is arbitrary, but we will be using “main” for our code samples. In Symfony projects, for example, domains are used to separate the translation for validation messages.

Locale code

A locale is simply a code that identifies one version of a language. It is defined following the ISO 639-1 and ISO 3166-1 alpha-2 specs: two lower-case letters for the language, optionally followed by an underline and two upper-case letters identifying the country or regional code. For rare languages, three letters are used.

For some speakers, the country part may seem redundant. In fact, some languages have dialects in different countries, such as Austrian German (de_AT) or Brazilian Portuguese (pt_BR). The second part is used to distinguish between those dialects - when it is not present, it is taken as a “generic” or “hybrid” version of the language.

Directory structure

To use Gettext, we will need to adhere to a specific structure of folders. First, you will need to select an arbitrary root for your l10n files in your source repository. Inside it, you will have a folder for each needed locale, and a fixed LC_MESSAGES folder that will contain all your PO/MO pairs. Example:

<project root>
 ├─ src/
 ├─ templates/
 └─ locales/
    ├─ forum.pot
    ├─ site.pot
    ├─ de/
    │  └─ LC_MESSAGES/
    │     ├─ forum.mo
    │     ├─ forum.po
    │     ├─ site.mo
    │     └─ site.po
    ├─ es_ES/
    │  └─ LC_MESSAGES/
    │     └─ ...
    ├─ fr/
    │  └─ ...
    ├─ pt_BR/
    │  └─ ...
    └─ pt_PT/
       └─ ...

Plural forms

As we said in the introduction, different languages might sport different plural rules. However, gettext saves us from this trouble once again. When creating a new .po file, you will have to declare the plural rules for that language, and translated pieces that are plural-sensitive will have a different form for each of those rules. When calling Gettext in code, you will have to specify the number related to the sentence, and it will work out the correct form to use - even using string substitution if needed.

Plural rules include the number of plurals available and a boolean test with n that would define in which rule the given number falls (starting the count with 0). For example:

Now that you understood the basis of how plural rules works - and if you didn’t, please look at a deeper explanation on the LingoHub tutorial -, you might want to copy the ones you need from a list instead of writing them by hand.

When calling out Gettext to do localization on sentences with counters, you will have to provide it the related number as well. Gettext will work out what rule should be in effect and use the correct localized version. You will need to include in the .po file a different sentence for each plural rule defined.

Sample implementation

After all that theory, let’s get a little practical. Here’s an excerpt of a .po file - don’t mind with its format, but with the overall content instead; you will learn how to edit it easily later:

msgid ""
msgstr ""
"Language: pt_BR\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

msgid "We are now translating some strings"
msgstr "Nós estamos traduzindo algumas strings agora"

msgid "Hello %1$s! Your last visit was on %2$s"
msgstr "Olá %1$s! Sua última visita foi em %2$s"

msgid "Only one unread message"
msgid_plural "%d unread messages"
msgstr[0] "Só uma mensagem não lida"
msgstr[1] "%d mensagens não lidas"

The first section works like a header, having the msgid and msgstr especially empty. It describes the file encoding, plural forms and other things that are less relevant. The second section translates a simple string from English to Brazilian Portuguese, and the third does the same, but leveraging string replacement from sprintf so the translation may contain the user name and visit date. The last section is a sample of pluralization forms, displaying the singular and plural version as msgid in English and their corresponding translations as msgstr 0 and 1 (following the number given by the plural rule). There, string replacement is used as well so the number can be seen directly in the sentence, by using %d. The plural forms always have two msgid (singular and plural), so it is advised not to use a complex language as the source of translation.

Discussion on l10n keys

As you might have noticed, we are using as source ID the actual sentence in English. That msgid is the same used throughout all your .po files, meaning other languages will have the same format and the same msgid fields but translated msgstr lines.

Talking about translation keys, there are two main “schools” here:

  1. msgid as a real sentence. The main advantages are:
    • if there are pieces of the software untranslated in any given language, the key displayed will still maintain some meaning. Example: if you happen to translate by heart from English to Spanish but need help to translate to French, you might publish the new page with missing French sentences, and parts of the website would be displayed in English instead;
    • it is much easier for the translator to understand what’s going on and do a proper translation based on the msgid;
    • it gives you “free” l10n for one language - the source one;
    • The only disadvantage: if you need to change the actual text, you would need to replace the same msgid across several language files.
  2. msgid as a unique, structured key. It would describe the sentence role in the application in a structured way, including the template or part where the string is located instead of its content.
    • it is a great way to have the code organized, separating the text content from the template logic.
    • however, that could bring problems to the translator that would miss the context. A source language file would be needed as a basis for other translations. Example: the developer would ideally have an en.po file, that translators would read to understand what to write in fr.po for instance.
    • missing translations would display meaningless keys on screen (top_menu.welcome instead of Hello there, User! on the said untranslated French page). That is good it as would force translation to be complete before publishing - however, bad as translation issues would be remarkably awful in the interface. Some libraries, though, include an option to specify a given language as “fallback”, having a similar behavior as the other approach.

The Gettext manual favors the first approach as, in general, it is easier for translators and users in case of trouble. That is how we will be working here as well. However, the Symfony documentation favors keyword-based translation, to allow for independent changes of all translations without affecting templates as well.

Everyday usage

In a typical application, you would use some Gettext functions while writing static text in your pages. Those sentences would then appear in .po files, get translated, compiled into .mo files and then, used by Gettext when rendering the actual interface. Given that, let’s tie together what we have discussed so far in a step-by-step example:

1. A sample template file, including some different gettext calls

<?php include 'i18n_setup.php' ?>
<div id="header">
    <h1><?=sprintf(gettext('Welcome, %s!'), $name)?></h1>
    <!-- code indented this way only for legibility -->
    <?php if ($unread): ?>
        <h2><?=sprintf(
            ngettext('Only one unread message',
                     '%d unread messages',
                     $unread),
            $unread)?>
        </h2>
    <?php endif ?>
</div>

<h1><?=gettext('Introduction')?></h1>
<p><?=gettext('We\'re now translating some strings')?></p>

2. A sample setup file (i18n_setup.php as used above), selecting the correct locale and configuring Gettext

<?php
/**
 * Verifies if the given $locale is supported in the project
 * @param string $locale
 * @return bool
 */
function valid($locale) {
   return in_array($locale, ['en_US', 'en', 'pt_BR', 'pt', 'es_ES', 'es']);
}

//setting the source/default locale, for informational purposes
$lang = 'en_US';

if (isset($_GET['lang']) && valid($_GET['lang'])) {
    // the locale can be changed through the query-string
    $lang = $_GET['lang'];    //you should sanitize this!
    setcookie('lang', $lang); //it's stored in a cookie so it can be reused
} elseif (isset($_COOKIE['lang']) && valid($_COOKIE['lang'])) {
    // if the cookie is present instead, let's just keep it
    $lang = $_COOKIE['lang']; //you should sanitize this!
} elseif (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) {
    // default: look for the languages the browser says the user accepts
    $langs = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']);
    array_walk($langs, function (&$lang) { $lang = strtr(strtok($lang, ';'), ['-' => '_']); });
    foreach ($langs as $browser_lang) {
        if (valid($browser_lang)) {
            $lang = $browser_lang;
            break;
        }
    }
}

// here we define the global system locale given the found language
putenv("LANG=$lang");

// this might be useful for date functions (LC_TIME) or money formatting (LC_MONETARY), for instance
setlocale(LC_ALL, $lang);

// this will make Gettext look for ../locales/<lang>/LC_MESSAGES/main.mo
bindtextdomain('main', '../locales');

// indicates in what encoding the file should be read
bind_textdomain_codeset('main', 'UTF-8');

// if your application has additional domains, as cited before, you should bind them here as well
bindtextdomain('forum', '../locales');
bind_textdomain_codeset('forum', 'UTF-8');

// here we indicate the default domain the gettext() calls will respond to
textdomain('main');

// this would look for the string in forum.mo instead of main.mo
// echo dgettext('forum', 'Welcome back!');
?>

3. Preparing translation for the first run

One of the great advantages Gettext has over custom framework i18n packages is its extensive and powerful file format. “Oh man, that’s quite hard to understand and edit by hand, a simple array would be easier!” Make no mistake, applications like Poedit are here to help - a lot. You can get the program from their website, it’s free and available for all platforms. It’s a pretty easy tool to get used to, and a very powerful one at the same time - using all features Gettext has available. This guide is based on PoEdit 1.8.

In the first run, you should select “File > New…” from the menu. You’ll be asked straight ahead for the language: here you can select/filter the language you want to translate to, or use that format we mentioned before, such as en_US or pt_BR.

Now, save the file - using that directory structure we mentioned as well. Then you should click “Extract from sources”, and here you’ll configure various settings for the extraction and translation tasks. You’ll be able to find all those later through “Catalog > Properties”:

After setting those points it will run a scan through your source files to find all the localization calls. After every scan PoEdit will display a summary of what was found and what was removed from the source files. New entries will fed empty into the translation table, and you’ll start typing in the localized versions of those strings. Save it and a .mo file will be (re)compiled into the same folder and ta-dah: your project is internationalized.

4. Translating strings

As you may have noticed before, there are two main types of localized strings: simple ones and those with plural forms. The first ones have simply two boxes: source and localized string. The source string cannot be modified as Gettext/Poedit do not include the powers to alter your source files - you should change the source itself and rescan the files. Tip: you may right-click a translation line and it will hint you with the source files and lines where that string is being used. On the other hand, plural form strings include two boxes to show the two source strings, and tabs so you can configure the different final forms.

Whenever you change your sources and need to update the translations, just hit Refresh and Poedit will rescan the code, removing non-existent entries, merging the ones that changed and adding new ones. It may also try to guess some translations, based on other ones you did. Those guesses and the changed entries will receive a “Fuzzy” marker, indicating it needs review, appearing golden in the list. It is also useful if you have a translation team and someone tries to write something they are not sure about: just mark Fuzzy, and someone else will review later.

Finally, it is advised to leave “View > Untranslated entries first” marked, as it will help you a lot to not forget any entry. From that menu, you can also open parts of the UI that allow you to leave contextual information for translators if needed.

Tips & Tricks

Possible caching issues

If you are running PHP as a module on Apache (mod_php), you might face issues with the .mo file being cached. It happens the first time it is read, and then, to update it, you might need to restart the server. On Nginx and PHP5 it usually takes only a couple of page refreshes to refresh the translation cache, and on PHP7 it is rarely needed.

Additional helper functions

As preferred by many people, it is easier to use _() instead of gettext(). Many custom i18n libraries from frameworks use something similar to t() as well, to make translated code shorter. However, that is the only function that sports a shortcut. You might want to add in your project some others, such as __() or _n() for ngettext(), or maybe a fancy _r() that would join gettext() and sprintf() calls. Other libraries, such as oscarotero’s Gettext also provide helper functions like these.

In those cases, you’ll need to instruct the Gettext utility on how to extract the strings from those new functions. Don’t be afraid; it is very easy. It is just a field in the .po file, or a Settings screen on Poedit. In the editor, that option is inside “Catalog > Properties > Source keywords”. Remember: Gettext already knows the default functions for many languages, so don’t be afraid if that list seems empty. You need to include there the specifications of those new functions, following a specific format:

After including those new rules in the .po file, a new scan will bring in your new strings just as easy as before.

References

Zurück zum Start{.top}

Datenbanken

Oft wird dein PHP-Code eine Datenbank verwenden, um Informationen dauerhaft zu speichern. Es gibt einige Möglichkeiten, um dich mit deiner Datenbank zu verbinden und mit ihr zu interagieren. Die empfohlene Auswahl _bis PHP 5.1.0__ waren die nativen Treiber wie mysql, mysqli, pgsql etc.

Native Treiber sind gut geeignet, wenn du nur ein Datenbanksystem in deiner Anwendung einsetzt. Wenn du aber zum Beispiel MySQL und ein wenig von MSSQL verwenden oder dich mit einer Oracle-Datenbank verbinden möchtest, kannst du nicht dieselben Treiber verwenden. Du musst ein völlig neues API für jedes Datenbanksystem erlernen - und das kann albern werden.

Zusätzlich ist zu sagen, dass die MySQL-Erweiterung für PHP nicht mehr aktiv weiterentwickelt wird und der offizielle Status seit PHP 5.4.0 “langfristige Abkündigung” lautet. Das bedeutet, dass sie im Zug der nächsten Releases entfernt werden wird. Sie könnte also mit PHP 5.6 (oder welche Version auch immer nach 5.5 kommen wird) verschwinden. Setzt du mysql_connect() und mysql_query() in deiner Anwendung ein, wirst du den Code dann umschreiben müssen. Die beste Wahl ist ist es, in deinen Anwendungen während eines geplanten Entwicklungszyklus mysql durch mysqli oder PDO zu ersetzen und so einer späteren erzwungenen Umstellung auszuweichen. Vermeide die mysql-Erweiterung bei einem neuen Projekt: Verwende die mysqli-Erweiterung oder PDO.

PDO

PDO ist eine Bibliothek zur Datenbankabstraktion - seit Version 5.1.0 in PHP integriert - die eine gemeinsame Schnittstelle zu vielen verschiedenen Datenbanksystemen bietet. PDO übersetzt keine SQL-Abfragen und emuliert keine fehlenden Eigenschaften; es dient rein der Verbindung zu mehreren Datenbanksystemen mit einem einheitlichen API.

Wichtiger noch: PDO erlaubt dir, externe Eingaben wie zum Beispiel IDs sicher in deine SQL-Abfragen einzubauen, ohne dich über SQL-Injection-Angriffe zu sorgen. Das geschieht über PDO-Statements und gebundene Parameter.

Nehme wir an, dass ein PHP-Script eine numerische ID als Query-Parameter annimmt. Diese ID soll verwendet werden, um einen Benutzerdatensatz aus der Datenbank zu lesen. Hier ist der falsche Weg, das zu erledigen:

<?php
$pdo = new PDO('sqlite:users.db');
$pdo->query("SELECT name FROM users WHERE id = " . $_GET['id']); // <-- NO!

Das ist schrecklicher Code. Du fügst einen ungefilterten Query-Parameter in eine SQL-Abfrage ein. Du wirst innerhalb von Sekunden gehackt. Stell dir vor, dass ein Hacker einen erfinderischen id-Parameter über eine URL wie http://domain.com/?id=1%3BDELETE+FROM+users übergibt. Das setzt die Variable $_GET['id'] auf 1;DELETE FROM users und löscht so alle deine User! Du solltest stattdessen die ID-Eingabe über PDO-gebundene Parameter reinigen.

<?php
$pdo = new PDO('sqlite:users.db');
$stmt = $pdo->prepare('SELECT name FROM users WHERE id = :id');
$stmt->bindParam(':id', $_GET['id'], PDO::PARAM_INT); //<-- Automatically sanitized by PDO
$stmt->execute();

Das ist korrekter Code. Er verwendet einen gebundenen Parameter in einem PDO-Ausdruck. Das bereinigt die externe Eingabe, bevor sie an die Datenbank weitergegeben wird, und verhindert so potentielle SQL-Injection-Angriffe.

Du solltest dir auch darüber klar sein, dass Datenbankverbindungen Ressourcen verbrauchen und es kann schon vorkommen, dass diese Ressourcen erschöpft werden, wenn Verbindungen nicht explizit geschlossen wurden. Das trifft aber vor allem auf andere Sprachen zu. Mit PDO kannst du eine Verbindung implizit schließen, indem du das Objekt freigibst. Dazu lösche alle verbleibenden Referenzen, indem du sie auf NULLsetzt. Wenn du das nicht ausdrücklich machst, schließt PHP die Verbindung automatisch am Ende des Scripts, sofern du nicht persistente Verbindungen benutzt.

Abstraktionsschichten

Viele Frameworks enthalten ihre eigenen Abstraktionsschichten, die teilweise auf PDO aufbauen. Diese emulieren oft fehlende Eigenschaften eines Datenbanksystems, indem sie Abfragen in PHP-Methoden kleiden und so die Datenbank tatsächlich abstrahieren. Damit entsteht natürlich ein wenig Overhead, der aber beim Bau einer zwischen MySQL, PostgreSQL und SQLite portablen Anwendung seine Berechtigung hat.

Einige Abstraktionsschichten wurden gemäß den Namespace-Standards nach PSR-0 entwickelt und können daher in jede Anwendung eingebaut werden:

Zurück zum Start{.top}

Dependency Injection

From Wikipedia:

Dependency injection is a software design pattern that allows the removal of hard-coded dependencies and makes it possible to change them, whether at run-time or compile-time.

This quote makes the concept sound much more complicated than it actually is. Dependency Injection is providing a component with its dependencies either through constructor injection, method calls or the setting of properties. It is that simple.

Basic Concept

We can demonstrate the concept with a simple, yet naive example.

Here we have a Database class that requires an adapter to speak to the database. We instantiate the adapter in the constructor and create a hard dependency. This makes testing difficult and means the Database class is very tightly coupled to the adapter.

<?php
namespace Database;

class Database
{
    protected $adapter;

    public function __construct()
    {
        $this->adapter = new MySqlAdapter;
    }
}

class MysqlAdapter {}

This code can be refactored to use Dependency Injection and therefore loosen the dependency.

<?php
namespace Database;

class Database
{
    protected $adapter;

    public function __construct(MySqlAdapter $adapter)
    {
        $this->adapter = $adapter;
    }
}

class MysqlAdapter {}

Now we are giving the Database class its dependency rather than creating it itself. We could even create a method that would accept an argument of the dependency and set it that way, or if the $adapter property was public we could set it directly.

Complex Problem

If you have ever read about Dependency Injection then you have probably seen the terms “Inversion of Control” or “Dependency Inversion Principle”. These are the complex problems that Dependency Injection solves.

Inversion of Control

Inversion of Control is as it says, “inverting the control” of a system by keeping organizational control entirely separate from our objects. In terms of Dependency Injection, this means loosening our dependencies by controlling and instantiating them elsewhere in the system.

For years, PHP frameworks have been achieving Inversion of Control, however, the question became, which part of control are we inverting, and where to? For example, MVC frameworks would generally provide a super object or base controller that other controllers must extend to gain access to its dependencies. This is Inversion of Control, however, instead of loosening dependencies, this method simply moved them.

Dependency Injection allows us to more elegantly solve this problem by only injecting the dependencies we need, when we need them, without the need for any hard coded dependencies at all.

S.O.L.I.D.

Single Responsibility Principle

The Single Responsibility Principle is about actors and high-level architecture. It states that “A class should have only one reason to change.” This means that every class should only have responsibility over a single part of the functionality provided by the software. The largest benefit of this approach is that it enables improved code reusability. By designing our class to do just one thing, we can use (or re-use) it in any other program without changing it.

Open/Closed Principle

The Open/Closed Principle is about class design and feature extensions. It states that “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” This means that we should design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code. Practically speaking, this means that we should write classes that implement and adhere to interfaces, then type-hint against those interfaces instead of specific classes.

The largest benefit of this approach is that we can very easily extend our code with support for something new without having to modify existing code, meaning that we can reduce QA time, and the risk for negative impact to the application is substantially reduced. We can deploy new code, faster, and with more confidence.

Liskov Substitution Principle

The Liskov Substitution Principle is about subtyping and inheritance. It states that “Child classes should never break the parent class’ type definitions.” Or, in Robert C. Martin’s words, “Subtypes must be substitutable for their base types.”

For example, if we have a FileInterface interface which defines an embed() method, and we have Audio and Video classes which both implement the FileInterface interface, then we can expect that the usage of the embed() method will always do the thing that we intend. If we later create a PDF class or a Gist class which implement the FileInterface interface, we will already know and understand what the embed() method will do. The largest benefit of this approach is that we have the ability to build flexible and easily-configurable programs, because when we change one object of a type (e.g., FileInterface) to another we don’t need to change anything else in our program.

Interface Segregation Principle

The Interface Segregation Principle (ISP) is about business-logic-to-clients communication. It states that “No client should be forced to depend on methods it does not use.” This means that instead of having a single monolithic interface that all conforming classes need to implement, we should instead provide a set of smaller, concept-specific interfaces that a conforming class implements one or more of.

For example, a Car or Bus class would be interested in a steeringWheel() method, but a Motorcycle or Tricycle class would not. Conversely, a Motorcycle or Tricycle class would be interested in a handlebars() method, but a Car or Bus class would not. There is no need to have all of these types of vehicles implement support for both steeringWheel() as well as handlebars(), so we should break-apart the source interface.

Dependency Inversion Principle

The Dependency Inversion Principle is about removing hard-links between discrete classes so that new functionality can be leveraged by passing a different class. It states that one should “Depend on Abstractions. Do not depend on concretions.”. Put simply, this means our dependencies should be interfaces/contracts or abstract classes rather than concrete implementations. We can easily refactor the above example to follow this principle.

<?php
namespace Database;

class Database
{
    protected $adapter;

    public function __construct(AdapterInterface $adapter)
    {
        $this->adapter = $adapter;
    }
}

interface AdapterInterface {}

class MysqlAdapter implements AdapterInterface {}

There are several benefits to the Database class now depending on an interface rather than a concretion.

Consider that we are working in a team and the adapter is being worked on by a colleague. In our first example, we would have to wait for said colleague to finish the adapter before we could properly mock it for our unit tests. Now that the dependency is an interface/contract we can happily mock that interface knowing that our colleague will build the adapter based on that contract.

An even bigger benefit to this method is that our code is now much more scalable. If a year down the line we decide that we want to migrate to a different type of database, we can write an adapter that implements the original interface and injects that instead, no more refactoring would be required as we can ensure that the adapter follows the contract set by the interface.

Containers

The first thing you should understand about Dependency Injection Containers is that they are not the same thing as Dependency Injection. A container is a convenience utility that helps us implement Dependency Injection, however, they can be and often are misused to implement an anti-pattern, Service Location. Injecting a DI container as a Service Locator in to your classes arguably creates a harder dependency on the container than the dependency you are replacing. It also makes your code much less transparent and ultimately harder to test.

Most modern frameworks have their own Dependency Injection Container that allows you to wire your dependencies together through configuration. What this means in practice is that you can write application code that is as clean and de- coupled as the framework it is built on.

Further Reading

Zurück zum Start{.top}

Databases

Many times your PHP code will use a database to persist information. You have a few options to connect and interact with your database. The recommended option until PHP 5.1.0 was to use native drivers such as mysqli, pgsql, mssql, etc.

Native drivers are great if you are only using one database in your application, but if, for example, you are using MySQL and a little bit of MSSQL, or you need to connect to an Oracle database, then you will not be able to use the same drivers. You’ll need to learn a brand new API for each database — and that can get silly.

Zurück zum Start{.top}

Sicherheit

MySQL Extension

The mysql extension for PHP is incredibly old and has been superseded by two other extensions:

Not only did development stop long ago on mysql, but it was deprecated as of PHP 5.5.0, and has been officially removed in PHP 7.0.

To save digging into your php.ini settings to see which module you are using, one option is to search for mysql_* in your editor of choice. If any functions such as mysql_connect() and mysql_query() show up, then mysql is in use.

Even if you are not using PHP 7.x yet, failing to consider this upgrade as soon as possible will lead to greater hardship when the PHP 7.x upgrade does come about. The best option is to replace mysql usage with mysqli or PDO in your applications within your own development schedules so you won’t be rushed later on.

If you are upgrading from mysql to mysqli, beware lazy upgrade guides that suggest you can simply find and replace mysql_* with mysqli_*. Not only is that a gross oversimplification, it misses out on the advantages that mysqli provides, such as parameter binding, which is also offered in PDO.

Sicherheit von Webanwendungen

Böse Menschen sind bereit und willig, deine Webanwendung auszubeuten. Es ist wichtig, die notwenigen Vorsichtsmaßnahmen zu treffen und die Sicherheit deiner Webanwendung zu verstärken. Zum Glück haben die netten Kollegen von The Open Web Application Security Project (OWASP) eine umfassende Liste bekannter Sicherheitsprobleme und Methoden zum Schutz zusammengestellt. Das ist Pflichtlektüre für jeden sicherheitsbewussten Entwickler.

PDO Extension

PDO is a database connection abstraction library — built into PHP since 5.1.0 — that provides a common interface to talk with many different databases. For example, you can use basically identical code to interface with MySQL or SQLite:

<?php
// PDO + MySQL
$pdo = new PDO('mysql:host=example.com;dbname=database', 'user', 'password');
$statement = $pdo->query("SELECT some_field FROM some_table");
$row = $statement->fetch(PDO::FETCH_ASSOC);
echo htmlentities($row['some_field']);

// PDO + SQLite
$pdo = new PDO('sqlite:/path/db/foo.sqlite');
$statement = $pdo->query("SELECT some_field FROM some_table");
$row = $statement->fetch(PDO::FETCH_ASSOC);
echo htmlentities($row['some_field']);

PDO will not translate your SQL queries or emulate missing features; it is purely for connecting to multiple types of database with the same API.

More importantly, PDO allows you to safely inject foreign input (e.g. IDs) into your SQL queries without worrying about database SQL injection attacks. This is possible using PDO statements and bound parameters.

Let’s assume a PHP script receives a numeric ID as a query parameter. This ID should be used to fetch a user record from a database. This is the wrong way to do this:

<?php
$pdo = new PDO('sqlite:/path/db/users.db');
$pdo->query("SELECT name FROM users WHERE id = " . $_GET['id']); // <-- NO!

This is terrible code. You are inserting a raw query parameter into a SQL query. This will get you hacked in a heartbeat, using a practice called SQL Injection. Just imagine if a hacker passes in an inventive id parameter by calling a URL like http://domain.com/?id=1%3BDELETE+FROM+users. This will set the $_GET['id'] variable to 1;DELETE FROM users which will delete all of your users! Instead, you should sanitize the ID input using PDO bound parameters.

<?php
$pdo = new PDO('sqlite:/path/db/users.db');
$stmt = $pdo->prepare('SELECT name FROM users WHERE id = :id');
$id = filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT); // <-- filter your data first (see [Data Filtering](#data_filtering)), especially important for INSERT, UPDATE, etc.
$stmt->bindParam(':id', $id, PDO::PARAM_INT); // <-- Automatically sanitized for SQL by PDO
$stmt->execute();

This is correct code. It uses a bound parameter on a PDO statement. This escapes the foreign input ID before it is introduced to the database preventing potential SQL injection attacks.

For writes, such as INSERT or UPDATE, it’s especially critical to still filter your data first and sanitize it for other things (removal of HTML tags, JavaScript, etc). PDO will only sanitize it for SQL, not for your application.

You should also be aware that database connections use up resources and it was not unheard-of to have resources exhausted if connections were not implicitly closed, however this was more common in other languages. Using PDO you can implicitly close the connection by destroying the object by ensuring all remaining references to it are deleted, i.e. set to NULL. If you don’t do this explicitly, PHP will automatically close the connection when your script ends - unless of course you are using persistent connections.

Passwort-Hashing

Früher oder später baut jeder eine PHP-Anwendung, die angemeldete Benutzer benötigt. Benutzernamen und Passwörter werden in einer Datenbank gespeichert und später verwendet, um den Benutzer bei der Anmeldung zu authentifizieren.

Es ist wichtig, Passwörter vor dem Speichern korrekt zu hashen. Passwort-Hashing ist eine nicht umkehrbare Einbahnfunktion, die auf das Passwort des Benutzers angewandt wird. Sie erzeugt einen String mit fester Länge, der nicht mit vertretbarem Aufwand entschlüsselt werden kann. Das bedeutet, dass du einen Hashwert mit einem zweiten vergleichen kannst, um festzustellen, ob beide den selben Quellstring repräsentieren. Du kannst den ursprünglichen String aber nicht mehr wiederherstellen. Wenn Passwörter nicht gehasht werden und die Datenbank in falsche Hände gerät, sind alle Benutzerkonten kompromittiert. Einige Benutzer werden das selbe Passwort auch bei anderen Diensten verwenden. Darum ist es wichtig, Sicherheit ernst zu nehmen.

Passwörter mit password_hash hashen

Mit PHP 5.5 wird die Funktion password_hash eingeführt. Zur Zeit verwendet sie BCrypt, den stärksten aktuell von PHP unterstützten Algorithmus. Zukünftig wird sie aktualisiert werden, um bei Bedarf weitere Algorithmen zu unterstützen. Die Bibliothek password_compat wurde geschaffen, um mit PHP >= 5.3.7 vorwärtskompatibel zu sein.

Unten hashen wir einen String und prüfen anschließend gegen einen neuen String. Wie die beiden Strings unterschiedlich sind (‘secret-password’ gegen ‘bad-password’), wird diese Anmeldung scheitern.

<?php
require 'password.php';

$passwordHash = password_hash('secret-password', PASSWORD_DEFAULT);

if (password_verify('bad-password', $passwordHash)) {
    //Correct Password
} else {
    //Wrong password
}

Daten filtern

Vertraue niemals (niemals!) Eingaben in deinen PHP-Code von außen. Bereinige und validiere externe Eingaben, bevor du sie in deinem Code verwendest. Die Funktionen filter_var und filter_input können Text bereinigen und Textformate wie zum Beispiel E-Mail-Adressen validieren.

Eine Eingabe von außen kann alles mögliche sein: Formulareingaben über $_GET und $_POST, einige Werte im Superglobal $_SERVER und der Inhalt des HTTP-Requests über fopen('php://input', 'r'). Denke daran: Fremdeingaben sind nicht beschränkt auf Formulardaten, die ein Benutzer absendet. Hochgeladene und heruntergeladene Dateien, Sessionwerte, Daten aus Cookies und Daten von dritter Seite wie Webservices sind auch Fremdeingaben.

Während Fremdeingaben gespeichert, kombiniert und später verwendet werden können, bleiben sie noch immer Fremdeingaben. Frage dich jedes Mal, ob die Daten korrekt gefiltert sind, wenn du sie in deinem Code verarbeitest, ausgibst, verbindest oder einbaust.

Daten können - abhängig von der Verwendung - unterschiedlich gefiltert werden. Werden ungefilterte Fremdeingaben in die HTML-Seite eingeschleust, kann HTML und JavaScript auf deiner Site ausgeführt werden. Das nennt man Cross-Site Scripting (XSS), eine sehr gefährliche Angriffsmethode. Eine Methode, um XSS zu vermeiden, ist, alle vom Benutzer erzeugten Daten vor der Ausgabe zu bereinigen. Dazu kannst du entweder alle HTML-Tags mit der Funktion strip_tags entfernen oder Zeichen mit spezieller Bedeutung mit Hilfe der Funktionen htmlentities oder htmlspecialchars in die entsprechenden HTML-Entitäten umwandeln.

Ein weiteres Beispiel ist die unerwünschte Weitergabe von Optionen an die Ausführung über die Befehlszeile. Das kann extrem gefährlich sein und ist ganz allgemein eine schlechte Idee. Du kannst die eingebaute Funktion escapeshellarg verwenden, um die Argumente des ausgeführten Befehls zu bereinigen.

Ein letztes Beispiel ist die Verwendung von Fremdeingaben zur Bestimmung einer Datei, die vom Dateisystem geladen wird. Das kann ausgenutzt werden, um an Stelle eines Dateinamens einen Dateipfad zu erreichen. Du musst “/”, “../”, Null-Bytes und andere Zeichen aus dem Dateipfad entfernen, damit nicht versteckte, private und heikle Dateien geladen werden.

Bereinigung

Mit der Bereinigung entfernt oder entschärft man illegale oder unsichere Zeichen aus Fremdeingaben.

Zum Beispiel solltest du Fremdeingaben bereinigen, bevor du die Eingabe in HTML einbaust oder sie in einer SQL-Abfrage verwendest. Wenn du gebundene Parameter mit PDO verwendest, wird PDO die Eingaben für dich bereinigen.

Manchmal ist es nötig, einige sichere HTML-Tags in der Eingabe zu erlauben. Das ist sehr schwierig und wird oft vermieden. Als Ausweichlösung werden Markdown, Textile oder BBCode verwendet, obwohl Whitelisting-Bibliotheken wie HTML Purifier aus diesem Grund existieren.

Siehe Filter zur Bereinigung

Validierung

Validierung stellt sicher, dass Fremdeingaben den Erwartungen entsprechen. Zum Beispiel kannst du eine E-Mail-Adresse, eine Telefonnummer oder eine Altersangabe validieren, wenn du eine Registrierungsanmeldung verarbeitest.

Siehe Filter zur Validierung

Interacting with Databases

When developers first start to learn PHP, they often end up mixing their database interaction up with their presentation logic, using code that might look like this:

<ul>
<?php
foreach ($db->query('SELECT * FROM table') as $row) {
    echo "<li>".$row['field1']." - ".$row['field1']."</li>";
}
?>
</ul>

This is bad practice for all sorts of reasons, mainly that it’s hard to debug, hard to test, hard to read and it is going to output a lot of fields if you don’t put a limit on there.

While there are many other solutions to doing this - depending on if you prefer OOP or functional programming - there must be some element of separation.

Consider the most basic step:

<?php
function getAllFoos($db) {
    return $db->query('SELECT * FROM table');
}

$results = getAllFoos($db);
foreach ($results as $row) {
    echo "<li>".$row['field1']." - ".$row['field1']."</li>"; // BAD!!
}

That is a good start. Put those two items in two different files and you’ve got some clean separation.

Create a class to place that method in and you have a “Model”. Create a simple .php file to put the presentation logic in and you have a “View”, which is very nearly MVC - a common OOP architecture for most frameworks.

foo.php

<?php
$db = new PDO('mysql:host=localhost;dbname=testdb;charset=utf8mb4', 'username', 'password');

// Make your model available
include 'models/FooModel.php';

// Create an instance
$fooModel = new FooModel($db);
// Get the list of Foos
$fooList = $fooModel->getAllFoos();

// Show the view
include 'views/foo-list.php';

models/FooModel.php

<?php
class FooModel
{
    protected $db;

    public function __construct(PDO $db)
    {
        $this->db = $db;
    }

    public function getAllFoos() {
        return $this->db->query('SELECT * FROM table');
    }
}

views/foo-list.php

<?php foreach ($fooList as $row): ?>
    <li><?= $row['field1'] ?> - <?= $row['field1'] ?></li>
<?php endforeach ?>

This is essentially the same as what most modern frameworks are doing, albeit a little more manual. You might not need to do all of that every time, but mixing together too much presentation logic and database interaction can be a real problem if you ever want to unit-test your application.

PHPBridge has a great resource called Creating a Data Class which covers a very similar topic, and is great for developers just getting used to the concept of interacting with databases.

Abstraction Layers

Many frameworks provide their own abstraction layer which may or may not sit on top of PDO. These will often emulate features for one database system that is missing from another by wrapping your queries in PHP methods, giving you actual database abstraction instead of just the connection abstraction that PDO provides. This will of course add a little overhead, but if you are building a portable application that needs to work with MySQL, PostgreSQL and SQLite then a little overhead will be worth it the sake of code cleanliness.

Some abstraction layers have been built using the PSR-0 or PSR-4 namespace standards so can be installed in any application you like:

Konfigurationsdateien

Wenn du Konfigurationsdateien erstellst, empfiehlt sich als beste Vorgehensweise eine der folgenden Methoden:

Register Globals

ACHTUNG: Seit PHP 5.4.0 wurde die Einstellung register_globals entfernt. Sie kann nicht mehr eingesetzt werden. Dieser Abschnitt ist nur als Warnung für jene gedacht, die eine alte Anwendung aktualisieren wollen.

Die Konfigurationseinstellung register_globals macht einige Typen von Variablen (inklusive denen aus $_POST, $_GET und $_REQUEST) im globalen Sichtbarkeitsbereich benutzbar. Das kann schnell zu Sicherheitsproblemen führen, da die Anwendung die Herkunft der Daten nicht mehr effektiv verfolgen kann.

Zum Beispiel: $_GET['foo'] würde über $foo erreichbar und könnte so Variablen überschreiben, die nicht deklariert wurden. Wenn du PHP < 5.4.0 einsetzt, stelle sicher, dass register_globals off ist.

Fehlermeldungen

Das Aufzeichnen von Fehlern kann helfen, Problembereiche in deiner Anwendung zu finden, es kann aber auch Informationen über die Struktur deiner Anwendung gegenüber der breiten Allgemeinheit enthüllen. Um deine Anwendung effektiv vor Problemen zu schützen, die durch die Ausgabe diese Meldungen entstehen könnten, musst du deinen Produktivserver anders konfigurieren als deinen Entwicklungsserver.

Entwicklung

Um jeden möglichen Fehler während der Entwicklung anzuzeigen, konfiguriere folgende Einstellung in deiner php.ini:

display_errors = On
display_startup_errors = On
error_reporting = -1
log_errors = On

Mit dem Wert -1 wird jeder mögliche Fehler auch in zukünftigen Versionen von PHP angezeigt. Die Konstante E_ALL verhält sich seit PHP 5.4 auch so. - php.net

Der Errorlevel E_STRICT wurde mit PHP 5.3.0 eingeführt und ist nicht Teil von E_ALL, wurde aber Teil von E_ALL in 5.4.0. Was bedeutet das? In Bezug auf Fehlermeldungen musst du in Verion 5.3 entweder -1 oder E_ALL | E_STRICT verwenden.

Jeden Fehler melden je nach PHP-Version

Produktion

Um keinen Fehler im Produktivsystem anzuzeigen, konfiguriere folgende Einstellung in deiner php.ini:

display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL
log_errors = On

Mit diesen Einstellungen im Produktivsystem werden Fehler immer noch in den Error Logs des Webservers eingetragen, aber dem Benutzer nicht angezeigt. Weitere Informationen zu diesen Einstellungen findest du im PHP-Handbuch:

Zurück zum Start{.top}

Templating

Templates provide a convenient way of separating your controller and domain logic from your presentation logic. Templates typically contain the HTML of your application, but may also be used for other formats, such as XML. Templates are often referred to as “views”, which make up part of the second component of the model–view–controller (MVC) software architecture pattern.

Zurück zum Start{.top}

Testen

Als bestes Verfahren gilt das Schreiben von automatisierten Test für deinen PHP-Code, das zu gut konstruierten Anwendungen führen kann. Automatisierte Tests sind ein großartiges Werkzeug, um sicherzustellen, dass deine Anwendung nicht nach Änderungen oder Erweiterungen versagt. Sie sollten nicht ignoriert werden.

Es gibt mehrere verschiedenen Typen von Testwerkzeugen oder Frameworks für PHP, die unterschiedliche Heransgehensweisen einsetzen - alle versuchen aber, manuelle Test und große Qualitätssicherungsteams nur zum Zweck der Fehlerfindung nach Änderungen zu vermeiden.

Benefits

The main benefit to using templates is the clear separation they create between the presentation logic and the rest of your application. Templates have the sole responsibility of displaying formatted content. They are not responsible for data lookup, persistence or other more complex tasks. This leads to cleaner, more readable code which is especially helpful in a team environment where developers work on the server-side code (controllers, models) and designers work on the client-side code (markup).

Templates also improve the organization of presentation code. Templates are typically placed in a “views” folder, each defined within a single file. This approach encourages code reuse where larger blocks of code are broken into smaller, reusable pieces, often called partials. For example, your site header and footer can each be defined as templates, which are then included before and after each page template.

Finally, depending on the library you use, templates can offer more security by automatically escaping user-generated content. Some libraries even offer sand-boxing, where template designers are only given access to white-listed variables and functions.

Testgetriebene Entwicklung

Aus Wikipedia:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence

Du kannst diene Anwendung auf verschiedene Arten testen.

Unit-Tests

Unit-Tests sind ein Entwicklungsansatz, der sicherstellt, dass Funktionen, Klassen und Methoden wie erwartet arbeiten von Beginn der Entwicklung über den ganzen Entwicklungszyklus. Durch die Überprüfung von Werten, die als Ein- und Ausgabe von Funktionen und Methoden fungieren, kannst du die Korrektheit der inneren Logik sicherstellen. Über Dependency Injection, “Attrappen”-Klassen und Funktionsstummel kannst du die Testabdeckung erhöhen und verifizieren, dass Abhängigkeiten korrekt verwendet werden.

Beim Bau einer Klasse oder Funktion solltest du einen Unit-Test für jedes Verhalten schaffen. Zumindest solltest du sicherstellen, dass bei ungültigen Eingabewerten Fehler passieren und die Funktion bei gültigen Argumenten funktioniert. Damit ist sichergestellt, dass alte Funktionalität erhalten bleibt, wenn du diese Klasse später änderst. Die einzige Alternative wäre var_dump() in einer test.php, und so baut man keine Anwendung - ob klein oder groß.

Die andere Anwendung für Unit-Tests ist als Beitrag in einem Open Source Projekt. Wenn du einen Unit-Test schreiben kannst, der zeigt, dass eine Funktionalität fehlerhaft ist und das dann mit durchlaufendem Testergebnis korrigierst, werden Patches wahrscheinlicher akzeptiert. Wenn du ein Projekt betreibst, das Pull Requests akzeptiert, solltest du das als Erfordernis empfehlen.

PHPUnit ist das De-Facto Testframework zum Erstellen von Unit-Tests für PHP, aber es gibt einige Alternativen:

Integrationstests

Aus Wikipedia:

Integration testing (sometimes called Integration and Testing, abbreviated “I&T”) is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Viele der gleichen Werkzeuge für Unit-Tests können auch für Integrationstests verwendet werden, da dieselben Prinzipien verwendet werden.

Funktionaler Test

Funktionale Test oder Akzeptanztest bestehen aus Werkzeugen, mit denen automatisierte Tests erstellt werden können, die deine Anwendung tatsächlich benutzen, anstatt nur das korrekte Verhalten einzelner Codeeinheiten und deren Verständigung untereinander zu verifizieren. Diese Werkzeuge arbeiten typischerweise mit Echtdaten und simulieren tatsächliche Anwender der Applikation.

Funktionale Testwerkzeuge

Verhaltensgetriebe Entwicklung

Es gibt zwei Arten verhaltensgetriebener Entwicklung (Behavior-Driven Development, BDD): SpecBDD und StoryBDD. SpecBDD konzentriert sich auf das technische Verhalten oder Code, während sich StoryBDD auf Geschäfts- oder Eigenschaftenverhalten oder Interaktionen fokussiert. Es gibt Framework für beiden Typen in PHP.

Für StoryBDD schreibt man menschenlesbare Geschichten, die das Verhalten deiner Anwendung beschreiben. Diese Geschichten können als tatsächliche Tests für deine Anwendung geprüft werden. Als Framework für StoryBDD in PHP wird Behat verwendet, das von Rubys Cucumber inspiriert wurde und das Gherkin als DSL zur Beschreibung des Eigenschaftsverhaltens implementiert.

Für SpecBDD schreibst du Spezifikationen, die beschreiben, wie sich dein tatsächlicher Code verhalten soll. Statt eine Funktion oder Methode zu testen wird beschrieben, wie sich diese Funktion oder Methode verhalten soll. PHP bietet für diesen Zweck das Framework PHPSpec, das von RSpec project für Ruby inspiriert wurde.

Plain PHP Templates

Plain PHP templates are simply templates that use native PHP code. They are a natural choice since PHP is actually a template language itself. That simply means that you can combine PHP code within other code, like HTML. This is beneficial to PHP developers as there is no new syntax to learn, they know the functions available to them, and their code editors already have PHP syntax highlighting and auto-completion built-in. Further, plain PHP templates tend to be very fast as no compiling stage is required.

Every modern PHP framework employs some kind of template system, most of which use plain PHP by default. Outside of frameworks, libraries like Plates or Aura.View make working with plain PHP templates easier by offering modern template functionality such as inheritance, layouts and extensions.

Simple example of a plain PHP template

Using the Plates library.

<?php // user_profile.php ?>

<?php $this->insert('header', ['title' => 'User Profile']) ?>

<h1>User Profile</h1>
<p>Hello, <?=$this->escape($name)?></p>

<?php $this->insert('footer') ?>

Example of plain PHP templates using inheritance

Using the Plates library.

<?php // template.php ?>

<html>
<head>
    <title><?=$title?></title>
</head>
<body>

<main>
    <?=$this->section('content')?>
</main>

</body>
</html>
<?php // user_profile.php ?>

<?php $this->layout('template', ['title' => 'User Profile']) ?>

<h1>User Profile</h1>
<p>Hello, <?=$this->escape($name)?></p>

Compiled Templates

While PHP has evolved into a mature, object oriented language, it hasn’t improved much as a templating language. Compiled templates, like Twig, Brainy, or Smarty*, fill this void by offering a new syntax that has been geared specifically to templating. From automatic escaping, to inheritance and simplified control structures, compiled templates are designed to be easier to write, cleaner to read and safer to use. Compiled templates can even be shared across different languages, Mustache being a good example of this. Since these templates must be compiled there is a slight performance hit, however this is very minimal when proper caching is used.

*While Smarty offers automatic escaping, this feature is NOT enabled by default.

Simple example of a compiled template

Using the Twig library.

{% include 'header.html' with {'title': 'User Profile'} %}

<h1>User Profile</h1>
<p>Hello, {{ name }}</p>

{% include 'footer.html' %}

Example of compiled templates using inheritance

Using the Twig library.

// template.html

<html>
<head>
    <title>{% block title %}{% endblock %}</title>
</head>
<body>

<main>
    {% block content %}{% endblock %}
</main>

</body>
</html>
// user_profile.html

{% extends "template.html" %}

{% block title %}User Profile{% endblock %}
{% block content %}
    <h1>User Profile</h1>
    <p>Hello, {{ name }}</p>
{% endblock %}

Ergänzende Textwerkzeuge

Neben individuellen Tests und verhaltensgetriebenen Frameworks gibt es auch eine Anzahl von generischen Frameworks und Hilfsbibliotheken, die für jeden bevorzugten Zugang nützlich sind.

Werkzeuge

Further Reading

Articles & Tutorials

Libraries

Zurück zum Start{.top}

Errors and Exceptions

Errors

In many “exception-heavy” programming languages, whenever anything goes wrong an exception will be thrown. This is certainly a viable way to do things, but PHP is an “exception-light” programming language. While it does have exceptions and more of the core is starting to use them when working with objects, most of PHP itself will try to keep processing regardless of what happens, unless a fatal error occurs.

For example:

$ php -a
php > echo $foo;
Notice: Undefined variable: foo in php shell code on line 1

This is only a notice error, and PHP will happily carry on. This can be confusing for those coming from “exception-heavy” languages, because referencing a missing variable in Python for example will throw an exception:

$ python
>>> print foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'foo' is not defined

The only real difference is that Python will freak out over any small thing, so that developers can be super sure any potential issue or edge-case is caught, whereas PHP will keep on processing unless something extreme happens, at which point it will throw an error and report it.

Error Severity

PHP has several levels of error severity. The three most common types of messages are errors, notices and warnings. These have different levels of severity; E_ERROR, E_NOTICE, and E_WARNING. Errors are fatal run-time errors and are usually caused by faults in your code and need to be fixed as they’ll cause PHP to stop executing. Notices are advisory messages caused by code that may or may not cause problems during the execution of the script, execution is not halted. Warnings are non-fatal errors, execution of the script will not be halted.

Another type of error message reported at compile time are E_STRICT messages. These messages are used to suggest changes to your code to help ensure best interoperability and forward compatibility with upcoming versions of PHP.

Changing PHP’s Error Reporting Behaviour

Error Reporting can be changed by using PHP settings and/or PHP function calls. Using the built in PHP function error_reporting() you can set the level of errors for the duration of the script execution by passing one of the predefined error level constants, meaning if you only want to see Errors and Warnings - but not Notices - then you can configure that:

<?php
error_reporting(E_ERROR | E_WARNING);

You can also control whether or not errors are displayed to the screen (good for development) or hidden, and logged (good for production). For more information on this check out the Error Reporting section.

Inline Error Suppression

You can also tell PHP to suppress specific errors with the Error Control Operator @. You put this operator at the beginning of an expression, and any error that’s a direct result of the expression is silenced.

<?php
echo @$foo['bar'];

This will output $foo['bar'] if it exists, but will simply return a null and print nothing if the variable $foo or 'bar' key does not exist. Without the error control operator, this expression could create a PHP Notice: Undefined variable: foo or PHP Notice: Undefined index: bar error.

This might seem like a good idea, but there are a few undesirable tradeoffs. PHP handles expressions using an @ in a less performant way than expressions without an @. Premature optimization may be the root of all programming arguments, but if performance is particularly important for your application/library it’s important to understand the error control operator’s performance implications.

Secondly, the error control operator completely swallows the error. The error is not displayed, and the error is not sent to the error log. Also, stock/production PHP systems have no way to turn off the error control operator. While you may be correct that the error you’re seeing is harmless, a different, less harmless error will be just as silent.

If there’s a way to avoid the error suppression operator, you should consider it. For example, our code above could be rewritten like this:

<?php
//Null Coalescing Operator
echo $foo['bar'] ?? '';

One instance where error suppression might make sense is where fopen() fails to find a file to load. You could check for the existence of the file before you try to load it, but if the file is deleted after the check and before the fopen() (which might sound impossible, but it can happen) then fopen() will return false and throw an error. This is potentially something PHP should resolve, but is one case where error suppression might seem like the only valid solution.

Earlier we mentioned there’s no way in a stock PHP system to turn off the error control operator. However, Xdebug has an xdebug.scream ini setting which will disable the error control operator. You can set this via your php.ini file with the following.

xdebug.scream = On

You can also set this value at runtime with the ini_set function

<?php
ini_set('xdebug.scream', '1')

The “Scream” PHP extension offers similar functionality to Xdebug’s, although Scream’s ini setting is named scream.enabled.

This is most useful when you’re debugging code and suspect an informative error is suppressed. Use scream with care, and as a temporary debugging tool. There’s lots of PHP library code that may not work with the error control operator disabled.

ErrorException

PHP is perfectly capable of being an “exception-heavy” programming language, and only requires a few lines of code to make the switch. Basically you can throw your “errors” as “exceptions” using the ErrorException class, which extends the Exception class.

This is a common practice implemented by a large number of modern frameworks such as Symfony and Laravel. In debug mode (or dev mode) both of these frameworks will display a nice and clean stack trace.

There are also some packages available for better error and exception handling and reporting. Like Whoops!, which comes with the default installation of Laravel and can be used in any framework as well.

By throwing errors as exceptions in development you can handle them better than the usual result, and if you see an exception during development you can wrap it in a catch statement with specific instructions on how to handle the situation. Each exception you catch instantly makes your application that little bit more robust.

More information on this and details on how to use ErrorException with error handling can be found at ErrorException Class.

Platform as a Service (PaaS)

PaaS stellt das System und die Netzwerkarchitektur für PHP-Anwendungen im Web bereit. Das bedeutet keine oder geringe Konfiguration zum Start von PHP-Anwendungen oder PHP-Frameworks.

In letzter Zeit wurde PaaS zu einer beliebten Methode für die Ausrollung, das Hosting und die Skalierung von PHP-Anwendungen aller Größen. Du kannst eine Liste von Anbietern für PHP-PaaS “Platform as a Service” in unserem Abschnitt Ressourcen finden.

Exceptions

Exceptions sind ein Standardbestandteil moderner populärer Programmiersprachen, werden aber oft von PHP-Programmierern übersehen. Sprachen wie Ruby legen viel Gewicht auf Exceptions, so dass viele Fehler wie etwa ein erfolgloser HTTP-Request, eine falsche Datenbankabfrage oder eine fehlende Grafikdatei die Anzeige von Exceptions am Bildschirm auslösen und so auf Fehler hinweisen.

PHP selbst ist relative nachlässig, so dass ein file_get_contents() üblicherweise nur zu einem FALSE und einer Warnung führt. Viele ältere Frameworks wie CodeIgniter geben auch nur FALSE zurück, scheiben eine Nachricht in ihr Fehlerlog und erlauben dir den Aufruf einer Methode wie $this->upload->get_error(), um die Ursache des Fehlers zu finden. Das Problem dabei ist, dass du nach dem Fehler fragen und in der Dokumentation nach der Fehlermethode für diese Klasse suchen musst, statt es äußerst offensichtlich zu machen.

Ein weiteres Problem besteht, wenn Klassen automatisch Fehler auslösen und den Prozess beenden. Wenn du so vorgehst, hinderst du andere Entwickler daran, Fehler dynamisch zu behandeln. Exceptions sollten ausgelöst werden, um Entwickler auf Fehler hinzuweisen und ihnen Gelegenheit zu geben, darauf zu reagieren. Ein Beispiel:

<?php
$email = new Fuel\Email;
$email->subject('My Subject');
$email->body('How the heck are you?');
$email->to('guy@example.com', 'Some Guy');

try
{
    $email->send();
}
catch(Fuel\Email\ValidationFailedException $e)
{
    // The validation failed
}
catch(Fuel\Email\SendingFailedException $e)
{
    // The driver could not send the email
}
finally
{
    // Executed regardless of whether an exception has been thrown, and before normal execution resumes
}

SPL Exceptions

Die generische Klasse Exception enthält sehr wenig Kontext für das Debugging durch den Entwickler. Zur Erleichterung kann man über eine Unterklassen der generischen Klasse Exception einen spezialisierten Exception-Typ schaffen:

<?php
class ValidationException extends Exception {}

So kannst du mehrere Catch-Blöcke einrichten und unterschiedliche Exception auch unterschiedlich behandeln. Das kan zu einer Vielzahl von benutzerdefinierten Exceptions führen, von denen einige durch den Einsatz von SPl Exceptions aus der SPL-Erweiterung vermeidbar sind.

Zum Beispiel könnte die magische Methode __call() beim Aufruf einer ungültigen Methode throw new BadFunctionCallException; aufrufen, statt die Standard-Exception oder eine benutzerdefinierte Exception auszulösen.

Virtuelle oder dedizierte Server

Wenn du mit der Systemadministration vertraut bist oder ein Interesse hast, das zu lernen, erhältst du bei virtuellen oder dedizierten Servern die volle Kontrolle über die Produktivumgebung deiner Anwendung.

nginx und PHP-FPM

Über den eingebauten FastCGI Process Manager (FPM) passt PHP sehr gut zu nginx, einem schlanken leistungsstarken Webserver. Nginx benötigt weniger Speicher als Apache und kann mehr gleichzeitige Zugriffe besser bearbeiten. Das ist speziell bei virtuellen Servern mit wenig Speicher wichtig.

Apache und PHP

PHP und Apache haben eine lange gemeinsame Geschichte. Apache ist flexibel konfigurierbar und besitzt viele Module zur Funktionserweiterung. Apache ist eine beliebte Wahl für billiges Shared Hosting und eine einfache Basis für PHP-Frameworks und Open-Source-Anwendungen wie Textpattern CMS. Unglücklicherweise benötigt Apache mehr Ressourcen als nginx und kann nicht so viele Besucher gleichzeitig bedienen.

Apache hat einige Möglichkeiten, um PHP zu starten. Die geläufigste und einfachste ist das Prefork MPM mit mod_php5. Zwar ist es nicht die effizienteste, aber die einfachste Methode der Installation und des Betriebs. Es ist wahrscheinlich die beste Wahl wenn du nicht zu tief in die Serveradministration einsteigen möchtest. Beachte, dass mod_php das Prefork MPM erfordert.

Alternativ kannst du für mehr Leistung und Stabilität dasselbe FPM-System wie nginx einsetzen und das Worker MPM oder das Event MPM mit mod_fastcgi oder mod_fcgid verwenden. Diese Konfiguration wird signifikant effizienter mit dem Speicher umgehen und schneller sein, aber mehr Arbeit bei der Installation machen.

Shared Hosting

PHP verdankt Shared Hosting seine Popularität. Man findet kaum einen Host ohne installiertes PHP, aber achte darauf, dass es die aktuelle Version ist.

Bei Shared Hosting starten du und andere Entwickler ihre Anwendungen auf einer einzigen Maschine. Der Vorteil ist, dass Shared Hosting zu einer billigen Massenware wurde. Der Nachteil ist, dass du nie weißt, welche Art von Krawall deine Mitbewohner anrichten; Überlast auf dem Server oder offenen Sicherheitslücken sind die Hauptargumente gegen Shared Hosting. Wenn es dein Budget erlaubt, solltest du Shared Hosting meiden.

Baue und verteile deine Anwendung

Wenn du das Datenbankschema manuell änderst oder deine Tests manuell startest, bevor du deine Dateien (manuell) aktualisierst, denke noch mal nach! Mit jeder manuellen Aufgabe, die man für die Ausrollung einer neuen Version deiner Anwendung benötigt, steigen die Chancen für potentiell fatale Fehler. Ob es um ein einfaches Update, einen umfassenden Build-Prozess oder sogar um eine kontinuierliche Integrationsstrategie geht, Build-Automation ist dein Freund.

Unter den Aufgaben, die du automatisieren kannst, sind etwa:

Werkzeuge für die Build Automation

Build-Werkzeuge kann man als Sammlung von Scripts beschreiben, die übliche Aufgaben der Softwareentwicklung bearbeiten. Das Build-Werkzeug ist nicht Teil deiner Software, sonder es wirkt “von außen”.

Es gibt viele Open-Source-Werkzeuge, die dir bei der Build Automation helfen. Manche davon sind in PHP geschrieben, andre nicht. Das solte dich nicht von ihrem Einsatz abhalten, wenn sie besser für einen bestimmten Job geeignet sind. Hier sind ein paar Beispiele:

Phing ist der einfachste Weg, mit automatisierter Ausrollung in der PHP-Welt zu beginnen. Mit Phing kannst du das Verpacken, Ausrollen oder Testen von einer einfachen XML-Datei aus steuern. Phing, das auf Apache Ant basiert, bietet eine umfangreiche Menge von Aufgaben, die üblicherweise benötigt werden, um Webanwendungen zu installieren oder zu aktualisieren, und kann mit zusätzlichen in PHP geschriebenen Aufgaben erweitert werden.

Capistrano ist ein System für Programmierer mit mittleren oder fortgeschrittenen Kenntnissen, um Befehle in einer strukturierten, wiederholbaren Art und Weise auf einer oder mehrerer Maschinen durchzuführen. Es ist für die Ausrollung von Anwendungen in Ruby on Rails vorkonfiguriert, es werden aber auch erfolgreich PHP-Systeme damit ausgerollt. Der erfolgreiche Einsatz von Capistrano hängt von brauchbaren Kenntnissen in Ruby und Rake ab.

Dave Gardners Blogbeitrag PHP Deployment with Capistrano ist ein guter Startpunkt für PHP-Programmierer, die sich für Capistrano interessieren.

Chef ist mehr als ein Framework für das Ausrollen - ein sehr mächtiges Integrationsframework auf Ruby-Basis, das deine Anwendung nicht nur ausrollt, sondern den gesamten Server oder virtuelle Maschinen baut.

Ressourcen zu Chef für PHP-Entwickler:

Weiterführende Literatur:

Kontinuierliche Integration

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

– Martin Fowler

Es gibt verschiedene Arten, um kontinuierliche Integration für PHP zu implementieren. In letzter Zeit hat Travis CI einen großen Beitrag dazu geleistet, kontinuierliche Integration auch für kleine Projekte Realität werden zu lassen. Travis CI ist eine gehostete Lösung für die Open-Source-Community. Es ist in Github integriert und bietet erstklassige Unterstützung für viele Sprachen inklusive PHP.

Weiterführende Literatur:

Zurück zum Start{.top}

Security

The best resource I’ve found on PHP security is The 2018 Guide to Building Secure PHP Software by Paragon Initiative.

Bytecode-Cache

Wenn eine PHP-Datei ausgeführt wird, wird sie im Hintergrund zuerst in Bytecode (auch Opcode genannt) kompiliert und dieser Bytecode anschließend ausgeführt. Solange die PHP-Datei nicht verändert wurde, bleibt dieser Bytecode gleich. Das heißt, dass der Kompilierungsschritt eine Verschwendung von CPU-Ressourcen ist.

Hier kommt der Bytecode-Cache ins Spiel. Er verhindert die redundante Kompilierung durch das Speichern von Bytecode im Hauptspeicher und ermöglicht die Wiederverwendung bei nachfolgenden Aufrufen. Der Bytecode-Cache ist innerhalb weniger Minuten einzurichten und wird deine Anwendung signifikant beschleunigen. Es gibt wirklich keinen Grund, ihn nicht einzusetzen.

Beliebte Bytecode-Caches sind:

Web Application Security

It is very important for every PHP developer to learn the basics of web application security, which can be broken down into a handful of broad topics:

  1. Code-data separation.
    • When data is executed as code, you get SQL Injection, Cross-Site Scripting, Local/Remote File Inclusion, etc.
    • When code is printed as data, you get information leaks (source code disclosure or, in the case of C programs, enough information to bypass ASLR).
  2. Application logic.
    • Missing authentication or authorization controls.
    • Input validation.
  3. Operating environment.
    • PHP versions.
    • Third party libraries.
    • The operating system.
  4. Cryptography weaknesses.

There are bad people ready and willing to exploit your web application. It is important that you take necessary precautions to harden your web application’s security. Luckily, the fine folks at The Open Web Application Security Project (OWASP) have compiled a comprehensive list of known security issues and methods to protect yourself against them. This is a must read for the security-conscious developer. Survive The Deep End: PHP Security by Padraic Brady is also another good web application security guide for PHP.

Objektcache

Manchmal ist es vorteilhaft, einzelne Objekte in deinem Code zu cachen wie etwa Daten, die nur mit hohem Aufwand zu erhalten sind, oder Datenbankzugriffe, deren Ergebnis sich wahrscheinlich nicht ändert. Du kannst Objektcache-Software verwenden, um diese Teile von Daten im Speicher zu halten und extrem schnell später darauf zuzugreifen. Wenn du diese Elemente in einem Datenspeicher sicherst, nachdem du sie abgerufen hast, und anschließend für nachfolgende Anfragen direkt aus dem Cache holst, kannst du wesentliche Geschwindigkeitsverbesserungen erreichen und die Last der Datenbankserver vermindern.

Viele beliebte Lösungen für Bytecode-Caches erlauben dir auch, eigene Daten zu cachen, was noch ein zusätzlicher Grund ist, diese zu deinem Vorteil zu nutzen. APC, XCache und WinCache bieten APIs, um Daten aus deinem PHP-Code in ihren Cachespeicher zu sichern.

Die meist verbreiteten Systeme für speicherbasierende Objektcaches sind APC und memcached. APC ist eine exzellente Wahl für Objektcaches; es beinhaltet ein einfaches API, das an den Server gebunden ist, auf dem es installiert ist. Memcached andererseits wird als getrennter Dienst installiert und kann über das Netzwerk angesprochen werden; das bedeutet, dass du Objekte in einem schnellen Datenspeicher ablegen und von vielen verschiedenen Systemen abrufen kannst.

Beachte: Wenn PHP als (Fast-)CGI-Anwendung deines Webserver läuft, besitzt jeder PHP-Prozess seinen eigenen Cache. Das heißt, dass die APC-Daten nicht zwischen den Arbeitsprozessen geteilt werden. In diesen Fällen könnte man den Einsatz von memcached überlegen, da dieser nicht an PHP-Prozesse gebunden ist.

In einer Netzwerk-Konfiguration wird APC im Regelfall schneller sein als memcached, während memcached weiter und schneller skaliert. Wen du nicht planst, deine Anwendung auf mehrere Server zu verteilen oder die zusätzlichen Eigenschaften von memcached nicht benötigst, ist APC wahrscheinlich die beste Wahl als Objektcache.

Beispiellogik für APC:

<?php
// check if there is data saved as 'expensive_data' in cache
$data = apc_fetch('expensive_data');
if ($data === false) {
    // data is not in cache; save result of expensive call for later use
    apc_add('expensive_data', $data = get_expensive_data());
}

print_r($data);

Mehr über populäre Objektcaching-Systeme:

Password Hashing

Eventually everyone builds a PHP application that relies on user login. Usernames and passwords are stored in a database and later used to authenticate users upon login.

It is important that you properly hash passwords before storing them. Hashing and encrypting are two very different things that often get confused.

Hashing is an irreversible, one-way function. This produces a fixed-length string that cannot be feasibly reversed. This means you can compare a hash against another to determine if they both came from the same source string, but you cannot determine the original string. If passwords are not hashed and your database is accessed by an unauthorized third-party, all user accounts are now compromised.

Unlike hashing, encryption is reversible (provided you have the key). Encryption is useful in other areas, but is a poor strategy for securely storing passwords.

Passwords should also be individually salted by adding a random string to each password before hashing. This prevents dictionary attacks and the use of “rainbow tables” (a reverse list of crytographic hashes for common passwords.)

Hashing and salting are vital as often users use the same password for multiple services and password quality can be poor.

Additionally, you should use a specialized password hashing algorithm rather than fast, general-purpose cryptographic hash function (e.g. SHA256). The short list of acceptable password hashing algorithms (as of June 2018) to use are:

Fortunately, nowadays PHP makes this easy.

Hashing passwords with password_hash

In PHP 5.5 password_hash() was introduced. At this time it is using BCrypt, the strongest algorithm currently supported by PHP. It will be updated in the future to support more algorithms as needed though. The password_compat library was created to provide forward compatibility for PHP >= 5.3.7.

Below we hash a string, and then check the hash against a new string. Because our two source strings are different (‘secret-password’ vs. ‘bad-password’) this login will fail.

<?php
require 'password.php';

$passwordHash = password_hash('secret-password', PASSWORD_DEFAULT);

if (password_verify('bad-password', $passwordHash)) {
    // Correct Password
} else {
    // Wrong password
}

password_hash() takes care of password salting for you. The salt is stored, along with the algorithm and “cost”, as part of the hash. password_verify() extracts this to determine how to check the password, so you don’t need a separate database field to store your salts.

Data Filtering

Never ever (ever) trust foreign input introduced to your PHP code. Always sanitize and validate foreign input before using it in code. The filter_var() and filter_input() functions can sanitize text and validate text formats (e.g. email addresses).

Foreign input can be anything: $_GET and $_POST form input data, some values in the $_SERVER superglobal, and the HTTP request body via fopen('php://input', 'r'). Remember, foreign input is not limited to form data submitted by the user. Uploaded and downloaded files, session values, cookie data, and data from third-party web services are foreign input, too.

While foreign data can be stored, combined, and accessed later, it is still foreign input. Every time you process, output, concatenate, or include data in your code, ask yourself if the data is filtered properly and can it be trusted.

Data may be filtered differently based on its purpose. For example, when unfiltered foreign input is passed into HTML page output, it can execute HTML and JavaScript on your site! This is known as Cross-Site Scripting (XSS) and can be a very dangerous attack. One way to avoid XSS is to sanitize all user-generated data before outputting it to your page by removing HTML tags with the strip_tags() function or escaping characters with special meaning into their respective HTML entities with the htmlentities() or htmlspecialchars() functions.

Another example is passing options to be executed on the command line. This can be extremely dangerous (and is usually a bad idea), but you can use the built-in escapeshellarg() function to sanitize the executed command’s arguments.

One last example is accepting foreign input to determine a file to load from the filesystem. This can be exploited by changing the filename to a file path. You need to remove "/", "../", null bytes, or other characters from the file path so it can’t load hidden, non-public, or sensitive files.

Sanitization

Sanitization removes (or escapes) illegal or unsafe characters from foreign input.

For example, you should sanitize foreign input before including the input in HTML or inserting it into a raw SQL query. When you use bound parameters with PDO, it will sanitize the input for you.

Sometimes it is required to allow some safe HTML tags in the input when including it in the HTML page. This is very hard to do and many avoid it by using other more restricted formatting like Markdown or BBCode, although whitelisting libraries like HTML Purifier exists for this reason.

See Sanitization Filters

Unserialization

It is dangerous to unserialize() data from users or other untrusted sources. Doing so can allow malicious users to instantiate objects (with user-defined properties) whose destructors will be executed, even if the objects themselves aren’t used. You should therefore avoid unserializing untrusted data.

If you absolutely must unserialize data from untrusted sources, use PHP 7’s allowed_classes option to restrict which object types are allowed to be unserialized.

Validation

Validation ensures that foreign input is what you expect. For example, you may want to validate an email address, a phone number, or age when processing a registration submission.

See Validation Filters

Configuration Files

When creating configuration files for your applications, best practices recommend that one of the following methods be followed:

Register Globals

NOTE: As of PHP 5.4.0 the register_globals setting has been removed and can no longer be used. This is only included as a warning for anyone in the process of upgrading a legacy application.

When enabled, the register_globals configuration setting makes several types of variables (including ones from $_POST, $_GET and $_REQUEST) available in the global scope of your application. This can easily lead to security issues as your application cannot effectively tell where the data is coming from.

For example: $_GET['foo'] would be available via $foo, which can override variables that have been declared.

If you are using PHP < 5.4.0 make sure that register_globals is off.

Error Reporting

Error logging can be useful in finding the problem spots in your application, but it can also expose information about the structure of your application to the outside world. To effectively protect your application from issues that could be caused by the output of these messages, you need to configure your server differently in development versus production (live).

Development

To show every possible error during development, configure the following settings in your php.ini:

display_errors = On
display_startup_errors = On
error_reporting = -1
log_errors = On

Passing in the value -1 will show every possible error, even when new levels and constants are added in future PHP versions. The E_ALL constant also behaves this way as of PHP 5.4. - php.net

The E_STRICT error level constant was introduced in 5.3.0 and is not part of E_ALL, however it became part of E_ALL in 5.4.0. What does this mean? In terms of reporting every possible error in version 5.3 it means you must use either -1 or E_ALL | E_STRICT.

Reporting every possible error by PHP version

Production

To hide errors on your production environment, configure your php.ini as:

display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL
log_errors = On

With these settings in production, errors will still be logged to the error logs for the web server, but will not be shown to the user. For more information on these settings, see the PHP manual:

Zurück zum Start{.top}

Ressourcen

Von der Quelle

Folgenswerte Menschen

Beratung

Anbieter für PHP PaaS

Zurück zum Start{.top}

Testing

Writing automated tests for your PHP code is considered a best practice and can lead to well-built applications. Automated tests are a great tool for making sure your application does not break when you are making changes or adding new functionality and should not be ignored.

There are several different types of testing tools (or frameworks) available for PHP, which use different approaches - all of which are trying to avoid manual testing and the need for large Quality Assurance teams, just to make sure recent changes didn’t break existing functionality.

Frameworks

Viele PHP-Entwickler verwenden Frameworks beim Bau von Webanwendungen, statt das Rad neu zu erfinden. Frameworks abstrahieren viele der grundlegenden Anliegen und bieten hilfreiche, einfach verwendbare Schnittstellen, um übliche Aufgaben zu erfüllen.

Du brauchst nicht für jedes Projekt ein Framework. Manchmal ist gewöhnliches PHP die richtige Art der Lösung, aber wenn du ein Framework benötigst, dann findest du drei typische Arten:

Micro-Frameworks sind im wesentlichen eine Hülle, um einen HTTP-Request möglichst schnell an einen Callback, einen Controller oder eine Methode weiterzuleiten, und werden manchmal von Bibliotheken wie etwa Datenbankhüllen und Ähnlichem begleitet. Sie werden typischerweise eingesetzt, um Remote-HTTP-Dienste zu bauen.

Viele Frameworks fügen eine beträchtliche Anzahl von Fähigkeiten zu dem hinzu, was ein Micro-Framework bietet. Diese nennt man “Vollständige Frameworks”. Sie enthalten oft ORMs, Pakte zur Authentifizierung etc.

Komponentenbasierende Frameworks sind Sammlungen von spezialisierten Bibliotheken für einen genau definierten Zweck. Verschiedene komponentenbasierende Frameworks können miteinander eingesetzt werden, um ein Micro- oder vollständiges Framework zu bilden.

Test Driven Development

From Wikipedia:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

There are several different types of testing that you can do for your application:

Unit Testing

Unit Testing is a programming approach to ensure functions, classes and methods are working as expected, from the point you build them all the way through the development cycle. By checking values going in and out of various functions and methods, you can make sure the internal logic is working correctly. By using Dependency Injection and building “mock” classes and stubs you can verify that dependencies are correctly used for even better test coverage.

When you create a class or function you should create a unit test for each behavior it must have. At a very basic level you should make sure it errors if you send it bad arguments and make sure it works if you send it valid arguments. This will help ensure that when you make changes to this class or function later on in the development cycle that the old functionality continues to work as expected. The only alternative to this would be var_dump() in a test.php, which is no way to build an application - large or small.

The other use for unit tests is contributing to open source. If you can write a test that shows broken functionality (i.e. fails), then fix it, and show the test passing, patches are much more likely to be accepted. If you run a project which accepts pull requests then you should suggest this as a requirement.

PHPUnit is the de-facto testing framework for writing unit tests for PHP applications, but there are several alternatives

Integration Testing

From Wikipedia:

Integration testing (sometimes called Integration and Testing, abbreviated “I&T”) is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Many of the same tools that can be used for unit testing can be used for integration testing as many of the same principles are used.

Functional Testing

Sometimes also known as acceptance testing, functional testing consists of using tools to create automated tests that actually use your application instead of just verifying that individual units of code are behaving correctly and that individual units can speak to each other correctly. These tools typically work using real data and simulating actual users of the application.

Functional Testing Tools

Behavior Driven Development

There are two different types of Behavior-Driven Development (BDD): SpecBDD and StoryBDD. SpecBDD focuses on technical behavior of code, while StoryBDD focuses on business or feature behaviors or interactions. PHP has frameworks for both types of BDD.

With StoryBDD, you write human-readable stories that describe the behavior of your application. These stories can then be run as actual tests against your application. The framework used in PHP applications for StoryBDD is Behat, which is inspired by Ruby’s Cucumber project and implements the Gherkin DSL for describing feature behavior.

With SpecBDD, you write specifications that describe how your actual code should behave. Instead of testing a function or method, you are describing how that function or method should behave. PHP offers the PHPSpec framework for this purpose. This framework is inspired by the RSpec project for Ruby.

Komponenten

Wie bereits erwähnt sind “Komponenten” ein weiterer Ansatz, um mehrfach verwendbaren Code zu erstellen, zu verteilen und zu implementieren. Es gibt mehrere Komponentenverzeichnisse, von denen die wichtigsten diese sind:

Diese beiden Verzeichnisse haben zugehörige Werkzeuge für die Befehlszeile, um beim Installations- und Aktualisierungsvorgang zu helfen, und wurden detaillierter im Abschnitt Verwaltung von Abhängigkeiten behandelt.

Es gibt auch komponentenbasierte Frameworks, die den Einsatz ihrer Komponenten mit minimalem oder keinen Voraussetzungen erlauben. Zum Beispiel kannst du das Paket FuelPHP Validation unabhängig vom gesamtem Framework FuelPHP einsetzen. Diese Projekte sind im Wesentlichen nur ein weiteres Verzeichnis von wiederverwendbaren Komponenten:

Complementary Testing Tools

Besides individual testing and behavior driven frameworks, there are also a number of generic frameworks and helper libraries useful for any preferred approach taken.

Zurück zum Start{.top}

Community

Die PHP-Community ist so vielfältig wie zahlreich, und ihre Mitglieder unterstützen Anfänger gerne. Vieleicht möchtest du einer örtlichen PHP-Anwendergruppe (PHP User Group, PUG) beitreten oder größere PHP-Konferenzen besuchen, um mehr über die besten Methoden zu lernen, die hier gezeigt werden. Du kannst dich mit Gleichgesinnten im Channel #phpc auf irc.freenode.com über IRC treffen oder @phpc auf Twitter folgen. Gehe raus, triff neue Entwickler, lernen neue Themen und schließe neue Freundschaften. Weitere Community-Ressourcen sind die Community der PHP-Entwickler auf Google+ und StackOverflow.

Lies den offiziellen PHP-Events-Kalendar

PHP-Anwendergruppen

Wenn du in einer größeren Stadt lebst, bestehen gute Chancen, dass es eine PHP-Anwendergruppe in der Nähe gibt. Obwohl es keien offizeille Liste der PHP-Anwendergruppen, kannst du die nächstgelegene PHP-Anwendergruppe einfach über eine Suche bei Google oder Meetup.com finden. Wenn du in einer kleineren Stadt lebst, gibt es vielleicht noch keine lokale PUG; wenn das so ist, gründe eine!

Mehr über Anwendergruppen im PHP-Wiki

PHP-Konferenzen

Die PHP-Community veranstaltet auch größere regionale und nationale Konferenzen in vielen Ländern rund um die Welt. Bekannte Mitglieder der PHP-Community halten oft Vorträge auf diesen größeren Veranstaltungen, so dass diese eine großartige Möglichkeit sind, direkt von führenden Köpfen zu lernen.

Finde eine PHP-Konferenz

Zurück zum Start{.top}

Servers and Deployment

Server und Ausrollung

PHP-Anwendungen können auf verschiedene Arten auf Server ausgerollt und betrieben werden.

Platform as a Service (PaaS)

PaaS provides the system and network architecture necessary to run PHP applications on the web. This means little to no configuration for launching PHP applications or PHP frameworks.

Recently PaaS has become a popular method for deploying, hosting, and scaling PHP applications of all sizes. You can find a list of PHP PaaS “Platform as a Service” providers in our resources section.

Virtual or Dedicated Servers

If you are comfortable with systems administration, or are interested in learning it, virtual or dedicated servers give you complete control of your application’s production environment.

nginx and PHP-FPM

PHP, via PHP’s built-in FastCGI Process Manager (FPM), pairs really nicely with nginx, which is a lightweight, high-performance web server. It uses less memory than Apache and can better handle more concurrent requests. This is especially important on virtual servers that don’t have much memory to spare.

Apache and PHP

PHP and Apache have a long history together. Apache is wildly configurable and has many available modules to extend functionality. It is a popular choice for shared servers and an easy setup for PHP frameworks and open source apps like WordPress. Unfortunately, Apache uses more resources than nginx by default and cannot handle as many visitors at the same time.

Apache has several possible configurations for running PHP. The most common and easiest to setup is the prefork MPM with mod_php5. While it isn’t the most memory efficient, it is the simplest to get working and to use. This is probably the best choice if you don’t want to dig too deeply into the server administration aspects. Note that if you use mod_php5 you MUST use the prefork MPM.

Alternatively, if you want to squeeze more performance and stability out of Apache then you can take advantage of the same FPM system as nginx and run the worker MPM or event MPM with mod_fastcgi or mod_fcgid. This configuration will be significantly more memory efficient and much faster but it is more work to set up.

If you are running Apache 2.4 or later, you can use mod_proxy_fcgi to get great performance that is easy to setup.

Shared Servers

PHP has shared servers to thank for its popularity. It is hard to find a host without PHP installed, but be sure it’s the latest version. Shared servers allow you and other developers to deploy websites to a single machine. The upside to this is that it has become a cheap commodity. The downside is that you never know what kind of a ruckus your neighboring tenants are going to create; loading down the server or opening up security holes are the main concerns. If your project’s budget can afford to avoid shared servers, you should.

To make sure your shared servers are offering the latest versions of PHP, check out PHP Versions.

Building and Deploying your Application

If you find yourself doing manual database schema changes or running your tests manually before updating your files (manually), think twice! With every additional manual task needed to deploy a new version of your app, the chances for potentially fatal mistakes increase. Whether you’re dealing with a simple update, a comprehensive build process or even a continuous integration strategy, build automation is your friend.

Among the tasks you might want to automate are:

Deployment Tools

Deployment tools can be described as a collection of scripts that handle common tasks of software deployment. The deployment tool is not a part of your software, it acts on your software from ‘outside’.

There are many open source tools available to help you with build automation and deployment, some are written in PHP others aren’t. This shouldn’t hold you back from using them, if they’re better suited for the specific job. Here are a few examples:

Phing can control your packaging, deployment or testing process from within a XML build file. Phing (which is based on Apache Ant) provides a rich set of tasks usually needed to install or update a web application and can be extended with additional custom tasks, written in PHP. It’s a solid and robust tool and has been around for a long time, however the tool could be perceived as a bit old fashioned because of the way it deals with configuration (XML files).

Capistrano is a system for intermediate-to-advanced programmers to execute commands in a structured, repeatable way on one or more remote machines. It is pre-configured for deploying Ruby on Rails applications, however you can successfully deploy PHP systems with it. Successful use of Capistrano depends on a working knowledge of Ruby and Rake.

Ansistrano is a couple of Ansible roles to easily manage the deployment process (deploy and rollback) for scripting applications such as PHP, Python and Ruby. It’s an Ansible port for Capistrano. It’s been used by quite a lot of PHP companies already.

Rocketeer gets its inspiration and philosophy from the Laravel framework. Its goal is to be fast, elegant and easy to use with smart defaults. It features multiple servers, multiple stages, atomic deploys and deployment can be performed in parallel. Everything in the tool can be hot swapped or extended, and everything is written in PHP.

Deployer is a deployment tool written in PHP. It’s simple and functional. Features include running tasks in parallel, atomic deployment and keeping consistency between servers. Recipes of common tasks for Symfony, Laravel, Zend Framework and Yii are available. Younes Rafie’s article Easy Deployment of PHP Applications with Deployer is a great tutorial for deploying your application with the tool.

Magallanes is another tool written in PHP with simple configuration done in YAML files. It has support for multiple servers and environments, atomic deployment, and has some built in tasks that you can leverage for common tools and frameworks.

Further reading:

Server Provisioning

Managing and configuring servers can be a daunting task when faced with many servers. There are tools for dealing with this so you can automate your infrastructure to make sure you have the right servers and that they’re configured properly. They often integrate with the larger cloud hosting providers (Amazon Web Services, Heroku, DigitalOcean, etc) for managing instances, which makes scaling an application a lot easier.

Ansible is a tool that manages your infrastructure through YAML files. It’s simple to get started with and can manage complex and large scale applications. There is an API for managing cloud instances and it can manage them through a dynamic inventory using certain tools.

Puppet is a tool that has its own language and file types for managing servers and configurations. It can be used in a master/client setup or it can be used in a “master-less” mode. In the master/client mode the clients will poll the central master(s) for new configuration on set intervals and update itself if necessary. In the master-less mode you can push changes to your nodes.

Chef is a powerful Ruby based system integration framework that you can build your whole server environment or virtual boxes with. It integrates well with Amazon Web Services through their service called OpsWorks.

Further reading:

Continuous Integration

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

– Martin Fowler

There are different ways to implement continuous integration for PHP. Travis CI has done a great job of making continuous integration a reality even for small projects. Travis CI is a hosted continuous integration service for the open source community. It is integrated with GitHub and offers first class support for many languages including PHP.

Further reading:

Zurück zum Start{.top}

Virtualization

Running your application on different environments in development and production can lead to strange bugs popping up when you go live. It’s also tricky to keep different development environments up to date with the same version for all libraries used when working with a team of developers.

If you are developing on Windows and deploying to Linux (or anything non-Windows) or are developing in a team, you should consider using a virtual machine. This sounds tricky, but besides the widely known virtualization environments like VMware or VirtualBox, there are additional tools that may help you setting up a virtual environment in a few easy steps.

Vagrant

Vagrant helps you build your virtual boxes on top of the known virtual environments and will configure these environments based on a single configuration file. These boxes can be set up manually, or you can use “provisioning” software such as Puppet or Chef to do this for you. Provisioning the base box is a great way to ensure that multiple boxes are set up in an identical fashion and removes the need for you to maintain complicated “set up” command lists. You can also “destroy” your base box and recreate it without many manual steps, making it easy to create a “fresh” installation.

Vagrant creates folders for sharing your code between your host and your virtual machine, which means that you can create and edit your files on your host machine and then run the code inside your virtual machine.

A little help

If you need a little help to start using Vagrant there are some services that might be useful:

Docker

Docker - a lightweight alternative to a full virtual machine - is so called because it’s all about “containers”. A container is a building block which, in the simplest case, does one specific job, e.g. running a web server. An “image” is the package you use to build the container - Docker has a repository full of them.

A typical LAMP application might have three containers: a web server, a PHP-FPM process and MySQL. As with shared folders in Vagrant, you can leave your application files where they are and tell Docker where to find them.

You can generate containers from the command line (see example below) or, for ease of maintenance, build a docker-compose.yml file for your project specifying which to create and how they communicate with one another.

Docker may help if you’re developing multiple websites and want the separation that comes from installing each on it’s own virtual machine, but don’t have the necessary disk space or the time to keep everything up to date. It’s efficient: the installation and downloads are quicker, you only need to store one copy of each image however often it’s used, containers need less RAM and share the same OS kernel, so you can have more servers running simultaneously, and it takes a matter of seconds to stop and start them, no need to wait for a full server boot.

Example: Running your PHP Applications in Docker

After installing docker on your machine, you can start a web server with one command. The following will download a fully functional Apache installation with the latest PHP version, map /path/to/your/php/files to the document root, which you can view at http://localhost:8080:

docker run -d --name my-php-webserver -p 8080:80 -v /path/to/your/php/files:/var/www/html/ php:apache

This will initialize and launch your container. -d makes it runs in the background. To stop and start it, simply run docker stop my-php-webserver and docker start my-php-webserver (the other parameters are not needed again).

Learn more about Docker

The command above shows a quick way to run a basic server. There’s much more you can do (and thousands of pre-built images in the Docker Hub). Take time to learn the terminology and read the Docker User Guide to get the most from it, and don’t run random code you’ve downloaded without checking it’s safe – unofficial images may not have the latest security patches. If in doubt, stick to the official repositiories.

The PHPDocker.io site will auto-generate all the files you need for a fully-featured LAMP/LEMP stack, including your choice of PHP version and extensions.

Zurück zum Start{.top}

Caching

PHP ist von Haus aus schnell, aber Flaschenhälse können entstehen, wenn du Verbindungen über weite Strecken aufbaust, Dateien lädst, etc. Zum Glück gibt es verschiedene Werkzeuge, die gewisse Teile deiner Anwendung beschleunigen oder die Häufigkeit dieser zeitintensiven Aufgaben reduzieren.

Opcode Cache

When a PHP file is executed, it must first be compiled into opcodes (machine language instructions for the CPU). If the source code is unchanged, the opcodes will be the same, so this compilation step becomes a waste of CPU resources.

An opcode cache prevents redundant compilation by storing opcodes in memory and reusing them on successive calls. It will typically check signature or modification time of the file first, in case there have been any changes.

It’s likely an opcode cache will make a significant speed improvement to your application. Since PHP 5.5 there is one built in - Zend OPcache. Depending on your PHP package/distribution, it’s usually turned on by default - check opcache.enable and the output of phpinfo() to make sure. For earlier versions there’s a PECL extension.

Read more about opcode caches:

Object Caching

There are times when it can be beneficial to cache individual objects in your code, such as with data that is expensive to get or database calls where the result is unlikely to change. You can use object caching software to hold these pieces of data in memory for extremely fast access later on. If you save these items to a data store after you retrieve them, then pull them directly from the cache for following requests, you can gain a significant improvement in performance as well as reduce the load on your database servers.

Many of the popular bytecode caching solutions let you cache custom data as well, so there’s even more reason to take advantage of them. APCu, XCache, and WinCache all provide APIs to save data from your PHP code to their memory cache.

The most commonly used memory object caching systems are APCu and memcached. APCu is an excellent choice for object caching, it includes a simple API for adding your own data to its memory cache and is very easy to setup and use. The one real limitation of APCu is that it is tied to the server it’s installed on. Memcached on the other hand is installed as a separate service and can be accessed across the network, meaning that you can store objects in a hyper-fast data store in a central location and many different systems can pull from it.

Note that when running PHP as a (Fast-)CGI application inside your webserver, every PHP process will have its own cache, i.e. APCu data is not shared between your worker processes. In these cases, you might want to consider using memcached instead, as it’s not tied to the PHP processes.

In a networked configuration APCu will usually outperform memcached in terms of access speed, but memcached will be able to scale up faster and further. If you do not expect to have multiple servers running your application, or do not need the extra features that memcached offers then APCu is probably your best choice for object caching.

Example logic using APCu:

<?php
// check if there is data saved as 'expensive_data' in cache
$data = apc_fetch('expensive_data');
if ($data === false) {
    // data is not in cache; save result of expensive call for later use
    apc_add('expensive_data', $data = get_expensive_data());
}

print_r($data);

Note that prior to PHP 5.5, APC provides both an object cache and a bytecode cache. APCu is a project to bring APC’s object cache to PHP 5.5+, since PHP now has a built-in bytecode cache (OPcache).

Zurück zum Start{.top}

Documenting your Code

PHPDoc

PHPDoc is an informal standard for commenting PHP code. There are a lot of different tags available. The full list of tags and examples can be found at the PHPDoc manual.

Below is an example of how you might document a class with a few methods;

<?php
/**
 * @author A Name <a.name@example.com>
 * @link http://www.phpdoc.org/docs/latest/index.html
 */
class DateTimeHelper
{
    /**
     * @param mixed $anything Anything that we can convert to a \DateTime object
     *
     * @throws \InvalidArgumentException
     *
     * @return \DateTime
     */
    public function dateTimeFromAnything($anything)
    {
        $type = gettype($anything);

        switch ($type) {
            // Some code that tries to return a \DateTime object
        }

        throw new \InvalidArgumentException(
            "Failed Converting param of type '{$type}' to DateTime object"
        );
    }

    /**
     * @param mixed $date Anything that we can convert to a \DateTime object
     *
     * @return void
     */
    public function printISO8601Date($date)
    {
        echo $this->dateTimeFromAnything($date)->format('c');
    }

    /**
     * @param mixed $date Anything that we can convert to a \DateTime object
     */
    public function printRFC2822Date($date)
    {
        echo $this->dateTimeFromAnything($date)->format('r');
    }
}

The documentation for the class as a whole has the @author tag and a @link tag. The @author tag is used to document the author of the code and can be repeated for documenting several authors. The @link tag is used to link to a website indicating a relationship between the website and the code.

Inside the class, the first method has a @param tag documenting the type, name and description of the parameter being passed to the method. Additionally it has the @return and @throws tags for documenting the return type, and any exceptions that could be thrown respectively.

The second and third methods are very similar and have a single @param tag as did the first method. The important difference between the second and third methods’ doc block is the inclusion/exclusion of the @return tag. @return void explicitly informs us that there is no return; historically omitting the @return void statement also results in the same (no return) action.

Zurück zum Start{.top}

Resources

From the Source

People to Follow

It’s difficult to find interesting and knowledgeable PHP community members when you are first starting out. You can find an abbreviated list of PHP community members to get you started at:

Mentoring

PHP PaaS Providers

To see which versions these PaaS hosts are running, head over to PHP Versions.

Frameworks

Rather than re-invent the wheel, many PHP developers use frameworks to build out web applications. Frameworks abstract away many of the low-level concerns and provide helpful, easy-to-use interfaces to complete common tasks.

You do not need to use a framework for every project. Sometimes plain PHP is the right way to go, but if you do need a framework then there are three main types available:

Micro-frameworks are essentially a wrapper to route a HTTP request to a callback, controller, method, etc as quickly as possible, and sometimes come with a few extra libraries to assist development such as basic database wrappers and the like. They are prominently used to build remote HTTP services.

Many frameworks add a considerable number of features on top of what is available in a micro-framework; these are called Full-Stack Frameworks. These often come bundled with ORMs, Authentication packages, etc.

Component-based frameworks are collections of specialized and single-purpose libraries. Disparate component-based frameworks can be used together to make a micro- or full-stack framework.

Components

As mentioned above “Components” are another approach to the common goal of creating, distributing and implementing shared code. Various component repositories exist, the main two of which are:

Both of these repositories have command line tools associated with them to help the installation and upgrade processes, and have been explained in more detail in the Dependency Management section.

There are also component-based frameworks and component-vendors that offer no framework at all. These projects provide another source of packages which ideally have little to no dependencies on other packages, or specific frameworks.

For example, you can use the FuelPHP Validation package, without needing to use the FuelPHP framework itself.

Laravel’s Illuminate components will become better decoupled from the Laravel framework. For now, only the components best decoupled from the Laravel framework are listed above.

Other Useful Resources

Cheatsheets

More best practices

News around the PHP and web development communities

You can subscribe to weekly newsletters to keep yourself informed on new libraries, latest news, events and general announcements, as well as additional resources being published every now and then:

There are also Weeklies on other platforms you might be interested in; here’s a list of some.

PHP universe

Video Tutorials

YouTube Channels

Books

There are many PHP books; sadly some are now quite old and no longer accurate. In particular, avoid books on “PHP 6”, a version that will now never exist. The next major release of PHP after 5.6 was “PHP 7”, partly because of this.

This section aims to be a living document for recommended books on PHP development in general. If you would like your book to be added, send a PR and it will be reviewed for relevancy.

Free Books

Zurück zum Start{.top}

Community

The PHP community is as diverse as it is large, and its members are ready and willing to support new PHP programmers. Consider joining your local PHP user group (PUG) or attending larger PHP conferences to learn more about the best practices shown here. You can hang out on IRC in the #phpc channel on irc.freenode.com and follow the @phpc twitter account. Get out there, meet new developers, learn new topics, and above all, make new friends! Other community resources include StackOverflow.

Read the Official PHP Events Calendar

PHP User Groups

If you live in a larger city, odds are there’s a PHP user group nearby. You can easily find your local PUG at PHP.ug. Alternate sources might be Meetup.com or a search for php user group near me using your favorite search engine (i.e. Google). If you live in a smaller town, there may not be a local PUG; if that’s the case, start one!

Special mention should be made of two global user groups: NomadPHP and PHPWomen. NomadPHP offers twice monthly online user group meetings with presentations by some of the top speakers in the PHP community. PHPWomen is a non-exclusive user group originally targeted towards the women in the PHP world. Membership is open to everyone who supports a more diverse community. PHPWomen provide a network for support, mentorship and education, and generally promote the creating of a “female friendly” and professional atmosphere.

Read about User Groups on the PHP Wiki

PHP Conferences

The PHP community also hosts larger regional and national conferences in many countries around the world. Well-known members of the PHP community usually speak at these larger events, so it’s a great opportunity to learn directly from industry leaders.

Find a PHP Conference

ElePHPants

ElePHPant is that beautiful mascot of the PHP project with elephant in their design. It was originally designed for the PHP project in 1998 by Vincent Pontier - spiritual father of thousands of elePHPants around the world and 10 years later adorable plush elephant toy came to birth as well. Now elePHPants are present at many PHP conferences and with many PHP developers at their computers for fun and inspiration.

Interview with Vincent Pontier