Descargar una lista de Temas en sus últimas versiones

A veces me encuentro que tengo que descargar un montón de Temas para probarlos. Con este simple script (sólo para usuarios Unix/Mac) podrás elegir de dónde descargarlos (el repositorio de wp.org o wp.com) y elegir una lista para bajar. El script descargará la última versión de cada Tema y los dejará en la carpeta desde donde ejecutas el script. No mostrará nada por pantalla a menos de que aparezca un error.

Script en Github.com

Generar dinámicamente CSS: La guía definitiva

Existe una situación muy común cuando desarrollamos un Plugin o Tema: Tenemos una serie de opciones que el usuario puede tocar a su antojo para personalizar una serie de estilos, sean colores, márgenes, fuentes o cualquier otro elemento visual. Sabemos cómo agregar una hoja de estilos en WordPress usando la función wp_enqueue_style pero no podemos generar las reglas dinámicamente, esto es, con PHP dentro de la hoja CSS.

Imaginemos que tenemos unas opciones en nuestra Base de Datos tal que así:

$options = array(
	'background-color' => '#DDD',
	'font-size' => 23
);

¿No sería maravilloso si en nuestra hoja de estilos pudiéramos hacer algo así?

$options = get_option( 'my-options' );
.my-class {
	background-color:<?php echo $options['background-color']; ?>;
	font-size:<?php echo $options['font-size']; ?>px;
}

Obviamente se puede, veamos qué posibilidades tenemos:

La forma brusca: El hook wp_head

No hay en realidad ningún problema en utilizar este hook para añadir algunos estilos:

De esta forma, los estilos quedan encerrados entre nuestras etiquetas <head></head> de nuestra página.

No está mal: Las reglas se generan bien y queda en la cabecera. No obstante, si usamos muchas reglas (por ejemplo, la personalización de un Tema), la cabecera de nuestra página podría quedar demasiado larga, añadiendo carga adicional a nuestra página. Cuando una página HTML llega al usuario, el navegador lee el cuerpo del código HTML mientras carga en paralelo el resto de los elementos como hojas de estilo o ficheros Javascript (no funciona exactamente así pero eso daría para otro post). Lo que nos interesa es que la página cargue lo más rápido posible mientras en paralelo se descargan las hojas de estilo adicionales.

La forma elegante: Hojas de estilo “virtuales”

Con hoja de estilo “virtual” nos referimos a cargar un fichero CSS que no existe. ¿Cómo? Lo vamos a explicar, pero vayamos paso a paso. Primero tenemos que saber cómo va esto del protocolo HTTP (algo básico pero que tendemos a pasarlo por alto).

Cuando nuestro navegador solicita la descarga de una hoja de estilos, pide al servidor mediante un mensaje dicho fichero. El servidor devuelve una respuesta compuesta por una cabecera que contiene los datos identificativos del fichero: longitud en bytes del fichero, tipo de contenido y el tiempo de expiración de la caché entre otros campos. Bajo la cabecera se emite el cuerpo del fichero que contiene pues eso, el contenido del fichero.

Es fácil verlo en Chrome con las herramientas para desarrolladores

headers

En este caso, el fichero noticons.css se descarga de la URL https://s1.wp.com/i/noticons/noticons.css. Nos interesa especialmente la parte de Response Headers. Ésta es la cabecera que el servidor ha devuelto y lo que nos debería llamar más la atención es el campo llamado Content Type que nos dice qué tipo de contenido tiene el fichero, en este caso text/css.

¿Qué pistas nos da todo esto? Bien, si queremos generar dinámicamente nuestro CSS tenemos que tener en cuenta que cuando el navegador solicite nuestro archivo “virtual”, nuestro sitio tiene que devolver una respuesta con una cabecera cuyo campo Content Type sea text/css. Y no hay más. Si el navegador del usuario reconoce dicha URL como un fichero CSS, lo aplicará como tal.

Ahora, sigamos unos pasos básicos que nos lleve a la meta:

  • ¿Qué URL debería tener nuestra hoja de estilos “virtual”? Bueno, la que queramos en realidad. Pongamos un ejemplo: https://holadolly.wordpress.com?dolly-styles=true. Esa URL, que normalmente devolvería un fichero HTML vamos a “engañarla” para que devuelva un fichero CSS en su lugar. En WordPress podemos generar dicha URL fácilmente:
$css_url = add_query_arg( 'dolly-styles', 'true', home_url() );
  • Agregar dicha URL como si fuera un estilo normal usando la función wp_enqueue_style

  • Hasta aquí, más o menos todo bien pero la URL todavía no devuelve un CSS, de hecho devuelve la página HTML de la home de nuestro sitio. Ahora llega el momento del engaño. Cuando llamamos a esa URL, WordPress se carga de forma normal pero hay que saber que no necesitamos cargarlo al completo. La idea es comprobar que existe una variable $_GET llamada ‘dolly-styles’, que tiene valor ‘true’. Si esta condición se cumple le decimos al usuario que estamos cargando un CSS (mediante los campos de cabecera), generamos los estilos y paramos la ejecución. No necesitamos cargarlo todo, sólo la parte que nos interesa. Lo vamos a ver mejor con un ejemplo:

De este código podemos sacar alguna pregunta: ¿Por qué plugins_loaded y no otro? Funcionaría en init por ejemplo, ¿Por qué no init entonces? Bueno, hay que recordar que la idea es cargar lo mínimo del núcleo de WordPress, además debe hacerse antes de que WordPress envíe las cabeceras. Esto se produce justo después de la ejecución del action template_redirect. Es decir, que podríamos utilizar éste último y aún así funcionaría pero ¿Para qué? Lo mejor es hacerlo lo antes posible. Si estamos desarrollando un plugin, el idóneo es justo cuando nuestro plugin ha cargado su código, esto es plugins_loaded pero si lo estamos haciendo para un Tema, el hook apropiado sería after_theme_setup. Aquí podemos ver una lista de actions y el orden de ejecución.

  • ¿Cómo generar la cabecera CSS y generar los estilos? Es muy sencillo generar una cabecera para nuestro supuesto fichero. Se usa la función header de PHP

Los pasos son sencillos: Generamos la cabecera de tipo text/css, recogemos las opciones de nuestro Plugin/Tema de Base de Datos y generamos las reglas CSS con los valores de las opciones.

Ahora ya sólo queda comprobar que todo funciona bien. Para esto, simplemente ponemos en el navegador la URL de nuestro CSS “virtual”. Deberíamos ver un fichero CSS normal y corriente.

Making Community

The WordPress community is a complex thing. It has many features that make it unique, yet make it unappetizing. When the structure of something is sooo big, it’s very difficult to get into it and feel comfortable.

Local communities of WordPress from Barcelona and Sevilla have arranged together and have tried to solve the most common problems that a volunteer finds when he wants to work with WordPress, or ask for help, in the WordPress Community.

WordPress is en_US

Yes. WordPress is in English. WordPress Community, spreaded among the world, use English as a common language to understand each other. That, in Spain, is a problem for many.

For year we have been working to have WordPress entirely in Spanish, and we have also launched the official WordPress.org forums in Spanish. A volunteer job with many participants.

There is also a WordPress Slack for volunteers worldwide, and several P2 for work. But they are global, and that leads to the next problem:

Local communities do not have a place to meet.

And we see four main problems:

  • WordPress in Spanish, as a section or local community of WordPress, has no proper place beyond es.WordPress.org, which is just a site for translations and has no P2 or communication tool for users
  • There are several local WordPress communities in Spain making events (WordCamps and Meetups) that are not in contact with each other, losing the benefit that this contact would be
  • Translation teams do not have a space to meet and organize, and to ask for help or support when in doubt. Or to organize when a new version of WordPress is going to be released
  • The forums teams don’t have a place to solve doubts internally, or to decide what to do with bozo users, or how to answer specific questions. Such place exists for the general (en) WordPress.org forums.

People still do not know what the WordPress Community is

Although it has been discussed in several Wordcamps and Meetups all over Spain, many people still don’t know or have not interiorized the philosophy of the WordPress Community. A Community where:

  • Everyone is welcome, regardless of race, ethnicity, social position…
  • All events are organized entirely by volunteers
  • All events are nonprofit
  • All the world is invited to actively participate and benefit from the work of others

The problem that we find here is that all the documentation, as much of the WordPress documentation, is in English.

Spanish WordPress Community is growing, and we need a place to organize ourselves. That’s why we have created a series of tools for the local Community, where we can meet, talk, organize, and help among us.

The proposed solution

Internal Communication: Slack

slackSlack is a tool to create channels of discussion. You can use slack in all platforms (mobile, pc, mac…), and is very easy to use.

We have created a general Slack, where we all can gather, and we have created channels for each of the fields we are working in. There are specific channels for all volunteer teams and for general WordPress users, where we include:

  • Translators
  • Developers
  • Commits to WordPress core
  • WordPress Documentation
  • Forums
  • Events: Meetups and WordCamps
  • Designers and theme review
  • Accessibility
  • General Support

External communication: wp-es.es

We have also created a website to have an updated list of all events of our WordPress Community and a calendar to know when is happening what, and even organize to go the events together.

The event area is still in development. The provisional area is here, and you can add your event by dropping us a line.

Setting the scene: the WordPress Manifesto

WordPress Community, by definition, is open, honest, and transparent.

Honoring that, we are building the WordPress Manifesto. A manifesto setting out the existing rules and standards for volunteers, events, official Meetups and WordCamps, in Spanish. No more doubts about translations or where to find what.

The next step

The next step is you.

  • If you like WordPress
  • If you like what you do
  • If you think you have something to share
  • If you think you have much to learn
  • If you want to organize a WordPress event
  • If you want to find out what is happening in the ecosystem of WordPress Spain

just stop by our page and ask for your access to the Slack of WordPress España (it is implied that you accept the rules for general WordPress volunteers and WordPress events described here and here).

Haciendo Comunidad

La comunidad de WordPress es una cosa compleja. Tiene muchas particularidades que la hacen única, y a la vez la hacen poco apetecible. Porque cuando la estructura de algo es taaan grande, es muy difícil entrar en ella y sentirse cómodo.

Las comunidades locales de WordPress de Barcelona y Sevilla nos hemos unido y hemos intentado dar solución a los problemas más comunes que uno encuentra cuando quiere entrar a colaborar, o a pedir ayuda, en la comunidad de WordPress.

WordPress es en_US

Sí. WordPress está en inglés. Su comunidad, por ser de todos los rincones del planeta, utiliza como lenguaje común para entenderse entre ellos el inglés. Eso, en España, echa ya a muchos para atrás.

Desde hace años hemos estado trabajando por que WordPress esté íntegramente en español, y hemos puesto en marcha también los foros oficiales de WordPress.org en español. Un trabajo voluntario en el que participa mucha gente.

También hay un slack de WordPress para los voluntarios de todo el mundo, y varios P2 de trabajo. Pero son globales, y eso nos lleva al siguiente problema:

Las comunidades locales no tienen un lugar donde reunirse.

En este apartado abrimos además cuatro líneas:

  • WordPress en español, como comunidad local de WordPress general, no tiene un sitio propio más allá de es.WordPress.org (que es sólo un sitio para las traducciones y no tiene ningún P2 o herramienta de comunicación entre usuarios asociada)
  • Existen varias comunidades locales de WordPress en España que montan sus eventos (WordCamps y Meetups) que no están en contacto entre ellas, con el beneficio que supondría
  • Los equipos de traducción no tienen un espacio donde reunirse y organizarse cuando tienen dudas, o cuando va a salir una nueva versión de WP
  • Los equipos de ayuda en foros no tienen un espacio donde solucionar dudas de forma interna, o de decidir qué hacer con usuarios o preguntas puntuales, como existe en el foro general

La gente sigue sin saber lo que es la Comunidad de WordPress

Aunque se ha contado en algunas WordCamps y meetups repartidas por la geografía española, mucha gente todavía no conoce, o no tiene interiorizada la filosofía de lo que es la Comunidad de WordPress. Una comunidad donde:

  • Todo el mundo es bienvenido, independientemente de su raza, etnia, posición social…
  • Todos los eventos son organizados íntegramente por los voluntarios
  • Todos los eventos son sin ánimo de lucro
  • Todos el mundo está invitado a participar activamente, y a beneficiarse del trabajo de otros

El problema de esta documentación, como de tanta otra acerca de WordPress, es que está en inglés.

Viendo que la Comunidad de WordPress en España sigue creciendo, y que necesitamos un espacio donde organizarnos, hemos avanzado en esa línea creando una serie de herramientas para la Comunidad, donde todos podamos encontrarnos, hablar, organizarnos, y ayudarnos.

La solución propuesta

Comunicación interna: Slack

slackSlack es una herramienta que permite crear canales de discusión. Está en todas las plataformas, y es muy sencillo de utilizar.

Hemos creado un Slack general, donde podamos estar todos, y en él hemos creado canales para cada uno de los campos que queremos tratar. Hay canales específicos para todos los equipos de voluntarios y usuarios de WordPress en general, donde incluimos:

  • Traductores
  • Desarrolladores
  • Commits al core de WordPress
  • Documentación de WordPress
  • Foros
  • Eventos: Meetups y WordCamps
  • Diseñadores y revisión de temas
  • Accesibilidad
  • Soporte general

Comunicación externa: wp-es.es

Hemos creado también una web donde podamos tener un listado actualizado de todos los eventos de la Comunidad de WordPress y un calendario para saber cuándo ocurrirá cada cosa, e incluso organizarnos para ir juntos.

La zona de eventos todavía está en desarrollo, seguimos trabajando en ella. La zona de eventos provisional está aquí. Si tu evento no está, no dudes en gritarnos.

Sentando las bases: el Manifiesto WordPress

La Comunidad de WordPress, por definición, es abierta, honesta, y transparente.

Haciendo honor a esas bases, estamos construyendo el Manifiesto WordPress. Un manifiesto que recoja las bases y normas ya existentes para voluntarios, eventos, Meetups oficiales y WordCamps, pero en español. Para que todos podamos hacer uso de ellas.

El siguiente paso

El siguiente paso eres tú.

  • Si te gusta WordPress
  • Si te gusta lo que haces
  • Si crees que tienes algo que compartir
  • Si crees que tienes mucho que aprender
  • Si quieres organizar algún evento WordPress
  • Si quieres enterarte de lo que pasa en el ecosistema WordPress España

sólo tienes que pasarte por nuestra página y pedir tu acceso al Slack de WordPress España (está implícito que aceptas las normas para voluntarios generales de WordPress y para eventos de WordPress, descritas aquí y aquí).

La API de opciones de WooCommerce (II)

Continuamos con la serie de API Settings para WooCommerce. Si te has perdido la primera parte, aquí la tienes: https://holadolly.wordpress.com/2014/05/13/la-api-de-opciones-de-woocommerce-i/

En el episodio anterior añadimos campos simples a nuestra pantalla de opciones en WooCommerce. Dichos campos son gestionados automáticamente sin necesitar de código adicional para su validación o HTML para mostrar los campos, WooCommerce se encargaba de todo.

Pero no todos los campos son simples, lo más probable es que en algún momento necesitemos mostrar campos más complejos que requieran un tratamiento especial. Afortunadamente, WooCommerce viene preparado para esto y con sólo unas líneas más podemos hacerlo sin complicar la cosa demasiado. Para ello tenemos que seguir unos pocos pasos:

  1. Decirle a WooCommerce que nuestro campo se tratará de forma diferente y mostrar el HTML del campo
  2. Validarlo ya que WooCommerce no lo hará por si mismo..

1. Agregar un campo personalizado y mostrarlo por pantalla

En la primera parte creamos una clase que se encargaría de mostrar/validar nuestra pestaña de opciones. Dicha clase contenía un método llamado get_settings() que devolvía un array con las opciones a mostrar y todas sus características. Ahora simplemente vamos a añadir un registro más a dicho array que contendrá la información de nuestro nuevo campo especial:

Como vemos, nuestro nuevo campo tiene una ID , holadolly_general_options_special y un tipo holadolly_special_field que no reconoce WooCommerce. Si refrescamos la pantalla no veremos nada nuevo. La nueva opción no se muestra por pantalla. WooCommerce necesita una función especial para dicho campo. Para ello necesitaremos dos cosas: un nuevo hook y una nueva función en nuestra clase:

Si nos fijamos, en el constructor de la clase hemos añadido un hook nuevo que se compone de la siguiente manera:

add_action( 'woocommerce_admin_field_$tipo_de_nuestro_campo', $funcion_que_muestra_el_campo );

El tipo de campo lo definimos ya en el array dentro de get_settings() y la función (o método) que se encarga de mostrarlo es display_special_field( $field ) que recibe como parámetro todos los atributos que definen el campo.

Para que veamos mejor qué contiene la variable  $field se la pasamos a var_dump:

01 woocommerce-ii

 

Básicamente, el contenido es el mismo que el del array en get_settings().

A partir de esta información vamos a recoger de Base de Datos el valor de nuestra opción y mostrarlo en un área de texto, que va a ser nuestro campo especial. La función display_special_field( $field ) queda de la siguiente manera:

Gracias a get_option, recogemos el valor, si no lo encuentra tomará el valor que definimos en la propiedad default de nuestro campo. Luego generamos el código HTML para el área de texto cuya propiedad name será el ID del campo. Y ya está, lo podemos complicar todo lo que queramos pero el campo ya nos tiene que aparecer:

02 woocommerce-ii

 

Esto va bien pero si guardamos cambios, el valor del campo no se guarda en Base de Datos. ¡Toca validarlo!

 

2. Validación y guardado del campo especial

Como viene siendo costumbre, vamos a necesitar otro hook para que cuando WooCommerce haya terminado de guardar los campos, pase de nuevo por nuestra clase y guardemos el campo especial.

De manera similar al punto anterior, el hook tiene la siguiente composición:

add_action( "woocommerce_update_option_$tipo_de_campo", $funcion_que_valida_y_guarda_el_campo );

Así, nuestra clase queda tal que así:

La función que valida el campo la hemos llamado sanitize_special_field( $field ) donde $field tiene exactamente el mismo valor que en el punto anterior; los atributos de nuestro campo. Sólo hay que limpiarlo un poco (con stripslashes) y guardarlo mediante update_option.

Ahora sí, nuestro flamante nuevo campo funciona a las mil maravillas:

03 woocommerce-ii

 

En resumen

La nueva API Settings de WooCommerce nos ofrece muchísima flexibilidad para crear una nueva pestaña de opciones dentro de WooCommerce. Es altamente recomendable que nuestras opciones estén bien integradas en el plugin ya que evitará futuros fallos y además mejorará la facilidad de uso del interfaz para los usuarios habituales de WooCommerce.

WooCommerce provee más hooks para poder personalizar las pestañas como por ejemplo añadir links de secciones debajo de las pestañas (tal y como las opciones de envío o Emails tienen) pero simplemente investigando un poco el código se puede sacar. No obstante en Hola Dolly estamos abiertos a cualquier duda o pregunta que pueda enriquecer esta entrada.

Cómo saber si un hook se ha ejecutado ya

La respuesta es fácil pero no muchos conocen esta función:

La función devuelve 1 si el hook ya ha sido ejecutado y 0 si todavía está pendiente.

A veces también necesitaríamos saber todos los hooks que han sido ya ejecutados para saber cuál nos convendría más y si tenemos que cambiar partes de nuestro código para que funcione. En ese caso podemos usar el siguiente código, un poco más pedestre pero que puede llegar a sernos útil:

Aquí tenemos un ejemplo de la salida:

 

array (size=59)
  'muplugins_loaded' => int 1
  'registered_taxonomy' => int 15
  'registered_post_type' => int 14
  'woocommerce_loaded' => int 1
  'plugins_loaded' => int 1
  'sanitize_comment_cookies' => int 1
  'setup_theme' => int 1
  'load_textdomain' => int 17
  'after_setup_theme' => int 1
  'auth_cookie_valid' => int 2
  'set_current_user' => int 1
  'init' => int 1
  'before_woocommerce_init' => int 1
  'woocommerce_integrations_init' => int 1
  'woocommerce_init' => int 1
  'widgets_init' => int 1
  'register_sidebar' => int 3
  'wp_register_sidebar_widget' => int 25
  'woocommerce_register_taxonomy' => int 1
  'woocommerce_register_post_type' => int 1
  'update_option' => int 1
  'update_option__transient_doing_cron' => int 1
  'updated_option' => int 1
  'set_transient__transient_doing_cron' => int 1
  'setted_transient' => int 1
  'http_api_curl' => int 1
  'http_api_debug' => int 1
  'wp_loaded' => int 1
  'auth_redirect' => int 1
  'wp_default_scripts' => int 1
  '_admin_menu' => int 1
  'admin_menu' => int 1
  'admin_init' => int 1
  'wp_default_styles' => int 1
  'admin_bar_init' => int 1
  'add_admin_bar_menus' => int 1
  'current_screen' => int 1
  'load-woocommerce_page_wc-settings' => int 1
  'woocommerce_shipping_init' => int 1
  'woocommerce_load_shipping_methods' => int 1
  'admin_xml_ns' => int 2
  'admin_enqueue_scripts' => int 1
  'woocommerce_admin_css' => int 1
  'admin_print_styles-woocommerce_page_wc-settings' => int 1
  'admin_print_styles' => int 1
  'admin_print_scripts-woocommerce_page_wc-settings' => int 1
  'admin_print_scripts' => int 1
  'wp_print_scripts' => int 1
  'admin_head-woocommerce_page_wc-settings' => int 1
  'admin_head' => int 1
  'adminmenu' => int 1
  'in_admin_header' => int 1
  'admin_bar_menu' => int 1
  'wp_before_admin_bar_render' => int 1
  'wp_after_admin_bar_render' => int 1
  'admin_notices' => int 1
  'all_admin_notices' => int 1
  'woocommerce_page_wc-settings' => int 1
  'woocommerce_settings_start' => int 1

Otra función más que puede resultar interesante es aquella que nos permite saber qué hook se está ejecutando en este mismo momento (aunque realmente lo que no sdice es qué filtro fue el último en ejecutarse)

La API de opciones de WooCommerce (I)

Entre otros muchos cambios, WooCommerce 2.0 trajo una renovación completa de su Settings API. Aunque no es de mi total agrado ya que el encapsulado de clases no es óptimo, nos hace muchísimo más fácil añadir nuestra propia pestaña a las opciones de WooCommerce, una práctica más que recomendable si queremos extenderlo. Crear nuestro propio plugin para WooCommerce puede traer varias preguntas, una de ellas es ¿Dónde poner las opciones de nuestro plugin? Crear un nuevo submenú sería absurdo si ya disponemos de una pantalla que WooCommerce trae de serie y que podemos extender a nuestro antojo. Además, en muchos casos podemos aprovecharnos del sistema de validación que WooCommerce trae de serie.

A grandes rasgos, esto es lo que tendremos que hacer:

  1. Añadir nuestra propia pestaña en la pantalla de opciones de WooCommerce mediante un filtro y programar una nueva clase que se encargue de gestionar la pestaña.
  2. Crear las secciones necesarias dentro de dicha pestaña.
  3. Agregar campos a cada una de las secciones que hemos creado. Los campos pueden ser simples, ya sea un número o un campo de texto que WooCommerce podrá gestionar él solito.
  4. Es más que probable que necesitemos algún campo especial personalizado. Aquí no podremos hacer uso de las funciones que WooCommerce incorpora y tendremos que crearnos las nuestras propias.
  5. Validar los datos. De nuevo, WooCommerce se encargará de validar aquellos que ya lleva incorporado, para los nuestros será necesario picar un poco más de código.

Pues vamos allá.

1. Añadir nuestra propia pestaña en la pantalla de opciones de WooCommerce y programar una nueva clase que se encargue de gestionar la pestaña

Ésta es la típica imagen básica de las opciones de WooCommerce una vez instalado:

 

01-woocommerce_settings_tabs

 

Para que nuestro plugin esté completamente integrado con WooCommerce vamos a insertar una pestaña al final, después de Emails. Para ello vamos a crear primero un fichero que incluya una nueva clase que extiende de WC_Settings_Page. Dicha clase viene incluida en WooCommerce y se encarga de dar forma a cada una de las pestañas en la pantalla de opciones. Si revisamos el código de WooCommerce en includes/admin/settings/class-wc-settings-page.php podremos entender mejor porqué tenemos que extender de dicha clase pero requeriría un poco de tiempo explicarla a fondo. Es más o menos sencilla de entender si vamos mirando línea por línea.

Vamos a crear un nuevo fichero llamado class-wc-settings-holadolly.php dentro de nuestro plugin que importaremos más adelante. Aquí tenemos la estructura básica de la clase:

En el constructor de la clase tenemos la información necesaria para la pestaña. Toda pestaña necesita una ID y un título que son propiedades dentro de la misma clase pero lo que realmente incluye la pestaña es el hook que viene inmediatamente después, woocommerce_settings_tabs_array, que llama a un método llamado add_settings_page dentro de la clase padre, WC_Settings_Page. Dicho método no necesitamos implementarlo nosotros, la clase padre se encargará de recoger la ID y el título de la pantalla y mostrarlo correctamente. Por último el filtro incluye una prioridad que hemos puesto a 20 para que la pestaña se muestre al final de la cola.

Ojo con la última línea porque estamos creando una instancia de la clase nada más incluir el archivo (cosa que todavía no hemos hecho).

Por ahora la pantalla de opciones sigue igual. Nos falta incluir nuestra clase pero no podemos hacerlo de cualquier manera, WooCommerce provee un filtro especial para ello. Aquí va el código:

Los archivos que incluyen las clases que extienden de WC_Settings_Page se añaden dinámicamente mediante este filtro y se agregan a un array que WooCommerce ya tiene rellenado con las los archivos que WooCommerce incluye por defecto. Creo que es fácil entender lo que está pasando ahí. Nuestra clase se incluye y además se instancia, con lo que ya deberíamos ver nuestra pestaña:

02-holadolly-tab

 

Obviamente, aún queda por hacer, no hemos definido ninguna opción para nuestra pestaña.

 

 2. Crear las secciones necesarias dentro de dicha pestaña.

Toca empezar a jerarquizar nuestras opciones. Vamos a crear un par de secciones dentro de nuestra pestaña. Cada sección tendrá una serie de opciones que añadiremos más tarde. Por el momento dos bastarán: Una sección general (con campos que WooCommerce gestionará automáticamente) y otra especial (que tendremos que codificar nosotros mismos).

Para crear nuestras secciones tendremos que crear un nuevo método llamado get_settings dentro de nuestra clase WC_Settings_Hola_Dolly que la clase padre llamará automáticamente. Dicho método devolverá un array con toda la información sobre nuestras secciones/campos:

Lo primero que vemos es que en el constructor hemos añadido un filtro más, ‘woocommerce_settings_’ . $this->id, que llama a un método output() que no tenemos en nuestra clase pero que sí tiene la clase padre, WC_Settings_Page. Dicho método se encarga de sacar por pantalla las opciones que estamos generando. Si no usamos ese filtro no veremos nada.

El método get_settings devuelve un array con las dos secciones bien marcadas. Si nos fijamos, aunque hay dos secciones, dentro del array tenemos cuatro elementos. Toda sección debe llevar un elemento que abre la sección ( ‘type’ => ‘title’ ) y otro que la cierra ( ‘type’ => ‘sectionend’). Si nos olvidamos de cerrarlas la página no se comportará correctamente.

Como vemos, cada sección tiene una id a la que debemos hacer referencia tanto al abrir como al cerrar la sección. Además hay otra propiedad, desc, que incluye la descripción de la sección. Dicha propiedad no es obligatoria, simplemente es el texto que aparecerá al principio de cada sección. Existen más propiedades pero no hay espacio suficiente aquí para explicar cada una de ellas, lo mejor es bucear un poco por el código de WooCommerce.

La pantalla se nos queda tal que así:

03-settings-tab-with-sections

 

Esto, lógicamente no sirve para nada, si pulsamos el botón no estaremos guardando nada. ¿Qué tal si rellenamos las secciones con unos cuantos campos?

 

3. Agregar campos simples

WooCommerce puede manejar automáticamente campos sencillos (y otros que no lo son tanto): números, texto, email, color, contraseña, áreas de texto, selects, multiselects, radios, checkboxes, ancho de imagen, selector de página, selector de país y multiselector de país. Como vemos la lista no está nada mal pero entre todos ellos vamos a escoger uno muy sencillo: Campo numérico. Este campo lo vamos a poner dentro de la sección de Opciones Generales y tendremos que darle un valor por defecto, una id, un título, indicar de qué tipo es y quizás una descripción. Muy sencillo, sólo hay que tener en cuenta que las opciones por pantalla aparecen en el mismo orden que indicamos en get_settings(), dentro del array:

Poco hay que explicar aquí, nuestro nuevo campo se define con un array tal y como hemos dicho, con un título, una id (holadolly_general_options_number), un valor por defecto ( 0 ) y un tipo de campo (number). Además le hemos añadido una propiedad llamada desc_tip que mostrará un icono con un símbolo de interrogación que al pasar el ratón por encima nos mostrará dicho texto. Podríamos haber optado por una simple descripción utilizando una propiedad desc pero así vemos la flexibilidad que WooCommerce nos ofrece.

04-settings-with-number

 

Bien, el campo se muestra correctamente con su icono de interrogación, valor por defecto, título, etc. Si cambiamos el valor a 1 y guardamos… Nada, vuelve a 0 el valor. Hay algo que todavía tenemos que hacer y es una de las cosas que no me terminan de gustar del diseño de esta clase, no es importante pero puede resultar molesto. Necesitamos decirle a la clase padre que cuando pulsemos el botón de guardar, nos guarde las opciones. Se hace mediante un filtro en el constructor de nuestra clase:

save() es un método que incluye la clase WC_Settings_Page y que guardará todas las opciones que mostremos por pantalla automáticamente a menos que le indiquemos lo contrario. Si ahora cambiamos el valor del campo y guardamos, el valor quedará guardado en base de datos, sí, ¿Pero dónde? Si volvemos un poco más arriba veremos de nuevo que dicho campo lleva asociado una id, holadolly_general_options_number, que es precisamente el slug de nuestra opción. Para recoger el valor simplemente tenndremos que llamar a get_option():

get_option('holadolly_general_options_number')

 

Aquí tenéis el código entero (es un plugin normal y corriente): https://github.com/igmoweb/woocommerce-settings-api-explained

 

Conclusión de la primera parte

Hemos aprendido a añadir nuestra propia pestaña a las opciones de WooCommerce de una manera eficaz, bien integrada y que nos evita mucho código. Un campo simple como puede ser un campo numérico es muy fácil de crear y ni siquiera hemos tenido que implementar código para tratar y guardar en Base de Datos dicho campo, WooCommerce lo ha hecho todo por nosotros: Muestra el campo, lo valida y lo guarda. También hemos aprendido a recoger su valor para usarlo donde queramos, todo en unas pocas líneas de código.

En la segunda parte del artículo aprenderemos a usar campos más avanzados que ya tendremos que mostrar, validar y guardar por nosotros mismos.

Todo esto y mucho más, muy pronto en Hola Dolly 🙂