Esto es muy fácil de hacer si estás haciendo una nueva instalación de WordPress, pero como nos decía @Juan en los comentarios, no es tan fácil hacerlo si ya tienes tu blog instalado y en funcionamiento. Es por esto que hoy he querido hablar de WP Prefix Table Changer, un plugin que nos facilitará muchísimo esta tarea.

Este plugin es práctico por dos razones. Primero, si tienes el prefijo cambiado, cualquier atacante tendrá que adivinar dicho prefijo, cosa que puede ser realmente difícil dependiendo del que pongas. Por otra parte, muchos servicios gratuitos de hosting proporcionan una sola base de datos: en caso de que quieras tener más de un blog WordPress, será imprescindible cambiar dicho prefijo. Esto puedes cambiarlo en la instalación, pero siempre va bien poderlo cambiar si ya tienes el blog instalado y funcionando.

Como ya debéis haber visto, estamos tratando con la base de datos, así que es imprescindible que antes de empezar hagas una copia de seguridad. En general, cuando utilices plugins que cambien cosas importantes o cuando estés manipulando tu sitio, te recomiendo que hagas backup tanto de la DB como de los archivos del servidor FTP: mejor prevenir que curar. Puedes hacerlo utilizando WordPress Database Backup.

Seguidamente, sólo tienes que descargar el WP Prefix Table Changer, instalarlo y ejecutarlo. ¡Fácil!

Fuente: BlogSecurity

Es por este motivo que se recomienda, en general, utilizar el mínimo de plugins posibles. Coge tu lista de plugins y pregúntate: ¿este plugin realmente es esencial para mi blog? Todos los plugins nos dan funcionalidades extra, pero seguro que algunos podrías ahorrártelos fácilmente. Y aquellos que sigas queriendo mantener instalados, debes tenerlos actualizados a su ultima versión para ahorrarte problemas.

Para controlar tu WordPress y comprobar que no esté fallando nada, puedes instalar algunos plugins de seguridad:

1. WordPress Database Backup: Siguiendo con el anterior artículo del tutorial de seguridad, plugin imprescindible para realizar tus copias de seguridad periódicamente sin preocuparte.
2. WP Security Scan: escanea tu instalación de WordPress para buscar vulnerabilidades de seguridad y sugerirte acciones para corregirlas. Escanea passwords, permisos de archivo, seguridad de la base de datos, protección de la administración de WordPress, etc.
3. Semisecure Login Reimagined: incrementa la seguridad del acceso (login) a tu blog utilizando una combinación de claves públicas y privadas de encriptación para esconder tus passwords de vistas ajenas. Se requiere JavaScript y es especialmente útil si no dispones de SSL.
4. Invisible Defender: Añade dos cajas de texto adicionales e invisibles a todos los formularios del blog, cosa que nos permite evitar muchos de los bots de SPAM y otras técnicas de ataque.
5. Theme Authenticity Checker: Nos permite escanear el código fuente de nuestro theme, siendo de esta forma capaz de encontrar inyecciones de código malicioso o ataques similares, mostrando donde está el código problemático para poderlo eliminar fácilmente.
6. WP Antivirus: Antivirus para WordPress que permite encontrar ficheros sospechosos, es una solución fácil y efectiva de proteger tu blog frente a exploits y inyecciones de SPAM. Aquí tienes la reseña de WP Antivirus en TodoWP de Marcelo Lynch.

Hay muchos más plugins disponibles por Internet, seguro que muchos muy buenos, pero creo que con estos puedes tener una buena instalación segura. Si conoces algún otro interesante, ¡coméntalo y así todos aprendemos!

Fuentes: Bitelia, anieto2k, bitsignals.

Este plugin para Wordpress tiene un error que solo afecta a las versiones 2.9 y 2.9.1, al menos hasta donde he podido comprobar, generando demasiados campos personalizados repetidos, como podéis ver en la captura. Entonces cuando la entrada se graba automáticamente antes de publicarse no tiene identificador de entrada (post_id) y se graba con post_id=0, generando un problema de datos no válidos en la tabla wp_postmeta.

La solución es borrar todos esos datos con post_id=0 con esta sentencia de mySQL:

DELETE FROM `wp_postmeta` WHERE `post_id` = 0 LIMIT 10000;

Si tenéis muchos registros erróneos ejecutar varias veces la sentencia ya que está limitada a 10.000 registros para evitar saturar vuestro servidor.

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

Encontrado problema con post-new.php en Wordpress

Habitualmente WordPress no falla, no perdemos datos cuando instalamos plugins o themes, ni cuando actualizamos alguno de sus componentes. No obstante, siempre que hagamos algún cambio importante en nuestro blog deberíamos tener copia de nuestra base de datos y de nuestros archivos de servidor. Un error típico y fácil es hacer copia solamente de la base de datos, y dejarnos sin copiar las imágenes y archivos que tengamos almacenados en nuestro blog.

Empecemos por la base de datos. Personalmente, en mi blog utilizo un plugin que se llama WordPress Database Backup. Al instalarlo, te aparece un menú de Backups en el apartado de Herramientas de tu blog, donde puedes configurar respaldos manuales (guardar una copia de tu base de datos en el servidor o en tu ordenador) o automáticos (programar respaldos que te enviarán a un correo electrónico, con posibilidad de hacerlo cada hora, dos veces al día, cada día, una vez a la semana…). Un plugin muy recomendable.

Personalmente, hago un backup semanal de la base de datos, de forma automática a mi correo electrónico. No obstante, esto no debe ser así en todo blog: depende, sobre todo, de lo que actualices. Si es un blog muy activo, con comentarios a diario, muchas entradas, etc., quizá es mejor hacerlo a diario. Es igual de fácil, ¡con este plugin es todo automático!

Para las copias de seguridad del servidor no utilizo ningun plugin ni programa automático. Muchas compañías de hosting te ofrecen la posibilidad de que te hagan respaldos automáticos en sus propios servidores, de forma que ya no necesitarías hacer nada. Aun así, yo estoy acostumbrado a hacer una copia de seguridad de mi servidor de vez en cuando, quizá una vez al mes o cada dos meses. En mi servidor básicamente lo que se actualiza son blogs, así que no tengo muchas novedades, solamente imágenes para ilustrar los posts. Creo que así es suficiente, pero esto es decisión vuestra.

Espero que este pequeño tutorial haga que los usuarios de WordPress se conciencien y hagan todas las copias de seguridad necesarias para no perder nunca nada. Y, sobre todo, no olvidéis las copias de seguridad antes de actualizar vuestro WordPress a una nueva versión: es el proceso más delicado que hace nuestro sistema de gestión de contenidos y es mejor no dejar nada al azar.

1. Usuario de la base de datos: lo ideal es crear un usuario destinado exclusivamente a nuestro blog, con permisos exclusivos para trabajar con las tablas de WordPress. Es por eso que no debemos utilizar nunca el usuario root. En general, los permisos que daremos al usuario destinado a acceder a la base de datos de nuestro blog serán SELECT, INSERT, UPDATE, DELETE (para datos) y CREATE, ALTER, DROP (para estructuras), pudiendo descartar el CREATE y el DROP si comparte su base de datos con otros proyectos.
2. Cambia el prefijo de tus tablas: WordPress por defecto utiliza wp_ como prefijo para las tablas correspondientes a nuestro WordPress, pero siempre se debería cambiar esta opción en nuestra instalación. De esta forma alguien que quiera acceder a nuestros datos deberá conocer ese prefijo antes. Lo mejor, pues, es utilizar un prefijo aleatorio que no sea de fácil deducción.
3. Elimina los ficheros de instalación: en /wp-admin/, install.php, upgrade.php e installer-helper.php. También puedes eliminar los importadores (wp-admin/import/), que sirven para importar contenido y modifican la base de datos.
4. Fichero wp-config.php: es nuestro fichero más importante para la configuración de WordPress y, por lo tanto, para nuestra seguridad. Con él conectamos a la base de datos, así que hay información confidencial. Por este motivo, tenemos que darle permisos 644, es decir, tenerlo como fichero de sólo lectura.
5. Cambia tu usuario Administrador. Ya tenemos nuestro WordPress instalado, es hora de configurarlo. Lo mejor es crear otro usuario para utilizarlo como administrador (puedes configurarlo desde el panel de administración) e inhabilitar (ponerlo como suscriptor) el administrador que nos crea nuestro WordPress.
6. No utilices tu usuario de administración. Aunque lo acabemos de crear, no lo utilices. En general no necesitarás ser administrador de tu blog, sólo querrás escribir y cambiar cuatro cosas. Así que puedes crearte otro usuario editor o autor, con tu nick y nombre, y configurarlo a tu manera para utilizarlo habitualmente para escribir. Así, si perdieras la contraseña o te la descubrieran, solamente podrían modificar unas pocas cosas de tu instalación. Puedes instalar Role Manager para marcar qué permisos quieres que tenga el usuario que utilizarás para escribir habitualmente.
7. Restringe los directorios que tus usuarios no verán: wp-content, wp-includes y wp-admin son los directorios más usados por WordPress, es por eso que debemos limitar el uso de estas carpetas.  En una próxima entrada haremos especial hincapié en este punto, explicando cómo configurar nuestros archivos .htaccess
8. Crea un archivo en blanco: por defecto, las carpetas de plugins son completamente visibles. Si creas un documento en blanco y lo guardas allí como index.html, ya no serán tan fácilmente visibles.
9. Bloquea las carpetas a los motores de búsqueda. No es necesario que los bots accedan a nuestros archivos de WordPress, así que podemos bloquearlos con el archivo robots.txt. Añade la siguiente línea: Disallow: /wp-*

Espero que estos consejos en la instalación os hayan servido. Si hay alguna duda, o queréis que hable sobre algún tema de seguridad concreto que no haya quedado claro, por favor, comentad.

Fuentes: anieto2k, Online Tech Tips, sigt.

Ocurre que WordPress siempre se fija en esto, pero llama a un archivo en la carpeta wp-content que no existe, llamado db-error.php

Así,  podéis crear este archivo por su cuenta, ingresando el siguiente código adentro:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" <?php if ( function_exists( 'language_attributes' ) ) language_attributes(); ?>>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Database Error</title>
</head>
<body>
<h1>Error establishing a database connection</h1>

<?php
$email = "tu correo";
mail(
$email,
// Asunto
"Error en la base de datos",
// Mensaje
"Parece que tu blog hay problemas con la base de datos."
);
?>
</body>
</html>

Por supuesto, debéis ingresar una direccion de mail en “tu correo”, y podéis modificar el cuerpo del e-mail y el asunto.

Lo que no hace es informaros cuál error es el que  figura, pero es interesante saberlo, ¿no?

Via WP-Hacks

A día de hoy no existe soluciones reales para esta tarea ya que WordPress no utiliza una implementación estándar de consultas a bases de datos para abstraer las consultas sin importar si es MySQL, Oracle, MSSQL, …, lo que sin duda ayudaría a utilizar cualquier sistema de base de datos, incluso bases de datos basada en ficheros XML. Las ventajas de una base de datos basada en ficheros XML creo que sería ideal para un blog acompañado de la generación de todas las páginas de forma estática, generando las mismas bajo demanda y según necesidades, como si de un sistema de cache se tratase. Estaría bien que alguien se currase un Plugin para crear un WordPress para XML.

Hay un artículo en Codex.Wordpress donde explican alternativas y porque no han optado por utilizar un sistema de abstracción de las consultas que permita usar a este popular gestor cualquier tipo de base de datos, yo creo que es un error no dejarlo abierto, pero en fin es una decisión de sus creadores. Algunos sistemas de abstracción de consultas de bases de datos para PHP son ADOdb, PearDB, MetaBase, ezSQL, creole, Zend Framework, …

Por el momento nos tendremos que conformar con la opción de WordPress para SQLlite y WordPress para PostgreSQL (que está un poco desfasada).

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

WordPress sin bases de datos

Todo el mundo trata de optimizar las bases de datos, pulir el funcionamiento de su sitio, ¿y alguien habla de matar todo el trabajo ?

Pues sí. WP Suicide es un plugin que en caso de querer empezar todo de nuevo, hacer un borrón y cuenta nueva, permite borrar todas las entradas de la base de datos sin dejar rastro alguno.

Bien usado, puede usarse para borrar entradas, links, categorías… y si uno no sabe lo que hace, puede realizar un verdadero desastre.

Como pone el desarrollador en la aclaración: Usar con extremo cuidado! El autor de este plugin no asume responsabilidad alguna por los efectos destructivos de su uso.

Note: There is a file embedded within this post, please visit this post to download the file.

Sitio Oficial^[en].

Para eliminar todas las revisiones de un blog, accede a la base de datos y ejecuta la siguiente sentencia SQL:

DELETE FROM `wp_posts` WHERE `post_type` = "revision"

Antes de hacerlo, recuerda hacer una copia de seguridad de la BBDD.

Vía WordPress-Tutoriel

Hice el traslado siguiendo más o menos estos pasos, pero cuando en principio, tras propagarse las nuevas DNS, todo debía funcionar perfectamente, me llevé un chasco: los posts aparecían sin caracteres con acentos ni especiales (como la ñ o los ordinales º y ª). En su lugar aparecían símbolos como ~ o Â. Esto sucedía sólo en los posts y en el nombre y descripción de las categorías (aunque de esto me di cuenta más tarde).

Tras maldecir mi antiguo servidor por guardar de forma tan extraña el backup de la base de datos, mi primera reacción fue buscar en Google. Muchos sugerían dejar el parámetro DB_CHARSET del wp-config.php así, sin definir:

define('DB_CHARSET', '');

Lo probé y el problema cambió por otro: las entradas se veían correctamente pero no así los comentarios. Me sucedió algo similar cuando elegí ISO-8859-1 o Latin 1:

define('DB_CHARSET', 'iso-8859-1');
define('DB_CHARSET', 'latin1');

Tras mucho leer, me dí cuenta de que UTF-8 es el estándar “de facto” así que decidí volver a dejar el parámetro DB_CHARSET como estaba al principio…

define('DB_CHARSET', 'utf8');

…y atacar por otro lado. Me puse a ver la codificación de las tablas con phpMyAdmin. Todas estaban supuestamente guardadas en UTF-8, pero eso fallaba por algún lado. Viendo que no llegaba a ninguna parte, busqué el backup de la base de datos y dejé sólo la tabla wp_posts. Como uso Windows, guardé el .SQL en diferentes codificaciones con los editores Notepad y WordPad, sin resultado e incluso empeorando la cosa puesto que en un momento dado se duplicaron los caracteres extraños que sustituían a los latinos. Siempre que abría la base de datos con esos editores, aparecían los malditos caracteres extraños.

Finalmente, ya por desesperación, abrí el archivo SQL con Microsoft Word, que me preguntó la codificación del archivo sugiriendo que era UTF-8. Acepté y para mi sorpresa todas las vocales con acento aparecían con él y los caracteres extraños se mostraban correctamente. Copié toda la tabla wp_posts, la pegué en Wordpad y la guardé como documento de texto simple, no como documento MS-DOS ni como documento Unicode. Mi alegría fue enorme al ver que, tras subirla con el phpMyAdmin, todos los acentos se mostraban perfectamente en el blog.

Finalmente, revisando para asegurarme de que todo estuviera en su sitio, vi que las categorías adolecían del mismo fallo con acentos y caracteres especiales. Como tengo pocas categorías, edité su nombre y descripción manualmente, pero en el caso de que fueran muchas, supongo que se podría arreglar haciendo lo mismo que hice con la tabla wp_posts, pero con la wp_term_taxonomy. Esa tabla es la que contiene los datos de las categorías.