David Esperalta

En PHP existe algo conocido como "magic quotes", una directiva de configuración, que, estando activada, se encarga de "escapar" determinados caracteres especiales, como son las comillas dobles o sencillas, directamente, sin más ni más, desde las variables de entrada del usuario, "GET", "POST", etc. Cómo será esta puñetera directiva que se considera obsoleta, que no va a estar disponible en PHP 6, y es que causa más problemas, tal vez, que las posibles soluciones que aporta. Al menos tal y como yo lo veo ahora, después de haberme estado toda una noche pegándome con este asunto, ¡que salí escaldado!

¿Qué es lo que ocurre con la famosa directiva "magic quotes"? Pues que no es consistente, por decirlo así, que en unos servidores está activa, y en otros no, que no causa problemas con ciertos datos, pero, sí con otros, en fin, ¡que no hay quien se aclare con ella! Y más sabiendo que desde el propio equipo de PHP se considera obsoleta, como ya he dicho, y, textualmente, dice el manual de PHP, "basar nuestro trabajo en esta directiva no se recomienda en absoluto". Ahora pongámonos en situación, y veamos una función crucial en cualquier sistema desarrollado en PHP, que de una u otra forma ha de existir: una función para escapar datos antes de incluirlos en una consulta SQL.

public function Escape($input){
  if(get_magic_quotes_gpc()){
    $input = stripslashes($input);
  }
  return mysql_real_escape_string(
    $input, $this->dbConnection);
}

Efectivamente, esa función, en realidad es un método de cierta clase "MySql" que vengo usando hace tiempo, y, el método en cuestión implementa el "escape" de caracteres exactamente como se recomienda en el manual de PHP. Se comprueba si la puñetera directiva "magic quotes" está activa, y, de ser así, se aplica la función "scripslashes", y, en todo caso, se aplica sobre la cadena a filtrar la función "mysql_real_escape_string". Hasta ahí todo bien, ya digo, tal como reza el manual de PHP, pero, amigo mío, ahí empiezan los problemas. Continuar leyendo...

Para gestionar las bases de datos MySQL conque cuento en mi "localhost", generalmente, me apaño bien con phpMyAdmin, y, cuando he necesitado ir un poco más allá, las propias herramientas de MySQL me han parecido más que suficientes. Sin embargo, reconozco que el programa HeidiSQL, desarrollado con Delphi, por cierto, y, del que me entero gracias a la bitácora de Javier Gutiérrez, digo, tiene una pinta excelente y todas las características que uno puede esperar de este tipo de herramientas.

Efectivamente, HeidiSQL es un completo gestor de MySQL, creo que lo digo bien, de código abierto y gratuito, por añadidura. Desde este programa es posible controlar el servidor de MySQL, importar, exportar, crear, editar bases de datos, realizar consultas SQL, etc., etc. Tal vez la única pega es que existe sólo para Windows, cuando el "SQL Explorer" que ofrece MySQL está disponible también en otros sistemas operativos, aunque desarrollado para la plataforma Java.

Por eso mismo, lo que es una desventaja de HeidiSQL, pensando en los usuarios de otros sistemas operativos, para los usuarios de Windows supone una ventaja: y es que HeidiSQL está desarrollado en Delphi y es un programa "nativo", mientras que "SQL Explorer" no lo es, lo que significa que el rendimiento de HeidiSQL debe ser superior al de "SQL Explorer", sin dejar de ser este último un excelente programa. En fin, para gustos los colores. Desde luego, si estás interesado en un gestor para MySQL para Windows, no dejes de echar un vistazo a HeidiSQL.

Probablemente conoces el proyecto XAMPP, que, agrupa en un sólo paquete, en un solo asistente de instalación, diferente software, principalmente, Apache, MySQL y PHP. Bueno, sin ir más lejos, es posible que hayas oído hablar de mi proyecto "localhost"... que viene a ser algo parecido. En ambos casos se trata de tener, de la manera más sencilla posible, al servidor web Apache, a MySQL y a PHP funcionando, en cuestión de minutos. No se recomiendan este tipo de instaladores para entornos "de producción", pero, son muy útiles para desarrollar sitios web, por ejemplo, porque en un momento tienes un "entorno de pruebas" con prácticamente todo lo necesario.

Pues bien, quizás es menos conocido el proyecto WLMP, que aúna en un mismo asistente de instalación al servidor web Lighttpd, junto con MySQL y PHP. En este caso, al contrario que el proyecto XAMPP, WLMP está disponible sólo para Windows, aunque, efectivamente, funciona tal como se espera, si eres capaz de pasar por encima de que parte de su asistente de instalación está en polaco o quizá otro idioma similar (lamento la inconcrección), cosa que es perfectamente asumible, porque, el asistente de instalación pasa del "Siguiente... siguiente" que ya sabemos, y utilizar el servidor web, MySQL y PHP, no debería ser ningún problema para nosotros.

El caso es que WLMP es una forma sencilla de tener en marcha el servidor Lighttpd en pocos minutos, junto con MySQL y PHP, de modo que podamos probar aquello que necesitemos, como he hecho yo con Gesbit, que, tengo que decirlo, ya está probado que funciona tanto en el servidor Apache, como en el servidor Lighttpd. En definitiva, que no está demás saber cómo instalar por nuestra cuenta todo este distinto software, pero, tampoco viene mal, en un momento dado, contar con proyectos como XAMPP y WLMP, que nos hacen la vida un poco más fácil. XAMPP para cuando sea preciso Apache, y WLMP para cuando se necesite Lighttpd.

Me entero en Error500 de la compra de MySql por parte de Sun Microsystem, por la que habría pagado la cantidad de 1.000 millones de dólares.

Como dice Antonio en Error500 es pronto aún para ver qué deparará el futuro a MySql. Él espera que las licencias de esta sean más abiertas aún. ¡Ojalá!

Como sabes, MySql es un motor de bases de datos relacionales muy utilizado en todo tipo de proyectos en Internet. Ojalá esta compra sirva para que MySql siga mejorando.

Tanto en el sitio web de MySQL como en el sitio web de Sun MicroSystem informan sobre este asunto, que, sin duda dará que hablar en el futuro, esperemos que bien.

Actualización: En Barrapunto se hacen eco de la noticia.

Actualizo hoy el "proyecto localhost" para incorporar la última versión de PHP 5.2.5 y la última versión de phpMyAdmin 2.11.2.1.

Además el "control de localhost" también ha sufrido cierto cambio. Ahora, antes de iniciar los servicios Apache y MySQL, estos se detienen, si estuvieran en marcha. De esta manera es más sencillo cambiar de PHP 4 a PHP 5, sin necesidad de detener los servicios primero, para luego iniciarlos de nuevo.

¿Qué necesita Gesbit para funcionar? La verdad es que como, por el momento, sólo estoy "corriendo" Gesbit en mi "localhost" (nunca mejor dicho, bueno, más o menos) los requisitos de Gesbit se cumplen con lo que mi "localhost" proporciona, es decir:

• Apache 2.2.4
• PHP 5.2.4
• MySQL 5

Con esas versiones de ese software estoy "haciendo" Gesbit. Apache, además, necesita tener activado el módulo "rewrite". Uso Windows, pero, nada hay en el sistema que haga uso de "cosas" exclusivas de Windows o de GNU/Linux.

Para mí tengo que Gesbit podría funcionar en versiones anteriores de MySQL, pero, esto, ni lo he probado, ni estoy puesto en MySQL como para asegurar una cosa u otra. Solamente supongo que puede funcionar en versiones anteriores, porque, hasta donde llego, no hago uso de "cosas" exclusivas de MySQL 5.

Respecto de la versión de Apache puedo decir lo mismo que de MySQL. Es posible que Gesbit funcione en versiones anteriores de este servidor HTTP, mejor dicho, del servidor HTTP. Teniendo el módulo mencionado disponible, ya digo, es posible que Gesbit pudiera funcionar.

Lo que hace falta sí o sí es PHP 5. En primer lugar porque la "notación" del código fuente requiere de esta versión de PHP. La verdad es que en esto último podía haberlo pensado dos veces, puesto que, el uso que le doy a PHP 5 es muy similar al que podría dar a PHP 4.

Por ejemplo, las excepciones, disponibles en PHP 5, no estoy utilizándolas, entre otras cosas, porque, no estoy tan puesto con ellas como pueda estarlo en un lenguaje como Delphi, que, si bien no soy ningún experto, creo que me defiendo un poco, al menos.

Y en segundo lugar, no hago uso de excepciones porque por el momento no estoy teniendo necesidad de ellas: probablemente porque al no conocer bien cómo funcionan en PHP, simplemente, no las tengo en la cabeza, y trabajo "como si no existieran", nunca mejor dicho, ahora sí.

En fin. Groso modo esos son los requisitos de Gesbit. :P

En fin, sé que no te importa nada, pero, te recuerdo que estamos tratando de dilucidar el nombre de la criatura... y tú puedes colaborar a ello.

Hay que jorobarse con las MySQL tools, o herramientas de MySQL. Que son estupendas, digo, además de estar disponibles en Windows y Linux, por lo menos. ¿O debería decir GNU/Linux? Bueno.

Generalmente me apaño bastante bien con phpMyAdmin, y hay que reconocer que también es un programa fenomenal, sin embargo, MySQL Query Browser me ofrece lo que el primero fuera del navegador, de modo que todo va más fluido.

Es natural. No sé si el programa está escrito en Java, pero, desde luego su presencia es prácticamente la misma en Linux que en Windows, y, como digo, en todo caso ofrece características muy curiosas, como el poder trabajar con varias consultas MySQL en el mismo "editor", ejecutando una u otra a conveniencia.

Ya no hablemos de MySQL Administrator. Este te cuenta al detalle qué está pasando en el servidor de MySQL. La verdad es que yo no sé hasta dónde alcanza el detalle, pero, el programa consigue no poca información acerca del servidor de MySQL y la muestra en una interfaz bastante conseguida, a mi modo de ver.

Si a todo lo dicho sumamos que estas herramientas de MySQL están disponibles gratuitamente y recordamos que están disponibles para varios sistemas operativos... ¿cómo no tenerlas por ahí, saber que existen, y echar de ellas mano cuando sea menester? Pues eso.

Todo iba bien con SMC, relativamente, como habrás podido comprobar por mis entradas eufóricas de estos últimos días sobre el asunto. Todo iba bien, relativamente, digo, hasta que he topado con las categorías.

Mi fuerte, desde luego, no es SQL. No es MySQL. No son las bases de datos. ¿Qué sé yo, si apenas he leído sobre ellas? Y así he llegado al punto en que me planteo las categorías para las entradas de SMC...

He visto como lo soluciona WordPress, y, por primera vez en SMC, he sentido la tentación de copiarlo, directamente. Pero, claro, si no sé qué estoy haciendo... cómo narices voy a copiar nada... y además, copiar se dice muy fácil, porque habría que saber al menos qué se quiere copiar y cómo hacerlo.

En la base de datos de WordPress existen tres tablas que tienen que ver con las categorías de las entradas. En una tabla se guarda información sobre las propias categorías, puesto que estas pueden ser categorías de enlaces o de entradas, por lo menos.

Otra tabla relaciona esta primera con una tercera, donde se guardan, propiamente, los nombres de las categorías. Y yo estoy absolutamente perdido en todo esto. Tengo la estructura de las tablas ahí delante, pero, es como si mirara la luna embobado.

Pienso partir de cero, es decir, llegar a una respuesta a la pregunta "¿Cómo lo harías tú?", pero, me temo que no voy a ser capaz de seguir adelante, y quizás lo tengo más que merecido, por meterme en camisas de once varas, por no pensar las cosas bien antes.

En fin. También puedo dejar pasar un poco el tiempo... como ahora mismo hago escribiendo esto. A ver si de algún modo se me aclaran las ideas, como suele decirse.

Acabo de actualizar el proyecto "localhost" a la versión 1.2. He actualizado el programa phpMyAdmin y he eliminado del "paquete" a phpDocumentor, para ahorrar el espacio que ocupaba, y porque lo considero "opcional" y no más o menos necesario.

Otro de los cambios es que ahora se incluye un usuario "root" con cierta contraseña en MySQL, de modo que para acceder al programa phpMyAdmin es preciso proporcionar dichos datos de usuario. Se ha determinado una contraseña "por defecto", pero, cada quien debería cambiarla para mayor seguridad.

Al menos eso me parece a mí, pero, a simple vista, a ojo de buen cubero, no es que me haya puesto a hacer "pruebas intensivas" ni nada de eso.

Es sólo que estoy migrando cierto proyecto y no sé, me da la sensación de que con PHP5 va mejor que con PHP4, más fino, como digo, más rápido, también.

Claro que como también estoy utilizando nuevas versiones de Apache y MySQL... lo más seguro es que esto también tenga algo que ver, es lo más probable, parece hasta obvio.

En fin. Ahí sigo liado. Ayer me pegaba con PHP-GetText y ahora me toca pegarme con The Incutio XML-RPC Library for PHP. Tampoco tiene versión para PHP5. Sin embargo, igual todo resulta tan, aparentemente, sencillo, que con PHP-GetText.

Básicamente se trata de que en PHP5 cada clase ha de ir en un archivo distinto. Y este archivo, como el del resto de las clases, ha de seguir una "norma", tiene que tener un nombre adecuado, justamente, para que pueda ser cargado por la función "__autoload()" de PHP5.

Se acabaron las largas listas de "require" para incluir archivos con las clases que vayamos a necesitar. La función susomentada se encarga cada vez que se requiere una clase, y, si esta no está ya disponible, se encarga, digo, de tratar de incorporarla al Script.

PHP4 ha muerto... ¡viva PHP5! :P