Fork me on GitHub

Bienvenido

Hoy en día existe mucha información anticuada acerca de PHP que guía a nuevos programadores por mal camino, propaga las malas prácticas y código inseguro. PHP: La Manera Correcta es una referencia práctica y fácil de entender, los mejores métodos, estándares de código, enlaces a tutoriales autoritativos alrededor de la Web y lo que los contribuyentes consideran como las mejores prácticas en la actualidad.

No existe una manera canónica de utilizar PHP. Este sitio tiene como objetivo introducir a los nuevos desarrolladores en PHP a algunos temas que tal vez no descubran hasta que es demasiado tarde, y también ofrecer nuevas ideas a los profesionales experimentados sobre aquellos temas que han estado haciendo durante años sin reconsiderar. Este sitio no le dirá que herramientas utilizar, en su lugar le ofrecerá diferentes opciones, cuando sea posible se le explicarán las diferencias de enfoque y casos de uso.

Consideramos este sitio como un documento vivo que se continuará actualizando con más información útil y ejemplos según se hagan disponibles.

Traducciones

PHP: La Manera Correcta ha sido (o muy pronto será) traducido a diferentes lenguajes:

Como Colaborar

¡Ayuda a que este sitio se convierta en el mejor recurso para nuevos programadores en PHP! Colabora en GitHub

¡Corre la voz!

PHP: La Manera Correcta tiene disponibles banners que puedes usar en tu sitio web. ¡Apoya la causa y hazles saber a nuevos desarrolladores en PHP donde es que pueden encontrar buena información!

Ver las imágenes para banners

Regresar al Inicio

Primeros pasos

Use la versión estable actual (5.5)

Si está dando sus primeros pasos con PHP, asegúrese de usar con la última versión estable (current stable) de PHP 5.5. En los últimos años se ha progresado mucho añadiendo nuevas y potentes características a PHP. Aunque la diferencia entre las versiones 5.2 y 5.5 aparenta ser mínima, en realidad la nueva versión representa grandes mejoras en el sistema. Si estás buscando alguna función en particular o su modo de uso, la documentación oficial en php.net tendrá la respuesta.

Servidor Web Embebido

Usted puede comenzar a aprender PHP sin tener que instalar y configurar un servidor web completo (se requiere la versión PHP 5.4). Para iniciar el servidor embebido se necesita correr el siguiente comando en la terminal desde el directorio raíz de su proyecto:

> php -S localhost:8000

Configuración en Mac

El sistema OSX viene previamente configurado con un PHP que normalmente no está actualizado a la versión corriente. El sistema “Lion” viene configurado con PHP 5.3.6, el sistema “Mountain Lion” con la versión 5.3.10 y el sistema “Mavericks” con al versión 5.4.17.

Para actualizar la versión de PHP en el sistema OSX se puede instalar por medio de diferentes gestores de paquetes, sin embargo, recomendamos el paquete php-osx by Liip.

La otra opción disponible es que usted compile el paquete de instalación. En tal caso debe asegurarse de tener la aplicación para desarrollo Xcode o, como sustituto, las herramientas “Command Line Tools for Xcode” que se pueden descargar directamente del Mac Developer Center de Apple.

También existen paquetes tipo “todo incluido” con un control gráfico de configuración bastante simple, MAMP o XAMPP. Estos incluyen una configuración de PHP junto con el servidor web Apache y el gestor de base de datos MySQL.

Configuración en Windows

Hay un sinnúmero de maneras de configurar PHP en el sistema Windows. Usted puede descargar los binarios y recientemente el paquete de instalación estaba disponible en el formato ‘.msi’. Este paquete de instalación ya no se actualiza y la última versión fue PHP 5.3.0.

Para aprender PHP o el desarrollo local, se puede utilizar el servidor web embebido que viene con la versión PHP 5.4, así no tendrá que preocuparse por configurar un servidor por separado. Ahora bien, si le gustaría disponer de una solución tipo “todo incluido”, que le ofrece un servidor web completo junto con el gestor de base de datos MySQL, entonces herramientas como el Web Platform Installer, XAMPP y WAMP le ayudaran a configurar un entorno de desarrollo web en Windows más fácilmente y en menos tiempo. Tenga en consideración que estas herramientas son un poco diferentes a las que usara en su sistema de producción, así que tenga cuidado de las diferencias en el entorno de su aplicación si es que la desarrolla en Windows pero la despliega en Linux.

Si necesita correr un sistema de producción en Windows entonces el servidor IIS 7 le ofrecerá un entorno más estable y con el mejor rendimiento. Una herramienta como phpmanager (un complemento GUI para IIS 7) le simplificara la gestión y configuración de PHP en este servidor. IIS 7 viene configurado con FastCGI listo para su uso, solo necesita apuntar a PHP como controlador. Para más información y recursos adicionales refiérase a la área dedicada en iis.net para PHP.

Vagrant

Si ejecuta su aplicación en diferentes entornos para desarrollo y producción puede conducir a que se manifiesten errores extraños al usar su aplicación. También es complicado mantener los diferentes entornos de desarrollo actualizados con la misma versión para todas las librerías utilizadas cuando se trabaja con un equipo de desarrollo.

Si está desarrollando en Windows y desplegando en Linux (o cualquier otro sistema que no sea Windows) considere el uso de una Máquina Virtual. Quizás suene un poco complicado, pero con el uso de Vagrant puede configurar una máquina virtual en pocos pasos. Estas máquinas virtuales (box) pueden ser configuradas manualmente, o puede utilizar un software “suministrador” como Puppet o Chef para hacer esto por usted. La suministración de una box base es una forma genial de asegurarse que las múltiples máquinas virtuales estén configuradas en forma idéntica y le evitan la necesidad de mantener una complicada lista de comandos de “configuración”. También puede “destruir” su box base y re-crearla sin muchos pasos manuales, por lo que es fácil crear una instalación “fresca”.

Vagrant crea carpetas compartidas para compartir su código entre su equipo y su máquina virtual, lo que significa que puede crear y editar sus archivos en su equipo y después correr el código dentro de su máquina virtual.

Un poco de ayuda

Si necesita un poco de ayuda para comenzar a utilizar Vagrant aquí hay dos servicios que pueden serle útiles:

Regresar al Inicio

Guía de Estilo de Código

La comunidad detrás de PHP es enorme y diversa, compuesta de innumerables librerías, armazones de desarrollo (frameworks) y componentes. Es común que desarrolladores en PHP escojan de entre estos y los combinen en un solo proyecto. Por eso es importante que el código PHP se adhiera (lo más cerca posible) a un estilo de código común para que se facilite el trabajo de los desarrolladores al combinar una variedad de librerías para sus proyectos.

El Framework Interop Group (antes conocido como el ‘PHP Standards Group’) ha propuesto y aprobado una serie de recomendaciones de estilo, conocidas como PSR-0, PSR-1 y PSR-2. No deje que los títulos raros lo confundan, estas recomendaciones son simplemente un conjunto de normas que algunos proyectos como Drupal, Zend, CakePHP, phpBB, AWS SDK, FuelPHP, Lithium, y otros han comenzado a adoptar. Usted puede utilizar estas normas en sus propios proyectos o continuar usando su propio estilo.

Sería ideal que escribiera código PHP que se adhiere a uno o más de estos estándares. Puede ser cualquier combinación de PSR, o uno de los estándares de codificación hechos por PEAR o Zend. Esto significa que otros desarrolladores pueden fácilmente leer y trabajar con su código, y las aplicaciones que implementan los componentes puedan tener consistencia incluso cuando trabajen con una gran cantidad de código de terceros.

Puede utilizar PHP_CodeSniffer para verificar que su código se apegue a estas recomendaciones, y plugins para editores de texto como Sublime Text 2 para obtener un análisis en tiempo real.

Utilice PHP Coding Standards Fixer de Fabien Potencier para modificar la sintaxis de su código automáticamente y así quede conforme a estos estándares, ahorrándole tiempo y esfuerzo que requeriría arreglar cada problema a mano.

Se prefiere la utilización del idioma Inglés para todos los nombres de símbolos e infraestructura del código. Los comentarios pueden ser escritos e un lenguaje fácilmente legible para todos autores y futuros desarrolladores que trabajaran en la base del código.

Regresar al Inicio

Aspectos Destacados del Lenguaje

Paradigmas de Programación

PHP es un lenguaje flexible y dinámico que permite usar una variedad de técnicas de programación. El lenguaje ha evolucionado dramáticamente a través de los años. Se añadió un modelo de objetos (object-oriented) sólido en la versión 5.0 (2004), funciones anónimas y espacios de nombres (namespaces) en PHP 5.3, y rasgos (traits) en PHP 5.4 (2012).

Programación Orientada a Objetos

PHP tiene un conjunto muy completo de aspectos que facilitan la programación orientada a objetos (OOP) que incluye la habilidad de crear clases, clases abstractas, interfaces, herencia, constructores, clonación de objetos, excepciones y mucho más.

Programación Funcional

PHP tiene la capacidad de declarar funciones de primera clase, en otras palabras, una función puede ser asignada a un variable. Las funciones definidas por el usuario, así como las funciones internas (incluidas), tiene la habilidad de ser referenciadas por un variable e invocadas dinámicamente. Las funciones pueden ser pasadas como argumentos a otras funciones (un aspecto llamado funciones de orden superior) y funciones pueden devolver otras funciones.

La recursividad es un aspecto que le permite a una función a llamarse a sí misma. El lenguaje PHP habilita este tipo de algoritmos, sin embargo, la mayoría del código PHP se enfoca en iteración.

Las funciones anónimas (con soporte para closures) están presentes en PHP desde la versión 5.3 (2009).

En PHP 5.4 se añadió la habilidad para vincular closure al ámbito de un objeto y también se mejoró el soporte de funciones de tipo callable para que puedan intercambiarse con funciones anónimas en casi todos los casos.

Programación Meta

PHP soporta varias formas de programación meta por medio de mecanismos como el API de Reflexión y los Métodos Mágicos. Hay muchos Métodos Mágicos disponibles como __get(), __set(), __clone(), __toString(), __invoke() y más, que permiten a los desarrolladores a conectarse con el funcionamiento de la clase. A menudo desarrolladores en Ruby dicen que a PHP le falta la función de method_missing, sin embargo los aspectos de esta función están disponibles en __call() y __callStatic().

Namespaces

Como mencionamos anteriormente, la comunidad de PHP tiene muchos desarrolladores creando una gran cantidad de código fuente. Esto quiere decir que existe la posibilidad que dos librerías diferentes utilicen el mismo nombre para una clase en su código. Cuando las dos librerías se usan dentro del mismo namespace esto se denomina como una colisión y puede causar problemas.

Los Namespaces resuelven este problema. Como se describe en el manual de referencia de PHP, los namespaces son similares a los directorios que separan los archivos en el sistema operativo. Dos archivos con el mismo nombre pueden coexistir en directorios separados. Igualmente, dos clases de PHP con el mismo nombre pueden coexistir en namespaces separados, es tan simple como eso.

Es importante que separe su código con un namespace para que pueda ser usado por otros desarrolladores sin la preocupación de que cause conflictos con otras librerías.

Uno de los métodos recomendados para el uso de espacios de nombres se indica en el PSR-0, el cual se propone proveer una convención estándar para los archivos, clases y los namespaces, lo cual facilita el intercambio y uso del código en diferentes proyectos.

Biblioteca Estándar de PHP

La Biblioteca Estándar de PHP (SPL) viene empaquetada con PHP y provee una colección de clases e interfaces compuesta principalmente de clases de estructura de datos (como stack, queue y heap) e iteradores que pueden atravesar estas estructuras de datos o sus propias clases que implementan las interfaces de la SPL.

Interface de Línea de Comando (CLI)

PHP fue creado principalmente para desarrollar aplicaciones web, pero también es muy útil para implementar programas que corren en la interface de línea de comando (CLI). Los programas de línea de comando en PHP pueden ayudarle a automatizar tareas comunes como pruebas, despliegues y la administración de aplicaciones.

Los programas CLI en PHP son muy potentes porque el código de la aplicación se puede utilizar directamente sin tener que crear o asegurar un GUI web para su uso. Por esta razón, ¡asegúrese de no colocar sus programas CLI en su directorio raíz público!

Intente correr PHP desde la línea de comando:

> php -i

La opción -i imprimirá la configuración de PHP, como sucede con la función phpinfo. La opción -a habilita una consola interactiva muy similar al IRB de Ruby o a la consola interactiva de Python. Existen varias opciones de línea de comando que resultan muy útiles. Vamos a escribir un programa simple que imprima “Hola, $nombre” a la línea de comando. Para empezar, vamos a crear un archive llamad hola.php como se muestra enseguida:

<?php
if($argc != 2) {
    echo "Uso: php hola.php [nombre].\n";
    exit(1);
}
$nombre = $argv[1];
echo "Hola, $nombre\n";

PHP hace disponibles dos variables especiales basados en los argumentos que recibe el programa el ser ejecutado. El variable de tipo entero $argc contiene el count o número de argumentos y el variable de tipo array $argv contiene el value o valor de cada uno de los argumentos que se pasaron durante la ejecución. El primer argumento siempre es el nombre del archivo del programa PHP, que en este caso es hola.php.

La expresión exit() se puede usar con un número que no es cero para dejarle saber a la consola que el comando ha fallado. Aquí puede encontrar los códigos de salida más comúnmente usados.

Para ejecutar el programa desde la línea de comando:

> php hola.php
Uso: php hola.php [nombre]
> php hola.php mundo
Hola, mundo

XDebug

Es una de las herramientas más útiles en el desarrollo de software, es un depurador o debugger. Permite el trazado de ejecución de tu código y monitorear el contenida de la pila de ejecución. XDebug, depurador para PHP, puede ser utilizado por varios IDEs para proveer Breakpoints e inspeccionar la pila de ejecución. También permite que herramientas como PHPUnit y KCacheGrind realicen análisis de cobertura del código.

Si te encuentras en un aprieto, y recurres a vardump/print_r_, y sigues sin encontrar la solución - tal ves necesitas usar un depurador.

Instalar XDebug puede ser complicado, pero una de las características más importantes es la “Depuración Remota” - Si ésta desarrollando su código localmente y después lo prueba dentro de una VM (Máquina Virtual) u en otro servidor, la Depuración Remota es la característica que necesitaras habilitar desde un comienzo.

Tradicionalmente, tendrá que modificar su VHost Apache o el archivo .htaccess con los siguientes valores:

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

El “remote host” y el “remote port” corresponderán a su computadora local y el puerto de escucha que usted configuró para su IDE. Ahora solo es cuestión de que ponga su IDE dentro del modo “escuchar conexiones”, y cargue la URL:

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

Su IDE ahora interceptará el estado actual de la ejecución de su script, permitiéndole establecer breakpoints y verificar los valores en memoria.

Los depuradores gráficos hacen muy fácil el proceso de recorrer el código, inspeccionar variables, y evaluar el código en tiempo de ejecución. Varios IDE’s tienen integrado o pueden ser integrados vía plugin la depuración gráfica con XDebug. MacGDBp es un GUI de XDebug para Mac y también es gratuito, open-source y stand-alone.

Regresar al Inicio

Gestión de Dependencias

Existen un sinnúmero de librerías, armazones de desarrollo (frameworks) y componentes de PHP de donde escoger y lo más probable es que su proyecto utilice varios de ellos. A estos se les llama dependencias de proyecto. Hasta muy recientemente, PHP no tenía una manera fácil de gestionar tales dependencias. Aun si usted se hacía cargo de estos manualmente, todavía tendría que mantenerse al tanto de los cargadores automáticos (autoloaders). Ahora ya no es así.

Actualmente hay dos sistemas principales de gestión de paquetes para PHP: Composer y PEAR. ¿Cuál es el adecuado para usted? La respuesta es, ambos.

Generalmente, los paquetes de Composer solo estarán disponibles en los proyectos que usted especifique explícitamente, mientras que un paquete de PEAR estaría disponible a todos los proyectos bajo el sistema PHP. Puede que PEAR parezca la propuesta más accesible a primera vista, sin embargo, también existen ventajas al manejar las dependencias con Composer en base al proyecto en que se está trabajando.

Composer y Packagist

Composer es un excelente gestor de dependencias para PHP. Solo tiene que añadir las dependencias de su proyecto a un archivo llamado composer.json, ejecutar algunos comandos y Composer descargará automáticamente las dependencias para su proyecto y configurará el cargador automático en cuestión de segundos.

Ya existen muchas librerías PHP compatibles con Composer y están listas para que las use en su proyecto. Hay una lista de estos “paquetes” en el sitio Packagist, que es el repositorio oficial de librerías compatibles con Composer.

Como configurar Composer

Se puede instalar Composer local (en el directorio de trabajo actual, aunque esto ya no es recomendable) o globalmente (por ejemplo, en /user/local/bin). Supongamos que usted quiere configurar Composer localmente. Desde el directorio raíz de su proyecto:

curl -s http://getcomposer.org/installer | php

Esto descargará el archivo binario composer.phar. Se puede ejecutar este archivo con php para manejar las dependencias de su proyecto. Por favor, tenga en cuenta: Si ejecuta el código directamente en el intérprete de PHP al mismo tiempo que lo descarga, tenga cuidado de leer el código del programa con anterioridad y confirmar que es seguro.

Como configurar Composer (manualmente)

Configurar Composer manualmente requiere técnicas avanzadas. No obstante, hay varias razones por las cuales un desarrollador como usted prefiera configurarlo de esta manera en vez de utilizar la rutina de configuración interactiva. La configuración interactiva verifica su sistema de PHP para asegurar que:

Ya que la configuración manual no realiza ninguna de estas verificaciones, necesita tomar en consideración si tal funcionamiento es lo que usted desea. De todas maneras, usted puede obtener y configurar Composer manualmente de la siguiente manera:

curl -s http://getcomposer.org/composer.phar -o $HOME/local/bin/composer
chmod +x $HOME/local/bin/composer

La ruta $HOME/local/bin (o un directorio que usted escoja) necesita estar en el variable de entorno $PATH. De esta manera, el comando composer estará habilitado en cualquier directorio del sistema.

Cuando se encuentre con instrucciones que le sugieran ejecutar Composer con php composer.phar install, esto se puede sustituir con:

composer install

Como Definir y Configurar Dependencias

Primero, se crea un archivo composer.json en el mismo directorio donde se encuentra composer.phar. Enseguida, encontramos un ejemplo que define el paquete Twig como una dependencia del proyecto:

{
    "require": {
        "twig/twig": "1.8.*"
    }
}

El siguiente paso es ejecutar Composer desde el directorio raíz de su proyecto:

php composer.phar install

Esto descargara y configurara la dependencia dentro de un directorio llamado vendors/. Una vez configurado, añada esta línea de código al archivo principal de su aplicación:

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

Esta instrucción le dice a su programa que use el cargador automático de Composer para cargar cualquier dependencia que haya configurado. Ahora sus dependencias serán cargadas dinámicamente según su programa las requiera.

PEAR

Otra alternativa para la gestión de paquetes que muchos desarrolladores en PHP prefieren es PEAR. Su funcionamiento es muy similar al de Composer y vale la pena investigar más sus aspectos sobresalientes.

Aprenda acerca de PEAR.

Regresar al Inicio

Buenas Prácticas

Fundamentos

PHP es un gran lenguaje que permite a cualquier desarrollador producir código de forma rápida y de manera eficiente. Sin embargo, mientras que avanzamos con el lenguaje, a menudo olvidamos (o pasamos por alto) las prácticas básicas que aprendimos al inicio, tomando así atajos o malas prácticas. Para ayudar a combatir este problema común, esta sección tiene como objetivo recordar a los desarrolladores las buenas prácticas dentro de PHP.

Fecha y Hora

PHP dispone de una clase llamada DateTIme para asistir en la lectura, escritura, comparación y calculación de la fecha y hora. Existen muchas funciones en PHP relacionadas con la manipulación de la fecha y la hora, sin embargo, la clase DateTime provee una mejor interface orientada a objetos para los situaciones más comunes. También tiene la capacidad de utilizar los husos horarios; esta información no se considerará en esta corta introducción.

Para comenzar a trabajar con DateTime primero se convierte la cadena de texto que contiene la fecha y la hora a un objeto con el método de fabricación createFromFormat() o también se puede crear un objeto con new \DateTime que contendrá la fecha y hora actual. Después, puede utilizar el método format() para convertir el objeto DateTime de regreso a una cadena de texto e imprimirla:

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

echo "Fecha de Inicio: " . $inicio->format('m/d/Y') . "\n";

Se puede utilizar la clase DateInterval para realizar calculaciones con DateTime. La clase DateTime tiene métodos como add() y sub() que requieren que pase un DateInterval como argumento. Nunca escriba código que cuente con el mismo número de segundos en todos los días ya que los ajustes de los husos horarios y el horario de verano (daylight savings time) invalidaría esa suposición. En vez de eso, utilice los intervalos de fechas para hacer sus calculaciones. Para calcular la diferencia entre fechas utilice el método diff(). Este le devolverá un return new DateInterval, lo cual puede ser fácilmente impreso en la pantalla.

<?php
// Crea una copia de $inicio y añade un mes y 6 días
$final = clone $inicio;
$final->add(new \DateInterval('P1M6D'));

$diff = $final->diff($inicio);
echo "Diferencia: " . $diff->format('%m mes, %d días (total: %a días)') . "\n";
// Diferencia: 1 mes, 6 días (total: 37 días)

Es posible comparar fácilmente los objetos DateTime:

<?php
if($inicio < $final) {
    echo "¡El inicio sucede antes que el final!\n";
}

Este último ejemplo demuestra cómo se utiliza la clase DatePeriod para iterar sobre eventos periódicos. El objeto toma dos objetos DateTime, uno para el inicio y el otro para el final, y el intervalo que define el número de eventos periódicos que se devuelven.

<?php
// Imprimir todos los jueves entre $inicio y $final
$intervaloDePeriodo = \DateInterval::createFromDateString('first thursday');
$iteradorDePeriodo = new \DatePeriod($inicio, $intervaloDePeriodo, $final, \DatePeriod::EXCLUDE_START_DATE);
foreach($iteradorDePeriodo as $fecha)
{
    // Imprimir cada fecha en el periodo
    echo $fecha->format('m/d/Y') . " ";
}

Patrones de Diseño

Cuando se desarrolla una aplicación es muy bueno utilizar patrones de uso común en su código y patrones para la estructura general de su proyecto. El usar estos patrones ayuda y facilita el manejo de su código y permite a otros desarrolladores a entender fácilmente como es que encajan todas las partes de su aplicación.

Si utiliza un armazón (framework) para el desarrollo de su proyecto, entonces la mayor parte del nivel superior de su código estará basado en este armazón, así que muchas de las decisiones ya han sido hechas por usted. Pero todavía depende de usted el escoger los mejores patrones a seguir en el código que desarrolla sobre este armazón. Si, por otro lado, no está utilizando un armazón para desarrollar su aplicación, entonces necesita encontrar los patrones que mejor se adapten al tipo y tamaño de su proyecto.

Regresar al Inicio

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 it’s 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 it 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 organisational 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 you 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.

Dependency Inversion Principle

Dependency Inversion Principle is the “D” in the S.O.L.I.D set of object oriented design principles that states 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 you 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 inject 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

Regresar al Inicio

Bases de Datos

Muchas veces su código PHP utilizara una base de datos para persistir información. Hay algunas opciones para conectarse e interactuar con la base de datos. La opcion recomendable, hasta PHP 5.1.0, era el utilizar los controladores nativos como mysql, mysqli, pgsql, y otros.

Los controladores nativos son excelentes si solamente estara utilizando UNA SOLA base de datos en su aplicación, pero si, por ejemplo, esta utilizando MySQL y un poco de MSSQL, o necesita conectarse a una base de datos Oracle, entonces no podrá utilizar los mismos controladores. Necesita aprender un nuevo API para cada base de datos — y eso puede ser frustrante.

Algo adicional sobre los controladores nativos: la extensión mysql para PHP ya no está siendo actualizada y el estatus oficial de ella desde PHP 5.4.0 es la de “Eliminación a Largo Plazo”. Esto quiere decir que la extensión será eliminada en los próximos lanzamientos, así que en PHP 5.6 (o lo que viene después de 5.5) puede que ya no exista. Si usted está usando mysql_connect() y mysql_query() en sus aplicaciones es posible que tenga que reemplazar su código en el futuro, así que la mejor opción es empezar a usar mysqli o la librería PDO de ahora en adelante. Si esta comenzando de cero entonces no utilice la extensión mysql en absoluto. Utilice la extensión MySQLi, o la librería PDO.

PDO

PDO (Objetos de Datos de PHP) es una librería de abstracción para establecer conexiones a bases de datos — incluida en PHP desde la versión 5.1.0 — que provee una interface común para comunicarse con diferentes sistemas de bases de datos. PDO no interpreta sus consultas en SQL ni emula características que faltan; solo se utiliza para establecer conexiones a diferentes bases de datos con el mismo API.

Lo que es más importante, PDO le permite inyectar la entrada de datos de forma segura en sus consultas de SQL sin tener que preocuparse de sufrir ataques de inyección de SQL en su base de datos. Esto es posible gracias a las declaraciones y los parámetros consolidados de PDO.

Supongamos que un programa de PHP recibe un ID numérico en la forma de un parámetro de consulta. Este ID debe ser utilizado para extraer un registro de usuario de una base de datos. El ejemplo que sigue muestra la manera incorrecta de hacerlo:

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

Esta es la peor manera de hacerlo, ya que se está insertando el parámetro directamente, o sin “sanear”, a la consulta de SQL y sin usar parámetros consolidados provistos por PDO. Veamos un mejor ejemplo:

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

Esta es la manera correcta porque se usa un parámetro consolidado en una declaración de PDO. Esto sanea la entrada de datos antes de que se introduzca en la base de datos, así previniendo un probable ataque de inyección de SQL.

Capas de Abstracción

Muchos de los armazones de desarrollo disponibles proveen su propia capa de abstracción que puede o no usar PDO como base. Estas capas muy a menudo emulan las características y diferencias entre un sistema de base de datos y otro al envolver las consultas en métodos de PHP, lo que proporciona una abstracción efectiva de la base de datos. Claramente, esto añade una pequeña sobrecarga a su proyecto, pero si está tratando de desarrollar una aplicación portable que necesite trabajar con MySQL, PostgreSQL y SQLite entonces esa pequeña sobrecarga valdrá la pena ya que mantendrá su código limpio y con una estructura elegante.

Algunas capas de abstracción han sido desarrolladas con el estándar PSR-0 para uso de espacios de nombres en mente, lo cual facilita la configuración en cualquiera de sus proyectos (La siguiente documentación solo está disponible en inglés):

Regresar al Inicio

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. Warnings are non-fatal errors, execution of the script will not be halted. Notices are advisory messages caused by code that may or may not cause problems during the execution of the script, execution is not 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 Warnings and Errors - but not Notices - then you can configure that:

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 suppress specific errors from being displayed using the Error Control Operator @. You simply put this operator at the beginning an expression, and any error that would be caused as a direct result of the specific expression will be silenced.

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.

This might seem like a good idea, but due to the way PHP actually handles @ it is incredibly unperformant, and has the unexpected effect of still actually logging the error anyway. If you have this code in a loop that runs 100 times in an instance, and you run that 1 million times, then you’ve got 100 million lines in your logs.

Instead, use the following:

echo isset($foo['bar']) ? $foo['bar'] : '';

This will be much quicker, and save filling up your logs with junk. SitePoint go a step further and say you should never suppress notices with @.

One instance where error suppression might make sense is where fopen() fails to find a file to load. You could check for 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.

In a stock PHP system, the behavior of the error control operator is irreversible. There are no configuration settings which allow a suppressed error to be temporarily un-suppressed.

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

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. By default Laravel will display all errors as exceptions using the Whoops! package if the app.debug switch is turned on, then hide them if the switch is turned off.

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.

Exceptions

Exceptions are a standard part of most popular programming languages, but they are often overlooked by PHP programmers. Languages like Ruby are extremely Exception heavy, so whenever something goes wrong such as a HTTP request failing, or a DB query goes wrong, or even if an image asset could not be found, Ruby (or the gems being used) will throw an exception to the screen meaning you instantly know there is a mistake.

PHP itself is fairly lax with this, and a call to file_get_contents() will usually just get you a FALSE and a warning. Many older PHP frameworks like CodeIgniter will just return a false, log a message to their proprietary logs and maybe let you use a method like $this->upload->get_error() to see what went wrong. The problem here is that you have to go looking for a mistake and check the docs to see what the error method is for this class, instead of having it made extremely obvious.

Another problem is when classes automatically throw an error to the screen and exit the process. When you do this you stop another developer from being able to dynamically handle that error. Exceptions should be thrown to make a developer aware of an error; they then can choose how to handle this. E.g.:

<?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

The generic Exception class provides very little debugging context for the developer; however, to remedy this, it is possible to create a specialized Exception type by sub-classing the generic Exception class:

<?php
class ValidationException extends Exception {}

This means you can add multiple catch blocks and handle different Exceptions differently. This can lead to the creation of a lot of custom Exceptions, some of which could have been avoided using the SPL Exceptions provided in the SPL extension.

If for example you use the __call() Magic Method and an invalid method is requested then instead of throwing a standard Exception which is vague, or creating a custom Exception just for that, you could just throw new BadFunctionCallException;.

Regresar al Inicio

Seguridad

Seguridad en Aplicaciones Web

Es importante reconocer que existen individuos sin escrúpulos que buscan explotar e inhabilitar su aplicación web. Por esta razón es imperativo que tome las precauciones necesarias y trabaje en mejorar la seguridad de su proyecto. Afortunadamente, la comunidad del The Open Web Application Security Project (OWASP) han compilado una lista completa de problemas de seguridad conocidos y los métodos que puede seguir para protegerse contra ellos. Esta guía es lectura obligada para cualquier desarrollador consciente de la seguridad en su aplicación.

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. Password hashing is an irreversible, one way function performed against the user’s password. 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. Some users may (unfortunately) use the same password for other services. Therefore, it is important to take security seriously.

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
}

El Filtrado de Datos

Nunca, jamás, se confíe de los datos que provienen del exterior de su aplicación PHP. Siempre sanee y verifique los datos de entrada antes de usarlos en su código. Las funciones filter_var() y filter_input() proporcionan saneamiento de los datos y verifican la validez del formato del texto (por ejemplo, las direcciones de correo electrónico).

Los datos de entrada exteriores pueden contener cualquier cosa: los datos provenientes de formularios en $_GET y $_POST, algunos valores provenientes del súper global $_SERVER, el cuerpo de la solicitud HTTP vía la función fopen('php://input', 'r'). Recuerde que la entrada exterior de datos no está limitada a los datos que provienen de un usuario a través de un formulario, también provienen de la subida y descarga de archivos, valores de sesión, datos de cookies, y los servicios web exteriores.

Aunque los datos que provienen del exterior pueden ser guardados, combinados y se puede acceder a ellos posteriormente, todavía siguen siendo datos exteriores. Cada vez que procesa, imprime, concatena, o los incluye con otros datos en su código, pregúntese si los datos han sido filtrados apropiadamente y si es confiable.

Los datos pueden ser filtrados de diferente manera dependiendo de su proposito. Por ejemplo, cuando se pasan datos sin filtrar a la salida de HTML de su página, corre el riesgo de ejecutar código sin verificar de HTML o JavaScript en su sitio. Esto es conocido (en inglés) como Cross-Site Scripting (XSS), y puede causar mucho daño a su aplicación. Una manera de prevenir estos ataques es sanear todas las etiquetas de HTML en sus datos de entrada al remover etiquetas o convirtiéndolas en entidades de HTML.

Otro ejemplo es cuando se pasan opciones que van a ser ejecutadas en la línea de comando. Esto puede ser extremadamente peligroso y en general no es una buena idea. Sin embargo, puede usar la función escapeshellarg que viene incluida en PHP para sanear los argumentos de ejecución de un comando.

Un último ejemplo es el de aceptar la entrada de datos para determinar que archivo se necesita cargar del sistema de archivos. Esto puede ser explotado al cambiar el nombre del archivo a una ruta de archivo diferente. En este caso es necesario remover los caracteres “/”, “../”, bytes nulos y otros de la ruta de archivo para que no permita cargar archivos escondidos, no públicos, o de otra manera sensitivos.

Saneamiento

El saneamiento remueve (o evita) los caracteres ilegales o inseguros que provienen de la entrada de datos externa.

Por ejemplo, debería sanear la entrada de datos antes de incluirla en el código HTML o insertarla a una consulta de SQL. Cuando utiliza parámetros consolidados con PDO, este saneara la entrada de datos automáticamente.

En veces es requerido que permita que algunas etiquetas de HTML que se consideren inofensivas puedan ser incluidas en la entrada de datos para una página de su sitio. Esto es algo muy difícil de realizar de una manera segura y muchos lo evitan al usar otros estándares de formato de texto más restrictivos como Markdown o BBCode, aunque librerías que proveen una lista blanca de etiquetas como el HTML Purifier se concibieron para este propósito.

Vea los filtros de saneamiento

Validación

La validación asegura que lo que contiene la entrada de datos es lo que usted esperaba. Por ejemplo, quizás desee validar una dirección de correo electrónico, un número telefónico, o la edad de un usuario al procesar una solicitud de registro.

Vea los filtros de validación

Archivos de Configuración

Cuando esté trabajando con archivos de configuración para su aplicación, las mejores prácticas dictan que utilice uno de los métodos siguientes:

Register Globals

NOTA: Desde el lanzamiento de PHP 5.4, la opción register_globals ha sido eliminada y ya no puede ser utilizada.

Cuando se habilita la opción register_globals en la configuración de PHP, varios tipos de variables (incluidos los de $_POST, $_GET y $_REQUEST) se hacen disponibles en el ámbito global de su aplicación. Esto puede muy fácilmente conducirlo a problemas de seguridad ya que su aplicación no tiene una manera efectiva de verificar de dónde provienen esos datos.

Si está usando una versión de PHP anterior a 4.2.0, tenga en cuenta que corre el riesgo de que esta opción le cause problemas. Desde la versión 4.2.0 en adelante, la opción register_globals viene desactivada. Para garantizar la seguridad de su aplicación, asegúrese de que esta opción siempre este desactivada, con el valor “off”, si es que está disponible.

Reporte de Errores

El registro de errores puede ser muy útil para encontrar los lugares donde existen problemas en su aplicación, pero también puede exponer información acerca de la estructura de su aplicación al exterior. Para proteger efectivamente su aplicación de problemas que pudieran ser causados por la salida de mensajes de error, necesita configurar su servidor de desarrollo de diferente manera que su servidor de producción.

Desarrollo

Para mostrar los errores durante el desarrollo de su aplicación, configure las siguientes opciones en su archivo php.ini:

Producción

Para esconder los errores en su entorno de producción, configure su archivo php.ini de la siguiente manera:

Con estas opciones en su entorno de producción, los errores seguirán siendo registrados en los registros de errores de su servidor web, pero no serán mostrados al usuario. Para más información en cuanto a estas opciones, vea el manual de PHP:

Regresar al Inicio

Pruebas

La creación de pruebas automatizadas para su código PHP es considerada una buena práctica y conduce a aplicaciones sólidamente construidas. Las pruebas automatizadas son una gran herramienta que asegura que su aplicación no sea afectada negativamente al hacer cambios o al añadir nuevas características a su código; estas son ventajas que no se puede ignorar.

Existen diferentes tipos de herramientas (o armazones) para pruebas disponibles en PHP, las cuales tiene enfoques diferentes, pero todas intentan eliminar las pruebas manuales y la necesidad de disponer grandes equipos de Control de Calidad que se encarguen de asegurar que la aplicación sigue trabajando bien cuando introduce nuevos cambios al código.

Desarrollo Guiado por Pruebas

De Wikipedia:

Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará el software cumple con los requisitos que se han establecido.

Existen diferentes tipos de pruebas que puede utilizar para su aplicación.

Pruebas Unitarias

Las pruebas unitarias son un enfoque de programación que asegura que las funciones, clases y métodos estén funcionando como se espera, desde el punto en que se desarrollan a través de todo el ciclo de desarrollo. Al verificar los valores que entran y salen de las diferentes funciones y métodos, se puede asegurar que la lógica interna funciona correctamente. Al usar la inyección de dependencias y al construir clases de maqueta y talones de funciones se puede verificar que las dependencias se están utilizando de la manera correcta y así tener una mejor cobertura de pruebas en su aplicación.

Cuando se crea una clase o función, se debe crear también una prueba unitaria para cada parte del funcionamiento que se espera de este nuevo bloque de código. En un nivel muy básico, debe asegurarse que la prueba lanza un error si le provee argumentos equivocados y que pase la prueba si le provee los argumentos correctos. Esto le asegura que seguirá trabajando como se espera cuando se hagan cambios a esta función o clase durante el ciclo de desarrollo. La única alternativa a este método es utilizar la función var_dump() en un archivo ‘test.php’, pero no recomendamos hacer esto para ningún tipo de proyecto.

El otro uso común que se le da a este tipo de pruebas es cuando se contribuye código a un proyecto “open-source”. Si provee una prueba que lanza errores y después provee una solución en su código para que pasa la prueba, es más probable que su parche sea aceptado en el proyecto. De igual manera, si usted está a cargo de un proyecto sería aconsejable que sugiriera esto como un requisito.

PHPUnit es el principal armazón de pruebas para el desarrollo de pruebas unitarias en aplicaciones PHP, pero existen varias alternativas:

Pruebas de Integración

De Wikipedia:

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Se pueden utilizar muchas de las mismas herramientas de pruebas unitarias para hacer pruebas de integración, ya que muchos de los principios son los mismos.

Pruebas Funcionales

También conocidas como pruebas de aceptación, las pruebas funcionales consisten en el uso de herramientas que automatizan el uso real de una aplicación en vez de solo la verificación del funcionamiento de unidades individuales de código. Estas herramientas suelen trabajar con datos reales y simulan usuarios reales en la aplicación.

Herramientas para pruebas funcionales

Desarrollo Guiado por Comportamiento

Existen dos tipos diferentes de Desarrollo Guiado por Comportamiento (BDD, por sus siglas en inglés): SpecBDD y StoryBDD. SpecBDD se enfoca en el comportamiento o funcionamiento técnico o de parte del código, mientras que StoryBDD se enfoca en el funcionamiento de negocios, el comportamiento de las características o las interacciones. PHP proporciona armazones para estos dos tipos de BDD.

Con el StoryBDD, se escriben historias legibles que describen el comportamiento de su aplicación. Estas historias pueden ser ejecutadas como pruebas en contra de su aplicación. El armazón que se utiliza en PHP para StoryBDD se llama Behat, el cual fue inspirado por el proyecto Cucumber de Ruby e implementa el Gherking DSL para describir el comportamiento de características.

Con el SpecBDD, se escriben las especificaciones que describen como su código debe de funcionar. En vez de probar una función o método, solo se describe como la función o método se tiene que comportar. PHP ofrece el armazón PHPSpec para este propósito. Este armazon fue inspirado por el proyecto RSpec de Ruby.

Enlaces de BDD

Herramientas Complementarias de Pruebas

Además de armazones para pruebas individuales y guiados por comportamiento, también existen varios armazones genéricos y librerías auxiliares que son útiles para cualquier enfoque que se tome.

Enlaces de herramientas

Regresar al Inicio

Servidores y Despliegue

Las aplicaciones PHP se pueden desplegar y ejecutar en servidores web de producción de varias maneras.

Plataforma como Servicio (PaaS)

Las aplicaciones PHP se pueden desplegar y ejecutar en servidores web de producción de varias maneras.

PaaS provee la arquitectura adecuada del sistema y la red que se necesitan para ejecutar aplicaciones PHP en la web. Esto significa que no es necesaria una configuración extensa del servidor para lanzar aplicaciones o armazones de PHP.

Recientemente, PaaS se ha convertido en un método muy popular de desplegar, alojar, y ampliar aplicaciones PHP de todos los tamaños. Encontrará una lista de Proveedores de PHP PaaS en la sección de recursos.

Servidores Virtuales o Dedicados

Si se siente cómodo trabajando en la administración de sistemas, o está interesado en aprender a hacerlo, entonces los servidores virtuales o dedicados le proporcionaran el control completo del entorno de producción de su aplicación.

nginx y PHP-FPM

PHP, via el Gestor de Procesos FastCGI de PHP (FPM, con sus siglas en inglés), hace buen par con el servidor nginx, que es un servidor ligero de alto rendimiento. Utiliza menos memoria que Apache y puede manejar más solicitudes simultáneas. Esto es de especial importancia en servidores que no disponen de mucha memoria.

Apache y PHP

PHP y Apache gozan de una larga historia juntos. Apache es muy configurable y tiene muchos módulos disponibles que extienden las características del servidor. Es una elección popular para servidores compartidos y es fácil de configurar armazones de desarrollo y aplicaciones como WordPress para que trabajen en el servidor. Desafortunadamente, Apache utiliza más recursos que nginx y por defecto no está configurado para manejar un alto número de visitantes al mismo tiempo.

Es posible configurar Apache para ejecutar PHP de diferentes maneras. La más común y más fácil de configurar es usando el módulo mod_php5 con el prefork MPM. Aunque no es el modulo más eficiente en cuanto al uso de la memoria, es el mas fácil de utilizar. Esta opción es la más viable si no está interesado en adentrarse en los aspectos de administrar un servidor. Cabe notar que si usa el módulo mod_php5, tiene que usar el prefork MPM.

Alternativamente, si desea sacar más rendimiento y estabilidad de Apache, entones puede tomar ventaja del mismo sistema de FPM que usa nginx y utilizar el worker MPM o el event MPM con mod_fastcgi o mod_fcgid. Esto le proporcionara una configuración más eficiente en memoria y mucho más rápida, aunque es más difícil de configurar.

Servidores Compartidos

PHP es un lenguaje popular gracias a su proliferación en servidores compartidos. Es difícil encontrarse con un servicio de alojamiento que no incluya PHP en sus opciones, sin embargo es importante que sea la versión más nueva. Los servidores compartidos le permiten a varios desarrolladores desplegar sitios web en un solo sistema. La ventaja de esto es que se ha convertido en una mercancía barata. La desventaja es que nunca sabe qué tipo de alboroto crearan sus inquilinos vecinos; La sobrecarga del servidor y los huecos abiertos de seguridad serían sus preocupaciones principales. Por esta razón, es recomendable evitar este tipo de servicios si el presupuesto de su proyecto lo permite.

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:

Build Automation Tools

Build tools can be described as a collection of scripts that handle common tasks of software deployment. The build 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, 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 is the easiest way to get started with automated deployment in the PHP world. With Phing you can control your packaging, deployment or testing process from within a simple XML build file. Phing (which is based on Apache Ant) provides a rich set of tasks usually needed to install or update a web app and can be extended with additional custom tasks, written in PHP.

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 people are successfully deploying PHP systems with it. Successful use of Capistrano depends on a working knowledge of Ruby and Rake.

Dave Gardner’s blog post PHP Deployment with Capistrano is a good starting point for PHP developers interested in Capistrano.

Chef is more than a deployment framework, it is a very powerful Ruby based system integration framework that doesn’t just deploy your app but can build your whole server environment or virtual boxes.

Chef resources for PHP developers:

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. Recently 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:

Regresar al Inicio

Caché

En sí, PHP es muy rápido, pero pueden surgir embotellamientos cuando realiza conexiones remotas, carga archivos y así por el estilo. Afortunadamente, existen varias herramientas disponibles para acelerar ciertas partes de su aplicación o reducir el número de veces que se ejecutan estas tareas que consumen tanto tiempo.

Caché de Bytecode

Cuando se ejecuta un archivo de PHP, detrás del telón primero se compila en bytecode (también llamado código de operación u opcode) y, solo entonces, el bytecode es ejecutado.

Si un archivo de PHP no es modificado, el bytecode siempre será el mismo. En este caso, el proceso de compilación se convierte en un desperdicio de los recursos del CPU.

Aquí es donde el caché de bytecode entra en acción. Este previene la compilación redundante al almacenar el bytecode en memoria y reutilizándolo en llamadas sucesivas.

La configuración del caché de bytecode toma solo unos minutos, pero su aplicación se acelerará notablemente. No hay en realidad ninguna razón por la cual no se debe utilizar.

Los cachés de bytecode más populares son:

Caché de Objetos

Hay ocasiones en que es de beneficio cachear objetos individualmente en su código, tal como los datos que se obtienen de una base de datos donde sabemos que el resultado no va a cambiar. En estos casos se puede usar el caché de objetos para guardar estos datos en memoria y estén disponibles para rápido acceso después. Si guarda estos datos en un almacén de datos después de que los solicita de la base de datos, y solo los recupera del almacén en futuras ocasiones, se puede obtener una mejora significativa en rendimiento, así como reducir la carga en los servidores de bases de datos.

Muchas de las soluciones de caché de bytecode populares también le permiten cachear datos personalizados, así que con más razón debe tomar ventaja de estos. APC, XCache y WinCache, proporcionan APIs para guardar al caché de memoria los datos que provienen de su código PHP.

Los sistemas de caché más utilizados son APC y memcached. APC es una gran elección para implementar caché de objetos, ya que incluye un API simple para añadir sus propios datos al caché de memoria y tiene una configuración muy simple. La una limitación de APC es que está vinculado al servidor donde ha sido configurado. Por otro lado, memcached, puede ser configurado como un servicio por separado y se puede acceder a través de la red, lo que significa que pueden guardarse objetos en un almacén de datos de alta velocidad y en una ubicación central y muchos otros sistemas pueden recurrir a él.

En una configuración de red, APC generalmente mostrará más rendimiento que memcached en lo que se refiere a la velocidad de acceso, pero es posible ampliar memcached a una capacidad mayor. Si no espera requerir de servidores múltiples para ejecutar su aplicación, o no necesita las características adicionales que le ofrece memcached, entonces APC es su mejor alternativa para el cacheo de objetos.

Ejemplo de lógica que utiliza APC:

<?php
// Verificar que los datos guardados como ‘datos_costosos’ existen en el caché
$datos = apc_fetch('datos_costosos');
if (!$datos)
{
    // Los datos no se encuentran en el caché, realiza llamada costosa y guárdala para después
    $datos = obten_datos_costosos();
    apc_store('datos_costosos', $datos);
}

print_r($datos);

Aprenda acerca de los sistemas de caché de objetos más populares:

Regresar al Inicio

Recursos

Directamente de la fuente

Gente a seguir

Mentores

Proveedores de PHP PaaS

Frameworks

En lugar de reinventar la rueda, muchos desarrolladores de PHP usan Frameworks para desarrollar nuevas aplicaciones web. Los Frameworks abstraen mucho del funcionamiento fundamental de la aplicación y proveen interfaces útiles y fáciles de usar para desempeñar tareas comunes.

No es necesario usar un framework en todos sus proyectos. A veces la mejor alternativa es utilizar PHP puro, pero si cree que necesitas un framework hay tres tipos disponibles:

Los micro frameworks son, en esencia, una envoltura para dirigir las solicitudes de HTTP a un controlador o método lo más rápido posible, y en veces incluyen otras librerías para asistir en el desarrollo, tal como envolturas básicas para bases de datos y así por el estilo. Estos frameworks son utilizados en su mayoría para desarrollar servicios remotos de HTTP.

Muchos frameworks añaden un número considerable de funciones y características sobre la base disponible en un micro framework. A estos se les conoce como frameworks full-stack (completos). A menudo, estos frameworks incluyen paquetes ORM para bases de datos, paquetes de autenticación, y otros.

Los frameworks de componentes son colecciones de librerías especializadas para un propósito en particular. Los componentes de estos frameworks pueden utilizarse con otras librerías para construir micro frameworks o frameworks full-stack (completos).

Componentes

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, which allow you to use their components with minimal (or no) requirements. For example, you can use the FuelPHP Validation package, without needing to use the FuelPHP framework itself. These projects are essentially just another repository for reusable components:

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.

Regresar al Inicio

Comunidad

La comunidad de PHP es una comunidad grande y con mucha diversidad. Sus miembros están listos y dispuestos para apoyar a los nuevos programadores en PHP. Usted debería considerar la posibilidad de unirse a un grupo local de usuarios de PHP (PUG, con sus siglas en inglés) o atender una de las conferencias enfocadas en PHP para aprender más acerca de las mejores prácticas expuestas en esta página. También puede asociarse en el canal de IRC, #phpc, disponible en irc.freenode.com y seguir la cuenta de twitter @phpc. Le exhortamos a que conozca a otros desarrolladores, aprenda más acerca de otros tópicos y, sobre todo, entable nuevas amistades.

Lea el calendario oficial de eventos de PHP

Grupos de Usuarios de PHP

Si usted vive en una ciudad grande, es muy probable que exista un grupo de usuarios de PHP cerca. Aunque no existe todavía una lista oficial de estos grupos, si puede encontrar fácilmente un grupo local usando Google o Meetup.com. Si usted vive en una ciudad más pequeña, quizás no haya grupos de usuarios locales. Si esa es su situación, ¡lo invitamos a que inicie su propio grupo!

Lea más acerca de los grupos de usuarios en el wiki de PHP

Conferencias de PHP

La comunidad de PHP también organiza conferencias de ámbito regional y nacional en muchos países alrededor del mundo. Miembros bien conocidos de la comunidad de PHP usualmente tienen intervenciones en estos eventos así que es una buena oportunidad para aprender directamente de estos líderes de la industria.

Encuentre una conferencia de PHP

Regresar al Inicio