Porque son un par de sinvergüenzas golpistas que no merecen estar caminando libremente por las calles. Sólo verlos nos recuerda que la justitica venezolana tiene que mejorar para poner tras las rejas a piltrafas como éstas.

Beginning last week a WordPress vulnerability has been the target of attacks on multiple WordPress websites on hosting platforms around the web. We have a blog post with additional details about the vulnerability and how to secure your WordPress site.

http://blog.networksolutions.com/2010/alert-wordpress-blog-network-solutions/

At this time we have implemented a fix that has removed the offending code, updated database credentials, and set a more secure permission for the WordPress config file.

If you have followed all of the above instructions/tips and are still having an issue with getting WordPress to work correctly due to this vulnerability please contact customer service at 1.888.391.4357

Notemos que dicho señalamiento incluye además una calumnia, al declarar que dicha “vulnerabilidad” afectó a “muchos sitios basados en WordPress a lo largo de la web”. Tal afirmación constituye una fuerte sugerencia de que el problema viene de WordPress, en lugar de reconocer que los supuestos sitios se encontraban alojados en servidores mal configurados propiedad de esta empresa. Tal calumnia también permanece en el texto corregido. Matt les extiende una sugerencia simple:

Tal como toda aplicación web, WordPress debe almacenar en texto plano la información de conexión con la base de datos. No sirve de nada encriptar las credenciales porque las claves deben estar guardadas donde el servidor pueda leerlas, de manera que pueda desencriptar los datos. Si un usuario malicioso obtiene acceso al sistema de archivos -cosa que parece haber ocurrido en este caso- es fácil obtener las claves y desencriptar la información. Si dejas las llaves de la puerta pegadas en la cerradura ¿sirve de algo cerrar la puerta?.

Y continúa con el más lógico de los silogismos:

Si como proveedor de hosting cambias un artículo que habla de permisos de archivos por un artículo sobre WordPress, es que algo estás haciendo mal.

Hasta el momento, Network Solutions no ha reconocido que la falla efectivamente provino de un error interno (quizás por temor a enfrentarse al montón de demandas por parte de sus clientes) y al evadir dicha responsabilidad 1) provocó que su círculo de usuarios injustamente colocasen en tela de juicio a WordPress como software de dudosa seguridad, 2) al transmitir la falsa matriz de información de forma pública, hace definitivos intentos por descalificar a un software que nada tiene que ver con los sucesos cometidos y 3) obligó al personal de WordPress a molestarse en ofrecer explicaciones técnicas sobre hechos que no necesitan actos de justificación. Tal como afirma Dexter Morgan y mi abuela: “así es la maldad, destroza todo lo que toca”.

Por mi parte le ofrezco a la gente de Network Solutions una amable recomendación y una asignación: la recomendación es que se vayan a la mierda y -una vez allá- cumplan con la asignación de descifrar este vocablo: é-ti-ca… Al menos hasta comprender parte de su significado.

Actualizaciones

14/04/2010 22:49 – Shashi Bellamkonda a última hora: WordPress no fue el problema

En cuanto a la calidad de traducción, se nota que han cuidado no sólo el apego a las frases originales, sino una política de sintaxis neutra que busca satisfacer a todos los usuarios de habla hispana. Sin duda un buen trabajo por parte de Fernando Tellado (Coordinador del grupo, quien además lleva las riendas de Ayuda WordPress) y un excelente grupo de colaboradores.

Igualmente el equipo traductor ha habilitado un sitio para fines de trabajo en Google Code con acceso abierto. Este paso era necesario y me complace ver que no sólo se cumplió, sino que efectivamente existe plena actividad operativa desde su fundación. Entre los integrantes del equipo se encuentran:

• Fernando Tellado
• Jose Conti
• Raul Illana
• David Carrero Fdez-Baillo
• Reyson
• Angeles Portillo
• Errante
• Juarbo

Si crees que puedes ofrecer tu ayuda para tal fin, puedes inscribirte en el grupo a fin de dar tu aporte y ayudar a la comunidad.

Personalmente -y desde que el nuevo equipo asumió la responsabilidad- me he acostumbrado a descargar WP en español nuevamente. Al principio hubo un par de tropiezos con un signo “%” suelto por ahí, pero desde entonces no he experimentado problema alguno (y mira que mi pan diario son las instalaciones). Las actualizaciones automáticas también transcurren limpias y fuera de todo inconveniente.

Traducción alterna de TodoWordPress

Resulta oportuno hacer mención de la traducción alterna proporcionada por el equipo de TodoWordPress. Igualmente se trata de un producto de máxima calidad.

De la misma forma vale la pena comentar que TodoWordPress fue uno de los sitios que cubrió el vacío dejado por el antiguo equipo oficial durante tanto tiempo, cumpliendo a cabalidad con cada una de las traducciones y -con dicha acción- ayudando a impulsar el empleo del software en Latinoamérica y España.

Francisco Marín, webmaster y administrador de TodoWordPress es quien coordina este trabajo que aún sigue estando vigente y con más fuerza que nunca. Puedes acceder a la sección de descargas, la cual también te explica cómo proceder con la instalación manual.

Como puedes notar, los usuarios estamos bien servidos respecto al idioma. Bien se trate de la traducción oficial o la alterna, contarás con un excelente producto en tus manos, ambos resultado de mucho esfuerzo y mística por parte de personas que no conoces, pero de todas formas ahí están echándote una mano.

Comencemos por explicar cómo puedes saber la memoria PHP que tu sitio web consume. Abre el archivo footer.php de tu plantilla y colocas el siguiente código en el lugar más apropiado (código más completo al final):

Respecto a los niveles “normales” de consumo no puedo ofrecer un dato exacto, pero luego de unas pruebas noté que:

• Una instalación nueva consume unos 10.5MB.
• Darioferrer.com se come alrededor de 25MB.
• Darioferrer.com con la plantilla “default” (y configuraciones por defecto) consume unos 14MB.
• Cierto portal grande (tipo 20minutos.es) consume aproximadamente 48MB.
• Otro proyecto, un catálogo de productos, consume unos 36MB

Por otra parte, efectué una prueba de los plugins que tengo instalados y anoté la memoria que cada uno de éstos exige en el frontend del sitio:

• CodeColorer: 2MB (mierda!)
• Sociable: 0.4MB
• WP Smart Image II: 0.2MB
• Custom Field Template: 2.2MB (mierda!)
• Get Recent Comments: 0.2MB
• WP-PageNavi: 0.2MB
• Max Image Size Control: 0.2MB

Obviamente lo anterior me indica que algunos plugins están consumiendo una memoria excesiva de PHP, por lo cual es posible que pronto decida probar otras opciones. Por cierto, no quiero ni imaginar lo que consumen plugins como CformII o NextGen Gallery (no uso ninguno de ambos debido a su innecesaria complejidad de funcionamiento), o el WP E-commerce.

Como conclusión debo decir que el límite regular de memoria (consumida por script) en un servidor compartido se encuentra en niveles aceptables. Y mi consejo a quienes experimenten problemas de tipo “Allowed memory exhaust bla bla bla…” es: Háganle una revisión a sus plugins, tanto la explicada como la de número de consultas a la base de datos. Dejo el código completo de ambas para copiar y pegar:

Mi abuela dice: “Si las tecnologías se convierten en una jaqueca, pues ríete de ellas, úsalas como esclavas, doblégalas a tu parecer, llévalas al límite. Si aún te responden con eficacia pues qué bien, podrás seguirlas machacando, redescubriendo y mejorando. Y el día que te dejen varado, pues mándalas al demonio o continúa creciendo con o sin ellas porque a fin de cuentas eres un ser libre”. Es de esta forma como deberías ver tu carrera profesional… Y es también de dicha forma como deberías leer este artículo.

“Soy fanático de…”

Permítete ser fan de The Matrix, Pink Floyd o los Tigres de Aragua, pero no de tecnología alguna (y menos de un CMS). El sujeto fanático -en general- experimenta a cada rato esa divina mezcla cuasiarmónica de entusiasmo, adrenalina, apego frenético y una ignorancia tan ingenua que llama a la ternura. Si acaso eres fanático a capa y espada de Joomla, WordPress o cualquier otra aplicación, mi modesto consejo hacia ti es simple: deja de serlo, no vale la pena. En este momento importa más tu criterio y crecimiento profesional que las 4 paredes de código dentro de las cuales estás empeñado en encerrarte. En lugar de invertir tiempo en encajonarte en un CMS, dedícalo a aprender lo que más te gusta: programar, diseñar/maquetar o planificar proyectos.

Quién escribe esto

Antes de entrar en tema, quizás resulte oportuno mencionar un par de datos sobre quien se encuentra martirizando las teclas en este preciso instante. Comenzar diciendo que he implementado Joomla en numerosos proyectos web, además de colaborar en la difusión del conocimiento del software a través de diversos artículos, así como experimentos varios de mejora de la plataforma tales como mostrar componentes como módulos o gestionar el CSS de Joomla dinámicamente. Hasta hace un par de años desarrollé alrededor de 22 portales y tiendas electrónicas bajo esta aplicación, pero el grueso de los trabajos en aquél entonces estaban constituidos por desarrolladores que requerían servicios para desarrollar módulos y componentes personalizados. Adicionalmente soy miembro del equipo de soporte de Joomlaworks (uno de los más relevantes desarrolladores de add-ons para Joomla) y moderador general de los foros de JoomlaSpanish (partner oficial en español de Joomla.org). En fin, conozco el software.

En cuanto a WordPress, reconozco que todavía no he conquistado el nivel de dominio que llegué a poseer con Joomla, aunque -basándome en lo aprendido hasta el momento- me siento optimista sobre lo que aún está por transcurrir. En el presente aplico WordPress en los proyectos que desarrollo, pues con éste he alcanzado resultados de mejor calidad integral, ejecutados en la mitad del tiempo y, desde luego, con menores costos para el cliente.

Joomla: estrictamente orientado al usuario común.

Joomla es un CMS esencialmente orientado a facilitarle la vida al usuario como ente creador de presencia en la web. Esto quiere decir que gracias a Joomla cualquier secretaria de recepción puede poseer, en escasos minutos, un completo sitio web con un montón de elementos preintegrados y el consecuente control integral desde un completo panel de administración. En ese aspecto Joomla es un líder indiscutible, superior a cualquier CMS.

Resulta acertado afirmar que Joomla es una aplicación prefabricada en el puro y crudo sentido de la palabra. A diferencia de WordPress, éste dispone nativamente de múltiples recursos controlables desde el panel administrativo, tales como sistemas de encuestas, banners, formulario de contacto, gestión de feeds RSS y hasta colorizado de sintaxis (basado en GeShi) si lo necesitas en tu contenido. Igualmente Joomla fue pionero en la implementación de la llamada “papelera de reciclaje” en un gestor de contenidos, característica que -en contraste- WordPress recién implementó a partir de la versión 2.9.

Tal como es ampliamente conocido, Joomla es hijo pródigo de Mambo, una aplicación cuya arquitectura fue conceptualizada desde un principio en función del usuario común, aquél que no sabe ni pío de programación y diseño web pero que al mismo tiempo tenía el derecho y necesitaba tener presencia en internet. En aquél entonces, Mambo le otorgó a ese usuario el poder, no sólo de tener su propio sitio, sino un sitio completo, con todos los accesorios y recursos necesarios para gestionar contenido, interactuar con los visitantes y hasta monetizarlo. Dicho esquema se mantuvo y sigue manteniendo con Joomla.

WordPress: orientado al usuario y al desarrollador web

En más de una ocasión he mencionado que WordPress se acerca más al concepto de framework que al de un CMS en sí. Visto desde el punto de vista de un programador, esta aplicación constituye un surtido de recursos que sólo pueden ser calificados como soluciones. La arquitectura de WordPress está fundamentada en principios productivos, cuya finalidad no es otra que la más apreciada por un desarrollador: consultar datos y devolverlos sin ningún accesorio imprevisto. WordPress devuelve al desarrollador la capacidad de decidir cómo, cuándo y dónde quiere colocar sus datos. WordPress permite al diseñador controlar la totalidad de la estructura y presentación resultantes.

Ahora bien, si aquella secretaria de recepción instalara WordPress, no llegaría a obtener más que un blog en pocos segundos. Por tal motivo, cuando me tropiezo con algún artículo que afirma que “WordPress sólo sirve para blogs”, inevitablemente imagino que detrás del teclado se encuentra alguna secretaria de oficina (o su equivalente en conocimientos sobre este software).

WordPress es un CMS para lo que la creatividad dicte (creatividad: imaginación orientada a lo productivo). No obstante, WordPress necesita de una mano profesional para demostrar todo lo que es capaz de ofrecer. Si pensabas que -por ejemplo- era imposible personalizar una interfaz administrativa de cabo a rabo sin tocar un pelo de los archivos del núcleo, es que aún no conoces WordPress.

¡Ah! también sirve para blogs :)

Por qué Joomla no puede ofrecer el mismo nivel de personalización que WordPress

¿Qué son los archivos del núcleo?

Son todos aquellos archivos que conforman la aplicación cuando está recién instalada. Me refiero a todos, desde el directorio raiz hasta el último escondrijo. Esos archivos no deben editarse jamás, pues -y aquí viene la primera Regla del buen CMS- uno de los primeros requisitos que debería cumplir un CMS con quien decida emplearlo, consiste en ofrecer los suficientes recursos que permitan al desarrollador proceder a su criterio sin necesidad de modificar los archivos del núcleo.

¿Por qué es inconveniente editar tales archivos? Porque las actualizaciones requieren tener plena disponibilidad sobre éstos para sobrescribir lo que sea necesario. Las actualizaciones son modificaciones que el equipo oficial de desarrollo efectúa al software. Éstas pueden incluir mejoras, soluciones de fallos o parches de seguridad en sus distintos niveles. Es importante que mantengas tu CMS actualizado. El procedimiento para tal fin es cuestión de minutos si mantienes intactos los archivos del núcleo.

De igual manera, si eres un cliente en la búsqueda de quien se encargue de tu proyecto web y, al mismo tiempo, tu proyecto involucra un CMS, debes asegurarte de que el futuro programador no toque esos archivos. Que proceda a criterio siempre y cuando respete esa regla única. Verás que tal manera de proceder te ahorrará múltiples dolores de cabeza a la hora de mantener el sitio al día. Entiende que las actualizaciones son tareas periódicas y debes considerarlas como parte normal del conjunto de procedimientos implicados en la optimización de un sitio web. En virtud de ello debes evitar todo tipo de elementos obstaculizantes para tal fin.

El problema con Joomla

Entendido el concepto de los archivos del núcleo de un software -así como la importancia de no modificarlos- nos encontramos con uno de los cuellos de botella más aleccionadores que puedan encontrarse.

Hace pocos años nació (ignoro de dónde pero nació) un planteamiento muy interesante en la llamada comunidad de desarrolladores web, cuya principal propuesta consistía en la opción de utilizar gestores de contenidos prefabricados en los proyectos para ofrecer más calidad a menores costos y tiempos mínimos de ejecución. Dicha tendencia resultó enteramente imprevista, y más imprevista aún para los respectivos equipos de desarrollo de Mambo/Joomla, quienes -como ya mencioné- habían jugado todas sus cartas en función del usuario común (sí, el que no sabe ni pío).

En virtud de tal estrategia y comparándolo con WordPress -que desde el principio sí encauzó su código hacia un entorno de desarrollo- Joomla tenía y sigue teniendo muy poco que ofrecer en materia de:

• Sitios que requieran escalabilidad de cero a infinito.
• Recursos nativos que ofrezcan total libertad de acción al programador para controlar lo que éste quiera controlar, sin que por tal motivo sea necesario modificar, desde luego, el núcleo.

Ante las nuevas tendencias de aprovechamiento de la tecnología, muchos individuos (yo incluido) insistían en que Joomla también podía responder exitosamente a requerimientos que involucrasen proyectos web de compleja estructura contextual. Nada más lejos de la realidad.

Si Joomla es el pan listo para servir, WordPress es la harina aún en el empaque. Puede que el pan servido y calientito guste a unos cuantos, pero justo cuando el comensal comienza a exigir algo más que un pan (o un pan de características más adaptadas a sus requerimientos) es cuando termina el encanto de Joomla, mientras WordPress recién comienza a calentar motores.

¿Nos entendimos o no? Joomla es el juguete lujoso con todos los accesorios, WordPress la caja de Lego. Joomla es el edificio, WordPress el montón de ladrillos, cemento y arena. Quien compre un edificio podrá gozar de su comodidad a mediano plazo, pero sólo crecerá a la misma altura de éste. Quien opte por los ladrillos y cuente con un buen profesional para trabajarlos, sencillamente conseguirá lo que quiere.

Si Neo tuviese que escoger entre ambas, Joomla le diría “My way or the Highway” mientras paralelamente WordPress diría “There is no spoon”.

No obstante, ser la caja de Lego o el montón de ladrillos no debe implicar que el usuario final (tu cliente) deba estar lidiando diariamente con legos y ladrillos, sino que tú tendrás el camino libre para construirle un sitio justo a su medida y totalmente escalable en el tiempo. Para una mejor comprensión de dicho factor veamos la siguiente lista de casos ilustrativos:

Personas, situaciones y soluciones

Si en este momento se efectuara una encuesta acerca de lo que distintos tipos de usuarios buscan en un CMS, probablemente las siguientes figurarían entre las principales respuestas:

1. El usuario común: “Quiero un software de fácil instalación y operatividad que además me ahorre, en la mayor medida posible, la jaqueca de meterme con los códigos. Quiero un panel de administración desde el cual pueda controlar todo el sitio, hasta el mínimo detalle. Quiero disponer de un montón de recursos al instante, todo sencillo, todo fácil. Y no quiero pagar un centavo por ello”. (Solución: Joomla)
2. El diseñador web amateur: “Quiero un sistema que me proporcione el máximo posible de etiquetas y snippets prestablecidos, a fin de permitirme enfocarme en el diseño/maquetación del sitio, sin necesidad de lidiar con programación”. (Solución: Joomla/WordPress)
3. El diseñador web profesional: “Quiero lo mismo que el diseñador web amateur, y además necesito controlar el 100% del HTML resultante”. (Solución: WordPress)
4. El programador web amateur: “No sé lo que quiero y el hecho de no saberlo me parece genial. En este momento estoy encerrado en mi habitación, totalmente enfocado en mi aprendizaje de PHP. No como ni duermo, y uso pañales de adultos para no tener que ir al baño. En la puerta hay un letrero que dice ‘Favor no molestar’ que significa exactamente eso: favor no molestar“. (Solución: una chica que lo salve de la demencia)
5. El programador web profesional: “No quiero nada, yo mismo construyo mi vaina desde cero. Pero si algún día optara por basar mis proyectos en una plataforma de gestión de contenidos, desearía un sistema que bajo ningún concepto entorpezca mi proceso propio de desarrollo”. (Solución: WordPress)
6. El cliente: “Quiero exactamente lo que pedí. Favor prestar atención a la palabra ‘exactamente’, la cual no significa ‘aproximadamente’ ni ‘semejante a…’ sino exactamente“. (Solución: WordPress + una mano profesional)

¿Podría Joomla fexibilizar radicalmente su arquitectura a favor de un entorno de desarrollo?

Posible pero difícil. En realidad Joomla sí tuvo una oportunidad única para replantear totalmente su arquitectura y no lo hizo. Eso fue en el transcurso del año 2007, cuando su equipo oficial de desarrollo decidió separar la plataforma -de las entonces versiones 1.0.X- de la llamada “herencia Mambo”. Ciertamente se efectuaron numerosos cambios que implicaron una reescritura completa del núcleo. Tan profundos fueron dichos cambios, que subir las 1.0.X a la 1.5 no implicaba una actualización sino una migración total de datos, tal como si se tratase de dos aplicaciones distintas.

Al final del día, el nuevo Joomla 1.5 no era extremadamente distinto al 1.0.X. De hecho, aún la plataforma sigue atada al famoso “legacy” (la compatibilidad con versiones viejas). Esta medida fue necesaria para no dejar obsoletos la gruesa cantidad de add-ons y plantillas de terceros existentes hasta entonces. Y el precio del “legacy” fue, precisamente, seguir atado a la “herencia Mambo” hasta el sol de hoy. Creo que es muy difícil que Joomla ejecute una segunda vuelta total de tortilla.

Con WordPress ocurrió un hecho similar (en cuanto al cambio radical de plataforma) pero la estrategia fue exactamente la contraria de Joomla, ya que el Core de WP sí se pasó por el forro las contribuciones de terceros, es decir, se le dio prioridad a la arquitectura (lo realmente permanente y evolucionable), pero pagaron el precio de dejar obsoletos todos los plugins existentes en aquél momento. Sólo funcionaban los que no requerían la base de datos para operar, es decir, una mínima cantidad. Tal cambio se dio en la versión 2.2, cuando se implementó por primera vez nada menos que el sistema de taxonomías.

Sólo imagínense si el core de WordPress hubiese tomado la misma decisión equivocada que el core de Joomla: el software hubiese quedado totalmente estancado y -tal como Joomla- debatiéndose entre callejones sin salida: por un lado la evolución/involución de la aplicación, y por el otro los add-ons (plugins en este supuesto negado) con los cuales había que “quedar bien”.

Por cierto, Hoy en día WordPress cuenta con el doble de add-ons que Joomla, los cuales operan bajo una arquitectura más robusta, versátil y escalable que las pre-2.2.

Conclusión

• Si no posees conocimientos de desarrollo web, deseas instalar un completo sitio en un santiamén de forma libre y gratuita, Joomla es tu mejor opción.
• Si necesitas desarrollar un sitio que requiera máxima personalización de elementos y funciones (incluyendo interfaces de usuario y administrativas), controlar el 100% del código, y posees los conocimientos suficientes para hacerlo, tu mejor opción es WordPress.

¡Espera el resto de las partes de este artículo!

Las partes 2, 3 y 4 del presente artículo conformarán precisamente la explicación técnica de todo lo expuesto hasta ahora (no pensabas que te iba a dejar en el aire con este aspecto). Prepárate para analizar códigos, diagramas y demás elementos detallados.

2ª parte: Tareas altamente esenciales que no se pueden hacer con Joomla (y sí con WordPress) sin tocar los archivos del núcleo

• Taxonomías (u organización de secciones). Profundidad, versatilidad y límites. Concepto e importancia para desarrollar estructuras complejas de contenido.
• Controlar el 100% de las funciones y comportamiento del sistema (frontend y backend)
• Controlar el 100% del HTML y CSS de toda la interfaz (frontend y backend)

3ª Parte. Templating en Joomla y WordPress

Hasta dónde puede llegar la capacidad de cada una de estas aplicaciones en el desarrollo de plantillas y cuáles son los recursos que las mismas tienen disponibles para tal fin.

4ª Parte. Desmintiendo mitos trillados.

¿”WordPress sólo sirve para hacer blogs”? ¿”Joomla es lo ideal para portales de alto tráfico”? Son algunas fantasías trasnochadas que nos ocuparemos de desmentir una a una con pruebas en mano, pelos y señales. También tomaremos ciertos artículos como referencia. Quien luego de leer la 4ta parte aún desee seguir fantaseando, pues nada, que se trague la pastilla azul y despierte creyendo que sólo tuvo una pesadilla.

La verdad aunque duela a algunos: a WordPress.org no le importa Google, pero aún así Google sigue amando a WordPress cual masoquista a su sádico. De esta pervertida relación podemos sacar provecho, ya que -a falta del motor de búsqueda nativo de WordPress- Google es la mejor opción para tal cometido ¡aún mejor que el mismo Yahoo, quien funge de motor interno de búsqueda en el sitio oficial y -a pesar que tiene toda la buena venia que el core le otorga- todavía se le hace imposible superar a Google en resultados!

Lo único que queda es discriminar el contenido de calidad ¿y cuál es el fulano “contenido de calidad”? pues los temas resueltos. Al respecto tenemos dos puntos a favor: 1) WordPress posee un sistema para indicar si el tema está resuelto o no y 2) Generalmente los usuarios son colaboradores al respecto y, en su defecto, los moderadores suelen hacer el trabajo. El texto publicado es: “This topic is resolved”. Entonces la sintaxis para buscar sería:

Un par de ejemplos para ilustrar: get_posts, WP_Query o “blank page after upgrading” ¿Qué representan estos resultados? Pues nada menos que numerosos problemas experimentados por múltiples usuarios, los cuales fueron resueltos… ¿Útil no?.

O me he tropezado con una de esas frases/joyas filosóficas cuyo significado sólo está reservado para las neuronas más portentosas de la galaxia, o ya estoy muy viejo y decadente como para comprender con eficacia esos textos publicitarios tan sofisticados de la actualidad. Hasta el momento me he tomado dos botellas ron y aún no logro contestar la pregunta de rigor: ¿Cómo demonios puede alguien declararse satisfecho antes de que el trabajo comience? ¡Mentes evolucionadas del mundo, he ahí un dilema!