Todos los cambios presentados giran sobre MagentoConnect Manager 2. Sólo basta con revisar el changelog.

Las opciones de creación de extensiones también han sido ajustadas.

Hay pequeños cambios en los datos de la versión.

Se modificó la forma en que se indicaban los autores de la extensión (algo más sencilla).

También se ha simplificado la especificación de dependencias.

En la carga de los archivos también vamos a encontrar pequeños ajustes (referentes al tipo de archivo a agregar).

MagentoConnect Manager presenta nuevas opciones.

Incluso la configuración agrega algunas cuestiones.

A nivel permisos se ha hecho un pequeño ajuste.

También se habilita una opción para realizar deploys remotos.

Otra nueva opción que para muchos casos ha de servir: al momento de estar ejecutando un proceso en MagentoConnect Manager, podemos dejar la tienda en modo “Mantenimiento”.

Nueva funcionalidad para instalar extensiones (que en varias oportunidades se reclamó) que nos permite instalar directamente una extensión subiéndola al servidor.

Otro detalle a tener en cuenta, es el cambio de las keys de las extensiones.

Voy a usar como ejemplo la extensión Dc_ArgentineRegions.

La key de la misma, para ser usada a través de MagentoConnect, es magento-community/Dc_ArgentineRegions.

Si usamos ésta key en el nuevo MagentoConnect Manager, nos vamos a encontrar con lo siguiente.

El error se debe al cambio de formato en las keys.

La forma de utilizar las viejas keys con lo que será el nuevo MCM es reemplazando parte de esa key.

Formato viejo

magento-community/Dc_ArgentineRegions

Formato nuevo

http://connect20.magentocommerce.com/community/Dc_ArgentineRegions

Si utilizamos el nuevo formato, obtendremos el resultado esperado.

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.

Como toda versión menor, su propósito es el de corregir bugs. Pueden darse una vuelta por el changelog para ver la lista completa. Pueden ver que la mayoría de los cambios están relacionados con el checkout (o con parte del proceso).

Con éste upgrade surgió un problema que no ha sido muy bien explicado (yo creo que tampoco se lo ha podido reproducir correctamente) y que tiene que ver con la falta de algunos archivos de los modelos del módulo de Sales que no son descargados en la actualización.

Para solucionar éste problema, se ha publicado un patch que agrega los archivos faltantes.

Hasta el momento, sólo he colaborado (colaboración mínima) con @mhhansen en una actualización de 1.4.0.1 a 1.4.1.1 y ha sido bastante tedioso.

Como siempre, lo pueden descargar vía MagentoConnect o en forma manual, pero recuerden no hacer la actualización directamente en producción sin antes haber hecho las pruebas correspondientes.

Lo primero que pensé fue que alguna de las actualizaciones requería algún reinicio (reconozco que no le presté gran atención a la lista de paquetes) y que ésto estaba generando algún tipo de incompatibilidad o conflicto entre paquetes.

Luego de haber reiniciado, la molestia se convirtió en problema. Buscando un poco encontré el bug sobre el no funcionamiento del teclado numérico en Ubuntu.

Al parecer se viene arrastrando el tema desde hace varias ediciones, aunque la solución es realmente sencilla.

Lo primero, es abrir “Tecnologías de asistencia”.

Ahora vamos a las opciones de “Accesibilidad del teclado”.

Luego a la solapa “Teclas del ratón” (si, suena rara la traducción).

Y para solucionar el problema, destildamos la opción “Permitir controlar el puntero usando el teclado numérico”.

Una vez que cerremos la configuración ya todo deberá funcionar normalmente.

En ésta oportunidad la lista de cambios, mejoras y correcciones es bastante amplia. Es lectura obligada (más que de costumbre) repasar el changelog.

El cambio más fuerte que se ha hecho presente, es el cambio de la estructura de datos de las órdenes, que pasaron de su ya conocido modelo EAV a Flat. Si bien se supone que implica una mejora de performance, está trayendo dolores de cabeza a más de una extensión que deberá ser modificada y adaptada al nuevo esquema.

Quizás hubiera sido interesante que este cambio fuera anunciado con anterioridad, para dar tiempo a los desarrolladores a prepararse para el cambio. Lamentablemente, como viene siendo costumbre, la interacción con la comunidad sigue siendo cada vez más pobre.

Como decía, la lista de novedades es muy extensa. A diferencia de posts previos sobre las nuevas versiones, me voy a limitar a mostrar aquellos cambios que he podido detectar y (en varios casos) probar en el backend.

Ya en la tienda podemos ver las referencias a PayPal.

En el backend, un detalle menor para nosotros, pero que tiene que ver con la evolución de la empresa, un cambio legal en cuanto a la marca.

En las opciones de importación y exportación contamos ahora con osCommerce. Lo cual nos permitiría hacer la migración desde esa plataforma.

Tenemos nuevo índice de datos para gestionar.

Manejo de la forma en que se generan las url’s en la parte cms.

Lo mismo para el catálogo.

Nueva opción de redirección en la configuración SEO.

En las opciones de stock, ahora podemos mostrar, optativamente, la leyenda “quedan X productos”.

Y contamos con nuevas opciones para el manejo de los productos en el carrito.

Nueva opción para la configuración del newsletter. Ahora podemos manejar si permitimos suscripciones anónimas o no.

Al haber cambiado la forma de almacenar los datos de las órdenes, podemos seleccionar cómo se mostrarán parte de esos datos en el dashboard.

Estaba anunciado y en las opciones de configuración de PayPal podemos verlo. Todo nuevo.

También vamos a encontrarnos con más medios de pago integrados. Algunos ya son módulos del core, como el cado de iDeal.

Vuelve a aparecer Strikeiron como servicio a integrar desde el backend.

Regeneración de datos para los reportes.

En la edición de categorías, tenemos una nueva opción que nos permitirá mostrarla (o no) en la barra de navegación.

Los productos simples y virtuales poseen una nueva opción.

El menú de Ventas viene con varias nuevas opciones. La primera de ella es el registro de transacciones.

Recurring profile (todavía estoy jugando con ésto para entender mejor).

Registro de los acuerdos de facturación.

Podemos ver las órdenes de osCommerce.

En líneas generales, y a primera vista, éstas son las nuevas opciones que vamos a encontrar en ésta nueva versión de la plataforma.

Si hasta ahora se recordaba que no debe actualizarse un sitio en producción, creo que nunca tuvo tanto sentido éste mensaje como el día de hoy. Es necesario mucho testeo, tanto por los datos, como por el backend, como los templates.

Esto se debe (además de la investigación que fue necesaria en su momento para llegar al generador) al uso y aprovechamiento de los elementos disponibles dentro del código de la plataforma.

Para aquél que lo haya usado, ya sabrá que dispondremos de una nueva tabla en la base de datos, en el backend habrá una grilla y un formulario de edición de datos, y también tendremos un controlador disponible en el store para acceder a esos datos que manipulemos en el backend.

Vamos a centrarnos en la grilla del módulo.

Como ven ésta grilla es igual a cualquier otra de las que encontramos en el backend. Por supuesto, las leyendas y columnas pertenecen a un módulo específico.

Ahora bien, si comparamos esa grilla con ésta otra, vamos a ver un pequeño detalle que las diferencia.

La grilla del módulo de newsletters tiene, junto a su título, una imagen.

Si, es un detalle menor, que no cambia la funcionalidad y que tampoco alterará el flujo de ventas.  Lo que si podemos considerar, en particular si nos dedicamos a la creación de módulos, es que cada detalle que podamos agregar ayuda a la mejor calidad de la extensión.

La pregunta ahora sería: ¿cómo logramos esa personalización?.

Si revisan el código html que obtenemos de la grilla, el título está compuesto de ésta forma.

<h3 class="icon-head head-adminhtml-integration">Integration Logs</h3>

Además del class icon-head, se le agrega un segundo class que coincide con el controlador de nuestro módulo.

Si lo pensamos rápido, la solución más sencilla sería editar el archivo /skin/adminhtml/default/default/boxes.css y agregar nuestro class css para obtener el mismo resultado.

Esto no estaría mal, salvo que pensemos en que vamos a armar una extensión que queremos replicar en varios backends o que incluso busquemos publicarla (ya sea que tenga o no fines comerciales).

Para esto, vamos a aprovechar una de las herramientas de manejo de layout.

Nuestro módulo ya posee directivas de layout para el backend, en donde se indica que bloques utilizar al momento de accederlo. Vamos a indicarle también que utilize un archivos css adicional al momento de ejecutarse.

En este ejemplo, el módulo se llama Integration, por lo cual vamos a editar el archivo /app/design/adminhtml/default/default/layout/integration.xml. Recuerden que el nombre del archivo de layout se corresponde (generalmente) con el nombre del módulo. (Hay formas para que esto no sea de ésta manera, pero pensando en módulos hechos de forma genérica, esa sería la regla).

Ahora bien, en mi caso, el archivo contiene el siguiente código.

<layout version="0.1.0">
    <integration_adminhtml_integration_index>
        <reference name="content">
            <block type="integration/adminhtml_integration" name="integration" />
        </reference>
    </integration_adminhtml_integration_index>
</layout>

Le agregamos nuestra llamada a nuestro css.

    <default>
        <reference name="head">
            <action method="addCss"><name>integration/css/style.css</name></action>
        </reference>
    </default>

Y éste sería el resultado final.

<layout version="0.1.0">
    <default>
        <reference name="head">
            <action method="addCss"><name>integration/css/style.css</name></action>
        </reference>
    </default>
    <integration_adminhtml_integration_index>
        <reference name="content">
            <block type="integration/adminhtml_integration" name="integration" />
        </reference>
    </integration_adminhtml_integration_index>
</layout>

El paso siguiente es crear nuestro archivo css y agregar nuestra imagen.

Siguiendo con el ejemplo de éste modulo, vamos a agregar en el skin del backend nuestros nuevos archivos. Por una cuestión de orden, mi decisión es crear, dentro del skin, una carpeta con el nombre del módulo y dentro de ella las carpetas css e images con sus correspondientes archivos.

La estructura de directorio debería quedar de la siguiente manera.

/
|
+--/ skin
   |
   +--/ adminhtml
      |
      +--/ default
         |
         +--/ default
            |
            +--/ integration
               |
               +--/ css
               |  |
               |  +--/ style.css
               |
               |
               +--/ images
                  |
                  +--/ icon_integration.png

De más está decir que los nombres usados se corresponden con lo definido en el layout del módulo.

Ahora sólo tenemos que agregar nuestra clase css para que al ser invocada en el h3 de la grilla, aparezca nuestra imagen.

.head-adminhtml-integration {
	background-image:url(../images/icon_integration.png);
}

Actualizamos la página y deberíamos obtener éste resultado.

En Ubuntu Lucid Lynx no vamos a encontrarnos con la excepción.

En mi caso, el error se presentó al querer instalar PhpEclipse. Durante el proceso, recibí un mensaje de error.

Ahora bien, a diferencia de otras veces, me puse a buscar (no puede ser que siempre haya problemas con ésta ide).

Después de leer muchísimos threads y hacer unas cuantas pruebas en más de un desktop, encontré que la forma para solucionarlo era agregando paquetes de Eclipse que por defecto no se instalan.

Para solucionarlo, vamos a buscar si los paquetes eclipse-pde eclipse-jdt eclipse-rcp están instalados.

root@linux:~# aptitude search eclipse-pde eclipse-jdt eclipse-rcp
p   eclipse-jdt                                                            - Eclipse Java Development Tools (JDT)
p   eclipse-pde                                                            - Eclipse Plug-in Development Environment (PDE)
i A eclipse-rcp                                                            - Eclipse Rich Client Platform (RCP)

En mi caso no lo estaban, así que sólo había que instalarlos.

root@linux:~# aptitude install eclipse-pde eclipse-jdt eclipse-rcp

Ahora bien, volvemos a probar la instalación del plugin y al finalizar deberían poder iniciar un proyecto php normalmente.

Problema resuelto.

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.

Hacemos una copia y vamos a llamar al archivo login.php. Al abrir el archivo tendremos el siguiente código.

class Welcome extends Controller {
 
    function Welcome() {
        parent::Controller();
    }
 
    function index() {
        $this->load->view('welcome_message');
    }
 
}

Lo primero que tenemos que hacer es cambiar el nombre de la clase.

Si prestan atención, dado que el framework es compatible con las versiones 4 y 5 de Php, todas las clases que veremos vienen programadas para Php 4. Esto no quita que nosotros podamos continuar nuestro desarrollo armando nuestras clases en Php 5.

Dicho ésto, nuestro controller Login lo haremos de esa forma, así que el cambio no será sólo de nombre, sino que declararemos los métodos como públicos y modificaremos el constructor de la clase.

El resultado debería quedarnos de la siguiente forma.

class Login extends Controller {
 
    public function __construct() {
        parent::Controller();
    }
 
    public function index() {
        $this->load->view('welcome_message');
    }
 
}

Si bien el controller ya funcionaría, todavía nos faltan algunos detalles para darnos cuenta, efectivamente, que el controlador que va a ejecutarse es el nuestro.

Dentro del método index(), podemos ver que se invoca a la vista welcome_message. Esa vista puede encontrarse en /system/application/views/welcome_message.php. De más está decir que el nombre de la vista se corresponde con el nombre del archivo (sin la extensión).

Siguiendo nuestro primer experimento, vamos a duplicar también ese archivo y vamos a llamarlo login.php. A éste archivo pueden hacerle las modificaciones que consideren necesarias. Ahora tenemos que indicarle al controlador que en lugar de utilizar la vista welcome_message, utilize la nuestra.

El código final nos quedaría de la siguiente forma.

class Login extends Controller {
 
    public function __construct() {
        parent::Controller();
    }
 
    public function index() {
        $this->load->view('login');
    }
 
}

Y si refrescamos nuestro navegador, veríamos algo similar a ésta pantalla (dependiendo de lo que hayan cambiado en la vista) .

Como ven, resulta bastante sencillo dar los primeros pasos.

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.

Los cambios y correcciones que presentó la versión fueron:

• Revisión de vulnerabilidades XSS.
• Agregado del módulo Phoenix_Moneybookers como medio de pago.
• Corrección de problemas en la actualización de versiones 1.3.x a 1.4.0.0.
• Corrección del uploader de imágenes (un problema que ya hemos tenido, aunque en este caso si fue por error de programación).

Hay algunos cambios más que pueden leer en el changelog oficial de ésta release.

Para aquellos que utilizan templates custom, presten atención a lo explicado sobre el cambio en el uso del bloque catalog/product_list_toolbar.

En lo personal, salvo algunas mejoras de performance que aparecieron con las versiones alpha de la rama 1.4, hace ya un buen tiempo que no me sorprende la plataforma.