En concreto, el proyecto IFashion permitirá la selección e interacción de imágenes o videos al cualquier usuario de Internet, con el objetivo de obtener información, participar en acciones, y tener la posibilidad de comprar productos que esté visualizando en ese momento en el elemento audiovisual.

Este nuevo sistema permitirá realizar el tracking de productos y objetos, con el ambicioso objetivo de conseguir un algoritmo de recomendación de artículos que favorezca el proceso de compra online, aumente la conversión y los ratios de compra, y la satisfacción general del cliente gracias a la sencillez y comodidad en el proceso.

Como innovación a añadir al abanico de recursos en publicidad online, este sistema tendrá la posibilidad de abrir una nueva vía para potenciar el comercio electrónico en España, especialmente en el caso de marcas fabricantes de moda: Complementar la presencia online de las marcas, reforzar acciones de branding, permitir al cliente comprar un producto que esté visualizando en video o imagen en cualquier tipo de plataforma ecommerce son sólo algunas de las posibles aplicaciones que tendrá el proyecto IFashion.

Una de las múltiples integraciones que esta tecnología puede tener lugar lo vemos en sites y comunidades de moda online del estilo de Chicisimo.com (donde las usuarias publican fotos de cómo van vestidas y comparten sus gustos), mediante la integración de la venta de productos en los looks gracias al reconocimiento inteligente de prendas y complementos.

Este tipo de aplicación de la plataforma IFashion no sólo tendrá un uso directo en comercio electrónico, proporcionando un canal orgánico de “social shopping” al convertir a las usuarias en prescriptoras directas de las marcas, si no que presentará múltiples variantes en lo relativo a la explotación de datos que situarán a IFashion como una plataforma altamente atractiva para las marcas.

Más allá del sector de la moda, la plataforma IFashion tiene aplicaciones en otros sectores como el de la electrónica, la alimentación, bricolaje, mobiliario, etc.

En los próximos meses estará disponible una versión beta para plataformas de comercio electrónico de esta tecnología. Estará especialmente indicado para tiendas online con un extenso catálogo, que quieran disponer de un recomendador avanzado de productos para sus clientes. La adaptación e integración se personalizará en cada proyecto estudiando sus características, la clasificación de productos y los atributos que los definen, así como el comportamiento de los usuarios como cross-selling y para conseguir un resultado lejos del alcance de otras herramientas disponibles actualmente en el mercado.

Este proyecto ha sido financiado por el Instituto de la Pequeña y Mediana Industria de la Generalitat Valenciana (IMPIVA) y por el Fondo Europeo de Desarrollo Regional de la Unión Europea (FEDER).

Las ponencias fueron bastante interesantes para todo tipo de perfiles. Bien es cierto que para los usuarios de WordPress algunas fueron demasiado técnicas, y que para los desarrolladores avanzados otras charlas profundizaron poco o carecían de interés. Pero a pesar de que cualquier ponencia tiene cierto grado de autopromoción, ninguna fue un publireportaje.

En la primera, Fernando Tellado nos siguió descubriendo plugins y usos de WordPress curiosos. Fernando siempre está descubriendo a la comunidad hispana de WordPress utilidades y plugins que mucha gente no encontraría porque ni siquiera se plantea buscarlos. Pero él está atento, y desde ayudawordpress.com siempre tiene algo interesante que enseñar. Podéis encontrar la ponencia de Fernando Tellado aquí.

La segunda fue para José Fontainhas, que expuso lo nuevo que viene con WordPress 3.1. Rápida y concisa. Según nos comentó lo mejor para conocer las novedades  de WP3.1 es visitar la página oficial.

Rafael Poveda, de Mecus, nos explicó los entresijos de la creación rápida de temas con la nueva versión de WordPress 3.x. Temas elásticos, frameworks themes y temas hijos. Sobre todo, la idea de no reinventar la rueda creando temas desde cero sin pensar en que podemos aprovechar soluciones existentes mediante el uso de temas hijos, o temas específicos hipercustomizables.  ¡Sólo falta que cuelguen la presentación! Puedes encontrar su presentación aquí.

Después fue el turno para el SeñorMuñoz, Fernando Muñoz, consultor SEO de profesión. Amplió la que nos ofreció el año pasado con unas nociones de SEO básicas pero imprescindibles a la hora de implementar temas de WordPress. Y para rematar nos mostró un amplio abanico de plugins para potenciar el aspecto SEO de un WordPress. Su presentación y su resumen la podéis encontrar en su web.

Tras la comida tuvimos el gusto de escuchar a Luis Rull, de Mecus, hablando de los distintos usos que se le puede dar a WordPress más allá de la creación de blogs. Y qué sorpresa la nuestra cuando presentó el proyecto de Chicisimo.com que con tanta ilusión estamos llevando hacia delante junto con sus creadores, Gabriel Aldamiz y su mujer María Arenaza. No nos cansaremos de agradecer a Luis que pusiese a chicisimo.com como ejemplo de uso de extremo de WordPress para crear una comunidad alrededor de un nexo común para sus usuarios, como es la moda. Además nos enseño otros sites que usan WordPress, aunque no lo parezca. Su presentación, en su blog personal.

Isaac Keyet, cofundador de IntenseDebate y ahora Coordinador del equipo de trabajo de desarrollos para dispositivos móviles de Automattic, nos introdujo a los temas específicos para este tipo de dispositivos y las herramientas principales que tenemos a nuestra disposición para usar WordPress en ellos.

Luego Karim Osman, también de Automattic, nos dio algunas pinceladas de los entresijos de una gran empresa como Automattic, de su historia y de hacia donde navegan en la actualidad. Siempre interesante que alguien tan simpático como Karim venga y te cuente como funciona una empresa que se ha hecho tan grande e importante en tan poco tiempo. Para tomar nota. Su presentación la podéis encontrar en su web.

Y por fin Fernando Serer, con su tan aplaudida ponencia (sobre todo en Twitter) sobre WordPress y el comercio electrónico. Temas y plugins para vender con WordPress. Que está claro que no es la misión de la plataforma en convertirse en un framework de tiendas online, pero para desarrollos rápidos, aprovechando quizás un site con Worpdress con cantidad de visitas, para crear tiendas con multitud de landing pages, es una cuestión a tener en cuenta. Y más después de tener en las manos el profundo análisis que expuso Fernando Serer y que realizaron en Blogestudio. Muy muy interesante. Superrecomendable ver la presentación en slideshare.

Jeffrey Pearce nos mostró su gran plugin WooThumbBlog, que forma parte de muchos temas que tienen a la venta en Woothemes. Jeffrey es un programador excepcional, y un tío muy simpático. Gracias a él nos vinimos con una camiseta de Woothemes, con un posible acuerdo para colaborar con ellos creando nuevos temas, y con un descuento del 30% en su plataforma Su presentación, en su web.

Y por último Rocío Valdivia nos enseñó como crear plugins multilenguaje desde cero y de una forma muy sencilla. Seguro que mucha gente perdió el miedo a crear su propio plugins, y alguno que incluía nueva funcionalidad en el tema ahora usará sus propios plugins a partir de ahora. Faltó tiempo para hacer una demostración en vivo, pero fue una ponencia muy interesante que podéis encontrar aquí.

Para finalizar, queremos darle nuestro agradecimiento a la gente de Packet Loss (Raúl Illana, Ismael Charif, Ricard Torres, etc etc) por hacer posible la Wordcamp en España y por el éxito de organización de este año. Y por supuesto a Cavalleto (su flickr) por ser testigo con su cámara y por permitirnos usar las fotos del evento.

Este año en Onestic vamos a montar un stand en la Feria para todos aquellos que queráis pasar a conocernos (stand 60). 5500 metros cuadrados de espacio ferial, 70 expositores, más de 4000 visitantes y 80 conferencias. También participaremos en una Mesa Redonda el día 9 de Junio cuya temática es “El software libre, una vía fácil y eficaz para tener tu negocio en Internet.” en la sala Amsterdam a las 10:00. Si alguno se quiere pasar ya sabéis…

El objetivo principal de esta mesa redonda es mostrar de manera clara las ventajas de las soluciones Open Source tanto a nivel económico como técnico. Intentaremos a través de nuestras experiencias y casos de éxito comentar lo que debemos tener en cuenta a la hora de montar un solución E-commerce.

Podéis consultar la lista de expositores aquí.

Módulo de pago para Servired

Bueno, si te dedicas a desarrollar tiendas para Magento, o incluso si quieres probar suerte con la tuya, es muy posible que termines instalando este módulo. La verdad es que funciona perfectamente. Hoy, uno de nuestros clientes ha encontrado un pequeño “bug”. La verdad es que es bastante chorra pero buscando la solución al final hemos encontrado mucha gente que pregunta y poca que responde.

El problema se describe en este post:

http://www.magentocommerce.com/boards/viewthread/33072/

El caso es que cuando se realiza una transacción que devuelve como resultado una operación válida, el estado del pedido no es visible desde “Mi cuenta” o desde el histórico de pedidos de un cliente. Además, el administrador se encontrará en el administrador con pedidos que no pueden cambiar de estado (lo cual es bastante engorroso).

Podríamos aprovechar la ocasión para hablar del módulo que permite ampliar el número de estados por los que puede pasar un pedido. Creo recordar que ya hablamos hace unas semanas.

La solución os la dejo aquí y si alguien quiere ampliarla será bien recibido.

El problema radica básicamente en la asignación de orderStatus y orderState. Lo primero que tenemos que hacer es buscar la función “public function  successAction() ” en el fichero StandardController.php que hay en módulo de Servired. al principio de la función comentar las líneas que hay referentes a la asignación del orderStatus e incluir estas dos:

</p>
<p>$orderState = Mage_Sales_Model_Order::STATE_PROCESSING;<br /> $orderStatus = Mage::getModel('servired/standard')-&gt;getConfigData('order_status');</p>
<p>

Al final de la misma función, justo antes de “$order->save();”  incluir estas líneas:

</p>
<p>if (!$orderStatus) {<br /> $orderStatus = $order-&gt;getConfig()-&gt;getStateDefaultStatus($orderState);<br /> }<br /> <br /> $order-&gt;setState($orderState, $orderStatus,$comment,true);</p>
<p>

Con esto será suficiente. La explicación pasa por asignar correctamente un orderStatus y un orderState. En el caso de no estar disponible el orderState le asignaremos uno por defecto. Ahora ya podemos ver en el histórico de pedidos de nuestro cliente el pago realizado con el módulo para Magento de Servired.

Saludos.

Las versiones de Magento han cambiado y la tarea de instalar una nueva tienda es algo que a las empresas que desarrollan/mos en Magento hacemos muy a menudo, os voy a poner los pasos para hacer una instalación base desde cero. Para anteriores versiones podéis ver este artículo, es prácticamente igual…

1. Lo primero de todo, acceso a la consola claro
2. Descargamos el paquete con la última versión:

   wget http://www.magentocommerce.com/downloads/assets/1.4.0.1/magento-1.4.0.1.tar.gz

3. Descomprimimos el paquete:

   tar -zxvf magento-1.4.0.1.tar.gz

4. Movemos el contenido de la carpeta Magento a nuestro directorio raiz (public_html. www, o el que sea):  

   mv magento/* magento/.htaccess .

5. Cambiamos permisos a la carpeta media (donde estarán las img de nuestro catálogo):

   chmod -R o+w media

6. Configuramos la instalación de Magento y buscamos las últimas actualizaciones:

   ./pear mage-setup .

   [code]./pear install magento-core/Mage_All_Latest-stable[/code]
7. Este último paso debería traernos e instalar bastantes paquetes, esperar a que termine.
8. Cambiamos permisos a la carpeta var (aquí es donde va la cache, logs, sesiones, etc):

   chmod o+w var var/.htaccess app/etc

9. Borramos la cache y “basura” que ha quedado en tras la instalación:

   rm -rf downloader/pearlib/cache/* downloader/pearlib/download/*

10. Borramos la carpeta Magento (debería estar vacia) y el paquete original que nos hemos bajado:

    rm -rf magento/ magento-1.4.0.1.tar.gz

11. Ahora pasamos a la creación de la Base de datos.
12. Desde la consola entramos a MySQL:

    $ mysql -u root

13. Ejecutamos:

    mysql> create database nombre_de_la_db;

14. Creamos el usuario:

    grant usage on *.* to nombre_usuario@localhost identified by 'aqui_la_contraseña;

15. Asignamos el usuario a la base de datos:

    grant all privileges on nombre_de_la_db.* to nombre_usuario@localhost ;

16. Ya hemos terminado, ahora podemos empezar la instalación de nuestra nueva tienda en Magento

Y nada más…

• En el admin, Sistema->Configuración
• En la columna de la izquierda, en Developer (bajo de la opción de Avanzado)
• Expandir la opción de “Log Settings”
• Guardar

var/log/system.log
var/log/exception.log

Activar el modo desarrollador. Magento Developer Mode

#Mage::setIsDeveloperMode(true);
#ini_set('display_errors', 1);

Creación del fichero de configuración

app/code/local/Alanstormdotcom/Helloworld/etc/system.xml

//header('Content-Type: text/xml');         
header('Content-Type: text/plain');         
echo $config = Mage::getConfig()
->loadModulesConfiguration('system.xml')        
->getNode()
->asXML();          
exit;

Añadir una solapa en el administrador de Magento

Ubicación: app/code/local/Alanstormdotcom/Helloworld/etc/system.xml
<config>
    <tabs>
        <helloconfig translate="label" module="helloworld">
            <label>Hello Config</label>
            <sort_order>99999</sort_order>
        </helloconfig>
    </tabs> 
</config>

indica el nombre del Tab y determina el orden de aparicion con respecto a los demás tabs en la columna de la izquierda del administrador.

Breve ayuda sobre las Helper Classes

Magento cuenta como muchos otros sistemas MVC con Helper classes, las cuales son usadas para una gran variedad de tareas que no encajan ni el Modelo, ni en la vista ni el controlador. Como desarrolladores de módulos podemos utilizar las Helper Classes del sistema o las nuestras propias (en el caso de nuestro módulo Helloworld). Lo primero será añadirlo en el fichero config.xml (ojo, no el system.xml)

Fichero: app/code/local/Alanstormdotcom/Helloworld/etc/config.xml
<!-- ... -->
<global>
    <!-- ... -->
    <helpers>
        <helloworld>
            <class>Alanstormdotcom_Helloworld_Helper</class>
        </helloworld>
    </helpers>  
    <!-- ... -->
</global>
<!-- ... -->

La única parte “rara” que podemos encontrar aquí es la que hace referencia al nombre de la clase. Como sabréis la notación para esto debe seguir la siguiente estructura:

Nombredelpaquete_Nombredelmodulo_Helper

Los Helpers se cargaran en el global Mage. La siguiente llamada servirá (teniendo en cuenta la configuración que hemos ido dando)

Mage::helper('helloworld/foo');

…cargará la siguiente clase

app/code/local/Alanstormdorcom/Helper/Foo.php
class Alanstormdotcom_Helloworld_Helper_Foo

Magento también permite el concepto de “Helper por defecto” para un módulo, lo que significa que podíamos haber usado esta llamada:

Mage::helper('helloworld');

lo que hubiera provocado que se hubiera buscado en:

app/code/local/Alanstormdorcom/Helper/Data.php
class Alanstormdotcom_Helloworld_Helper_Dara

Con esto llegamos a la conclusión de que es lo mismo poner estas dos líneas:

Mage::helper('helloworld');
Mage::helper('helloworld/data');

Supongo que estas líneas os habrán aclarado más de una duda (o eso espero) Por último tenemos que añadir el Helper class actual.

Fichero: app/code/local/Alanstormdorcom/Helper/Data.php
class Alanstormdotcom_Helloworld_Helper_Data extends Mage_Core_Helper_Abstract
{
}

Si hemos seguido los pasos y hemos borrado la cache, ya no deberíamos tener ningún error en el administrador. Eso si, todavía no podremos ver nuestro nuevo Tab.

Añadir una Nueva Sección

El siguiente paso es saber por qué nuestra ficha no aparece todavía en el administrador. Cada Tab/ficha dispone de una serie de secciones. Por ejemplo, el Tab “Avanzado” por defecto tiene una de Administrador, Sistema, Avanzado y Desarrollador. Si creamos un Tab sin secciones no se mostrará, por eso vamos a añadir un nodo llamado :

Ubicación: app/code/local/Alanstormdotcom/Helloworld/etc/system.xml

<config>
    <tabs>
        <helloconfig translate="label" module="helloworld">
            <label>Hello Config</label>
            <sort_order>99999</sort_order>
        </helloconfig>
    </tabs> 
    <sections>
        <helloworld_options translate="label" module="helloworld">
            <label>Hello World Config Options</label>
            <tab>helloconfig</tab>
            <frontend_type>text</frontend_type>
            <sort_order>1000</sort_order>
            <show_in_default>1</show_in_default>
            <show_in_website>1</show_in_website>
            <show_in_store>1</show_in_store>                    
        </helloworld_options>
    </sections>     
</config>

helloworld_options, como antes, un nombre arbitrario, usado para identificar nuestra nueva sección. label , define lo que se mostrará en la interfaz. Es decir, la etiqueta. tab , identifica bajo que Tab estará agrupada nuestra nueva sección. frontend_type , esta no está muy clara. Parece que no sirve para nada (corregirme si me equivoco), yo la pongo por si las moscas sort_order , determina el orden de aparición (vertical) con respecto a las otras secciones. show_in_default , , , determina el nivel la granularidad que tiene esta sección. Los valores son 0 y 1. Con todo esto claro ya deberíamos ver la nueva Ficha con su sección. Si queremos añadir nuevas secciones únicamente tenemos que introducir nuecas .

Control de Acceso

Si pulsamos en la nueva sección que acabamos de crear obtendremos una página en blanco. Esto se debe a que el Adminhtml no puede encontrar la entrarda de nuestra nueva sección en el ACL (Access Control List) – Lista de control de acceso. La gente de Magento decidió en su momento que las secciones de configuración de Sistema deberían tener porotección ACL. Los recursos son definidos mendiante URI’s. Por ejemplo, la sección de configuración “web” se define de la siguiente forma:

admin/system/config/web

en nuestro caso…

admin/system/config/helloworld_options

La sección del administrador (conocida como Adminhtml) está desarrollada con el mismo framework que la tienda. Cada vez que un usuario accede a un recurso del admin, el adminhtml debe:

• Deducir la URI donde el usuario quiere acceder
• Comprobar la URI contra el sistema ACL y determinar si el usuario tiene permisos sobre este recurso
• Si el usuario no tiene privilegios informar

Para los que estéis interesados en esta parte el método usado es _isSectionAllowed que podemos encontrar en el siguiente controlador:

app/code/core/Mage/Adminhtml/controllers/System/ConfigController.php

Como todos sabréis, una forma de ver los Roles asignados en el administrador es desde Sistema-> Permisos -> Roles

Añadir Roles. ACL

Para entender esta sección hay que leer la anterior. Para los despistados Editamos el fichero que controla los permisos necesarios para acceder a nuestra nueva sección:

Fichero: app/code/local/Alanstormdotcom/Helloworld/etc/config.xml
<config>    
    <!-- ... -->
    <adminhtml>
        <acl>
            <resources>
                <admin>
                    <children>
                        <system>
                            <children>
                                <config>
                                    <children>
                                        <helloworld_options>
                                            <title>Store Hello World Module Section</title>
                                        </helloworld_options>
                                    </children>
                                </config>
                            </children>
                        </system>
                    </children>
                </admin>
            </resources>
        </acl>
    </adminhtml>
    <!-- ... -->
</config>

Resumiendo:

<adminhtml>
    <acl>
        <resources>
        </resource>
    </acl>
</adminhtml>

Dentro del recurso, cada nodo hijo representa una porción de la URI. Por ejemplo:

admin/system

nos devuelve la siguiente URI

admin/system

Si has seguido todos los pasos, tenemos las siguiente configuración:

<helloworld_options>
    <title>Store Hello World Module Section</title>
</helloworld_options>

Para ver todos estos cambios desde el administrador, como siempre, borrar la cache, cerrar sesión y volver a iniciarla. Si todo ha ido bien, deberíamos ver una nueva página de llamada “Hello World Config Options”.

Añadir Grupos

Ya tenemos nuestra página de configuración (en blanco) con los permisos adecuados. Vamos a crear grupos para las secciones.

Ubicación: app/code/local/Alanstormdotcom/Helloworld/etc/system.xml
<config>
    <tabs>
        <helloconfig translate="label" module="helloworld">
            <label>Hello Config</label>
            <sort_order>99999</sort_order>
        </helloconfig>
    </tabs> 
    <sections>
        <helloworld_options translate="label" module="helloworld">
            <label>Hello World Config Options</label>
            <tab>helloconfig</tab>
            <frontend_type>text</frontend_type>
            <sort_order>1000</sort_order>
            <show_in_default>1</show_in_default>
            <show_in_website>1</show_in_website>
            <show_in_store>1</show_in_store>
            <groups>
                <messages translate="label">
                    <label>Demo Of Config Fields</label>
                    <frontend_type>text</frontend_type>
                    <sort_order>1</sort_order>
                    <show_in_default>1</show_in_default>
                    <show_in_website>1</show_in_website>
                    <show_in_store>1</show_in_store>                
                </messages>
            </groups>
        </helloworld_options>
    </sections>     
</config>

Guardamos y recargamos la página. ¿Veís la caja con el título “Demo Of Config Fields”. ? (espero que si, sino mal vamos….)

Añadir campos de configuración. Config fields

Y ya por último, vamos a introducir los campos necesarios para la configuración de nuestro módulo. Esto se hace con el nodo Por ejemplo, un campo con el nombre “hello_message”.

<!-- ... -->
<messages translate="label">
    <label>Demo Of Config Fields</label>
    <frontend_type>text</frontend_type>
    <sort_order>1</sort_order>
    <show_in_default>1</show_in_default>
    <show_in_website>1</show_in_website>
    <show_in_store>1</show_in_store>                
    <fields>
        <hello_message>
            <label>Message</label>
            <frontend_type>text</frontend_type>
            <sort_order>1</sort_order>
            <show_in_default>1</show_in_default>
            <show_in_website>1</show_in_website>
            <show_in_store>1</show_in_store>                    
        </hello_message>
    </fields>                   
</messages>
<!-- ... --> 

Os acordáis que antes comentábamos la finalidad del campo frontend_type, bueno, pues aquí tenéis la explicación. En esta sección si tiene sentido. Si recargamos la página deberíamos ver un text field. Vamos ahora con otro tipo de campo, uno de tipo time.

<!-- ...-->
<fields>
    <hello_message>
        <label>Message</label>
        <frontend_type>text</frontend_type>
        <sort_order>1</sort_order>
        <show_in_default>1</show_in_default>
        <show_in_website>1</show_in_website>
        <show_in_store>1</show_in_store>                    
    </hello_message>
    <hello_time>
        <label>Time to Say Hello</label>
        <frontend_type>time</frontend_type>
        <sort_order>1</sort_order>
        <show_in_default>1</show_in_default>
        <show_in_website>1</show_in_website>
        <show_in_store>1</show_in_store>                    
    </hello_time>       
</fields>
<!-- ... -->

La única diferencia entre ambos nodos es el tipo. time Para ver los tipos soportados por Magento podemos ir a lib/Varien/Data/Form/Element. No están todos, pero si la mayoría… Ahora vamos a cambiar el text de hello_message por un combo.

<!-- ... -->
<hello_message>
    <label>Message</label>
    <frontend_type>select</frontend_type>
    <sort_order>1</sort_order>
    <show_in_default>1</show_in_default>
    <show_in_website>1</show_in_website>
    <show_in_store>1</show_in_store>                    
</hello_message>
<!-- ... -->

pero… el combo no tiene datos, no hay problema, tenemos que indicarle el origen de datos:

<hello_message>
    <label>Message</label>
    <frontend_type>select</frontend_type>
    <!-- adding a source model -->
    <source_model>helloworld/words</source_model>                           
    <sort_order>1</sort_order>
    <show_in_default>1</show_in_default>
    <show_in_website>1</show_in_website>
    <show_in_store>1</show_in_store>                    
</hello_message> 

El elemento source_model define el URI de un Model class que usaremos para meter datos en el combo. Como siempre, este cambio lo metemos en el config.xml (dentro de la sección de models):

Ubicación: app/code/local/Alanstormdotcom/Helloworld/etc/config.xml
<config>    
    <!-- ... -->
    <global>
    <!-- ... -->
        <models>
            <!-- ... -->
            <helloworld>
                <class>Alanstormdotcom_Helloworld_Model</class>
            </helloworld>   
            <!-- ... -->
        </models>
    </global>
</config>

Si recargamos la página nos dará un error, claro, no hemos definido la fuente de nuestro Model class.

Warning: include(Alanstormdotcom/Helloworld/Model/Words.php)

Nota: si en el error vemos algo parecido a “Mage/Helloworld/…” significa que no hemos creado bien la sección de models. Revisar el config.xml Para definir la fuente del Modelo:

File: app/code/local/Alanstormdotcom/Helloworld/Model/Words.php
class Alanstormdotcom_Helloworld_Model_Words
{
public function toOptionArray()
{
return array(
array('value'=>1, 'label'=>Mage::helper('helloworld')->__('Hello')),
array('value'=>2, 'label'=>Mage::helper('helloworld')->__('Goodbye')),
array('value'=>3, 'label'=>Mage::helper('helloworld')->__('Yes')),
array('value'=>4, 'label'=>Mage::helper('helloworld')->__('No')),
);
}

}

El método devuelve un array con los valores que usaremos posteriormente. Al recargar la página veremos el combo con nuestros datos. Fijaros que hemos usaros el método (__) para las traducciones. Ya que lo hacemos lo hacemos bien, no?

Recogiendo valores

Hemos visto cómo desarrollar formularios para crear valores de configuración. Para obtenerlos desde nuestro código y poder utilizarlos tenemos que usar un método llamado getStoreConfig. Por ejemplo:

Mage::getStoreConfig('helloworld_options/messages/hello_message');

El método getStoreConfig acepta como parámetro la URI:

section_name/group_name/field_name
Mage::getStoreConfig('helloworld_options/messages');
Mage::getStoreConfig('helloworld_options');

Por útlimo, si quieremos grabar un valor para una tienda en concreto, getStoreConfig acepta un segundo valor, el storeID:

Mage::getStoreConfig('helloworld_options',1);

Y para los que no tengáis ganas de estar copiando y pegando, como siempre, os dejamos directamente el código. Descargar]]>