Url friendly en CodeIgniter

CodeIgniter nos permite la utilización de urls amistosas (si, la traducción suena bastante fea).

Dado que por defecto ésto no funciona, tenemos que hacer algunos pequeños ajustes.

Lo primero será crear un archivo .htaccess con lo siguiente.

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

A partir de ahora, en lugar de usar:

http://www.dominio.com.ar/index.php/controlador/accion/

Vamos a poder usar:

http://www.dominio.com.ar/controlador/accion/

Para que la impresión de urls resulte correcta, es necesario hacer un ajuste en el archivo de configuración. Esto aplica en particular si vamos a usar la función site_url del helper Url.

Para evitar que al llamar a la función nos devuelva http://www.dominio.com.ar/index.php, vamos a cambiar la línea 23 de /system/application/config/config.php, y vamos a dejar el valor de la key index_page en blanco.

La configuración debería quedar de ésta forma:

$config['index_page'] = "";

Con estos pequeños ajustes ya deberíamos estar aplicando urls semánticas sin problemas.

Creando un nuevo controller en CodeIgniter

Vamos a crear nuestro primer controlador, para luego ir sumando los otros elementos del patrón MVC.

A manera de ejercicio vamos a ir armando, a lo largo de varios posts, una pequeña y sencilla aplicación que nos obligue a loguearnos para que luego podamos realizar alguna tarea (sobre la marcha veremos qué se puede armar).

Siguiendo ésta línea, vamos a crear un controlador que nos obligará a loguearnos. De ésta forma, se convertirá en el controlador por defecto de la aplicación.

Cuando comenzamos a jugar o trabajar con el framework, vamos a ver que nos aparece un mensaje de bienvenida. Justamente, es el controlador Welcome el que se hace presente.

Ahora bien, por qué ese controlador y no otro. Esto se debe a que una de las configuraciones de CodeIgniter nos permite especificar cuál controlador se ejecutará por defecto.

Para saber cuál es o para cambiarlo, debemos acceder al archivo /system/application/config/routes.php y buscar los siguientes valores (serán los únicos no comentados):

$route['default_controller'] = "welcome";
$route['scaffolding_trigger'] = "";

Vamos a cambiar el valor de default_controller a login. Debe quedarnos de la siguiente forma.

$route['default_controller'] = "login";
$route['scaffolding_trigger'] = "";

Entendido esto, creamos nuestro primer controlador. En la carpeta /system/application/controllers tenemos el archivo welcome.php. Ese es el controlador (el único) que vamos a encontrar.

Continue reading

Primeros pasos con CodeIgniter

Ya habíamos visto (hace un tiempo) cómo se compone, mínimamente, la estructura de directorios y archivos que componen CodeIgniter.

Una vez que hayas descomprimido el framework, ya estamos listos para empezar.
Lo primero que deberíamos hacer es comenzar con las configuraciones básicas. Para esto vamos a abrir el archivo /system/application/config/config.php y vamos a cambiar el primer parámetro en la línea 14:

$config['base_url'] = "http://example.com/";

Lo vamos a cambiar por la url completa de nuestra aplicación.
Vamos a suponer que se tratara de este mismo blog, la url quedaría de la siguiente forma.

$config['base_url'] = "http://www.damianculotta.com.ar/";

Como bien dice el manual, si vamos a utilizar base de datos, debemos especificar la configuración en /system/application/config/database.php. Busquemos la siguiente sección:

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "";
$db['default']['password'] = "";
$db['default']['database'] = "";
$db['default']['dbdriver'] = "mysql";
$db['default']['dbprefix'] = "";
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = TRUE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = "";
$db['default']['char_set'] = "utf8";
$db['default']['dbcollat'] = "utf8_general_ci";

Y completemos, al menos, los datos de conexión a nuestra base de datos.

Cuando accedamos a nuestra url, veremos el mensaje de bienvenida que es manejado por el controller Welcome del framework.

Con esto ya estamos listos para comenzar a desarrollar nuestra primera aplicación.

Iniciar un proyecto con CodeIgniter

En Php podemos encontrar gran cantidad de frameworks que buscan resolver cuestiones estructurales al momento de plantearnos una aplicación. Uno de ellos, es CodeIgniter.

Este post no trata sobre vender las bondades del framework, sino sobre cómo empezar a usarlo.

Inicializar un proyecto es algo bastante sencillo y rápido.

Lo primero será descargar CodeIgniter.

Una vez descomprimido el paquete (y suponiendo que lo ubicamos en el directorio del proyecto) nos vamos a encontrar con la siguiente estructura.

/
|
+--/ system
|
+--/ user_guide
|
+-- index.php
|
+-- license.txt

Ahora, si apuntamos con nuestro navegador hacia la dirección/carpeta en donde esté el proyecto, tendríamos que ver la siguiente página.

Bienvenida de CodeIgniter

Continue reading

¿Cómo saber si una constante ha sido definida en Php?

Es posible que ante ciertos escenarios, utilizemos una constante para almacenar algún valor global dentro de nuestro código.

Para definir una constante, basta con la siguiente línea:

<?php
define("CONSTANTE", "Hola mundo.");
?>

Una vez definida, simplemente debemos invocarla para hacer uso de ese valor.

<?php
echo CONSTANTE;
//El resultado en pantalla será "Hola mundo."
?>

Normalmente, damos por sentado que dichas constantes están definidas, pero, ¿y si por algún motivo una constante no se definió?.

Si hacemos uso de esa constante y se diera ése último caso, lo más probable es que el resultado que obtengamos no sea el esperado.

Para controlar si la constante está declara, basta con hacer la siguiente pregunta.

<?php
if (defined('CONSTANTE')) {
    echo CONSTANTE;
} else {
    echo "La constante no ha sido definida";
}
?>

Un tip bastante sencillo, para algunos hasta obvio, pero de seguro útil.

Debuggear Php en la consola de Firebug

A lo que ya hemos visto sobre el uso de la consola de Firebug, vamos a sumar una segunda extensión (siempre para Firefox), que nos va a permitir aprovechar la consola no sólo para Javascript, sino también para Php.

Esto lo vamos a lograr gracias a FirePHP, que funciona integrándose sobre Firebug, y se compone de dos elementos:

Una vez que hayas instalado la extensión, bajamos la librería (con soporte para Php 4 y 5) y la incluimos en nuestro proyecto.

Continue reading

Antileech sencillo con Php

El Antileech se utiliza para evitar exponer el link directo a un archivo que pueda descargarse.

Otra ventaja de ésta técnica, es que podemos forzar las descargas para que se realizen desde nuestra página.

Lo que vamos a hacer, es generar un archivo de descarga que, dependiendo de algún parámetro que pueda llegarle, va a leer el contenido de un archivo, y ese contenido, será impreso en nuestro archivo de descarga.

De ésta forma, la ubicación real del archivo nunca será expuesta.

El ejemplo:

<?php
$archivo = "documento.pdf";
$carpeta = "descargas/";
header("content-disposition: attachment; filename=" . $archivo);
header("content-type: application/octet-stream");
header("content-length: " . filesize($carpeta . $archivo));
header("pragma: no-cache");
header("expires: 0");
$lectura = fopen($carpeta . $archivo,"r");
echo fread($lectura,filesize($carpeta . $archivo));
fclose($lectura);
exit();
?>

Lo que nos va a interesar modificar, es el valor de las varaibles $archivo y $carpeta.

Según cada caso, puede llegar el nombre del archivo mediante un $_POST o un $_GET; o en lugar del nombre, algún id que a través de alguna consulta a base de datos, nos de el nombre del archivo a descargar.

Las posibilidades son tantas como escenarios enfrentemos.

Conociendo el contexto de un objeto en Php

Por lo general, si formamos parte de un desarrollo desde el comienzo, nos es bastante fácil tener noción de la arquitectura completa.

Existen otros casos, en los cuales llegamos con la arquitectura ya definida, pero la documentación se encarga de tapar esos baches con los cuales uno se topa.

El otro escenario posible, es la razón de ser de éste post.

Supongamos que estamos ante una aplicación en la cuál no tuvimos nada que ver con su arquitectura, y para rematarla, no tenemos documentación que pueda consultarse.

Si a esto le sumamos algunas cuestiones relacionadas con la complejidad del codigo y el grado de abstracción que pueda presentar, se nos pueden complicar un poco las tareas diarias.

En mi caso, la aplicación que se ajusta a éste último esquema, es Magento.

Para los que ya han visto algo del código de ésta aplicación, en particular la capa de plantillas que utiliza, entenderán mejor hacia dónde apunto con conocer el contexto de un objeto.

Continue reading