El otro día, después de actualizar este blog a WordPress 2.6, observé algo extraño, ya que al crear un post, WordPress le asignó como ID de identificación en la base de datos un número mayor al esperado. En concreto esperaba el 357 y el ID asignado fue el 366, pero pensé que sería algo debido a la actualización y no le di mayor importancia.
Pero hoy observé que el ID asignado para el siguiente artículo a publicar es el 389????
¿Donde fueron a parar todos los ID intermedios si solo publiqué dos o tres artículos tras la actualización a la versión 2.6?
Para quien no lo sepa cuando hablo de ID me estoy refiriendo al campo de la base de datos de WordPress que identifica de forma unívoca cada artículo o página de nuestro blog. Los ID de cada artículo deben ir correlativos (o casi, dependiendo de si tenemos borradores o similares), por eso si hay un ID que no está relacionado con ningún artículo hay que preguntarse qué contiene esa fila de la base de datos.
Así que accedí a la bases de datos de WordPress y …. sorpresa!!!
La nueva versión de WordPress, la 2.6, se dedica a realizar una copia de respaldo cada vez que modificamos algo en cualquiera de nuestros posts (nuevos o antiguos). Esto lo hacía la versión anterior con carácter temporal pero en esta ocasión WordPress almacena los cambios en filas con ID correlativos de forma que nuestra base de datos se va llenando de copias innecesarias con cada modificación. Para colmo de males el autosave del programa tiene el mismo comportamiento, de modo que mientras escribo este artículo se van creando varias copias que van ocupando espacio en la base de datos.

No se si habrá alguna forma de desactivar este comportamiento, pero de no ser así deberán tener cuidado quienes tengan contratadas bases de datos con espacio bastante limitado pues en breve pueden llevarse una sorpresa desagradable por consumir toda la cuota asignada.
Espero que haya forma de desactivar esto o que se arregle pronto desde WordPress pues creo que es un error grave que debe corregirse. Saludos avinagrados.
19 - 07 - 2008 [12:37 pm]
Prueba poniendo: “define (’WP_POST_REVISIONS’, false);”
en el archivo wp-config.php.
Así se debería solucionar el problema, pero me temo que las tablas ya creadas no se borrarán.
19 - 07 - 2008 [12:44 pm]
Cuando leo articulos com el tuyo es cuando se me quitan las ganas de actualizar, yo ando todavia por la 2.3.2 y creo que esperare para actualizar el blog.
19 - 07 - 2008 [1:02 pm]
Intruso, el problema es que así eres más vulnerable a hackers que un heterosexual en el día del orguyo gay.
19 - 07 - 2008 [3:26 pm]
Yo opino como Intruso, no suelo actualizar la versión nada más salir, toda versión necesita un periodo de adaptación de pruebas en producción, lo que significa que casi siempre se tiene que sacar una nueva release que arregle cosas de estas. Ya posó con la 2.5 y la 2.5.1. Normalmente espero un tiempo prudencial. Dado que no existe por definición un software sin bugs, pero lo que si se puede conseguir es estabilizar una versión, y para eso tiene que madurar.
Saludos y esta bien saberlo.
19 - 07 - 2008 [4:07 pm]
en Maestros del Web explican la desactivación, http://tinyurl.com/5vsefl y que bueno que comentas ese detalle para optar por ella
19 - 07 - 2008 [6:19 pm]
[...] advierte de un Error garrafal en WordPress 2.6 a tener en [...]
20 - 07 - 2008 [12:39 am]
Creo que fue en anieto2k donde se estuvo debatiendo sobre esto. A mi sí me parece una buena funcionalidad pero lo que no tenían que haber hecho es meterlo en la propia tabla de posts, ahí sólo tenía que estar la vigente, y en otra tabla meter todas las demás versiones del post.
Al menos mientras la entrada está en borrador sólo guarda una copia del post y en posteriormente cuando ya guarda una copia nueva por cada modificación que hagas sea esta gande o pequeña.
20 - 07 - 2008 [2:17 am]
Ya versa los sabios preceptos de oro de la informática:
1. No siempre las últimas versiones son las mejores
2. Si algo funciona bien no lo toques
3. Siempre hay alguien que sabe más que tú
Me preocupa estar al día, como creo la gran mayoría de los cibernautas, pero no me desespero por tener lo último ya ya. Aún recuerdo como luchaban en un foro por tener la versión RC1 de Vista instalado, todos los parches, trucos, vericuetos y demás. Y luego como se DESESPERABAN por tenerlo activado una vez que salío a la luz la versión final. ¿Resultados?, vamos todos los conocemos.
En muy poco tiempo han pasado de la versión 2.3 (creo que esa era) a la 2.5, luego rapidito a la 2.5.1 y ahora a la 2.6.
Cuando un software o aplicación se actualiza tan pero tan rápidamente (salvo honrosas excepciones) me da mala espina. No porque hagan mal las cosas, sino que por solucionar algo dejan cabos sueltos por otro lado. Y veo que el problema de los plug-ins sigue latente versión tras versión. En algunos casos porque algunas funciones han sido eliminadas, renombradas o modificadas.
Yo inicié WP con la versión 2.5.1 y pienso quedarme con ella por un buen tiempo. Es más, ya metí mano al código fuente para eliminar el aviso de la nueva versión pues me distrae un poco (el aviso suena algo así como que si no actualizas eres un tonto, obviamente parafraseando y exagerando bastente).
Un saludo para todos desde Lima,Perú
20 - 07 - 2008 [8:23 pm]
Gracias por el aviso Vinagre!!
Yo he actualizado la versión hoy y de esto no me había dado cuenta aún!!
20 - 07 - 2008 [11:44 pm]
Normalmente utilizo un blog independiente para probar los nuevos cambios antes de ejecutarlos en el real. Esta última versión ya la he puesto en el blog de pruebas y verdaderamente es un coñazo ver todas las actualizaciones de un artículo por mínimas que sean y si esto consume base de datos el problema es grave.
Es decir, la versión 2.6.1 tiene que estar al caer para dejar el programa más coherente. O lo que es lo mismo, esperar un tiempo antes de instalar una nueva versión sigue siendo una acción prudente y necesaria.
Gracias a anieto2k y a Agamum ya he desactivado estas funciones, pero no deberían salir de fábrica en estas condiciones.
21 - 07 - 2008 [12:44 am]
Me corrijo a mi mismo, el autoguardado sólo guarda una copia, pero tanto si el post está en borrador como publlicado, cada edición añade una fila a la tabla.
21 - 07 - 2008 [8:59 am]
Pues creo que he hecho bien en esperar antes de instalar esta nueva versión… :S
21 - 07 - 2008 [12:23 pm]
[...] entero por Vinagre Asesino que esta opción viene activada por defecto y que la nueva versión de WordPress se dedica a [...]
21 - 07 - 2008 [12:27 pm]
Hola,
Estoy con Dondado, la funcionalidad en si está bien, ya que te permite tener versiones de tus posts que es posible que según la naturaleza de tu blog (personal, corporativo, colaborativo) pueda serte útil o no. Lo que si me parece un error es utilizar la tabla wp_posts.
Para mi, más que un error de concepto es un error de desarrollo.
Un saludo,
22 - 07 - 2008 [12:08 am]
Bueno, he realizado el cambio en el wp-config a ver que tal
Por cierto, me gustaría que hicieras un manual de como incluir el boton de bitacoras para votar cada entrada que has puesto en la portada
22 - 07 - 2008 [5:04 pm]
[...] de los problemas que trae WordPress -que a alguno le habrá de servir- es el Histórico de Revisiones, ese elemento [...]
25 - 07 - 2008 [9:00 am]
[...] otro día hablaba del histórico de WordPress (en su versión 2.6) y de como, desde mi punto de vista, es un error el que lo hayan incluido [...]
27 - 07 - 2008 [1:53 am]
[...] de las novedades, interesante para unos e inútil para otros, de WordPress 2.6 es la posibilidad de disponer del historio de revisiones de los artículos, ya [...]
02 - 09 - 2008 [10:10 pm]
Pues a mi no me parece un error de concepto el hecho de que las revisiones permanezcan en wp_posts, puesto que de por sí es allí donde wordpress guarda casi todo: páginas, entradas, e incluso los objetos de media que usamos en ellos. Eso si, me parece que el impacto que esto ha de tener sobre el rendimiento de blogs muy grandes ha de ser enorme, sobre todo por el espacio utilizado en la base de datos. Yo pienso que donde si hay un error de concepto muy importante es en la carencia de una interfaz de control en el dashboard para esta función.
Otra cosa, poner WP_POST_REVISIONS en false no desactiva el autoguardado, solo elimina el historial de revisiones que aparece al gestionar cada entrada, … y para eliminar las revisiones ya exstentes en la base de datos puden hacer un query “DELETE FROM $wpdb->posts WHERE post_type=’revision’;” puesto que todas esas entradas repetidas son del tipo “revision” (ovbiamente distinto de post, page, o attachment, a las que estamos acostumbrados) …
Un saludo … !!
02 - 09 - 2008 [10:15 pm]
aah vale, se me olvidaba …
1. El “ha” del comentario de arriba va si la hache.
2. Para corregir este detallito yo coloque AUTOSAVE_INTERVAL en 2400, de modo que solo se creará una revisión en caso de halla transcurrido una hora desde el momento en que empecé a escribir el post: define(’AUTOSAVE_INTERVAL’, 2400); en el wp-config.php