domingo, 17 de febrero de 2013

Guía para crear el perfecto tema WordPress

developer

En ThemeShaper han creado una guía para cualquier desarrollador que quiera crear un tema WordPress que atienda a todos los estándares, de manera que ofrezca la mejor experiencia puramente WordPress.

La guía está pensada para desarrolladores de temas para WordPress.com pero es igualmente útil para cualquier entorno WordPress. Y cómo creo que es de un tremendo interés aquí lo tienes en español …

Escapes

  1. Todos los datos dinámicos deben tener escape con esc_attr() antes de entregarse como atributo HTML
  2. Todas las urls dinámicas deben tener escape con esc_url().
  3. Si los datos dinámicos se entregan cómo el atributo de un elemento script HTML deben tener escape con esc_js().
  4. Las peticiones SQL que contengan datos dinámicos deben tener escape con $wpdb->prepare().

Internationalización

  1. Todos los textos visibles para el usuario deben prepararse para traducción.
  2. Evita HTML dentro de cadenas de las funciones “gettext” siempre que sea posible.
  3. La salida de sprintf() debe tener escape en las cadenas de texto utilizadas en los atributos.
  4. Los localizadores printf() deben tener escape antes de incluirlos en atributos HTML.
  5. Ofrece contexto donde haga falta.
  6. Evita anti-patrones comunes.

Peticiones (queries)

  1. Las peticiones SQL directas deben evitarse. Es mejor utilizar uno de los nuevos objetos WP_Query cuando sea posible.
  2. No pueden usarse peticiones ilimitadas. Básicamente, esto significa que el parámetro posts_per_page de WP_Query no puede establecerse a -1. Además, el parámetro numberposts de get_posts() (y funciones similares) también debe tener un valor positivo.
  3. Las peticiones grandes deben cachearse de manera transitoria.
  4. No se puede usar query_posts(). Si necesitas modificar la petición principal es mejor usar el filtro pre_get_posts. Si necesitas recuperar entradas además de la petición principal es mejor usar el nuevo objeto WP_Query.
  5. Los valores vacíos no deben pasarse al argumento  post__in usado para crear un nuevo objeto WP_Query. Si estás usando un valor dinámico que deba estar vacío es importante comprobar que está vacío antes de usar el valor en la petición (ejemplo).
  6. Las peticiones de términos deben comprobarse en una instalación que tenga 10.000 términos.

Envíos a la cola (enqueues)

  1. Todos los archivos de terceros incluidos deben ser compatibles con la licencia GPL.
  2. Asegúrate de que se usa el protocolo adecuado para poner en espera archivos de terceros.
  3. Asegúrate de que se usan los hooks adecuados para poner en espera scritpts y estilos.

Scripts

  1. Usa los scripts incluidos en la instalación estándar si existen.
  2. Los scripts personalizados no deben minimizarse.
  3. Los scripts de terceros que se incluyan no pueden minimizarse pero deben incluir lo siguiente:
    1. El nombre de la librería.
    2. Número de versión
    3. Licencia
    4. URL

Estilos

  1. La hoja de estilos principal (style.css) debe ponerse en espera durante la acción wp_enqueue_scripts.
  2. Nunca se debe utilizar overflow:hidden para que contenga objetos flotantes (floats). Es una alternativa mejor usar micro clearfix.
  3. La clave !important no debe utilizarse donde sea suficiente una especificación.
  4. El poner en espera una fuente de Google con varios bloques de caracteres incluye de manera condicional los bloques con gettext.
  5. No están permitidas los atributos de estilo en tags HTML.

Conflictos con plugins

El entorno de WordPress.com está sobrecargado con una gran cantidad de plugins que ofrecen funcionalidades compartidas con todos los temas. Para ofrecer a los usuarios una experiencia consistente no deberían incluirse en los temas funcionalidades que dupliquen las de los plugins. Esto también debe ser aplicable a otros entornos.
A la hora de diseñar temas para WordPress.com esto es lo se usa:
  1. Las opciones de publicidad se gestionan con WordAds.
  2. Los ajustes de color personalizado se gestionan con el plugin Custom Colors.
  3. Los ajustes de fuentes personalizadas se gestionan con el plugin Custom Fonts.
  4. Los favicons se gestionan con el plugin Blavatar.
  5. Se usa soporte HiDPI para las imágenes subidas por los usuarios
  6. El scroll infinito lo ofrece Jetpack.
  7. Protocolo Open Graph
  8. Soporte de Twitter meta tag
  9. Diversos widgets

Portabilidad de datos

Asegurar que el contenido del usuario no cambia cuando cambia de tema es muy importante. Las siguientes características de la instalación estándar de WordPress, aunque son fantásticas por si solas, pueden provocar un cambio en el contenido del usuario o no estar disponible si se activan desde el tema.
  1. Tipos de entradas personalizas públicas
  2. Taxonomías personalizadas públicas
  3. Campos personalizados o campos meta de entradas
  4. Códigos cortos (shortcodes)

Opciones del tema

Si tu tema incluye ajustes personalizados es altamente recomendable usar el Personalizador en vez de una pantalla personalizada de administración. Hacerlo así tiene muchas ventajas:
  1. Los usuarios pueden ver sus cambios inmediatamente, ya que se adapta a la interfaz de usuario.
  2. Hay que escribir mucho menos código.
  3. Dispones de módulos de interfaz de usuario para la mayoría de las situaciones habituales.
Si tu tema necesita ofrecer una pantalla de administración de ajustes personalizados estos son los requisitos:
  1. Debe ser un menú hijo del menú Apariencia, con el título de “Theme Options”.
  2. Se requiere el uso de la Settings API de WordPress.
  3. Todos los ajustes deben guardarse un “array” en serie.
  4. Los ajustes por defecto no deben insertarse en la base de datos hasta la instalación o una petición http.
  5. Todos los valores deben sanearse antes de guardarlos en la base de datos.
  6. Debe utilizarse la funcionalidad de la instalación estándar para cualquier necesidad de carga de archivos.
La mayoría de estos requisitos, si no todos, están en este Archivo de ejemplo de ajustes de temas para principiantes.

Miscelanea

  1. Deben usarse los “loops” completos en todas las plantillas. No es suficiente simplemente con llamar a the_post() en una plantilla cómo single.php o page.php.
  2. El $content_width global debe definirse correctamente.

wordpress-codex-themes

Guías de usabilidad

La Unidad de datos de prueba para temas de WordPress.org está repleta de entradas y páginas diseñadas para llevar tu tema a sus límites. Descarga los datos e impórtalos a tu servidor de pruebas. Probar tu tema con todos los tests disponibles te ayudará a asegurar que tu tema será lo suficientemente flexible para manejar una amplia variedad de datos reales de usuario.

Recursos

Traducción (algo libre pero precisa en lo vital) de Theme guide

No hay comentarios:

Publicar un comentario