El viernes un cliente me pidió un favor de ayudarle a terminar de instalar un script de un amigo en su servidor.Â
Todo parecÃa ser un simple problema con la importación de MySQL por los acentos, aunque eso solucionó parcialmente aún tenÃa un error en la parte medular del sistema, en cuanto abri el archivo que estaba dando el error me arrepentà de hacerlo y mi mente se volcó a recordar hace cinco años o tal vez seis cuando se programaba de esa manera =)
Con ese ejemplo me vino a la mente una frase célebre de mi buen amigo Nexus en esas épocas cuando estaba aprendiendo a programar en PHP, mi geek interno terco siguió programando con las antiquÃsimas $HTTP_POST_VARS a pesar de que se habÃan desalentado utilizar esas variables y se reemplazó por las variables tipo: $_POST ó $_GET
Recuerdo que cuando Nexus vio un código mio que tenÃa el $HTTP_POST_VARS me dijo en un chat con (me parece Carlos Cortez): “Programas a la manera viejita jajajaja”. Claro por orgullo después de eso nunca volvà a tocar $HTTP_POST_VARS
Aqui tengo unos consejos para que no solamente sea fácil programar, depurar y para otros leer tu código. También para evitar que PHP siga siendo visto como un lenguaje de “bajo presupuesto” (por aquello que muchos prefieren Java por lo ‘empresarial’)
Â
Tip: PHP dejó de ser un lenguaje de Script hace años
Lo digo en completo tono sarcástico, si bien PHP no se puede compilar no hay razón para meter todo dentro de un solo archivo como print’s con funciones, prácticamente se debe separar de preferencia en un modelo MVC si no puedes hacerlo, entonces al menos hazlo en VE (Vista-Espaguetti donde vas a meter tanto modelo como controlador)
Â
Tip: register_globals está muerto
Por eso me dio miedo abrir el archivo, necesitaba register_globals. Para el que no sepa que es register_globals es simplemente que cuando mandamos parámetros a un script como por ejemplo: prueba.php?variable1=hola&variable2=mundo PHP convierte automáticamente esas dos variables en $variable1 y $variable2 con su respectivo contenido.
Qué fácil, ¿No?. Pues en realidad no, cuando el mundo no se percataba del error fatal de hacer esto, parecÃa que PHP era tan fácil de programar, vaya no necesitabas ni siquiera  vincular los parámetros.
Poco después un balde de agua fria cayó sobre todos nosotros… el problema es que cualquier tipo con algo de sesos puede simplemente pasar variables y asignar valores de la aplicación. En el caso de una aplicación que no inicializara las variables (el 99% para ser sinceros) podÃa sufrir porque era fácilmente “hackeada” sin necesidad de hacer mucho.
Por eso rápidamente se eliminó register_globals y se dejó como un parámetro opcional, pero muy opcional. Tanto que en PHP 6 va a desaparecer definitivamente.Â
register_globals no ayuda, no hace más rápido el desarrollo; simplemente destruye todo lo bueno que podrÃa tener una aplicación, porque en primer lugar es difÃcil saber cuales variables son parámetros del usuario y cuales son variables internas. También hace fácil explotar un sistema (creo que ya lo habÃa dicho 
).
La solución para esto… reescribe tu aplicación.
Â
Tip: die() está muerto
¿Alguien se ha preguntado porqué existe esta construcción del lenguaje de PHP?, supongo que es un legado de los viejos dÃas cuando PHP era un lenguaje de script.
die() permite simplemente eso: hace que el script muera. Muchos lo hacÃan para verificar una situación intolerable como al abrir una conexión a una base de datos y que no se pudiera conectar; como no se pueden mostrar datos entonces simplemente le decimos al usuario: “perdon pero aqui nos detenemos” un ejemplo es el siguiente:
<?php
mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>
¿Cuál es el problema?, muy simple la función die funciona tan perfectamente que el script se muere ahi. Por lo que el usuario simplemente verá una pantalla blanca con un texto crÃptico. En el peor de los casos mostrará una parte de la página y la “cortará” donde se haya ejecutado esta instrucción.
No seas perezoso, utiliza construcciones de if() para separar bloques de instrucciones en vez de suicidarte.
Si aún asà quieres hacer un die() o un exit() al menos manda a llamar a una plantilla especial que muestre el error con la mayor parte del mismo estilo de la página que vas a mostrar, te lo agradecerá el usuario.
Â
Â
Tip: include y require es un arma de dos filos
También un legado de aquellos dÃas es que un script luzca como:
<?php include 'cabecera.php'; ?>
<?php print "Hola mundo 'plantilla'; ?>
<?php include 'pie_pagina.php'; ?>
En aquellos dÃas estas eran nuestras plantillas, cabecera.php mostraba el código inicial de HTML y pie_pagina.php cerraba ese código HTML, qué facil, ¿verdad?
Pues no, el problema de este método es que en primer lugar las variables son globales y compartidas, por lo que si haces el código espaguetti anterior es un total NO.
Por ejemplo es fácil sobreescribir variables dentro de un archivo “plantilla” y el error se propaga a las otras “plantillas”.
Otro problema es que hacen difÃcil seguir un flujo real de plantillas (si no quieres una parte tienes que reescribir todo en lugar de simplemente cambiar por ejemplo la distribución de los objetos en una plantilla general. También es fácil de romper todo el HTML por una etiqueta fuera de lugar
Una vez más, no seas perezoso y utiliza un manejador de plantillas como Smarty
Ahora bien del lado de programación un include() por lo regular es utilizado para incluir pedazos de código tales como funciones, clases, etc. Pero lamentablemente también es utilizado para incluir pedazos de código que tienen el mismo uso que funciones!!
Eso es algo totalmente prohibido, no se porque no utilizas funciones o mejor aún una clase.
Â
Tip: mysql_connect y sus vicios
Un legado también de aquellos dÃas es que se programaba de la siguiente manera:
<?php
include 'configuracion_db.php';
mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>
donde configuracion_db.php era simplemente:
<?phpÂ
$host = 'localhost';
$usuario = 'mi_usuario';
$password = 'mi_password';
?>Â
El primero se incluia prácticamente como cabecera para todas las páginas porque necesitaban acceso a la base de datos, y también se incluia dentro de otros bloques dentro de la misma página.
O peor aún, incluir en cada archivo los parámetros de configuración. Esto último es simplemente un caos y es no saber programar, asà que toma un curso de programacion básica en otro lenguaje antes de programar en PHP
Para el primer caso si bien es válido, es simplemente malo debido a que otro script puede fácilmente sobreescribir esas variables (o el mismo script por error). Aunque es utilizado, es muchÃsimo mejor utilizar un patron de diseño llamado: Singleton
El Singleton es un patron de diseño muy simple, en términos de orientación a objetos es un método estático de una clase que regresa siempre la misma instancia de la clase. Es decir solamente existirá un objeto en todo el sistema y que lo creará ese método estático normalmente llamado: obtenerInstancia()
En lenguaje de funciones es simplemente una función que regresará la misma variable (tendrá la misma dirección de memoria) cada vez que se llame, asà que en lugar de hacer el primer ejemplo utiliza este:
<?php
function obtenerConectorMysql() {
   static $conector_mysql = null;Â
   if ($conector_mysql == null) {
     //aqui insertar las instrucciones para obtener el host, usuario y password,Â
     // por ejemplo de un archivo o simplemente escribirlas aqui
     $conector _mysql = mysql_connect($host, $usuario, $password);
   }Â
   return $conector_mysql;
}
Â
Esto simplemente crea la primera vez que se llame el conector_mysql, después simplemente lo regresa por lo que no se crean diferentes instancias, es la misma conexión a MySQL
Si lo quieres hacer mediante clases, puedes utilizarlo algo similar como una llamada a una función estática o “envolverlo” en la clase que tengas para manejar la base de datos.
Tip: La seguridad no es para sitios de comercio o bancos solamente
Mucha gente piensa que debe hacer “seguro” un sitio solamente si va a tener operaciones monetarias. Nada más fuera de la realidad.Â
Todos los sitios necesitan seguridad para evitar que los ataques logren su resultado: hacer “explotar” la aplicación.
Evitando los errores más comunes tendrás una aplicación que si bien no es tan segura como la de la CIA (lease con sarcasmo) evitará el 90% de los ataques comunes.
- Al desarrollar una aplicación, recuerda que el usuario no es de fiar, por lo que todo lo que provenga del usuario puede ser alterado
- Siempre verifica la información que el usuario envió mediante parámetros. Si es posible restringe mediante un arreglo de valores válidos, si no es posible entonces haz muchas verificaciones, por ejemplo en el caso de un archivo, elimina caracteres peligrosos como: ‘..’ o ‘/’ que pueden hacer que el sistema lea (o incluso escriba) un archivo muy diferente al planeado.
Esto se hace indispensable si vas a utilizar una función poderosa como include() o acceso al archivo (como fopen() )
- Nunca pongas datos importantes en una
cookie, utiliza sesiones. Si lees datos de una cookie nunca asumas que por ser cookie es dificil de alterar
Si los datos van a “perdurar” más alla de una sesión, entonces deja en la cookie un identificador único y guárdalo en la base de datos, de esta manera el usuario solo debe proveer su identificador y no otra información que pudiera ser alterada.Â
- Siempre “escapa” las variables que vas a utilizar en una consulta a la base de datos, utiliza funciones como:Â
mysql_escape_string(), si utilizas un framework la mayorÃa de ellos tienen una función para hacer esto (que terminan llamando a algo similar a la primera función)
Â
Tip: PHP5 no es una opción, es obligatorio >=)
No veas a PHP5 como una “extensión” o una versión más. El propósito de PHP5 es hacer una transición entre el mundo de scripts de código espaguetti a un sistema de clases muy bien separadas.
Aunque PHP5 aún permite programar sin clases y con solo funciones; si tienes la oportunidad no dudes en utilizar PHP5 con clases con todo lo nuevo que trae. La guia de estudio de Certificación Zend es un buen inicio.Â
PHP5 tiene un gran potencial y está esperando para ser plenamente utilizado, algunos frameworks ya están utilizando plenamente su potencial, entre ellos Zend Framework que es altamente recomendable.
Â
Último tip: MVC es lo único para web
Si vas a desarrollar una aplicación en PHP que contenga todo lo que una aplicación web contiene (contenido en HTML, bases de datos, procesamiento, etc) simplemente utiliza un framework que tenga un diseño de MVC; los más conocidos son Zend Framework (mi recomendación nuevamente) y CakePHP, también están otros en rápido ascenso como Simfony y Code Igniter
También son de uso popular los CMS como drupal y joomla/mambo, aunque ellos no proveen directamente el modelo MVC si proveen el modelo Vista-Espaguetti por lo que con un poco de trabajo extra puedes lograr algo similar a MVC
Â
En resumen PHP es un lenguaje muy poderoso y con historia; por lo que es fácilmente quedarse con las primeras formas de programar, pero con todos los nuevos desarrollos ahora si se puede empezar a hablar de un PHP a nivel empresarial (ya formalmente )
Â