Para variar, cuando aún no nos hemos acostumbrado a las novedades de WordPress 3.1 ya está en marcha el desarrollo de la siguiente versión: WordPress 3.2, y según Mark Jaquith será una revisión potente como pocas, a saber …

• El asunto es “más rápido, más ligero” Se van a retirar tecnologías obsoletas para  hacer que sea todo más rápido y que la experiencia de escritura sea más ligera y sosegada.
• Mejoras en la API de listado de tablas— más flexibilidad para uso de la API por parte de terceros.
• Carga en el listado de tabla XHR — algo a investigar cuando se estabilice la API de listado de tablas.
• PHP 5.2 ( en concreto 5.2.4, specifically) va a ser obligatorio. A hacer puñetas la compatibilidad hacia atrás, sin rémoras inseguras del pasado. No es cuestión de incorporar un montón de nuevas funcionalidades de PHP 5 sino de eliminar todo lo viejo y sustituirlo por lo nuevo..
• MySQL 5 también será obligatorio. No van a cambiar las queries, solo los requisitos para la instalación.
• Fin de IE6 para el admin. Si, ya va siendo hora de abandonar Internet Explorer 6 y usar un navegador "de verdad". Seguramente no se pueda hacer mucha limpia de CSS ya que IE7 comparte muchos de los problemas de su hermano previo pero habrá menos cosas que comprobar y con las que ser compatible arcaicamente. Por supuesto, los problemas de seguridad de IE6 no afectarán.
• Escritura sin distracciones. Esta es la característica estrella para el usuario. Se va a reemplazar la funcionalidad de pantalla completa con algo más útil, simple y agradable, inspirándose en WriteRoom, OmmWriter, http://www.quietwrite.com/. Koop está mirando este tema para ver si puede ofrecer un plugin que facilite las cosas y así haya que hacer menos desarrollo.
• Mejoras en las actualizaciones. Las actualizaciones en las que solo se cambian algunos archivos se harán sin tocar los ficheros "core". Si acaso se ofrecerá una actualización completa si hay muchos ficheros a modificar, a elección del usuario, sobreescribiendo los antiguos. Esto será efectivo para las actualizaciones menores dentro de la misma versión (de la 3.2 a la 3.2.1, por ejemplo).
• Mejoras de velocidad. Hay muchas pequeñas cosas que se pueden hacer aún para que WordPress cargue y se perciba más rápido. Nacin está trabajando en la lentorra carga de PHP y también en un parche para que el menú de admin cargue más rápido haciendo la expansión en PHP. Se podrá acelerar el Escritorio evitando peticiones asíncronas de los paneles si la cache está activa. Dion ha realizado mejoras en el FTP para que las actualizaciones sean más rápidas en algunos servidores FTP. Aquí

Parece que Mark tiene las cosas muy claras y vamos en una muy buena dirección para hacer que WordPress siga siendo el CMS por excelencia.

Personalmente me encanta la línea de desarrollo propuesta, algo que veníamos pidiendo hace mucho: dejarse de adornos y hacer un WordPress más ligero y rápido.

Bueno, afortunadamente ya está solucionado gracias a la intervención de Rafa Poveda, así que si ya actualizaste a WordPress 3.1 en español de España, para solucionar los fallos de traducción solo tienes que ir a la página de actualizaciones y pulsar el botón de “Re-instalación automática” para que se cargue la traducción completa y correcta.

Por supuesto, ya está cargada en el sitio oficial de WordPress España. No obstante, como siempre, esto es un trabajo constante y si en varios sitios detectáis algún error no dejéis de comentario y lo solucionamos.

¡Que disfrutes WordPress 3.1 en español!

El mejor modo de actualizar WordPress es mediante el actualizador del escritorio. Esto es debido a que no hay dudas de que actualiza desde el repositorio oficial y además es el método más rápido. ¿Por qué?, pues sencillamente porque no actualiza todo sino solo aquellos ficheros que han cambiado sobre tu versión actual.

Ahora bien, hay ocasiones en que, o no tienes permisos suficientes de tu servidor para actualizar de este modo, o simplemente te sientes más seguro haciéndolo por FTP, a la antigua usanza. Este método, el tradicional, está especialmente recomendado cuando has realizado modificaciones a ficheros ‘core‘ (que ya sabes que no es buena costumbre) o, mucho más común, si has personalizado el tema por defecto (K2 o TwentyTen), ya que muchas actualizaciones realizan cambios en el tema por defecto y pueden sobreescribir tus maravillosas personalizaciones.

En estos casos, una de las cosas que personalmente me llevan los demonios es que la actualización tarda bastante de cara a tus lectores, y además no ven ningún aviso de que estás actualizando (salvo que lo prepares claro). Entre tanto actualizas suelen ver errores horribles en tu sitio ya que se están sobreescribiendo archivos de manera aleatoria.

Los culpables de esta tardanza son las carpetas de la instalación, las que más ficheros contienen y que ralentizan el proceso de carga por FTP. Y, bueno, yo tengo un truquito que igual os viene bien.

El proceso que yo hago en estos casos es el siguiente:

1. Descargas este enlace http://wordpress.org/latest.zip
2. Descomprimes el fichero en tu ordenador y verás que la instalación estandar de WordPress son varios archivos sueltos y 3 carpetas
3. Las carpetas son: wp-content, wp-includes y wp-admin
4. Borras la carpeta wp-content local recién descomprimida, esa no se sube nunca porque sino sobreescribes la carpeta de contenido de tu sitio, donde se guardan fotos, plugins, el tema, etc. Así no te equivocas, la borras tras descomprimir el zip y así no hay error posible.
5. Ahora el truco para una actualización rápida: renombra las carpetas locales wp-admin y wp-includes a wp-admin_nueva y wp-includes_nueva o como quieras, antes de subirlas.
6. Subes por ftp las carpetas wp-admin_nueva y wp-includes_nueva, de este modo tienes lo más pesado subido, ganas tiempo en que no está fuera de servicio tu sitio por la actualización.
7. Cuando estén subidas las carpetas renombradas subes los ficheros sueltos por ftp, en este caso si te pedirá el cliente ftp sobreescribir los ficheros remotos, aceptas (esto es muy rápido). A partir de este momento tu sitio mostrará errores a los lectores así que desde aquí tienes que hacer rápido este punto y los dos siguientes (el último punto no afecta a la visualización de tu sitio).
8. Renombras las carpetas remotas wp-admin y wp-includes a wp-admin_vieja y wp-includes_vieja.
9. Renombras las carpetas remotas wp-admin_nueva y wp-includes_nueva a wp-admin y wp-includes.
10. Accedes a http://tudominio.com/wp-admin/upgrade.php y en la siguiente pantalla te dirá si tienes que actualizar la base de datos, si es así, le das al botón y ya está hecho.
11. Para dejar todo limpito borras las carpetas remotas wp-admin_vieja y wp-includes_vieja

Ya está. Con este método casero consigues reducir bastante el tiempo de actualización de WordPress por FTP. De hecho, la carga de los ficheros sueltos dura pocos segundos y es el único momento en que tus visitantes podrían notar algo.

Espero te haya servido.

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía para Administrar WordPress

Westi anunció hace unos días un nuevo sitio desarrollado para que todo aquel que tenga una idea, un parche, que aportar para mejorar el “core” de WordPress lo pueda hacer de manera sencilla e inmediata: Patches Welcome.

La idea es facilitar el modo de colaborar con el desarrollo de WordPress mediante la aportación de lo que cada uno sienta que puede ofrecer.

Ahora que acaba de salir una nueva versión "lista para publicar", o "release candidate" como dicen los guiris, nos surgió esta mañana a José y a un servidor la discusión sobre la política reciente de Automattic al respecto de este tipo de versiones RC.

Y es que estas versiones son para que las probemos, no solo a modo de anuncio de que ya está casi terminada la versión final. Y claro, luego los chicos de WordPress se quejan de que la gente no las usa, que no las prueba, y que los fallos de las primeras versiones finales no ocurrirían si realmente probáramos las versiones RC, incluso las betas. Pero ¿tienen razón?.

Vamos por partes (como diría Jack "el destripador") … 

Por supuesto, tienen razón al decir que las versiones RC son para revisarlas, probarlas en nuestro PC o carpeta de servidor, ver si hay fallos y avisar al equipo de desarrollo. De este modo las versiones finales saldrían mucho más finas, tras haber sido probadas las versiones RC y Beta en todo tipo de servidores y situaciones.

Esto es especialmente relevante si nos referimos a desarrolladores de plugins. WordPress hizo hace tiempo la apuesta valiente de que avanzar, de no pretender compatibilidades excesivas "hacia atrás", como hizo Joomla y así se le está viendo el pelo. Pero es entonces responsabilidad de cada desarrollador probar las versiones ßeta para comprobar si su plugin o tema funciona correctamente en la nueva versión, no va a estar el equipo de desarrollo de WordPress probando cada plugin, para eso se planteó el asunto de los plugins core o canónicos.

Hasta ahí bien, los chicos de Automattic tienen razón en quejarse cuando luego nos ponemos estupendos si hay algún fallito en las versiones finales. Peroooooo … todo tiene su pero.

Si esto es todo cierto, y yo lo suscribo, es más, ¡por favor, probad las versiones RC!, entonces ¿por qué las últimas versiones RC de WordPress han salido tan pegadas a las versiones finales?, sin tiempo para probarlas realmente. Un ejemplo especialmente sangrante fue la última, la 2.9. Y claro, hubo que sacar la 2.9.1 a los cuatro días (literal).

Ciertamente, para que una versión RC fuera realmente útil debería estar disponible durante como poco una quincena, para que la gente - de puro ansia de probar - la descargara e instalara a ver que tal le va y esas cosas que hacemos todos ¿no te parece?.

A eso hay que sumarle un error tonto, más bien carencia, en las distros de WordPress, y es que debería haber un enlace permanente en el pié de página del escritorio, o algo así, para informar de fallos al equipo de soporte. Con eso se ganaría mucho en efectividad y rapidez. Es algo que espero se tome nota e incorpore en siguientes versiones.

Así que eso es lo que hay, hoy estamos esperando la versión final de WordPress 3.0, una versión "mayor" que seguro que nos traerá de cabeza durante un tiempo, una versión que no recomiendo instalar en sitios activos, porque es un cambio realmente importante el que supone. Y no estaría haciendo esta recomendación si tuviéramos - al menos en este caso - un mes para probarla a fondo, que los cambios de WordPress 3.0 son muchos y profundos.

Bueno, no os aburro más, os dejo una encuesta, a ver como está el panorama … 

Una peculiaridad es que los temas serán Open Source, por lo que podrás modificarlos y mejorarlos a tu gusto una vez adquiridos. Es un proyecto interesante, de los que hay que estar pendiente … 

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía para Administrar Wordpress

Lo que se ha añadido es la posibilidad de exportar el contenido de tu WordPress pero pudiendo seleccionar por …

• Fecha (eliges el rango completo de fecha)
• Autor (uno o todos)
• Categoría (una o todas)
• Tipo de contenido (páginas, entradas o ambas)
• Estado (publicado, borrador, etc)

¿Te suena?, pues si, parece que se ha integrado en el core la funcionalidad de Advanced Export for WP/WPMU, un estupendo plugin del que, desde WordPress 3.0, podrás prescindir.

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía Domina tu Blog

Como anticipo a la ya anunciada muerte de WordPress MU como tal, para la integración en WordPress como software único, ahora se ha cerrado el trac de WordPress MU.

De modo que desde ahora todos los tickets de aviso de nuevas funcionalidades, soluciones a fallos, etc, irán en el trac de WordPress, que ya se dirige a la integración de la versión WordPress 3.0.

Donncha ha despedido a MU con esta frase … 

Gracias a todos los que han ayudado a hacer WordPress MU mejor a lo largo de los años, ya sea ayudando en los foros, escribiendo plugins, contribuyendo al código, trabajando en los tickets del Trac o en cualquiera de los cientos de tareas que conlleva un proyecto de código libre.

Ya pronto habrá que dejar de usar la etiqueta WordPress MU. Parece que WordPress 2.9.1 es ya la última versión de WordPress MU, que nos ha acompañado durante años, dando buen servicio y ofreciendo comunidades. ¡Gracias WordPress MU!

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía Windows Live Writer

Si gestionas sitios de clientes y quieres eliminar acceso a los menús de administración, aunque el usuario sea administrador, puedes hacerlo de un modo muy sencillo y, lo más importante, sin tocar los archivos 'core' de WordPress, con lo que no tendrás que rehacer las modificaciones tras una actualización.

Como ya estarás imaginando, echaremos mano del fichero functions.php de tu tema activo - y si no existe lo creas ahora mismo - y le añadiremos este código:

¿Que consigues con esto?, pues que solo se vean los menús personalizados - normalmente los que añaden los plugins - y aquellos que elimines de la lista de $restricted. En el ejemplo anterior solo verías el escritorio y aquellos menús de los plugins que tengas activos y a los que, por tu perfil de usuario, tengas acceso, justo lo que ves arriba en la captura.

Si también quieres quitar acceso al escritorio solo tendrías que añadir a la ista __('Dashboard'),.

Ahora bien, un usuario avezado aún podrá acceder a las distintas secciones tecleando la URL, o sea, que aunque quites el menú, si alguien teclea http://tudominio.com/wp-admin/plugins.php tendrá acceso. Si quieres eliminar también esa posibilidad, para los menús que definas, entonces el código se debe complicar un poco más, algo así:

Con este código eliminas la visualización y el acceso a los menús. Y en la lista de $restricted puedes añadir o quitar a voluntad los menús a los que se tendrá acceso.

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía Windows Live Writer

Si gestionas sitios de clientes y quieres eliminar acceso a los menús de administración, aunque el usuario sea administrador, puedes hacerlo de un modo muy sencillo y, lo más importante, sin tocar los archivos 'core' de WordPress, con lo que no tendrás que rehacer las modificaciones tras una actualización.

Como ya estarás imaginando, echaremos mano del fichero functions.php de tu tema activo - y si no existe lo creas ahora mismo - y le añadiremos este código:

¿Que consigues con esto?, pues que solo se vean los menús personalizados - normalmente los que añaden los plugins - y aquellos que elimines de la lista de $restricted. En el ejemplo anterior solo verías el escritorio y aquellos menús de los plugins que tengas activos y a los que, por tu perfil de usuario, tengas acceso, justo lo que ves arriba en la captura.

Si también quieres quitar acceso al escritorio solo tendrías que añadir a la ista __('Dashboard'),.

Ahora bien, un usuario avezado aún podrá acceder a las distintas secciones tecleando la URL, o sea, que aunque quites el menú, si alguien teclea http://tudominio.com/wp-admin/plugins.php tendrá acceso. Si quieres eliminar también esa posibilidad, para los menús que definas, entonces el código se debe complicar un poco más, algo así:

Con este código eliminas la visualización y el acceso a los menús. Y en la lista de $restricted puedes añadir o quitar a voluntad los menús a los que se tendrá acceso.