Cómo crear una clase para el Shell en Magento

Cuando pensamos en módulos para Magento nos quedamos, normalmente, con agregar funcionalidad para el frontend o para el backend.

Creo que cuando pensamos en un módulo debemos imaginarnos los cuatro posibles entornos para su aplicación. Por los cuatro entornos me refiero:

  • Frontend o tienda propiamente dicha.
  • Backend o administración.
  • API.
  • Consola.

Si bien ésta división puede parecer arbitraria, éstas serán las posibles puertas de entrada que normalmente utilicemos (dependiendo sobre si nos toca ser usuario, administrador, desarrollador o el encargado del mantenimiento; o todo).

Claro está que no todos los módulos requieren funcionalidad en los cuatro entornos, pero en muchos casos deberíamos cuidar las formas y proveer de herramientas para cada caso.

En mi caso, desde hace ya un buen tiempo, me ha tocado desarrollar unas cuantas integraciones que importan o exportan información. Normalmente, con procesos manejados a través del Cron de Magento.

Uno de las situaciones con las que nos vamos a encontrar cuando trabajemos con módulos que funcionan con un cronjob, es la de la prueba de ejecución. Está claro que podemos programar la tarea para que se ejecute y esperar a que suceda. Luego de la quinta prueba es muy probable que empecemos a perder un poco la paciencia.

Lo que vamos a ver hoy es cómo crear una clase para el shell respetando el estilo de la plataforma. Si bien podemos hacerlo por fuera de éstos lineamientos, vamos a tratar de ser lo más respetuosos posible. La idea es lograr tener siempre extensiones prolijas para que puedan ser reutilizadas y no nos generen conflictos con otras extensiones (o al menos que esos casos sean los menos posibles).

Continue reading

Collabtive-CI 0.6.5.2

Al comienzo es fácil mantener el ritmo, así que vamos a aprovechar la inercia.

Versión 0.6.5.2 de Collabtive-CI con otro cambio referente a las tareas. En ésta oportunidad, agregué la posibilidad, opcional, de cargar para una tarea la cantidad de tiempo estimado que va a llevar.

La idea será avanzar sobre el control de tiempo para luego poder medir la estimación contra el tiempo real demandado.

A diferencia de las prioridades, éste campo no es obligatorio al momento de crear la tarea.

Como ya he dicho, ante cualquier error o comentario, éste es el link del Gestor de Incidencias de Collabtive-CI.

Collabtive-CI 0.6.5.1

El primer set de cambios ya se encuentra publicados bajo la versión 0.6.5.1 de Collabtive-CI.

Los cambios implementado son:

  • Cambios en las plantillas de mail, enviando ahora mayor información al agregar o editar una tarea.
  • Correcciones de traducciones.
  • Se agregó la constante CL_BRANCH_VERSION y se implementó su uso junto a CL_VERSION en el footer.
  • Creación automática de las carpetas files y templates_c al momento de la instalación.
  • Se quitó el indicador de usuarios online y el chat de la barra lateral.
  • Se restauró el calendario en la barra lateral.
  • Se muestran todos los proyectos a los cuales el usuario está asociado, para dar la posibilidad de cambiar de proyecto si tener que pasar por el Escritorio.
  • Se implementaron prioridades para las tareas.

Continue reading

Collabtive y Collabtive-CI

Desde hace ya un buen tiempo utilizo Collabtive para intentar gestionar proyectos, tareas, ideas, etc. Es una herramienta bastante cómoda y sencilla (tanto para trabajar de forma individual como grupal).

Básicamente, la aplicación presenta una pantalla general en la que veremos los proyectos en los que estamos involucrados y todas las tareas que tenemos asignadas.

Continue reading

Extendiendo la configuración gráfica del cron en Magento

Para evitar tener que lidiar con la configuración por xml, en Magento podemos crear la configuración gráfica para los cron jobs de nuestros módulos, de manera que estamos dando mayor flexibilidad al usuario y nos evitamos riesgos que podrían ocasionarse por una mala edición de los archivos.

Normalmente las opciones que nos ofrece la configuración suelen ser suficiente.

En otros casos, es posible que no nos alcance con sólo poder configurar una ejecución diaria, semanal o mensual. En éste esquema, nos estamos perdiendo la posibilidad de configurar la ejecución con repetición por horas o por minutos.

Para poder obtener esas opciones vamos a necesitar crear dos modelos para nuestro módulo, que serán los encargados de brindarnos esas nuevas posibilidades (y de paso vamos a arreglar otras que no funcionan desde la implementación original).

Continue reading

Configuración gráfica para un cron job en Magento

Siempre que se habla de crear cron jobs para un módulo en Magento, se explica cómo configurar el crontab y el xml del módulo.

Si bien vamos a lograr el objetivo, esto siempre obliga a quien administra el proceso a estar editando un archivo y corrigiendo los tiempos de ejecución.

De ésta forma no sólo estamos ante una situación incómoda sino que, además, podríamos estar comprometiendo la integridad del módulo.

Voy a dar por sentado que ya nuestro cron job funciona como queremos y que hemos creado la configuración de otros parámetros del módulo. Sólo nos vamos a concentrar en agregar la configuración gráfica para la ejecución.

Ahora bien, el primer paso es crear un nuevo modelo que será el encargado de transformar los valores que ingresemos en la configuración a valores que el Cron Manager de Magento entienda.

Continue reading

Crear un cron job en Magento

Muchas veces vamos a necesitar procesos que se ejecuten sin importar si del otro lado de la pantalla hay algún usuario realizando alguna acción.

Por lo general éste tipo de tareas tienen que ver más con procesos administrativos que con la experiencia de compra en si misma.

Una de las funcionalidades de Magento es el cron, que no es más que una extensión del cron del sistema operativo. La pequeña diferencia sería que desde el sistema operativo ejecutamos un único archivo de la plataforma y ésta, según configuraciones, se encargará de correr los procesos que correspondan.

Un cron job para Magento es, básicamente, un método de un modelo que se encargará de realizar una acción.

Para lograr el nuestro, lo primero sería crear la clase y el método que más tarde invocaremos. Un ejemplo podría ser el siguiente.

class Dc_Modulo_Model_Cron {
 
    public function runMyCronJob() {
 
        //Acciones a realizar
 
    }
 
}

De más está decir que lo que haga el método quedará librado a la necesidad de cada uno. No hace al ejemplo definir algún proceso.

Continue reading

Cómo crear un renderer para las grillas en Magento

Si bien tanto para los formularios como para las grilla Magento nos provee de una serie de tipos listos para usar, en algunas oportunidades nos hará falta alguna nueva funcionalidad.

En el caso de las grillas, es bastante sencillo agregar un nuevo tipo de columna.

Normalmente, cuando nuestro formulario permite subir archivos, el resultado en la grilla sería el siguiente.

La columna filename se muestra como texto, pero en realidad es una referencia a un archivo que nos gustaría poder ver como imagen.

Continue reading

Dropdowns en los formularios de backend de Magento

Uno de los ejemplos que el creador de módulos de Magento no incluye para el caso de los formularios del backend, es el del uso de dropdowns que deben ser llenados con valores de algún modelo que referencia a una tabla.

Por defecto, nos encontramos con esto.

Para lograrlo, el código que se utiliza en la composición del formulario es el siguiente.

$fieldset->addField('status', 'select', array(
    'label'     => Mage::helper('news')->__('Status'),
    'required'  => true,
    'name'      => 'status',
    'values'    => array(
        array(
            'value'     => 1,
            'label'     => Mage::helper('news')->__('Enabled'),
        ),
        array(
            'value'     => 2,
            'label'     => Mage::helper('news')->__('Disabled'),
        ),
    ),
));

Uno de los problemas de ésta modalidad, es que luego nuestro modelo deberá responder por esos mismos id’s para poder mostrar, “hacia afuera”, los valores como corresponden. Queda claro que dependiendo de la cantidad de opciones que vayan a utilizarse para llenar el dropdown, esto podría convertirse en una situación difícil de mantener.

Supongamos que estamos haciendo un módulo que se compone por más de un formulario, y donde uno de éstos genera valores que serán usado por un segundo. A manera de ejemplo, podríamos pensar en un sencillo módulo de noticias, en donde en el primero de los formularios cargaríamos una categoría y luego en el segundo seleccionaríamos en un dropdown la categoría.

¿Cómo hacer entonces para que los que carguemos como categorías sea utilizable por el segundo formulario sin tener que estar editándolo?.

Continue reading

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.