En esta última semana he comenzado a participar en un nuevo proyecto. Consiste en hacer una auditoría del rendimiento y la calidad del software de una aplicación implementada con tecnología PHP. El problema está en que la aplicación va degradando el servidor de aplicaciones web Apache hasta que este provoca una denegación de servicio y es preciso reiniciarlo.

Para esta auditoría se van a utilizar diversas herramientas:

1. Análisis del rendimiento de la aplicación web. En esta parte se localizarán los cuellos de botella en tiempo de ejecución y en definitiva los motivos por los cuales la aplicación consigue degradar el servidor hasta el punto de hacer que provoque la denegación de servicio antes comentada. Para ello se van a utilizar dos herramientas, The Grinder y XCacheGrind.

• The Grinder. Me la recomendó mi compañero Antonio, y es simplemente espectacular. Es una herramienta basada software libre y su funcionamiento e instalación es muy simple, está basado en una consola central y en uno o varios agentes, cada uno de estos agentes (que son distribuidos entre distintas máquinas físicas) despliega una serie de workers y cada uno de estos workers despliega los hilos que los agentes tengan configurados. Además proporciona un proxy que nos permite realizar las pruebas UI fácilmente con cualquier navegador.

Esquema de funcionamiento de The Grinder

• XCacheGrind. Esta herramienta tiene dos variantes WinCacheGrind y KCacheGrind y permiten visualizar gráficamente el consumo de tiempo que cada una de las funciones o scripts PHP ha tardado en ejecutarse y otra información que puede ser de interés para realizar las tareas de profile. Para ello hace uso de los logs que proporciona XDebug, que se tendrán que configurar con los siguientes parámetros:

xdebug.remote_autostart = On
xdebug.remote_enable=On
xdebug.profiler_output_dir = “/home/aclr/kcachegrind/”
xdebug.trace_output_dir = “/home/aclr/kcachegrind/”
xdebug.profiler_append = On
xdebug.profiler_enable = On
xdebug.auto_trace = On

Veamos un ejemplo de la información que obtenemos haciendo uso de estas herramientas:

<?php
function escribe($cad){
echo $cad.’<br/>’;
}

for($i = 0 ; $i < 100 ; $i++){
for($j = 0; $j < 100 ; $j++){
escribe(“hola”);
}
}
?>

Como se puede apreciar en esta imagen solo el 9.6% del tiempo consumido en la ejecución es utilizado por la función escribe, el resto, el 99.4% del tiempo de ejecución se ejecuta en el main, es decir, en el bucle, en un caso real una situación análoga a esta nos diría que tenemos que tratar de centrar nuestros esfuerzos de optimización en el main, no en la función escribe.

En próximas entradas intentaré hablar un poco más en profundidad de The Grinder y sobre las herramientas que se utilizarán para el análisis de la calidad del código.

Aunque me gusta terminar mis posts con la cita de alguna frase célebre que trate o evoque sobre el tema del que versa el post, esta vez voy no podrá ser, son las 2:04 y me voy a la cama

Hace algún tiempo comenzamos con el desarrollo de un proyecto utilizando tecnología OpenCms, como fruto de este trabajo hemos liberado cinco nuevos módulos que esperamos sea de utilidad para la comunidad (los módulos están modelados con maven y documentados con docbook):

RestrictedVFSWidget

Este módulo es una evolución del wdiget de exploración de OpenCms, con él se modelará el comportamiento de un árbol de exploración del directorio virtual de OpenCms en el que tan sólo se mostrarán los directorios y aquellos tipos de contenidos que se hayan configurado en la declaración del tipo de contenido que lo use.

SurveyModule

Con este módulo se amplía el funcionamiento del módulo Alkacon OAMP Survey Module, de manera que se ofrece la posibilidad de generar las gráficas de los informes en flash mediante Open Flash Chart.

Modulo Alfresco

El objetivo de este módulo es proporcionarle a los usuarios de OpenCms una herramienta con la que asignar recursos de un gestor documental Alfresco para ser utilizados en el portal. De esta forma se consigue separar la capa de gestión de contenidos de la capa de gestión documental, pudiendo aprovechar todas las funcionalidades que un gestor documental como Alfresco proporciona.

Georeference

Este módulo permite llevar a cabo la geolocalización de puntos a través de Google Maps, estableciendo las localizaciones directamente sobre un mapa que se muestra en el formulario de alta/edición de contenidos de OpenCms.

Thesaurus

El objetivo de este módulo es proporcionarle a los usuarios de OpenCms una herramienta con la que etiquetar los contenidos (noticias, eventos, etc) que se utilicen en el portal.

El software es como el sexo, es mejor cuando es libre. Linus Torvalds

Hace ya algo menos de un año que comencé a trabajar con el gestor de contenidos OpenCms 7.0.5, durante este tiempo he desarrollado nuevos tipos de contenidos, widgets personalizados y puntos de administración, para el desarrollo de estas tareas me he servido de muchos recursos online pero sobre todo me ha sido de gran utilidad el foro de la comunidad de OpenCmsHispano, es por ello que he decidido realizar este tutorial cuando el otro día me encontré con este mensaje, manos a la obra.

Un punto de administración en OpenCms es una entrada en la vista de administración del gestor de contenidos con la que podremos realizar ciertas operaciones, OpenCms trae en su distribución básica una serie de entradas de administración con la que se podrán llevar a cabo tareas de administracion de usuarios, módulos, caché, etc, así como los mecanismos necesarios para extender con nuevas entradas estas funcionalidades de administración

Vista de administración del workplace

Para crear un nuevo punto de administración en OpenCms deberemos crear la correspondiente estructura de directorios en /system/workplace/admin es en este directorio donde se definen los puntos de administración a través de la creación y edición de propiedades de los directorios.

Correspondencia con la zona de administración

En este tutorial vamos a crear un nuevo punto de administración en OpenCms denominado “Personas” que nos permitirá hacer CRUD de entidades de tipo persona, para ello he desarrollado un nuevo módulo que he denominado “PersonManagement”. Como veréis cuando instaléis el módulo (y reincieis el servidor de aplicaciones) el módulo genera un nuevo directorio /system/workplace/admin, si accedemos a las propiedades de este directorio veremos que se encuentran editadas las siguientes propiedades:

• Description: Establece el texto que se mostrará en la caja “Ayuda” de la zona de administración.
• NavImage: Establece la imagen que se mostrará en la zona de administración.
• NavInfo: Establece el nombre del grupo al que pertenecerá el nuevo punto de administración.
• NavPos: Establece con un número real (float) la posición que ocupará el icono del nuevo punto de administración.
• NavText: Establece el texto que aparecerá bajo el icono del punto de administración.
• Title: Establece el título del directorio aunque no es de utilidad dentro de la zona de administración.
• admintoolhandler-class: Establece la clase que se ejecutará para hacer la gestión de los permisos de acceso al punto de administración.
• default-file: Establece la página jsp que se ejecutará cuando accedamos a ese directorio.

Propiedades del directorio

Si accedemos a este directorio veremos que podemos encontrar tres páginas jsp person_list.jsp (genera el listado de los elementos), person_edit.jsp (genera el formulario de edición de los elementos de tipo persona) y person_new.jsp (genera el formulario de creación de elementos de tipo persona), si accedemos a cada una de estas páginas veremos cómo podemos encontrar un fragmento de código que sigue el siguiente patrón:

<%@page import=”paquete.de.la.clase.*”%>
<%
NmbreClase admin = new NmbreClase(pageContext, request, response);
admin.displayDialog();
%>

Como podemos observar para generar el formulario solo necesitamos una clase, que extenderá las correspondientes clase de OpenCms, y que se encargará de generar todo el código html necesario para
generar un listado o un formulario de edición o de alta.

En estas páginas jsp también es necesario editar las propiedades para que el contenido de dichas páginas se muetren correctamente.

También me gustaría haceros un par de recomendaciones para el desarrollo de funcionalidades con OpenCms:

• Código fuente de OpenCms.
• El libro OpenCms 7 Development.

Código del módulo

La información compartida progresa y mejora, de manera que su valor sólo puede aumentar. El conocimiento acaparado simplemente se detiene. Paul Jones, director de ibiblio.

En el proyecto en el que actualmente estoy trabajando tiene la necesidad de incorporar un servicio de mensajería instantánea (IM), como punto de partida mi compañero Manu me recomendó que empezara estudiando la tecnología que había desarrollada alrededor del protocolo Jabber (protocolo libre IM basado en XML).

Alrededor de este protocolo hay toda una comunidad de software libre que se dedica al desarrollo tanto de servidores como de clientes XMPP. Entre todos los servidores que estuve evaluando me decanté por uno que por su extensibilidad, tecnología y comunidad me convenció, Openfire. Se trata de un servidor de código abierto basado en Java, extensible a través de plugins y desarrollado por la comunidad bajo licencia GPL.

Como comentaba antes en el proyecto existía la necesidad de integrar un servidor de mensajería instantánea, la integración de Openfire con Opencms, el CMS que estamos utilizando, consistía en la autenticación de los usuarios. Para conseguirlo hemos tenido que hacer dos cosas, una del lado de OpenCms y otra de Openfire.

OpenCms

Hemos desarrollado un módulo de OpenCms que ofrece un servicio web con dos operaciones para realizar la autenticación de usuario, a este servicio web solo hay que pasarle el usuario y la contraseña encriptada, él se encargará de comprobar que el usuario y la contraseña son correctos así como de chequear toda la lógica de negocio, devolviendo un objeto en el que se indica si el proceso ha sido correcto.

Openfire

En este caso hemos desarrollado un plugin que cuenta con un cliente para el servicio web y que es el encargado de hacer la petición. Para que Openfire realice la autenticación utilizando la clase que hemos desarrollado, y que ha de implementar la interfaz (AuthProvider), en el método de inicialización del plugin hemos de cambiar la propiedad provider.auth.className para indicarle que utilice nuestra clase, es sumamente importante que previo a este paso hayamos registrado en el classpath del plugin dicha clase.

Una vez hecho esto, OpenCms y Openfire ya se conocen ;-p

No hay lugares remotos. En virtud de los medios de comunicación actuales, todo es ahora. Herbert Marshall Mcluhan

En este post voy a explicar un tema muy específico: cómo generar un módulo de OpenCms 7.0.5 que despliegue un web service sobre mismo contexto de OpenCms 7.0.5.

Para ello me recomendaron que me basara en la arquitectura Axis2 de Apache.

Antes de comenzar es muy importante que se haya comprendido cómo se ha de trabajar con un módulo de OpenCms 7.0.5 y Maven, para ello me gustaría recomendaros el estupendo post que en su día escribió mi compañero Antonio Manuel Muñiz respecto a este tema.

El primer paso que debemos dar para poder desplegar servicios web sobre el contexto de OpenCms, a través de un módulo, es preparar la instancia de OpenCms para tal propósito, para ello crearemos dentro del directorio “WEB-INF” un nuevo directorio “services” tal y como se muestra en la siguiente ilustración:

Estructura de directorios

A continuación deberemos modificar el fichero web.xml de OpenCms para declarar el servlet de Axis2 que se encargará de atender las peticiones a los servicios web que declaremos.

<servlet>
—-<servlet-name>AxisServlet</servlet-name>
—-<display-name>Apache-Axis Servlet</display-name>
—- <servlet-class>org.apache.axis2.transport.http.AxisServlet</servlet-class>
—-<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
—-<servlet-name>AxisServlet</servlet-name>
—-<url-pattern>/services/*</url-pattern>
</servlet-mapping>

Una vez hecho esto, crearemos un módulo de OpenCms y modificaremos las directivas “<exportpoint />” del fichero “manifest.xml” para que OpenCms copie en el directorio “/WEB-INF/services” los servicios web desplegados como ficheros .aar

<exportpoint uri=”/system/modules/com.test.webservice.regard/services/” destination=”WEB-INF/services/”/>

Lo que tenemos que hacer a continuación es generar el fichero pom.xml necesario para que realice dos tareas fundamentales: obtener las librerías necesarias para que los servicios web puedan funcionar sobre la instancia de OpenCms y para que genere el fichero .aar a partir de los fuentes que le indiquemos.

Una vez hecho todo lo anterior tendremos listo el módulo para poder generar servicios web que corran dentro del mismo contexto que el OpenCms sobre el que se despliegan y, por tanto, puedan acceder a su información, para ello lo último que tendremos que hacer será generar un Singleton o un método dentro de la propia clase que se encargue de iniciar un objeto de la clase CmsObject que será el objeto a partir del cual podremos realizar todas las operaciones necesarias. Para llevar a cabo el desarrollo del servicio web para Axis2 os recomiendo el siguiente post.

Una vez hecho todo lo anterior ya solo nos quedará desplegar el módulo OpenCms y probar el nuevo servicio web a través de algún programa de generación de clientes.

Respuesta positiva

Respuesta negativa

Aquí dejo el módulo por si os es de utilidad.

Hace ya algún tiempo leí un post en el que Justin Carmony hacía una comparación de dos IDE´s para trabajar con tecnología PHP, Zend Studio  y Eclipse PDT. Me gustaría seguir la tarea que comenzara Justin (como se puede observar por el título del post) haciendo una comparación entre dos IDE´s de desarrollo de software libre, Eclipse PDT y la que podría ser la estrella revelación de la temporada NetBeans IDE 6.5.

Ahora bien, qué factores podríamos evaluar sobre estos dos IDE´s, Justin nos propone 6, veáse: facilidad de instalación, refactoring, PHP Unit testing, debugging, editor y Zend Platform & Zend Framework. A mí me gustaría plantear los siguientes factores: code completion, code errors y project plan, aunque también comentaré algo sobre los primeros.

Debbuging.

Esta primera característica es una de las que Justin evalua en su post. Tras haber trabajado un tiempo con PHP PDT me he podido percatar que durante la depuración la profundidad de exploración no pasaba de 3, este problema no lo tenemos en NetBeans, como podemos ver en las imágenes.

Code completion.

Con este factor se evaluará la capacidad del IDE para completar el código, facilitando de esta manera la programación. Aunque tanto PDT como Netbeans poseen esta característica, la ejecutan de forma distinta, mientras que Netbeans completa el código tanto de las funciones y métodos que hemos definido, como de las funciones existentes en el core y extensiones de PHP, PDT lo hace tan solo de los métodos y funciones que están definidos en el proyecto actual.

Code errors.

Con este factor se evaluará la capacidad del IDE no sólo para mostrar los errores que se pueden producir durante la programación, sino también la claridad y completitud de los mismos. En este factor la diferencia es más clara, como podemos observar en las siguientes imágenes.

Project plan.

Con este factor se pretende evaluar el roadmap de ambos proyectos, ya que éste nos indica las líneas de trabajo que se están siguiendo e incluso podremos solicitar qué líneas de trabajo nos gustaría que se siguieran. En la wiki del proyecto Netbeans podemos ver cuáles son las características que se van a implementar en futuras releases del IDE e incluso ¡¡¡votar por las que más nos interesen!!!, entre ellas podemos encontrar algunas muy interesantes como PHP Unit Support, Support for Symfony, PHPDocumentor integration y otras muchas. En el roadmap de PDT IDE podemos encontrar cuál será el mantenimiento evolutivo del proyecto, de las características que están planeadas implementar llama la atención, personalmente: Code Template y Code Assit for Dynamic Variables.

La construcción exitosa de toda máquina depende de la perfección de las herramientas empleadas. Charles Babbage

Después de todo este tiempo sin escribir me gustaría hablar de dos gestores de contenidos con los que he estado trabajando durante este tiempo, OpenCms 7 y Drupal 6.

Alguien me enseñó que en los proyectos de gestión de contenidos a la hora de seleccionar el CMS con el que vamos a trabajar nos interesa tener en cuenta, entre otros, tres factores: comunidad que existe tras el producto, facilidad para modificar la funcionalidad que el CMS nos proporciona y facilidad para modificar su aspecto visual para adaptarlo a la entidad corporativa del cliente, analicemos estos factores para los dos gestores de contenido que nos ocupan.

OpenCms 7 es un gestor de contenidos open source desarrollado por la empresa Alkacon Software haciendo uso de Java y XML. Para su instalación necesita un contenedor de aplicaciones como Tomcat y un SGBD como MySQL. El proceso de instalación es fácil, ya que tras su despliegue en el contendor de aplicaciones tan solo es necesario seguir un gestor de instalación que nos irá solicitando los datos necesarios para llevar a cabo la instalación del CMS. La idea de OpenCms va un poco más allá, además de proporcionar el propio gestor de contenidos, este CMS intenta proporcionar un IDE a través del cual poder realizar nuestros desarrollos.

Drupal 6 es un gestor de contenidos open source que fue originalmente desarrollado por Dries Buytaert y es usado para impulsar los sitios web Debian Planet, Spread Firefox, Kernel Trap y más. Para su instalación necesita un servidor web como Apache y un SGBD como MySQL, al igual que ocurre con OpenCms, Drupal proporciona un gestor de instalación paso a paso.

Estos dos CMS tienen en común que proporcionan un marco de trabajo con una serie de funcionalidades básicas y la capacidad de extender dichas funcionalidades básicas a través del desarrollo de nuevos módulos, funcionales, de contenido y de visualización (skins), a partir de aquí todo es distinto, veámoslo:

Comunidad

Cuando empezamos a utilizar estos dos gestores de contenidos vemos, a la luz de las búsquedas, que existe una gran diferencia entre las comunidades de OpenCms y de Drupal, podríamos fijarnos en el número de módulos que la comunidad de Drupal a aportado y el número de módulos de la comunidad de OpenCms.

Extensión funcional

La extensión funcional de estos dos CMS´s se realiza a través de la creación de módulos, ya sean funcionales o de contenido. La creación de un tipo de contenido para OpenCms es, a priori, más ventajosa que la de Drupal, pero ahí está el matiz, a priori, si lo que queremos crear es un tipo de contenido nuevo simple, por ejemplo, una noticia, con validaciones simples, comprobar si los campos están rellenos, OpenCms nos lo pone más fácil que Drupal, pero esa facilidad es un arma de doble filo cuando queremos hacer algo más complicado, por ejemplo una validación que no se pueda realizar con expresiones regulares, por ejemplo, que la fecha de alta de la noticia no sea posterior al día actual, ahí es donde Drupal le saca ventaja a OpenCms, mientras que con OpenCms tendríamos que crear una clase que X’ que heredara de la clase X y que implementa la interfaz Y, con Drupal tan solo tendríamos que tomar el valor del campo en el correspondiente hook y realizar la validación mencionada, esto para tipos de contenidos, el caso más fácil, pero si complicamos el caso, por ejemplo con la creación de un módulo funcional de administración, empezaremos a tener problemas, incluso en el propio desarrollo. Me explico, la idea de OpenCms de proporcionar un marco desde el que poder implementar, ahora mismo la considero hilarante, teniendo en cuenta el estado actual del mercado de IDE´s, suponiendo que no vamos a usar OpenCms para desarrollar nos encontramos con el problema del versionado, ¿cómo lo hacemos?. Cuando tenemos un módulo de contenidos versionamos el módulo y listo, pero cuando desarrollamos un módulo funcional, mucho de los ficheros y estructura de directorios han de ubicarse en una carpeta específica del VFS, para solventar este problema, un posible solución pasaría por replicar en el módulo los directorios VFS y mantener el fichero manifest.xml para que al importar el módulo lo mapee correctamente. Con Drupal no nos encontramos con este problema, los módulos, ya sean de contenidos o funcionales tienen una ubicación específica y desde ahí pueden trabajar, no necesitan declarar ninguna propidad y el versionado es trivial.

Apariencia

En este apartado las cosas están más o menos igual. En OpenCms 7 tenemos el Workspace desde donde podremos crear los contenidos y administrarlos con una apariencia similar a la de un sistema operativo. Para generar la interfaz del portal, podemos, de manera opcional, instalar y usar el Template Two, configurando esta plantilla podremos generar, de forma ágil, el skin de nuestro portal. En el otro lado tenemos los themes de Drupal, con ellos podemos modificar, con unos pocos golpes de ratón, completamente la apariencia de nuestro portal, sin existir una ruptura abrupta en la interfaz como ocurre con OpenCms, además estos themes, al igual que el Template Two, son totalmente transparentes con otras características como las URL´s amigables. El problema existiria si decidiéramos hacer uso de nuestras propias templates, en ese caso tendremos que programas nosotros esas características.

Horizontalmente a estos existen otros problemas, como por ejemplo la necesidad de tener un OpenCms para poder generar los instalables de los módulos a partir de los fuentes del repositorio, por suerte, siempre hay quien se preocupa de poner remedio a este tipo de eventualidades.

Nada es verdad ni es mentira; todo es según el color del cristal con que se mira. Ramón de Campoamor.

El proceso de documetación (históricamente vinculado al perfil del becario) de un proyecto aunque es en cierta medida un proceso automatizable, gracias a herramientas como PHPDoc, Javadoc, etc, es una tarea que se antoja tediosa y larga. Si a esta ecuación le añadimos variables como la extensión de la documentación, necesidad de distribuir la documentación en distintos formatos (html, pdf, etc), con distintos estilos y a través de distintos canales la cosa comienza a tomar un cariz oscuro.

Con este escenario en mente y sabiendo la relación 1 a 1 que existe entre las entidades Tiempo y Dinero es cuando comienza a tomar fuerza el uso de herramientas como Docbook, entre las ventajas que esta herramienta nos proporciona podemos citar algunas como:

• Nos permite abstraernos del aspecto y centrarnos en el contenido.
• Estilos personalizables.
• Producción de contenidos en distintos formatos partiendo de un mismo fuente.

Por supuesto también tiene algunas desventajas, como:

• Debemos superar la curva de aprendizaje que toda nueva tecnología nos impone.
• Poca madurez en muchas de las herramientas libres.

A continuación presento un esquema que ilustra el funcionamiento de Docbook

Esquema de funcionamiento de docbook

La instalación de dockbook junto con los procesadores XSLT es sencilla, basta con seguir los siguientes pasos:

Instalamos los esquemas de docbook y las xsl

1. apt-get install docbook-xml
2. apt-get install docbook-xsl

Instalamos el procesador XSLT

1. apt-get install xmlto

Instalamos el generador para pdf

1. wget http://www.uniontransit.com/apache/xmlgraphics/fop/fop-0.94-bin-jdk1.4.tar.gz
2. tar -xvzf fop-0.94-bin-jdk1.4.tar.gz
3. mv fop-0.94 /opt
4. ln -s fop-0.94 fop

Ahora si queremos, por ejemplo, generar un documento html,partiendo de un documento test.xml que sigue el formato docbook, haremos lo siguiente:

1. xsltproc -o test.html /usr/share/xml/docbook/stylesheet/nwalsh/html/docbook.xsl test.xml

Si en vez de un documento html queremos generar un pdf haremos esto otro:

1. xsltproc -o test.html /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test.xml
2. /opt/fop/fop test.fo -pdf test.pdf

Invertir en conocimientos produce siempre los mejores beneficios. Benjamin Franklin

Con este primer post comenzaremos a sentar las bases necesarias para conseguir montar un entorno de desarrollo e integración continua para proyectos realizados con tecnología PHP.

Los elementos que vamos a necesitar serán los siguientes:

EclipsePDT, es un IDE Eclipse que trae instalado los plugins necesarios para desarrollar aplicaciones con tecnología PHP (necesitaremos tener instalado JRE1.5).

WampServer permite instalar PHP, Apache y MySQL sobre un sistema operativo Windows. A partir de la versión 2.0 WampServer ofrece, además, la posibilidad de cambiar las versiones de los distintos componentes.

Xdebug es una extensión PHP que permite la depuración de scripts PHP ofreciéndonos una gran cantidad de información útil.

El primer paso que daremos será llevar a cabo la instalación del servidor WampServer. Una vez terminado el proceso de instalación podremos comprobar su correcto funcionamiento accediendo a “http://localhost/”.

Una vez hecho esto pasaremos a instalar Xdebug en nuestra máquina, para ello copiaremos la extensión Xdebug en el directorio de extensiones de PHP, en nuestro caso será “<WAMP_HOME>\wamp\bin\php\phpX.Y.Z\ext” (debemos tener cuidado de descargar la versión de Xdebug correspondiente con la versión de PHP que hemos instalando), opcionalmente, le podremos cambiar el nombre a “php_xdebug.dll” con el fin de facilitarnos los siguientes pasos

El siguiente paso será informar a WampServer que tiene disponible la extensión Xdebug para permitir la depuración, esto lo haremos accediendo al fichero de configuración “php.ini” a través de la consola de WampServer y añadiendo el siguiente fragmento de código al final de dicho fichero

zend_extension_ts=”<WAMP_HOME>\wamp\bin\php\phpX.Y.Z\ext\php_xdebug.dll”
xdebug.remote_enable=On
xdebug.remote_host=”localhost”
xdebug.remote_port=9000
xdebug.remote_handler=”dbgp”

Grabamos los cambios y reiniciamos el servidor, si hemos realizado todos los pasos correctamente de una imagen como la siguiente en “http://localhost/?phpinfo”

pasaremos a tener una como esta otra, en la que podemos observar cómo tenemos disponible la extensión de depuración Xdebug

Ahora sólo nos queda indicarle a EclipsePDT qué servidor tiene que usar para llevar a cabo la depuración , para ello abriremos EclipsePDT y creamos un nuevo proyecto PHP vacío al que llamaremos Test y crearemos un nuevo fichero “index.php” con un código de prueba.

A continuación nos iremos a “Window -> Preferences…” y expandiremos el árbol “PHP/Debug” y le indicaremos a EclipsePDT que debe usar la extensión de depuración Xdebug.

También deberemos crear un perfil de depuración para nuestro proyecto, para ello, haremos click derecho sobre el proyecto y selecionaremos “Debug As -> Open Debug Dialog …” crearemos una nueva configuración sobre “PHP Web Page” que llamaremos “Test_Configuration”, en File seleccionaremos “/Test/index.php” y pasamos a la siguiente pestaña, “Advanced”.

Tras pulsar sobre “Apply” saltará inmeditamente el navegador predefinido intentando acceder a “http://localhost/Test/index.php” devolviéndonos un error 404, esto se debe a que no tenemos dado de alta el proyecto, esto lo haremos fácilmente gracias a la gestión de los alias que WampServer nos ofrece.

Seleccionaremos “Apache -> Alias directories -> + Add an alias” en la consola de WampServer, esto nos mostrará una ventana en la que nos solicitará la dirección tanto lógica como física

Tras proporcionarle los datos necesarios volveremos a lanzar el depurador y obtendremos el depurador funcionando correctamente para poder trabajar

Para correr primero debemos aprender a andar.