Tras mi migración de Simple PHP Blog a WordPress, he familiarizándome con el funcionamiento interno de este CMS, encontrando por desgracia bastantes aspectos que no son de mi agrado.
WordPress es magnífico en mucho sentidos, tiene una herramienta de administración sencillo y cómodo; la cantidad de plugins y temas disponibles nos permiten personalizarlo a nuestro antojo con poco esfuerzo; y sobre todo, la cantidad de funcionalidades que soporta «out-of-the-box», nos permiten cubrir casi cualquier necesidad.
Poca separación entre datos y presentación
No me malinterpretéis, la forma en que WordPress está programado, con sus temas que separan el código del sistema de la presentación es magnífica, sin embargo, la base de datos guarda el contenido de los posts, y de los comentarios directamente en código HTML, y en este sentido, no habría una peor forma de hacerlo si lo que queremos es separar los datos de la presentación.
Más aún, si tenemos en cuenta que ese HTML, puede llegar a tener Javascript incrustado, estilos CSS, etcétera. La consecuencia de hacerlo así estriba en que va a ser tremendamente complejo exportar esos contenidos a otro formato. En lo que a mi respecta, me ha sorprendido, ya que hasta Simple PHP Blog, utilizaba BB code.
Lo encuentro especialmente grave, a la hora de guardar URL de enlaces a otros posts, páginas, o imágenes del propio blog, que se guardan como URL absolutas, e implicarán un reemplazo masivo sobre los datos, en caso de que cambiemos nuestra URL principal.
Eficiencia
La página de home de un WordPress 3.1 tal cual viene de serie con el tema Twenty Ten requiere ejecutar 16 consultas a la base de datos, lo cual me parece demasiado, e implica que a poco que el site tenga tráfico se requiera algún mecanismo de caché.
Inconsistencias
Probablemente debido a un diseño deficiente en sus versiones iniciales, que es requerido mantener por compatibilidad con instalaciones existentes, se encuentran ciertas inconsistencias de nomenglatura en las tablas y campos de la base de datos.
Así tenemos wp_comments.comment_ID, pero en cambio wp_terms.term_id, donde como podemos ver el sufijo de ID está escrito en mayúsculas y minúsculas respectivamente. Tenemos también wp_posts.ID, en contraposición con por ejemplo wp_options.option_id. Es decir, la clave primaria autoincremental, a veces es simplemente ID (esta vez también en mayúsculas), y otras, viene precedido por el prefijo de la tabla y en minúsculas. Como extensión a esto, algunos campos de una misma tabla, llevan por prefijo el nombre de tabla, y otros no (post_author, post_title; pero guid).
Sólo se soporta MySQL
Sería interesante dar soporte a otros SGBD que son más convenientes para determinados usos, como SQLite (cuando hay pocas escrituras concurrentes), o PostgreSQL (cuando se necesita un elevado número de operaciones transaccionales).
Hablo de memoria, pero creo recordar que sí admite SQLite, es más, y de esto sí estoy seguro: hay un HowTo en http://php.iis.net/ de cómo instalar WordPress con IIS y SQLServer.
Fernando, supongo que te refieres por ejemplo a Install WordPress on IIS. En ese caso, si que se instala WordPress en un Windows con IIS, pero igualmente sobre PHP y MySQL.
Lo cierto es que no leí el HowTo, sólo supe de su existencia gracias a AyudaWordpress… aunque ahora que lo miro igual era otra cosa la que vi respecto al sito oficial de IIS, no obstante aqui tienes el post en que que apuntan al tutorial para hacer funcionar WordPress con IIS+PHP+SQLServer:
http://ayudawordpress.com/instalar-wordpress-en-microsoft-sql-server/
Y ojo, que a WordPress y al 90% de las aplicaciones PHP les da lo mismo Apache+PHP que IIS+PHP (si la aplicación no utiliza extensiones o funcionalidades solo disponibes para linux o apache…).
Te lo dice alguien que lleva enredando desde 1999 con PHP (ya sea con Apache, PWS, IIS o en línea de comandos bajo linux o windows).
Un saludo
es cierto, la cantidad de consultas a la base de datos es excesiva, tantos recursos consume que me echaron de un hosting gratuito por consumir demasiados recursos del servidor 🙁