Como ya todos (o casi todos) sabréis, WordPress ya está en su versión 3.0. Ha sido un trabajo muy duro y hemos pasado algunos momentos difíciles propiciados por las fechas de entrega. Para muchos desarrolladores de Automattic la versión 3.0 se ha convertido en su infierno personal. Y para los que desarrollamos sobre y bajo WordPress, un dolor de cabeza continuo por tratar fechas previstas como reales y teniendo a todos nuestros clientes detrás sin parar de preguntar.

El desarrollo de este 3.0 ha tenido cosas muy curiosas. Podemos contar, por ejemplo, que ha sido la versión más difícil y con más cambios de WordPress hasta la fecha. Y para ella programamos el tiempo de desarrollo interversiones más corto de toda la historia de WordPress. Como curiosidad, en el Codex podéis ver que los últimos periodos interversiones de WordPress han sido de 6 meses y que éste no ha sido una excepción. Son esas cosas de las que nos damos cuenta a posteriori.

Y ahora viene lo importante. Este fin de versión ha necesitado de mucho esfuerzo, por lo que hay muchas otras cosas que han tenido que dejarse a un lado para poder centrarse en 3.0. Todos teníamos muchas ganas de sacar la versión en su momento y con los mínimos fallos posibles y hemos trabajado duro para conseguirlo.

3.0 ha resultado ser una versión estable, potente, y preparada para el futuro: WordPress ya no es un sistema de blogs. Aunque ya desde 2.7 nos fuimos centrando cada vez más en sus posibilidades como CMS, ahora WordPress es un CMS muy completo con el que también puedes tener tu blog, por supuesto.

Dando un punto de vista muy personal, creo que es la forma más acertada de hacer las cosas. La potencia de WordPress como CMS es precisamente que está construido al revés: se ha buscado que el usuario tenga el formato de publicación más sencillo y ordenado de todos los tiempos, primando la usabilidad y la experiencia de usuario, y alrededor de esa idea se han construido todo un ecosistema de funciones que dotan a WordPress de una de las estructuras más potentes y completas de software para páginas web del mercado.

Esto tenemos que agradecérselo a mucha gente. Por un lado, a Jane Wells, que se ha encargado desde un primer momento de toda la organización de usabilidad y experiencia de usuario. Por otro, a Matt Mullenweg, por aceptar nuevas ideas y permitir que nos metiéramos en este berenjenal. Otro más, la gente del TRAC, un equipo cada vez más sólido donde todos reman a una y en la misma dirección. A la gente del Codex, que mantienen la documentación. A los equipos de traducción, incluyendo el nuestro.

Personalmente tengo también que agradecérselo a un buen puñado de gente, y hacer listas siempre hace que te dejes alguien fuera. No puedo dejar de nombrar a Donncha (creador de WordPress MU), Daryl Koopersmith (creador del Elastic Theme), a Zé Fontainhas y Nikolay (de los que he aprendido una barbaridad), Hanni, Barry, Noël, Beau, mrmist… y seguro que me dejo a alguien.

Después de haber tenido parados durante un tiempo el resto de proyectos asociados a WordPress, es hora de cambiar las tornas y hacer justo lo contrario.
Con una versión estable a la que le queda mucha vida, el equipo de WordPress abandona el TRAC. Durante 2 meses, sólo se aceptarán incidencias blocker, aquellas que puedan romper nuestros WordPress. El resto se añadirán a una lista, y se empezará a trabajar en ellas en Septiembre. Hasta entonces, WordPress entra en vía de servicio y nace un nuevo proyecto: 3.org.

3.org no es un dominio de WordPress. Es simplemente una denominación para referirnos a que estaremos trabajando en la versión .org de WordPress 3.0.
Como si del GSoC se tratase, se han propuesto pequeños equipos de trabajo y desarrollo que estarán a cargo de un Lead Developer. Serán pequeños sprint projects que tendrán una duración máxima de 2 meses (es preferible, a su vez, separarlos en pequeños proyectos de como máximo 2 semanas de duración), y que estarán orientados a mejorar alguna funcionalidad externa a WordPress que podamos utlizar en su versión .org.

Algunos proyectos que se han propuesto por ahora:

• WordPress.org Profiles
• Plugin Directory/Infrastructure
• inline documentation team
• WordPress stats
• Documentation / Codex
• API
• Forum improvements
• BBPress as a plugin
• BuddyPress
• UI area for plugins

Por nuestra parte nos hemos unido al proyecto y hemos parado también nuestras aportaciones al TRAC. Hemos escogido proyecto, como los demás, y los de Mecus hemos decidido trabajar en la documentación en línea y el Codex. Por una parte, ampliaremos (o añadiremos en los casos en los que todavía no la haya) la información acerca de las nuevas funciones de WordPress 3.0, añadiendo ejemplos prácticos. Por otra, seguiremos con el trabajo de traducción del Codex, para lo que hemos abierto un grupo de Google con idea de poder realizar una buena gestión y que no nos pisemos trabajo.

Si quieres participar en 3.org, puedes presentarte voluntario aquí. La presentación y elección de proyectos será este jueves, a las 22h30 hora española, en el canal #wordpress-dev del irc.
Y si quieres participar con nosotros en el proyecto del Codex, puedes suscribirte a nuestro grupo de Google aquí.

Happy coding & happy translating

“Sita sings the blues¡” es una película animada que Karl Fogel usa para explicar cómo crear con Creative Commons. Estos son algunos de los consejos que dio:

1. Minimiza riesgos: prueba si el producto y las formas de colaboración funcionan. Ejemplo: Poner formulario preguntado si estarías dispuesto a compra el DVD a $15.
2. Haz que los regalos y donaciones sean fáciles.
3. Libera el contenido, vende los contenedores: La película es el río, hay que dejarlo fluir para que no se pudra. Cuando se venden DVD, camisetas, … se venden contenedores, no la obra en sí, que se permite ser exhibida donde uno quiera.
4. Incentiva la actividad comercial. Permite que se venda merchandising, que se puedan vender DVDs,… Hay que financiar.
5. Deja que los usuarios se conviertan en productores: Hicieron un wiki para los subtítulos de la película.

Podéis ver la película aquí.

Para demostrar que las obras de arte no nacen de la nada, que siempre son revisiones de otras anteriores, nos puso este maravilloso vídeo. Todos nos levantamos sobre hombros de gigantes, hasta los artistas. “All creative work is derivative”:

1. La posibilidad, la libertad de escribir y distribuir las ideas propias es una revolución que no apreciamos.
   

   “wordpress is the platform for revolution”

   pero ¿dónde está nuestro Thomas Paine, el genio que escribe las ideas revolucionarias de nuestro tiempo? WordPress debería estar aquí para darle a esos revolucionarios las herramientas para difundir sus ideas.

2. El problema del aumento de los usuarios y sus demandas, con el riesgo de complejizar demasiado tiene una solución: los plugins. Pero hay que mejorar su gestión, seguridad y estabilidad para usuarios avanzados. Las actualizaciones de seguridad y la compatibilidad entre plugins debe ser mejorada.
3. Hay que cambiar de “WordPress debería hacer x” a “para mi, estaría bien que wp hicera esto”.
4. Las principales acciones que se pueden hacer:Consumir, comunicar, colaborar y crear. ¿Qué acciones quieres priorizar para tu WordPress?
5. Plataforma para la revolución poderosa y segura para la dominación mundial completa. (Una broma para demostrar que no falta ambición y ganas de cambiar las cosas)

Hoja de estilo CSS

A la hora de crear una página web, siempre llega un momento delicado para todo desarrollador, darle el aspecto deseado a tu página de manera que se vea igual (o lo más parecida posible) en todos los navegadores.

Esto, a veces, no es tan fácil, puesto que unos navegadores cumplen con unos estándares y otros no. El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los navegadores. Para el que no esté familiarizado, las hojas de estilo o CSS, es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML).

Y aquí es donde nos solemos encontrar con los problemas, las características de CSS3 (soportadas por Mozilla Firefox, Google Chrome, Safari…) incluyen la propiedad border-radius, la cual define la curvatura que debe tener el borde de un elemento. Esta propiedad es muy usada por los diseñadores gráficos por su estética, pero en el caso de Internet Explorer, IE 6 y 7 sólo dan soporte para CSS1 y la versión de IE 8 sólo soporta hasta CSS2.

Sin embargo, ya tenemos una solución para poder ver nuestros elementos redondeados en IE 6, 7 y 8. Es un script escrito por Remiz y muy fácil de usar. Sólo tienes que seguir estos pasos:

• Descargate el archivo border-radius.htc o la demo.
• Sube el archivo al mismo directorio donde se encuentra tu archivo de estilo .css ( En wordpress suele ser: wp-content/themes/nombre-de-tu-tema/ ).
• Añade a tu hoja de estilo la clase:

.curved {

-moz-border-radius: 15px; /* Firefox */

-webkit-border-radius: 15px; /* Safari and Chrome */

border-radius: 15px; /* Opera 10.5+, future browsers, and now also Internet Explorer 6+ using IE-CSS3 */

-moz-box-shadow: 10px 10px 20px #000; /* Firefox */

-webkit-box-shadow: 10px 10px 20px #000; /* Safari and Chrome */

box-shadow: 10px 10px 20px #000; /* Opera 10.5+, future browsers and IE6+ using IE-CSS3 */

behavior: url(border-radius.htc); /* This lets IE know to call the script on all elements which get the 'box' class */

}

• Por último, dale el estilo a los elementos de tu página que desees, por ejemplo:

¡Listo!, ahora tu imagen photo.jpg aparecerá con los bordes redondeados y sombra en todos los navegadores

Nota: Nick F. ha ampliado funcionalidades, puedes echarle un vistazo a su tutorial en inglés y al artículo que ha escrito aNieto2k.

Es bueno poder sacar del error a todas estas personas, ya que el retraso de la fecha de salida de WordPress 3.0 es justo y necesario, y no puede ser más beneficioso para el usuario.

La fecha

WordPress 3.0 se presentará en la WordCamp SF (el día 1 de Mayo). A muchos nos parecía la fecha lógica, y ya la propusimos en febrero cuando hablamos de las fechas de salida de WordPress 3.0. Sin embargo, se propuso una fecha anterior (el 13 de Abril) para su salida oficial. La razón, muy lógica: que cuando llegáramos al la WordCamp llevásemos casi 3 semanas de rodaje de WordPress 3.0 y se pudieran contar cosas mucho más interesantes y con más visión de futuro.

Sufrimos ahora un retraso que hace que la presentación oficial sea en la WordCamp. No es nada grave. Puede hacer más interesante, si cabe, esta WordCamp, que podríamos titular perfectamente como The Future is Now.

La avalancha

Todos los procesos tienen ciertas fases. Si nos centramos en las cinco fases clásicas, WordPress ha calado y está calando en los usuarios de distintas formas:

• Negación: miedo a lo nuevo, al cambio. Más vale malo conocido que bueno por conocer.
• Ira: el liarse con el formato de publicación de WordPress es un clásico. Demasiado sencillo de manejar y moderar, nada que ver con Facebook o BlogSpot, donde todo está escondido.
• Negociación: El inicio del uso de WordPress como usuario. A ver cómo hago esto, a ver cómo hago aquello que en el otro sistema se hacía así…
• Depresión: ¿En qué he estado perdiendo mi tiempo hasta ahora?
• Aceptación: ¡Hey, esto me gusta!

Independientemente de que el usuario final pueda estar en una fase o en otra, para los desarrolladores estas pautas se modifican un poco. Mientras que los desarrolladores de código (programadores) se encuentran casi todos en la fase de aceptación (excepto unos cuantos desarrolladores de plugins y temas, que se encuentran en la fase de negociación –su único interés es ganar algo de dinero–), en la línea de desarrollo de WordPress 3.0 se ha abierto una nueva puerta a los desarrolladores de interfaz (diseñadores) para que participen activamente en la nueva versión de WordPress y ha dado lugar a distintas reacciones. Casi todos han comenzado en la fase de negación, pensando que tendrían poca participación, y ahora mismo están en diversas fases.

Este gran boom de participación ha tenido diversos efectos en el desarrollo de WordPress 3.0:

• Se han dado de alta en el trac cientos de usuarios nuevos.
• Las listas de correo se han poblado considerablemente.
• Las reuniones por IRC han estado muy pobladas y sido muy movidas.
• De los 200 tickets iniciales para 3.0 hemos llegado a la cifra de 943.
• Los foros de WordPress tienen más de 1,000 consultas al día.
• Muchísimos usuarios están utilizando el plugin WP Beta tester y probando la versión en desarrollo, reportando problemas.
• Hay muchas ideas nuevas cada día.

Como se puede ver, un retraso en fechas más que lógico para poder lidiar con todo esto.

El usuario

Después de muchos años (seis ya) y mucho desarrollo, la verdadera revolución de WordPress 3.0 no es otra que el usuario. ¿Sorprendidos? Sí, WordPress 3.0 está diseñado pensando principalmente en el usuario final. En que esté a gusto trabajando con WordPress.

De la mano de Jane Wells, nuestra experta en Experiencia de Usuario (UX), para esta versión de WordPress en la que ya teníamos tan avanzada la programación nos hemos centrado en hacer que la vida del usuario y de los desarrolladores medios (los que no se enfangan en el código hasta la cintura) sea mucho más sencilla. Los cambios, muchos:

• Miniaturas. Ahora llamada imagen destacada, que indica mucho mejor cuál es su funcionalidad para los temas en 3.0.
• Custom post types. Ya no hay sólo entradas y artículos. Ahora tenemos el tipo de publicación que queramos, y con sólo tres líneas de código. Esto hará también que los desarrolladores medios puedan crear plugins de publicaciones específicas (libros, música, publicaciones en revistas…) de forma muy sencilla.
• Custom taxonomies. Se pueden crear también nuevas relaciones, distintas de las que conocemos (categorías y etiquetas), que a veces se nos pueden quedar cortas. Ordenar jerárquicamente y etiquetar semánticamente se queda corto en un software que hace mucho que dejó de ser únicamente una plataforma de blogs.
• Menús. Zonas preparadas para incluir widgets donde podemos colocar casi cualquier contenido de nuestro blog.
• Repositorio de plugins. Los desarrolladores tienen un nuevo sitio donde subir sus creaciones, pudiendo actualizarlas de forma sencilla. La gran ventaja: los usuarios finales sólo tienen que hacer click en Actualizar todo en su blog y descargará automágicamente la última versión de WordPress, de sus plugins, y de sus temas.
• Repositorio de temas. Lo mismo que en el anterior.
• Página de plugins. Una página donde poder buscar semánticamente plugins desde tu propio blog e instalarlos con un solo click.
• Página de temas. Una página donde poder buscar semánticamente temas desde tu propio blog e instalarlos con un solo click.
• Temas hijos. Una gran revolución de la que ya hemos hablado.
• Nueva gestión de galerías. Y multigalerías por artículo o página con un sencillo plugin.

Si hablamos también de los cambios para los programadores medios o los desarrolladores de temas, con WordPress 3.0 ha llegado a la fase de aceptación, independientemente de en cuál estuviera antes.

Ya está cerca. Comienza la revolución.

Hoy vamos a intentar aprender a utilizar un tema hijo. ¿Te apuntas?

¿Qué es un tema hijo?

Como hemos contado en alguna otra ocasión, es un tema que hereda funciones de un tema padre. Es decir, lee toda la información de un tema existente y modifica ciertas acciones.

¿Por qué usamos temas hijos?

Es sobre todo un tema funcional. Utilizar un tema hijo facilita mucho el trabajo porque hace más simples las actualizaciones. Para entenderlo, vamos a poner un ejemplo.

Imaginemos que tenemos el nuevo tema por defecto de WordPress, Twenty Ten, y queremos hacer modificaciones. Twenty Ten es un tema vivo, es decir, que se actualiza cada vez que actualizamos nuestro WordPress, lo que tiene ventajas e inconvenientes. La ventaja principal es que, al ser un tema vivo, está siempre actualizado con los últimos cambios que se hayan realizado en el core (el núcleo de WordPress). La desventaja, que cualquier cambio que hayamos realizado sobre él se perderá en la actualización.

El tema hijo nos resultará útil como un contenedor para nuestros cambios separado del tema principal, de forma que cuando éste se actualice no perdamos nuestros cambios.

No es necesario que padre e hijo se parezcan . El tema hijo puede construirse a partir de cualquier tema ya existente. Una vez hecho, tenemos la seguridad de que será compatible con todas las futuras versiones de WordPress. Empresas como la nuestra son capaces de hacerlo sin mucha dificultad. (Consúltanos si estás interesado).

¿Cómo se utiliza un tema hijo?

Crear un tema hijo es más sencillo de lo que parece. Sólo hay que:

• Crear un directorio nuevo en la carpeta wp-content/themes.
• Crear dentro de él un archivo style.css.
• En el style.css, indicar que es un tema hijo y quién es su padre.

Con esto ya tenemos nuestro tema hijo. Fácil, ¿eh? Vamos a seguir los pasos y a hacer unas pequeñas modificaciones para ver su efecto. Lo primero es indicar que el tema es hijo de su padre.

/*
Theme Name: Tema hijo
Theme URI: http://temahijo.com/
Description: Tema hijo de Twenty Ten para WordPress
Author: Mecus
Author URI: http://mecus.es/
Template: twentyten
Version: 0.1.0
*/

Nótese que template tiene que coincidir con el nombre del directorio del tema padre.

Con este código todo lo que escribamos en el style.css sustituirá a lo indicado en el tema padre.

Probando el tema hijo

Para probar que el tema hijo funciona lo más fácil es cambiar algún color, para ver de forma visual qué está ocurriendo. Lo primero que tendremos que hacer es añadir la plantilla del tema padre. Para eso utilizaremos el siguiente código:

@import url('../twentyten/style.css');

Y ahora escribiremos las directivas que queramos modificar. Hay que tener en cuenta aquí, de nuevo, que cualquier cambio sustituirá a las líneas que haya escritas en el tema padre. En nuestro ejemplo modificaremos cómo se muestran los asides (artículos cortos) en Twenty Ten.

Extendiendo el tema hijo

Como hemos visto, un tema hijo necesita únicamente un archivo style.css para funcionar, pero puede utilizar más archivos. El que nos será más útil, sin duda será el functions.php.

El archivo functions.php, a diferencia del archivo style.css, añade funcionalidades al functions.php existente. El sistema utilizará el functions.php de forma automática, por lo que únicamente tendremos que añadir nuestras funciones al archivo.

Sin duda la función más interesante para añadir en nuestro archivo functions.php es el reconocimiento del favicon, del que carece el tema padre.

Para eso, crearemos nuestro archivo functions.php y añadiremos el siguiente código:

<?php
function favicon_link() {
$favicon = get_bloginfo('template_url').'/images/favicon.ico';
echo '<link rel="shortcut icon" type="image/x-icon" href="'.$favicon.'" />' . "\n";
}
add_action('wp_head', 'favicon_link');
?>

En nuestro caso hemos alojado el favicon en el directorio /images/ del tema, por lo que lo buscaremos ahí.

Extendiendo (aún más) el tema hijo

¿Eres de los que quieres control total? ¡Estupendo! Sólo tienes que crearte tus propias páginas en el directorio de tu tema hijo y éstas sustituirán a las páginas originales del tema padre. Puedes modificar hasta el index.php y crear páginas que no existan en el tema padre (como tag.php para las etiquetas, caso de que no existiera).

Ya tienes las claves. Ahora toca experimentar

Para desarrolladores

Recordad el uso de add_action y add_filter en vuestros temas hijos. Twenty Ten tiene 150 filtros y 60 acciones, así que ¡úsalas!

** Información extraída del archivo Child Themes del Codex de WordPress – Autor: Demetris.

Ahora los chicos de WordPress le han dado una nueva vuelta de tuerca al asunto con WYSIWYRG, What You See Is What You Really Get, que es el sistema que han impuesto en el nuevo tema para WordPress por defecto, Twenty Ten.

Podéis ver una prueba de cómo funciona este nuevo sistema, utilizando la CSS de nuestro tema en el editor visual, para ver realmente cómo queda nuestra publicación:

Puedes ver más en el artículo oficial en el blog de Twenty Ten.

Daryl

La primera conferencia de la WordCamp en el Tech Track fue la de Daryl Koopersmith. Daryl estaba allí para hablarnos de Elastic Theme.

Fue una buena entrada para la WordCamp. Un comienzo muy potente e interesante que nos dejó a todos con muy buen sabor de boca, tanto por lo que nos contaron, como por la demostración de cómo son las cosas: Daryl, un estudiante desconocido, ahora es parte de Automattic y está trabajando a pleno rendimiento con ellos. Y es que en Automattic no dejan que el talento se vaya corriendo. Hacen que se quede con ellos, y que siga creando valor añadido.

Pero vamos a lo que nos interesa. Rethinking themes.

Quién es Daryl

Daryl (@drylk) es un estudiante de la Universidad Washington en St. Louis que el año pasado decidió participar en el Google Summer of Code (una especie de campamento para programadores) donde estuvo trabajando en un nuevo Theme Framework para WordPress.

Qué es el Google Summer of Code

GSoC es un proyecto mundial que ofrece a estudiantes que sean desarrolladores la posibilidad de escribir código para proyectos software de código abierto. En GSoC han trabajado con muchos proyectos de código abierto y software libre.

La idea de GSoC es que un participante pueda tener un mentor para trabajar en un proyecto que haya elegido libremente. Por supuesto, eso le dará mucha experiencia y le brindará muchas posibilidades de quedarse en la empresa después.

En Automattic también se ofrecen proyectos en el GSoC, de forma que un desarrollador puede tener como mentor a Andy Peatling, Andy Skelton, Austin Matzko, Beau Lebens, Dion Hulse, Donncha O’Caoimh, John Godley, John James Jacoby, Joseph Scott, Mark Jaquith, Nikolay Bachiyski, Noel Jackson, Peter Westwood, Ryan Boren, Thorsten Ott, Jane Wells o al propio Matt Mullenweg. Cada uno de ellos es especialista en un apartado de WordPress (podéis consultar la lista de mentores aquí) y ayudarán a sus estudiantes en todo lo que puedan.

Daryl participó en el GSoC de 2009 en el apartado de Themes Framework. Y en esta conferencia nos ha mostrado sus resultados.

Qué es un Theme Framework

Un Theme Framework es algo así como un constructor de temas. Es decir, es una herramienta muy flexible que se puede utilizar para crear nuevos temas.

En la última actualización de WordPress se ha incluido algo que llevábamos tiempo usando en la sombra y que ahora está adquiriendo toda su relevancia: los temas hijos. El uso de frameworks hace el trabajo mucho más sencillo y reduce (en mucho) el tiempo que empleamos en crear el tema. Dejamos, pues, el uso duro de PHP con los WordPress Template Tags.

Un framework, como veremos, puede venir en dos sabores: como tema base, o como plugin.

Los temas hijos

Un tema hijo es un tema que tiene padre. Es decir, que se nutre de él.

Para explicarlo de una forma más simple, es un tema que hereda su funcionalidad del padre. Así, nosotros podremos crear un tema hijo a nuestro gusto utilizando las funcionalidades de padre (llamándolas), y si éste se tiene que actualizar, lo hará de forma transparente sin afectar en absoluto al tema hijo y sus cambios.

El Elastic Theme

El tema elástico (Elastic Theme) fue un proyecto que Daryl desarrolló durante el Google Summer of Code de 2009.
Con él, lo que nos intenta mostrar es la consecución final de todo lo que busca busca WordPress adaptado a un tema: más libertad para los usuarios y para los desarrolladores.

El tema elástico tiene:

• Estructura por niveles (ya hablaremos en próximos artículos del tema), lo que reduce mucho el trabajo.
• Las repeticiones de código se reducen usando jerarquías, modificando únicamente pequeños bloques. Utiliza mucho el famoso algoritmo divide y vencerás, sobre todo en el loop.php.
• WordPress 3.0 nos trae nuevas funciones que nos hacen más sencillo trabajar con temas. Una de ellas es get_generic_template(). Con ella podemos hacer llamadas como get_generic_template(‘loop’,'author’).
  • Más información acerca de get_generic_template (incompleto).
  • Más información acerca de los cambios de temas en 3.0 (incompleto).

Podemos sacar en claro que ahora los temas están creados:

• Como si fueran mini-páginas
• Como hijos de un tema principal
• Siguiendo una estructura jerárquica

Esa misma estructura jerárquica es la que hace que los temas sean más usables, ya que si tenemos un bloque que se repite podemos convertirlo en un módulo.

El motor del Elastic Theme

¿Quieres verlo en acción? Aquí tienes el vídeo.

El Elastic Sandbox ofrece:

• editor de temas en vivo
• un editor de estilos muy ligero
• temas modulares

Consideraciones para programadores

• Léete el código de WordPress. Úsalo. ¡Aprenderás un montón!
• Usa el trac, phpxref y el Codex. ¡Sigue aprendiendo!
• Experimenta. Ahora tienes dos nuevas funciones que te hacen la vida más fácil. Son nuevas en 3.0 y modifican la query. Y, lo mejor de todo, se ejecutan antes que el tema.
  • template_redirect
  • template_include
• Ahora podemos crear mashups usando WordPress de forma sencilla.
• ¡Tenemos un editor visual de temas! Lo que permite infinitos diseños.
• Al programar un tema, ten en cuenta que cualquiera debe poder modificar cualquier valor por defecto que hayas puesto.
• ¡Piensa en módulos!

Atualización (10/05/2010) Aquí está el vídeo de la charla:

Darragh Doyle

Viernes. Hora de salida: 7.20am. Viaje largo, muy largo, con muchas esperanzas puestas en todo lo que vamos a vivir durante este fin de semana. Por delante tenemos 14 horas de viaje y muchas cosas que queremos hacer. Estamos concienciados de que no podremos bloguear las conferencias (es prácticamente imposible hacerlo en vivo) y que con un tweet se pierden miles de detalles, de impresiones, que son imposibles de contar en 140 caracteres. Hace falta más espacio. Mucho más.

Llegamos a Kilkenny cerca de las 8 de la tarde, ya instalados, para asistir a la cena de ponentes y patrocinadores. Primero, una cervecita con las chicas. Después, elegir mesa. Nos sentamos con Jane Wells (UI Goddess), Paul Gibbs , Joost de Valk, Sheri Bigelow y Hanni Ross. No estuvo mal elegida .

Durante la cena (amenizada por Adam, el hijo de Donncha, que no paraba de pasearse por nuestra mesa) estuvimos hablando de unas cuantas cosas (casi todas gracias al pie que nos daba Joost, que no paraba de preguntar):

1) Core para plugins.

WordPress tendrá en breve una API en la que podremos encontrar una buena lista de funciones para utilizar en la creación de nuestros plugins. Estará incluida en el núcleo de WordPress, y se añadirá toda la información a la página de Plugin API que ya existe.

2) WordCamp SF.

Como sabréis, ya tiene fecha. La lista de ponentes de esta WordCamp viene directamente de la mano de Matt, lo que nos asegura la mejor calidad posible y que se revele mucha información acerca del futuro de WordPress, WordPress MU, BuddyPress y del resto de proyectos de Automattic.

3) BuddyPress.

Escuchamos en la mesa hablar de una posible integración de BuddyPress en el núcleo de WordPress. En Mecus llevamos un tiempo pensando en el tema, y en la mesa se ven confirmadas nuestras sospechas. Aunque tiene mucho sentido, no la vemos demasiado viable por varias cuestiones:

• Todavía estamos trabajando en la fusión de WP y WP-MU.
• BuddyPress es un plugin fácilmente instalable. No tendría sentido incluir más peso en el núcleo teniendo esa facilidad de instalación.
• No todo el mundo quiere instalar una red social (en contra de este argumento, también podemos decir que no todo el mundo quiere instalar un WordPress multiusuario y en la nueva instalación tendremos esa opción).

La cuestión está bien documentada, por supuesto. Si se ha hablado de esta posibilidad es porque en un futuro muy cercano, cuando queramos instalar WordPress, nos preguntará si lo que queremos instalar es un WordPress o un WordPress multiusuario. ¿Por qué no preguntarnos si queremos instalar una red social directamente? (Este tema lo abordaremos más adelante, cuando tratemos la charla de BuddyPress).

Lo que sí está claro es que BuddyPress estará incluído en el Codex de WordPress.org, y no como proyecto aparte como hasta ahora. Cada vez toma más relevancia.

4) Las chicas de Automattic.

Son geniales. Todas. Es muy agradable compartir con ellas una cena, unas cervezas, o lo que propongan. Están muy metidas en su trabajo: siempre están hablando de WordPress. Y han incluido a nuestro enviado especial en la lista de sus WP Evangelists.

5) VideoPress.

El nuevo servicio de Automattic está pegando fuerte. Aunque tienen claro que para ellos es y será deficitario (económicamente hablando), también tienen claro que en el momento actual debían sacar un servicio de soporte de vídeo en HD distinto a WordPress.tv para WordPress y el resto de servicios de Automattic.

VideoPress ya está funcionando en WordPress.com, y dentro de muy poco veremos aparecer un plugin con widget asociado para todos los blogs de instalación externa y para servicios que no estén asociados a WordPress. Todo aquel que quiera podrá hacer uso de VideoPress en cualquier plataforma, sin necesidad de que esté asociada a WordPress o a otros servicios de Automattic.

6) GPL.

SEO y GPL han sido las palabras más repetidas de la WordCamp. También le dedicaremos un apartado propio, como a BuddyPress.

Y, por supuesto, si queréis hacer preguntas nuestros comentarios están abiertos

Todas las sesiones son interesantes, pero no tenemos el don de la ubicuidad, por lo que hemos tenido que decidir. Y teniendo ya claro casi todo, aún nos queda una sesión en la que todavía no sabemos dónde estaremos. Estamos muy expectantes ante la charla plenaria de Jane Wells, que es una de las empleadas de Automattic con más peso específico. Esperamos saber algo más de la inminente versión 3.0, la definitiva fusión de los blogs individuales con el multiblog. Joost de Valk sobre Frameworks y Donncha con su imprescindible Super Cache son también imprescindibles para nosotros.

Éstas son las sesiones a las que asistiremos. Si quieres que preguntemos algo en tu nombre, puedes utilizar los comentarios. Y si nos quieres ayudar a decidir en nuestra sesión, las opiniones son también bienvenidas.

Sábado

Domingo

Como podéis ver, nuestra indecisión está en la sesión de temas del domingo a las 10:30. Nuestras opciones:

• Panel sobre distintos usos de temas (themes), dónde se utilizan, por qué y para qué (Introducción).
• Temas bonitos (Themes) que quizás no conozcamos que nos pueden ser útiles para algún proyecto (Bloggers).
• Una vuelta de tuerca sobre el diseño de temas –incluyendo programación para WP 3.0– (Técnico).

La tercera opción quizá es la que más nos llama la atención por nuestro perfil. Aunque conocer más a otros niveles no estaría nada mal. ¿Opiniones?

¿Algo que queráis transmitir a alguno de los ponentes?