Clic para ampliar

¿Detalles? …

WordPress fue la mejor elección por estos motivos:

• Open Source - Libre de usar en proyectos personales y profesionales
• Fácil de usar - La interfaz de administración es realmente sencilla de utilizar
• Sencillo de actualizar - Actualización a un clic
• Soporte de temas - Miles de temas libres y comerciales entre los que elegir
• Plugins - Multitud de plugins con los que ampliar y mejorar tu sitio
• Protección de spam - Protección contra spam incluida

Yo, ahora mismo, le sumaría estos otros:

• Totalmente escalable, crece junto a ti, sin limitaciones, y sin necesidad de herramientas externas, lo haces todo desde el escritorio
• Multisitio - Puedes ofrecer la creación de sitios a tus lectores
• Red social - Puedes convertir tu WordPress en una completa red social a un clic gracias a BuddyPress
• Móvil - Aplicación nativa con la que gestionar tus sitios desde iPhone, iPad, Blackberry, etc
• No solo blogs - Mediante temas avanzados, plugins, menús personalizados y tipos de post y taxonomías personalizadas, puedes crear cualquier tipo de sitio

¿Se te ocurren más virtudes?

En el estudio, además de constatar que, aunque asusten un poco las cifras, el software Open Source no es más inseguro que el software propietario, a pesar de no disponer de equipos técnicos dedicados a mantenerlos para "sus clientes", quedó patente la diferencia que marca WordPress, ¿lo vemos?.

La herramienta, de todos los sitios analizados, encontró vulnerabilidades en el …

• 77% de los sitios creados con Movable Type
• 91% de los sitios basados en Joomla
• 95% creados con MediaWiki
• 69% de sitios creados con Drupal

WordPress solo mostró un 4% de vulnerabilidades críticas y un 21.5% de vulnerabilidades medias

También ha quedado patente en el estudio que las vulnerabilidades encontradas en WordPress afectaban a las versiones antiguas, siendo las actuales las más seguras y estables. Así que ya sabes ¡a actualizar WordPress!

Está más que probado que MySQL 5 es más lento que MySQL 4. Además, WordPress no requiere ninguna funcionalidad específica de MySQL 5 para funcionar.

Entonces ¿por qué se acaba de anunciar que WordPress 3.2 requerirá MySQL 5.0.15?

Repetimos:

1. MySQL 5 ofrece mejoras de rendimiento en InnoDB que, como he dicho, WordPress no utiliza.
2. MySQL 4 es más rápido en MyISAM, el formato de base de datos más común que, dicho sea de paso, es el que usa WordPress.

¿Alguien lo entiende?

Pero nada, además insisten en que los servidores también deban ejecutar PHP 5.2 como mínimo para WordPress 3.2.

En este caso, aunque PHP 5.2 es más rápido que PHP 4.4 (y PHP 5.3 es aún más rápido que la versión 5.2) no habría ningún problema en que WordPress 3.2 soportara PHP 4.4. Pero cuando Matt se emperra no hay quien lo pare, y estoy seguro de es capaz de forzar a que se actualice a PHP 5 quitando código que funcione en PHP 4.4.

¿Tan difícil es hacer que el software sea flexible, escalable?. Entiendo que se quieran eliminar problemas de seguridad forzando actualizaciones en los servidores pero no hay que ser tan radical. Tampoco soy un talibán de la compatiblidad a toda costa, causa de la mayoría de los males de software como Joomla o el mismo Windows y, al tiempo, parte del gran éxito de WordPress, pero creo que se están llevando las cosas, no demasiado lejos pero si demasiado rápido.

Lo que temo es que se pretenda forzar un ritmo de actualizaciones tan tremendo, no ya de WordPress, sino de los mismos sistemas para soportarlo, provocando unos requisitos demasiado elevados. ¡Coño, si hasta han publicado un plugin para que comprobemos si nuestro servidor va a soportar WordPress 3.2.!. Ya hasta me molesta el nombrecito: prueba de salud le han llamado. ¡Por favor!

Además, como puede que los proveedores de alojamiento no sigan este frenético ritmo, en vez de conseguir instalaciones más seguras, lo que se podría provocar es que muchos usuarios no pudieran actualizar WordPress a una versión más estable y fiable (como sería cualquier actualización mayor) porque su servidor no la soportara. Y, por favor, no vamos a estar cambiando de proveedor de hosting cada dos por tres ni pagando de más para poder actualizar WordPress.

A ver si a este paso vamos a terminar como con cada versión de Windows, que te requiere que cambies de ordenador.

Lo dejo a vuestro criterio y reflexión, esta es solo un punto de vista acerca de esta noticia.

Hola.

He llegado aquí mientras buscaba información sobre Joomla y Drupal y al final me he pasado toda la tarde leyendo artículos re-encachados que he encontrado aquí sobre este tema. Verán, uso WP desde hace un par de años tanto en mi blog personal como en mi trabajo haciendo plugins a pedido (sólo plugins no temas ni he usado el famoso loop).

Siempre he pensado que Joomla y Drupal son bastante diferentes a WP, aunque estos sólo los he visto muy por encima. A tal punto que hace tiempo quiero encontrar algún justificativo que me impulse a desarrollar alguna solución basada en ellas, cualquiera de las dos. Tengo la idea de que me pueden permitir estar un poco más cerca de la programación a mano.

Veo a ambas como en un estado intermedio (y siempre en relación a su uso más por parte de un programador de un CMS que como administrador de uno) entre wordpress y un framework como, por ejemplo, Codeigniter.

Es decir, creo que con el sistema de hooks de WP se puede hacer absolutamente de todo. Pero si se trata de hacer un sistema que básicamente sea algo más que para escribir artículos y administrarlos (por ejemplo un sistema para reserva de vuelos/visitas/entradas), Joomla y Drupal debieran superarlo. Ya sé que no es así, lo acabo de decir, con WP se puede hacer de todo.

He aquí una excelente oportunidad para mostrar mi primer plugin WP gratuito y que pronto descansará en paz para siempre (terminado el mundial batirá records entre los plugins menos bajados): http://nomikos.info/2010/06/10/fifa-world-cup-south-africa-scoreboard-wp-plugin.html.

Actualiza automáticamente los resultados después de cada partido recabando datos en el sitio de la FIFA mediante un scraper interno. A todas vista una extensión que no tiene nada que ver con manipular artículos. Pero aún así Joomla y Drupal parecen de aplicación más general recién instalados (out of the box).

Bueno, leyendo algunos artículos y referencias encontradas aquí, me están haciendo cambiar de opinión. Sinceramente sería fantástico especializarse realmente a fondo en sólo un sistema manejador de contenidos y dejar más tiempo para profundizar en otros aspectos de la programación web como puede ser el javascript orientado a objetos, que es lo que más rápido está cambiando ahora.

Cuando empecé a trabajar en rentacoder.com (ahora vworker.com) hice una búsqueda de los términos Joomla, Drupal y Wordpress en los jobs ofrecidos. WP ganó por lejos y por eso lo empecé a estudiar en pos de aumentar mi mercado de trabajo. Aún así Joomla y Drupal aparecen a diario y parecen tener un nicho ganado cada uno por cuenta propia. Y me sigue pareciendo que WP es más usado en sitios (varios muy importante por cierto) netamente de noticias y publicación de artículos. Mientras que Joomla y Drupal en sitios multipropósito. Y en esto sólo queda adaptarse a lo requerido en el mundo real.

La razón de este post más que confrontar estos CMS desde el punto de vista técnico o de usabilidad es saber de sus experiencias en cuanto a rendimiento y uso de recursos computacionales de cada uno. Ya que si con los tres se puede hacer más o menos lo mismo como lo demuestra http://www.cmsshowdown.com/competition (sí, lo vi aquí primero o/\o) entonces lo que sigue en importancia es el rendimiento neto de cada sistema. No está de más agregar que al momento de la elección del ganador se decidió por un empate.

También sería interesante hablar un poco sobre los resultados de esta confrontación, en que WP perdió por lejos en cuanto al tiempo (en horas) necesario para desarrollar un sitio modelo bastante completo, con galería de imágenes, encuestas y avisos clasificados: (D: 79.25, J: 57.25, WP: 90.5) y líneas de código a crear/optimizar en cada sistema base --recién instalado (D: 220, J: 30, WP: 1.808) hasta lograr los objetivos requeridos. Cosa que todos lograron.

Gracias por su participación.

Si echas de menos algunas funcionalidades características de Drupal a la hora de usar WordPress no te preocupes, hay solución para todo, como no, gracias a los plugins de WordPress. Vamos a ver algunos modos de tener en WordPress utilidades típicas de Drupal.

WP-Vimcolor - Este plugin es una adaptación del módulo vimcolor de Drupal, un editor de texto al estilo de los viejos editores VI o VIM de UNIX, que muestra con codificación de colores una buena cantidad de lenguajes de programación.

WordPress Menu Creator - Una de las características que históricamente han distinguido a los CMS más populares como Joomla y Drupal ha sido la posibilidad de crear menús personalizados que mostrar donde elijas. Con este plugin puedes definir menús personalizados y decidir mostrarlos donde quieras, en posts concretos, en páginas, donde sea.

Nicemap - Este plugin es un porte del módulo Nice Map de Drupal, que ofrece un servidor web de mapas para tu sitio. Por si solo no ofrece geolocalización pero puedes añadirla con plugins como WP-Geo.

Next page - ¿Echas de menos la navegación "estilo libro" de Drupal?, pues con este plugin puedes añadir este tipo de ayuda de navegación por tus entradas de manera sencilla.

Hikari Titled comments - Quizás una de las características que, en seguida, distingue a un sitio creado con Drupal es la posibilidad de dar título a los comentarios, quizás una funcionalidad algo antigua pero que gusta, y mucho, a usuarios veteranos de la red, de los que - como yo - han estado muchos años navegando por foros. Si quieres añadir la posibilidad de que tus lectores, además del nombre y demás datos personales, pongan título a su comentario solo tienes que instalar este plugin.

Virtual pages - Otra de las peculiaridades que se encuentra uno en casi cada sitio creado con Drupal es las "Vistas", un módulo que permiten integrar - por ejemplo - entradas en una página, opaca si quieres a la navegación habitual de páginas, pudiendo configurar los parámetros de manera sencilla. Es una utilidad muy potente al mismo tiempo que sencilla de configurar.

Y, bueno, estos son los que he encontrado, si sabes de alguno más no dejes de comentarlo.

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 … 

Adobe se acerca un poco más al mundo, aunque no a nivel de precios de sus paquetes de edición y diseño. La nueva versión CS5 trae muchas novedades que estoy deseando probar en cuanto pueda descargarse y pueda actualizar mi actual CS4.

Una de las cosas que más me ha llamado la atención en DreamWeaver CS5 es su soporte para gestores de contenidos o CMS, soportando la edición y creación de temas para Wordpress, Joomla, Drupal, … sin duda un gran movimiento para la comunidad de diseño que ayudará a que estos CMS de código abierto ganen mucho más terreno del que tienen. Además de integrar un navegador entre las funciones de estos CMS para facilitar la integración y desarrollo sobre CS5.

Pero las novedades no se quedan aquí, integración de BrowserLab, el servicio de Adobe para probar como se verían nuestras páginas web en diferentes navegadores y versiones de estos, así como diferentes resoluciones, para estar seguros de que se verá bien en cualquier sistema donde se muestre.

Más información en Adobe.

Original Post / Entrada Original: Carrero.es. Si quieres Juegos Gratis disfruta aquí o decora tu casa.

Dreamweaver CS5 y su soporte para CMS

La nueva versión de Dreamweaver permitirá no solo editar ficheros de cualquier tema de WordPress sino que incluirá herramientas de completado de código que reconocerá las funciones y tags de plantilla de WordPress. ¿No te lo crees?, pues aquí tienes una captura de esta funcionalidad … 

Se desconoce como se realizará el proceso de actualización de WordPress a Joomla pero lo que si podemos intuir es que, con este paso, el CMS se convertirá en uno aún más pesado (para que luego nos quejemos de lo que pesa WordPress).

Los de Joomla se han dado cuenta que nunca podrán competir con WordPress y han preferido enfrentarse a su rival a golpe de talonario. Toda una pena, Joomla es un CMS mucho más complicado y menos intuitivo que WordPress y eso afectará bastante a los nuevos usuarios (y a los actuales) sobre todo por la cantidad de menús y opciones que Joomla dispone.

¿Es el momento de buscar una alternativa a WordPress? Creo que sí.

Así, consultando la bola de cristal, adivino los siguientes hitos en WordPress para 2.010:

• bbPress se convierte en plugin para WordPress (en esto juego sobre seguro)
• WordPress y WordPress Mu se integran como plataforma única (esto ya está confirmado) en WordPress 3.0
• BuddyPress se ofrece como plataforma de pago para empresa aún manteniendo la versión Open Source libre pero sin funciones avanzadas como integración de perfiles en redes sociales, por ejemplo (espero equivocarme)
• De nuevo apuesto por podcasting integrado en WordPress
• Se establece el foro de soporte oficial de WordPress.org en español y, en consecuencia, se cierra el Foro WordPress al dejar de ser una necesidad.
• Automattic se hace cargo del desarrollo de Joomla y planifica su futura integración con WordPress

y, para terminar … 

• Ayuda WordPress por primera vez es rentable

Ea, te toca …