Se recomienda hacer la actualización automática, o descargar la versión en ingles desde WordPress 2.8.6, ya que al parecer el archivo de lenguaje no ha sufrido ningún cambio.

La mayoría de los usuarios que han comentado el problema coinciden en que sus instalaciones las realizaron con autoinstaladores como cPAddon (En español “sitio de software” de cPanel) y Fantastico De Luxe (Plugin de cPanel), los cuales permiten hacer la instalación de WP y otros scripts con un solo click.

El problema reside en la configuración inicial de nuestra instalación, es decir los sitios con WordPress instalados estos sistemas de auto instalación vienen con la configuración de privacidad activada en: “Quiero bloquear los motores de búsqueda, pero permitir visitantes normales.” (ver imagen). Por lo consiguiente los robots ignoran al sitio.

La solución es tan simple como entrar a “Opciones -> Privacidad” y elegir “Deseo que este blog sea públicamente visible, incluso para motores de búsqueda (como Google y Technorati) y directorios.”

Un problema común de esta característica es cuando WordPress es incapaz de acceder al sistema de archivos directamente, lo que da como resultado una página indicando lo siguiente: “Para realizar la acción solicitada, se requieren los datos de conexión.” (En ingles: “To perform the requested action, connection information is required.”).

Primero que nada no es problema de WordPress, ni tampoco de la instalación. La razón de esta solicitud es por que, siempre que se usa el panel de control de WordPress para instalar, actualizar o eliminar automáticamente los plugins, WordPress hace cambios a los archivos desde nuestro sistema de archivos interno del servidor.

WordPress antes de realizar cualquier cambio, verifica primero si tiene o no acceso a manipular directamente el sistema de archivos y si WordPress no encuentra los permisos necesarios para modificarlos directamente, es cuando solicita las credenciales FTP para que intente hacer lo que necesita a través de la conexión FTP.

Para entender un poco mejor el por que WordPress no puede escribir en el sistema de archivos, tenemos que echar un vistazo a algunos detalles internos de WordPress.

El siguiente código es del método get_filesystem_method() del archivo wp-admin/includes/file.php:

if( ! $method && function_exists('getmyuid') && function_exists('fileowner') ){
if ( !$context )
$context = WP_CONTENT_DIR;
$context = trailingslashit($context);
$temp_file_name = $context . '.write-test-' . time();
$temp_handle = @fopen($temp_file_name, 'w');
if ( $temp_handle ) {
if ( getmyuid() == fileowner($temp_file_name) )
$method = 'direct';
@fclose($temp_handle);
unlink($temp_file_name);
}
}


Este código crea un archivo temporal y confirma que el archivo recién creado es del mismo usuario dueño del script que está siendo ejecutado. En el caso de la instalación de plugins, el script que se ejecutara es wp-admin/plugin-install.php. En otras palabras la función requiere saber si el dueño de los archivos es el mismo usuario dueño de la cuenta del hospedaje web.

Durante años hemos estado acostumbrados a usar los permisos CHMOD 777 ó 666, para escribir o modificar algún archivo en nuestro servidor web, y teníamos que hacer prácticamente publico el permiso de escritura, pero al ser un método inseguro esto ha ido cambiando.

No vamos a adentrarnos mucho en los permisos CHMOD (aquí les dejamos un enlace que explica claramente CHMOD), pero básicamente los permisos en un servidor linux se dividen en tres niveles de acceso a los archivos, owner (propietario), group (grupo) y other (otros). Y tres tipos de permiso de acceso, read (lectura), write (escritura) y execute y se representan en texto así: -rwxrwxrwx ó en números así: 777.

Pues bien WordPress nos evita tener que dar permisos tan amplios a nuestros archivos y carpetas en nuestro servidor, ya que solo requiere los permisos en el nivel de acceso “owner“. Y aquí es donde reside el problema, pues para que WordPress pueda funcionar así, es necesario que en nuestro hospedaje web tenga asignado el nombre del “owner” en sus permisos.

La Solución
Para solucionar este problema, tenemos que hacer que los scripts (en este caso WP) sean propiedad del mismo usuario que se ejecuta en Apache de nuestro hospedaje web.

Existen varias formas de hacerlo, si nuestra instalación esta hospedada en nuestro propio servidor dedicado solo tenemos que configurar que nuestro PHP corra con el modulo de Apache SuPHP (mod_suphp).

Si aun no tenemos hospedado nuestro WP o estamos por cambiar de hospedaje, podemos preguntar a nuestro proveedor si lo tienen instalado, la mayoría de las empresas de hosting, utilizan este modulo y ejecutan su instancia de Apache utilizando el nombre de la cuenta del usuario, por lo que los archivos serán propiedad de la misma cuenta y no tendremos problemas.

Si nuestra instalación ya se encuentra en un servidor compartido y este NO tiene SuPHP, pero tenemos acceso a SSH (shell) entonces podemos correr el siguiente comando:


chown -R nombre_de_cuenta_owner carpeta_wordpress/


Este comando (chown) permite modificar a los usuarios o grupos dueños de un archivo o carpeta en el sistema de archivos. De ese modo le decimos al servidor que le asigne “dueño” a nuestro WordPress. De cualquier manera es aconsejable que si no estamos familiarizados con Linux, este método sea realizado por un experto, por lo que lo más aconsejable sería solicitarlo a nuestro proveedor de hospedaje. Hay que recordar que no todas las versiones de Linux y por lo tanto del comando chown son iguales, por lo que siempre es aconsejable ver el manual correspondiente del comando según la versión del OS.

Es por eso que el plugin “WordPress Automatic Image Hotlink Protection” resultara bastante útil para protegernos sin tener que meternos en líos para modificar manualmente nuestro .htaccess.

WordPress Automatic Image Hotlink Protection está diseñado para impedir que otros se apropien de nuestras imágenes. El plugin simplemente añade un archivo .htaccess en nuestra carpeta “uploads” deteniendo de ese modo que servidores externos enlacen directamente los archivos.

El programa verifica de forma automática si nuestro servidor web es compatible con el script antes de añadir el archivo .htaccess y establecer los permisos adecuados. Si el plugin es desactivado, eliminará el código del archivo .htaccess automáticamente.

Una herramienta que sin duda nos evitara pasar más enojos.

Descarga


Unable to create directory /la/ruta/de/tu/wordpress.
Is its parent directory writable by the server?


Esto puede ser causado por un error en la configuración o por algún cambio de servidor y/o de carpeta.

La solución a este problema es simple, solo hay que ir a:

En Español:
Opciones -> Miceláneas

En Ingles:
Settings -> miscellaneous

Y cambiar el valor del campo “Guardar los archivos subidos en esta carpeta” (En ingles: “Store uploads in this folder“) a: wp-content/uploads

Hay que tener cuidado al hacer esto por que NO debe de llevar la diagonal “/” al principio “/wp-content/uploads”, lo correcto es SIN la diagonal, de lo contrario seguirá fallando.

Eso es todo y mucha suerte.

Los fallos que soluciona esta versión son los siguientes:

• Se Eliminó la evaluación de la función permalink_structure.
• Se eliminaron algunas llamadas a create_function() que estaban duplicadas y que cargaban el sistema.
• Se hizo un parche para evitar la denegación de servicio (DOS) usando trackbacks.
• Se Eliminó el envío de archivos de forma no filtrada. La cual se puede activar manualmente condefine(’ALLOW_UNFILTERED_UPLOADS’, true); en wp-config.php
• Se añadieron algunas secuencias de escape (formateo de cadenas) para evitar errores.
• Se retiraron dos importadores antiguos. Uno de ellos es el antiguo fetch_rss().
• Y se solucionaron otros pequeños bugs.

El archivo de lenguaje no sufre ninguna modificación, aun así ya esta lista la versión WordPress 2.8.5 en Español España (es_ES).