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

Scott Berkun nos da la primera charla, sobre cómo sería su WordPress preferido.
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?

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 gestion, seguridad y estabilidad para usuarios avanzados. Las actualuzaciones de seguridad y la compatibilidad entre plugins debe ser mejorada.

De “wordpress debería hacer x” a “para mi, estaría bien que wp hicera esto”

Consumir, comunicar, colaborar y crear.

Plataformapara la revilucion poderos y segura para la dominación mundial completa.

I think these critics’ point of view is not correct. Running late in the release date of WordPress 3.0 is fair and necessary, and cannot be more beneficial for the user.

The release date

WordPress 3.0 will be announced officially in WordCamp SF (May the 1^st). Some of us thought it was the right release date for WP 3.0, and we proposed it in febrary when we were discussing WP 3.0 release dates. However, a prior date, April 13^th, was proposed for the official release date. With a very logic reason: to have a 3-week feedback with WP 3.0 when we arrive to the WordCamp and be able to show much more interesting things and a more long term vision.

We are now suffering a delay that will make the official presentation to happen in WordCamp SF. Nothing serious. It will make more interesting, if possible, this WordCamp, that we can title like The Future is Now.

The avalanch

All processes have certain phases. If we focus on the five classic stages, WordPress is reaching people in different ways:

• Denial: Fear to the new, fear the changes. Better the evil you know.
• Anger: The affair with the WordPress publishing format is a classic. This too easy to use to be true. You must be kidding me, this is not as difficult as Facebook or Blogger, where everything is hidden.
• Bargaining: The classic start of a new user in WordPress. How to do this or that, in my old system it was different…
• Depression: Have I been wasting my time all this time?
• Acceptance: Hey, I like it!

Whether the final user can be in one stage or another, for developers these guidelines are slightly different. While source developers (programmers) are almost all in the acceptance phase (except a few plugin and theme developers, which are mostly in the bargaining stage, –their only interest is to earn money–), WordPress 3.0 has opened a new door to the interface developers (designers) to participate actively in the new version of WordPress and has risen to different reactions. Almost all have started at the stage of denial, thinking they would have little participation, and right now are in different phases.

This great boom of participation has had different effects in the development of WordPress 3.0:

• There are hundreds of new users in trac.
• Mailing lists have been populated considerably.
• IRC meetings are very active.
• Of the 200 original tickets for 3.0 we have reached the figure of 943.
• WordPress forums have over 1,000 visitors per day.
• Many users are using WP Beta tester plugin and testing development versions and reporting problems.
• There are lots of new ideas every day.

As you can see, a small date delay seems to be reasonable if we want to manage this.

The user

After many years (six!) and a lot of development, the real WP 3.0 revolution is the user. Yes, we are not crazy. WP 3.0 is designed and focused in the end user, trying to give him the best user experience using WordPress.

By the hand of Jane Wells, our User eXperience leader, we have focused in this WordPress version in making the end user experience and middle developers experience (those who don’t digg very deep in the code) easier. And we have many changes:

• Thumbnails. Now called featured images, which is more accurated with its  functionality in WP 3.0.
• Custom post types. We had posts and pages. Now we have the type of publication that we need, and with only three lines of code. This will allow middle developers to create specific-publications plugins (books, music, magazines…) easily.
• Custom taxonomies. Now we can create new relations different from categories and tags. Hierarchical order and semantical tagging is very poor in a software like WordPress, which is more than a blog platform.
• Menus. Custom zones for widgets where we can put almost any content of our blog.
• Plugins repository. Developers now have a new site to upload and share their creations, updating in a simple way. The great advantage: end users only need to click in Update all in their dashboard and they will update automagically the last version of WordPress, its plugins and its themes.
• Themes repository. Same as prior.
• Plugins page. A page in which you can search semantically plugins from your dashboard and install them with one click.
• Themes page. A page in which you can search semantically themes from your dashboard and install them with one click.
• Child themes. A great revolution. We have already speaked about it.
• New galleries management. And multi-galleries per post or page with a simple plugin.

With WordPress 3.0 all middle code developers and theme developers are in the acceptance phase, regardless of in what they were before.

It’s here. The revolution begins.

Today we are going to learn how to use a child theme. Interested?

What is a Child Theme?

As we have told some times before, a child theme is a theme that inherits functions of a parent theme. It reads all the information about an existing theme and modifies some actions.

Why we use Child Themes?

Because it’s very useful. Using a child theme makes our work easier. To understand it better, let’s see an example.

Suppose that we have the new default WordPress theme, Twenty Ten, and we want to make some modifications. Twenty Ten is an alive theme. It means that every time we update our WordPress the theme is updated too. It has advantages and disadvantages. The main advantage is that being a live theme it’s always updated with the last changes done in the core. The disadvantage is that every change we have done is lost in the update.

The child theme will be useful as a container for our changes being separated of the parent theme, so if it updates we will not lost our changes.

Parent and child do not necessary look alike .  Child theme may be built from any already built. Once it’s properly built, we can be sure our theme will be compatible with all upcoming versions of WordPress. Companies like us can do it for you. Please, contact us if you have any question.

How we use a Child Theme?

Creating a child theme is very easy. Just follow:

• Create a new directory in wp-content/themes.
• Create the file style.css inside it.
• In style.css you must indicate that it’s a child theme and who is his father.

Doing this we have our child theme. Easy, huh? Now let’s change some little things to see how it works. The first we must do is indicate that the child theme is the child of his father .

/*
Theme Name: Child theme
Theme URI: http://childtheme.com/
Description:  Twenty Ten Child Theme for WordPress
Author: Mecus
Author URI: http://mecus.es/
Template: twentyten
Version: 0.1.0
*/

Here, in the header of the style.css file, template must coincide with the name of the directory of the parent theme. Using this code, everything that we write in style.css will replace and override all the things written in the parent style.css.

Testing the Child Theme

To test the child theme changing some colors is the easiest, seeing directly what is happening. First of all, we have to add the parent stylesheet. To do this, we will use this code:

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

And now we will write all the things that we want to change. We must have in mind that any change will override what is written in the parent theme. In our example we are modifying the asides in Twenty Ten.

Extending the child theme

As we have seen, a child theme only needs a style.css file to work, but we can use more files. The most useful file that we can use here is, without doubt, functions.php.

functions.php file, unlike style.css, adds functionality to the existing functions.php parent file. The system will use the child functions.php automatically, so we only have to add our functions to it.

One of the most interesting things to add to our functions.php is the favicon, who is not in the parent theme. To do this, we will create our functions.php file and will add this code:

<?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');
?>

In our example we have saved our favicon in the theme /images/ directory.

Extending (more) the child theme

Do you want total control? Great! You only need to create your own pages in the directory of your child theme and they will override the originals in the parent theme. You can modify even index.php file and create nonexistent pages in the parent theme (like tag.php for tags in the themes in which it’s absent).

Now you have the clues. Let’s experiment

Developers info

Remember the use of add_action and add_filter in your child themes. Twenty Ten has 150 filters and 60 actions, so use them!

** Data from Child Themes – WordPress Codex – Author: Demetris.

But WordPress team have make a new twist on that issue with WYSIWYRG (What You See Is What You Really Get), the tool built on the new default theme for all new WordPress: Twenty Ten.

You can see below how this new tool works: we have used our theme’s CSS in the Edit Post Menu (Visual mode) to show how a post is displayed in this site.

To know more, go to the post in the official Twenty Ten Blog.

Daryl

The first WordCamp conference in the Tech Track was the one from Daryl Koopersmith. Daryl was there to talk us about the Elastic Theme.

It was a very good intro for the WordCamp. A very strong and interesting beginning which gave a very good impression to all of us. First, because all the things that we learned from his speech. And second, for the demonstration about how cool life can be: Daryl, an unknown student one year ago, now is a part of Automattic and is working full-time with them. That’s because Automattic doesn’t allow talented people run away. They made them to stay and continue creating valuable stuff.

But let’s go to the interesting part. Rethinking themes.

Who is Daryl

Daryl (@drylk) is a computer science student from Washington University at St. Louis. Last year he decided to participate in Google Summer of Code (a programmers camp) where he was working in a new Theme Framework for WordPress.

What is Google Summer of Code

GSoC is a mundial project which offers to students who are developers too the opportunity of write code for open source software projects. GSoC have got lots of open source and free software projects.

The idea surrounding GSoC is that the attendants could have a mentor to work in a project chosen. It will give them a lot of experience and lots of opportunities to work in the desired company.

In Automattic there are projects in GSoC too. It means that a developer can have to 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 or Matt Mullenweg like a mentor. Each one is specialist in a WordPress field (you can see the complete list of mentors here) and they will help their students in everything they can.

Daryl was one of this students in 2009 GSoC, more precisely in Themes Framework field. And in this conference he showed us his achievements.

What is a Theme Framework

A Theme Framework is a theme constructor. It’s a very flexible tool that can be used to create new themes.

In this last WordPress update we can find a new relevant tool: child themes. Using frameworks makes our work much more easy and reduces the time that we spend in creating our themes. That means that we stop using PHP and the WordPress Template Tags reference for everything.

A framework can be presented in two flavours: parent theme or plugin

Child themes

A child theme is a theme with a father: It uses functions and other characteristics directly from him.

We can create a child theme and use all the functions that we need casting from the parent theme. And if we need to update the parent theme, it will update without harming our child theme and our changes.

The Elastic Theme

The Elastic Theme is a project that Daryl developed during Google Summer of Code in 2009.

And what he wants to achieve is what everyone is looking in WordPress, adapted to a theme: freedom for users and developers.

The Elastic Theme has:

• Level-structure, which reduces work a lot. We’ll talk about it in next posts.
• Code repetitions are reduced using hierarchy, modifying only small blocks of code. It uses the infamous divide-and-conquer algorithm. One small sample is the archive loop.php.
• WordPress 3.0 has new functions which makes easier our work with the themes. One of them is get_generic_template(). Using it we can do calls like get_generic_template(‘loop’,'author’).
  • More info about get_generic_template (incomplete).
  • More info about changes in themes in WordPress 3.0 (incomplete).

We can do a small resume about the new way of creating themes:

• They are created like mini-pages.
• They are children of principal (parent) themes.
• They have a hierarchy-level structure.

This hierarchy-level structure makes the themes more usable, because if we have a block which repeats itself we can convert it in a module.

The Elastic Theme engine

Do you want to see it in action? Here’s the video.

The Elastic Sandbox offers:

• Live theme editor.
• Light style editor.
• Modular themes.

If you are a developer

• Read the WordPress Code. Use it. You’ll learn a lot!
• Use trac, phpxref & Codex. Continue learning!
• Experiment. Now you have two new functions which will do your life easier. They are brand new in 3.0 and modifies wp query. And, best of all, they execute before the theme.
  • template_redirect
  • template_include
• Now we can create mashups using WordPress in an easy way.
• We have a visual theme editor! It allows infinite layouts.
• When programming a theme you must get in mind that everyone must be allowed to modify any default value.
• Think modular!

Update: This is the video:

Darragh Doyle

Friday. Time of departure: 7.20am. Very long trip, with many hopes put in what we are going to live during this weekend. Ahead we have 14 hours of trip and many things that we want to do. We are aware of that we will not be able to blog the conferences (it’s practically impossible to do it live) and that using twitter we will lose thousands of details, of impressions, that are impossible to transmit in 140 characters. We need more space. Much more.

We arrived at Kilkenny about 8pm, already unpacked, to attend to the speakers & sponsors dinner. First, some beer with the Automattic girls. And then, time to choose table to have dinner. We sat down with Jane Wells (UI Goddess), Paul Gibbs , Joost de Valk, Sheri Bigelow & Hanni Ross. Not a bad election .

During the dinner (brightened up by Adam, Donncha‘s son, who didn’t stop talking and playing) we were speaking about a few things (thanks to Joost, who did not stop asking):

1) Core Plugins.

WordPress will shortly have an API in which we will be able to find a great list of functions to use in the creation of our plugins. It will be including in the WordPress core, and all the information will be added to the page of Plugin API that already exists.

2) WordCamp SF.

As you will sure know, we already have a date for WordCamp SF. Speakers list of this WordCamp is directly done by Matt, which assures us the best-ever quality possible and to be revealed a lot of information about the future of WordPress, WordPress MU, BuddyPress and the other projects of Automattic.

3) BuddyPress.

We were talking about the possible integration of BuddyPress in the WordPress Core. We have been discussing about this in Mecus last month, and now they have confirmed our suspicions. Although it makes sense, we do not like this path by several reasons:

• We are already working in the merging of WP and WP-MU.
• BuddyPress is an easy-to-install plugin. It have not sense to include more weight to the core having 1-click-install.
• Not everybody wants to install a social network (we have the contrary argument: not everybody wants to install a multiuser WordPress and it’s an installation option).

But it makes sense for WordPress people, of course. If we are talking about this possibility it’s becausse in the near future, when we want to install WordPress, it will ask us if what we want to install (single-user) WordPress or a multiuser WordPress. Why not to ask then if we want to install a social network? (We will talk about it in a future BuddyPress article).

We are aware that BuddyPress will be included in the Codex of WordPress.org, and won’t be a separate project like now. It’s getting more relevance everyday.

4) The Automattic girls.

They are brilliant. All of them. It’s very pleasant and an honor to share with them a dinner, beers, or whatever they propose. They are very concerned about their job: they are always speaking about WordPress. And they have included to our special agent in their list of their WP Evangelists.

5) VideoPress.

The new service of Automattic is beating hard. Although they know clearly that for them it’s not a profitable project, they also know that, by now, they had to offer a video service with HD support in addition to WordPress.tv for WordPress and the rest of services of Automattic.

VideoPress is already working in WordPress.com, and we will soon see a plugin with widget for all the blogs of external installations and services that are not associated to WordPress. Everyone who wants to use VideoPress will be able to do that, in any platform, and without the need of being associated to WordPress or to other services of Automattic.

6) GPL.

SEO & GPL have been the most repeated words of the WordCamp. We will dedicate them its own section, like to BuddyPress.

And, of course, if you want to make questions our comments are open

All sessions are interesting, but we do not have the gift of ubiquity, so we have to decide. And having already clear almost everything, we still have a session in which we don’t know where to be. We are very excited at the plenary talk by Jane Wells, who is one of the employees of Automattic with more weight. We hope to know more about the upcoming version 3.0 of WordPress and the final fusion of the individual blogs with multiblog. Joost de Valk on Frameworks and their essential Donncha Super Cache are also critical for us.

These are the sessions we will attend. If you want us to ask something in your name, you can use the comments. And if you want to help decide where to be in our ubiquity problem, opinions are also welcome.

Saturday

Sunday

As you can see, our indecision is in session on topics of Sunday at 10:30. Our options:

• Panel discussion on various uses of themes. Why and where they are used (Introduction).
• Beautiful and useful themes maybe you don’t know (Bloggers).
• A new twist in the design of themes –including programming for WP 3.0– (Tech).

The third option is perhaps the most striking to us by our profile. Although knowing more at other levels would not be bad. Opinions?

Anything you want to say to any of the speakers?

]]> http://en.mecus.es/a-que-asistiremos-wordcamp-irlanda/feed/ 1