Caso “URL limpia de CodeIgniter” para Linux, SOLUCIONADO

Hoy en día, somos muchos los desarrolladores que disfrutamos de las bondades de este muy buen framework, pero siempre se ha tenido el problema para quitar esa porcion de url “index.php” de nuestros proyectos.

Bien, pues luego de investigar, buscar y preguntar… y demas cosas, encontre un modo de retirar ese “index.php”, el cual lo trabaje en una distro de Linux.

Pues comencemos:

• Como sabran, se necesita activar el mod_rewrite en la configuracion de nuestro servidor Apache. Pues se puede hacer manualmente accediendo al archivo de configuracion o simplemente ejecutando el siguiente comando:   sudo a2enmod rewrite
• Una vez activado el mod_rewrite, procederemos a quitar las restricciones en el archivo:  sudo gedit /etc/apache2/site-enable/000-default , donde reemplazaremos todos los “AllowOverride None” por “AllowOverride All“.
• Una vez terminado esto, procedemos a reiniciar el servicio de Apache con: sudo /etc/init.d/apache2 restart .
• Si al reiniciar el servicio de Apache, por casualidad les aparece mensaje como: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName , no se preocupen, se soluciona agregando la siguiente linea: ServerName localhost en el apache2.conf.
• Es hora de comprobar que en nuestro archivo de configuracion  ”system/application/config/config.php” , esté ya modificado la opcion del index page, de modo que quede así:  $config['index_page'] = “”;
• Ahora viene lo más importante, y es crear un archivo: .htaccess con el siguiente contenido, en la carpeta donde se encuentra nuestro proyecto, es decir donde se encuentra la carpeta “system”:

        ErrorDocument 404 /index.php

        DirectoryIndex index.php.

        <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.*)$ index.php/$1 [L,QSA]
        </IfModule>

Y con esto ya tenemos podemos trabajar sin el poco querido: index.php , es decir, si nuestra url era: http://localhost/proyecto/index.php/controlador ahora sera simplemente http://localhost/proyecto/controlador.

Espero les haya servido este post, ya saben que cualquier consulta, pueden hacerla dejandonos un comentario, y nosotros gustosamente responderemos. Gracias.

Usando CodeIgniter en un proyecto real

Recientemente en la empresa para la que trabajo (Sistemas Globales Multimeda, también conocida como SGM Sistemas) se nos planteó un presupuesto, cuanto menos, atractivo e interesante. Tras muchas deliberaciones en torno a qué lenguaje utilizar (ASP o PHP), finalmente nos inclinamos por éste último por varias razones:

• Mayor cantidad de herramientas disponibles (Eclipse frente a Dreamweaver; MySQL frente a SQL Server; MySQL Workbench para el diseño de la base de datos, PHPMyAdmin y un servidor con Plesk).
• Más componentes disponibles y a un precio más asequibles (cuando no gratuitos).
• Mejor separación entre el código y el diseño.

Nuestro equipo de trabajo había tenido de forma reciente buenas experiencias con PHP, logrando reducir los tiempos de desarrollo y aumentando sensiblemente la calidad y reusabilidad de las aplicaciones realizadas.

El proyecto constaba de las siguientes áreas:

• Extranet con posibilidad de intercambio de documentos.
• Notificación de disponibilidad de documentos, y de lectura de los mismos vía e-mail.
• Gestor de contenidos basado en plantillas predefinidas.
• Gestión de descargas, noticias y galerías.

No es uno de los mayores proyectos a los que nos hemos enfrentado; no obstante, dada la importancia del cliente (una institución pública) el resultado debía ser óptimo, bien probado y en un marco de seguridad importante.

Tras barajar las posibilidades disponibles (utilizar un framework o programar con PHP puro), nos decantamos por el uso de CodeIgniter, por las siguientes razones:

Razones para el uso de un marco de trabajo (framework) frente a desarrollar la aplicación desde cero con PHP:

1. La seguridad debía ser un factor clave: datos introducidos por el usuario debidamente validados y filtrados para evitar ataques XSS.
2. Comunicación con Base de Datos (MySQL) automatizada, validando todas las consultas y filtrando los datos variables para evitar inyección SQL.
3. Disponer de componentes plenamente probados, con el objetivo de mejorar la productividad.

Razones para el uso de CodeIgniter frente a otros marcos de trabajo:

1. Amplia documentación disponible.
2. Ligero, y sin instalación (para comenzar a desarrollar una aplicación basta con copiar los archivos, y ponerse a trabajar).
3. Compatibilidad con una amplia variedad de servidores y configuraciones (la aplicación se concebiría para ejecutarse en un hosting compartido con otros clientes, y con relativamente poca posibilidad de configuración).
4. Flexibilidad, ya que no obliga a tener una determinada estructura de tablas, nombres de campos, ni adherirse a una forma de programar concreta.

Entre las desventajas y dificultades con las que nos encontramos durante el desarrollo del proyecto están:

• Curva de aprendizaje: necesidad de aprender nuevas funciones, estructuras y métodos de programación.
• Dificultad para adaptar el código escrito en PHP tradicional (nuestra empresa contaba con una administración escrita en PHP puro, con listados, formularios, subida de archivos, etc.). No disponíamos de tiempo para comenzar de cero, por lo que se optó por adaptar el existente a la nueva filosofía. Esto no debería representar mucha dificultad para un programador avanzado, con experiencia en desarrollo de proyectos de complejidad media.

A medida que avanza el desarrollo de la aplicación (aún está en fase de desarrollo) hemos solventado todas estas dificultades, resultando un proyecto muy interesante, de gran calidad y fácilmente reutilizable. La adaptación de los componentes ya desarrollados no conllevó serios problemas (eso sí, manual de CodeIgniter en mano) y el resultado está siendo más que satisfactorio.

No obstante, al ser este el primer proyecto serio en el que empleamos CodeIgniter no podemos hacer una valoración de la facilidad o dificultad de las futuras modificaciones. No obstante, por la forma de estructurar la aplicación y los archivos suponemos no entrañará mayor dificultad.

Proyecto con CodeIgniter