Error WordPress – No actualiza automáticamente ni WordPress ni los plugins: Nos pide datos FTP

Muchas veces, cuando hemos intentando actualizar WordPress o algún plugin o incluso subiendo alguna foto a nuestro blog gestionado por WordPress, nos hemos encontrado con un mensaje en el que nos pedía que proporcionáramos los datos de nuestra conexión FTP.

¿Por qué tenemos podemos tener este problema en WordPress? En la mayoría de las ocasiones suceden porque tenemos configurado PHP handler como DSO. Sí lo cambiamos a Suphp, todos nuestros problemas se solucionaran de manera inmediata (tenemos que tener acceso a un panel WHM (en VPS) o ponernos en contacto con nuestro proveedor de hosting (Servidores compartidos). Se trata de un problema en el que los usuarios ‘dueños’ de los archivos y los usuarios que ejecutan los programas (en este caso WordPress) no coinciden y entonces… no funciona la actualización automática de WordPress…

Aunque Suphp es más seguro, en determinados entornos, la gente prefiere utilizar DSO porque es más rápido ejecutando PHP, por lo que… ¿Qué podemos hacer para solucionar el problema de otra manera?

Wordpress Logo

Tenemos varias opciones para solucionarlo:

  • Cambiar los permisos (CHMOD) de /wp-content de 755 a 775 0 777 mediante un programa FTP. Esto puede suponer un riesgo de seguridad en ciertos entornos, sobre todo en servidores compartidos.
  • Añadir a wp-config.php (en el directorio raíz de WordPress) nuestros datos para acceder mediante FTP al servidor.

/*** FTP login ***/

define(“FTP_HOST”, “localhost”);

define(“FTP_USER”, “nombre-usuario-ftp”);

define(“FTP_PASS”, “password-ftp”);

  • Definir la constante FS_METHOD en tu wp-config.php:

/*** Definir FS_METHOD en WordPress para poder actualizar de manera automatica sin FTP ***/

define(‘FS_METHOD’,'direct’);

 



WordPress más seguro: Evita escaneos en busca de vulnerabilidades

Navegando por internet, me he encontrado este interesante articulo “WordPress Add-on for 5G Blacklist” donde hay un código muy útil para protegernos de visitantes no deseados en nuestro WordPress y evitar escaneos en busca de vulnerabilidades en nuestra instalación (buscando “bad URL requests”). Hay que copiar el siguiente código en el fichero .htaccess de tu carpeta raiz:

# 5G:[WordPress]

<ifModule mod_rewrite.c>

RedirectMatch 403 /\$\&

RedirectMatch 403 (?i)/\&(t|title)=

RedirectMatch 403 (?i)/\.(bash|git|hg|log|svn|swp|tar)

RedirectMatch 403 (?i)/(1|contact|i|index1|iprober|phpinfo|phpspy|product|signup|t|test|timthumb|tz|visit|webshell|wp-signup).php

RedirectMatch 403 (?i)/(author-panel|class|database|manage|phpMyAdmin|register|submit-articles|system|usage|webmaster)/?$

RedirectMatch 403 (?i)/(=|_mm|cgi|cvs|dbscripts|jsp|rnd|shadow|userfiles)

</ifModule>

Con este código lo que vamos a conseguir es que todas las solicitudes de direcciones URL se comparen con cada una de las cadenas de caracteres y si coinciden con alguna de estas condiciones, se muestra una pagina 403 impidiendo el acceso. Entre ellos nos encontramos al últimamente famoso timthumb.php que tantos problemas ha provocado en muchas instalaciones de WordPress debido a una vulnerabilidad en el código.

 



Trucos para tener un WordPress seguro gracias a htaccess

Wordpress LogoVamos a intentar hacer nuestra instalación de WordPress un poco más seguro añadiendo unas cuantas lineas de codigo en nuestro archivo .htaccess situado en la carpeta root de nuestro servidor (normalmente en /public_html/).

Lo primero: ¿Qué es el fichero .htaccess?

Un fichero .htaccess es un fichero especial, popularizado por el Servidor HTTP Apache que permite definir diferentes directivas de configuración para cada directorio (con sus respectivos subdirectorios) sin necesidad de editar el archivo de configuración principal de Apache”. Wikipedia

El fichero .htaccess de wordpress suele tener esta pinta cuando usamos permalinks con mod_rewrite:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ – [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

Bien, pues justo antes de estas lineas añadimos lo siguiente (OJO: Haz backup de tu archivo .htaccess por si hay algun problema):

Para reducir el spam en nuestro blog (impedimos que los robots de spam accedan a wp-comments-post.php). Acuerdate de cambiar tunombrededominio por el nombre real sin www o similares (Fuente wordpress):

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_METHOD} POST

RewriteCond %{REQUEST_URI} .wp-comments-post\.php*

RewriteCond %{HTTP_REFERER} !.*tunombrededominio.* [OR]

RewriteCond %{HTTP_USER_AGENT} ^$

RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

</IfModule>

Protegemos nuestro fichero de .htaccess de miradas no deseadas:

# STRONG HTACCESS PROTECTION</code>

<Files ~ “^.*\.([Hh][Tt][Aa])”>

order allow,deny

deny from all

satisfy all

</Files>

Protegemos nuestros directorios. Impedimos que se puedan listar en el navegador:

# disable directory browsing

Options All -Indexes

Protegemos de miradas indiscretas nuestro archivo de configuración de wordpress:

# protect wp-config.php

<files wp-config.php>

Order deny,allow

Deny from all

</files>

Impedimos que nos inyecten codigo en nuestro blog mediantes scripts (impedimos modificaciones de _REQUEST y GLOBALS):

# protect from sql injection

Options +FollowSymLinks

RewriteEngine On

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ index.php [F,L]

Vía: www.mastermindblogger.com



Optimiza y tunea my.cnf (Mysql) en tu servidor VPS

Imaginemos la situación. Acabas de mudar todas tus webs de un servidor compartido (Shared server) a un Servidor Virtual dedicado (VPS) y te encuentras que tienes que optimizar un monton de cosas, entre ellas tu base de datos Mysql que usabas en tus blogs de WordPress, en Drupal, Joomla o Moodle. ¿Por donde empezamos?

  1. ¿Cuanta RAM tenemos en nuestro servidor? Factor clave y determinante para la optimización de nuestra base de datos Mysql
  2. ¿Qué es lo que tengo que optimizar en Mysql? Principalmente el archivo my.cnf que encontraremos en /etc/mysql/my.cnf o /etc/my.cnf despendiendo del Sistema operativo.
  3. ¿Como lo edito? A través de terminal mediante una conexión ssh al servidor y gracias al editor de unix ‘vi’
  4. ¿Que cantidad de memoria RAM puede consumir Mysql? En función de los parametros que configuremos en my.cnf. Podemos hacernos una idea con esta calculadora de memoria RAM para Mysql
  5. Leemos esta biblia de optimización de MySQL, para comprender el significado de cada parametro.

Antes de empezar a hacer ningun cambio, sería mejor culturizarnos un poco. Normalmente, en nuestro servidor, podemos encontrar ejemplos de archivos my.cnf en función de la RAM que tengamos disponible:

/usr/share/doc/mysql-server-5.1/

my-small.cnf: para sistemas con 64MB de RAM (Como!!!)

my-medium.cnf: para sistemas con 256MB de RAM

my-large.cnf: para sistemas con 512MB de RAM

my-huge.cnf: para sistemas con 1-2GB de RAM

Para empezar no esta mal y nos podemos hacer una idea de cuales son los parametros más importantes a ajustar.

Comprobamos el uso que nuestro VPS hace de la memoria con los siguientes comandos en el terminal: top, ps aux y free -m

Nos familiarizamos con el aspecto que tiene un archivo my.cnf

[mysqld]
safe-show-database
open_files_limit = 5000
tmp_table_size = 95M

max_heap_table_size = 95M

query_cache_limit=2M

query_cache_size=55M ## 64MB for every 1GB of RAM

query_cache_type=1

max_connections=100

collation_server=utf8_unicode_ci

character_set_server=utf8

delayed_insert_timeout=40

interactive_timeout=10

wait_timeout=30

connect_timeout=20

thread_cache_size=64

key_buffer=16M ## 32MB for every 1GB of RAM

key_buffer_size=40M

join_buffer=1M

max_connect_errors=20

max_allowed_packet=8M

table_cache=2048

table_definition_cache=2048

record_buffer=1M

sort_buffer_size=1M ## 1MB for every 1GB of RAM

read_buffer_size=1M ## 1MB for every 1GB of RAM

read_rnd_buffer_size=1M ## 1MB for every 1GB of RAM

thread_concurrency=2 ## Number of CPUs x 2

myisam_sort_buffer_size=16M

innodb_file_per_table=1

innodb_buffer_pool_size=35M

Y la verdad es que nos es facil optimizarlo… ¿Cuales son las variables más importantes?

max_connections
wait_timeout
thread_cache_size
table_cache
key_buffer_size
query_cache_size
tmp_table_size

¿Donde encontramos más ayuda para tunear Mysql? Afortunadamente hay varios programas que nos pueden ayudar a optimizar el archivo my.cnf de Mysql (lo mejor es usar los tres y comparar resultados):

MySQLTuner, Tuning Primer y mysqlreport

Nos descargamos estos programas en nuestra carpeta /usr/local/sbin/, les damos los permisos para que se puedan ejecutar (entrando en el servidor como root) y nos preparamos para el despliegue de datos.

¡Suerte a todos! Tened en cuenta que hay que ejecutar estos programas entre 24 y 48 horas despues de haber hecho los primeros cambios en my.cnf. Dejamos pasar ese tiempo, los volvemos a ejecutar y volvemos a optimizar la bbdd editando my.cnf. ¡OJO! Después de editar el archivo hay que reiniciar Mysql a través del terminal o del panel WHM o similar, sino, los cambios en el archivo no se verán reflejados.



Error en tu WordPress: “Fatal error: Class ‘Memcache’ not found…” y php.ini

He cambiado de servidor de un Shared Hosting a un VPS y como en todos los cambios, siempre pasa algo. Uno de los problemas que me he encontrado (uno de muchos) es que después de instalar Memcached para reducir la carga del servidor, mis instalaciones de WordPress no funcionaban correctamente y me mostraban un error como este:

“Fatal error: Class ‘Memcache’ not found…”

Y yo había comprobado que tanto memcached como la “PHP PECL memcache extension” estaban instalas y funcionando correctamente en el servidor (con el comando “ps aux | grep memcached”)… ¿Qué pasaba? Si por algo he elegido Hostgator como compañía de Hosting es por su excelente servicio al cliente y sus rápidas respuestas cuando tienes un problema. Después de unos cuanto tickets, lo que sucedia es que aunque en la php.ini del servidor estaba claramente especificada la extensión para que todo fuera OK (extension = “memcache.so”), los dominios no estaban utilizando ese php.ini.

¿Solución al problema? (en todos los casos sustituimos username por nuestro nombre de usuario en cpanel)

  1. Crear un archivo php.ini para cada dominio en el servidor en /home/username/
  2. Añadir las siguientes lineas en los archivos .htaccess de cada dominio situados en /home/username/public_html/.htacces, donde vamos a decirle donde se encuentra nuestro archivo php.ini con nuestra linea de código (extension = “memcache.so”) configurada para que funcione Memcached.

<IfModule mod_suphp.c>
suPHP_ConfigPath /home/username
<Files php.ini>
order allow,deny
deny from all
</Files>
</IfModule>

Y me podeis decir… “Esto esta muy bien, pero… ¿Que hacemos para que WordPress aproveche la potencia de Memcached?” Hay varias opciones en forma de plugin, una es muy conocida: Usar W3 Total Cache. En mi caso uso Wp Super Cache como plugin para cachear mis paginas, y según el soporte, tambien hace uso de Memcached (pero no de manera tan intensiva como el otro), así que instale WP Memcached Manager (para chequear que Memcached estaba funcionando)  y Memcached Object Cache (el plugin que hace a WordPress utilizar a fondo esta característica - ¡Ojo! NO se instala en el directorio de plugins de WordPress, sino en wp-content).



Un blogger y su iPad: Una relación complicada

Es cierto. Un blogger y su iPad tienen una relación complicada. ¿Por qué? Todavía no es nada sencillo gestionar tu blog desde un iPad. Veamos el porque en dos situaciones: Tu blog en blogger, el servicio de Google y tu blog en WordPress y luego veamos algunas herramientas útiles que nos facilitaran la vida a la hora de publicar en nuestro blog.

WordPress en el iPad:

Actualmente, los chicos de Automattic han publicado una versión de WordPress para el iPad que es bastante limitada. No tiene editor de formato, por lo que algo tan imprescindible como poner negritas, hay que hacerlo mediante código html.

Aparentemente, tampoco puedes poner enlaces ¿?… o por lo menos no puedes hacerlo de manera evidente. Sí empiezas a escribir http://, te salta un pop-up que te indica si quieres poner un enlace.

Pero no todo son cosas negativas en esta aplicación: Puedes subir fotos, cosa que no puedes hacer si entras en la administración de blog wordpress desde Safari en el iPad y la gestión de comentarios es bastante buena.

Creo que la mejor opción es combinar las dos formas de editar tu blog: Primero escribes tu articulo a través de la aplicación especifica de WordPress para el iPad y subes las fotos (se colocaran por defecto al final del post) y posteriormente, si no se quiere completar el formato de la entrada con código html, lo guardaremos como borrador y nos conectaremos a nuestro blog mediante Safari para editar el formato de la entrada (aunque no nos funcione el visual, podemos utilizar el modo html donde encontraremos las opciones más básicas de edición…).

Blogger en el iPad:

Con blogger el asunto se complica un poco, porque todavía no hay aplicación oficial para postear desde el iPad. Hay que liarse la manta a la cabeza y echarle imaginación para poder postear con corrección.

Podemos utilizar la aplicación de pago BlogPress (2,99 dolares) para gestionar nuestro blog, tanto de blogger como de wordpress, pero las críticas no ponen muy bien a la aplicación, así que no la he usado…

¿Como publico en blogger? Me conecto mediante Safari al panel de control de blogger y allí, con las pocas opciones que funcionan, edito el post (lo fundamental son las negritas y los links, que si funcionan)… Y para subir fotos… Desde blogger imposible… Así que hay que utilizar algún servicio externo tipo Flickr o Photobucket, que nos permita copiar el código e insertarlo en nuestra entrada para que se vea la foto… Para gestionar vuestras fotos en Flickr os recomiendo la aplicación FlickStackr (1,99$)

Como veis no es nada inmediato poder publicar tus post en el iPad tal y como lo harías en un PC/Mac.

Edición de fotos en el iPad:

Otro problema que se os puede plantear es como modificar vuestras fotos en el iPad. Esto es más sencillo. Existen varias aplicación gratuitas para poder editar nuestras fotos (recortarlas, cambiar tamaño etc): Adobe Photoshop Express o PhotoPad by ZAGG

Aquí si que no tenemos problemas. Los dos programas son excelentes y nos proporcionan las funcionalidades básicas que vamos a necesitar para modificar las fotos que vayamos a publicar en nuestro blog

Continuar leyendo



WordPress para Android: Aplicación oficial

Wordpress para AndroidYa tenemos en el Market, la aplicación oficial de WordPress para Android. Ya podemos postear desde nuestros móviles en nuestro sistema de blogging favorito.

Desde esta aplicación podremos:

  • Moderar los comentarios incluyendo la opción de responderlos
  • Crear y modificar los post, incluyendo categorías, etiquetas y fotos
  • Crear y Editar páginas
  • Enterarnos de los nuevos comentarios en la barra de notificación de Android

Por fin tenemos esta aplicación. A mi me va a venir de perlas :)



¿Por qué falla el cargador de imágenes Flash en WordPress? .htaccess – passwd en wp-admin

Muchos de vosotros tendréis un blog propio alojado en vuestro servidor gestionado por WordPress. Uno de los problemas más comunes que aparecen en nuestros blog WordPress es la imposibilidad de usar el cargador de imágenes mediante Flash…

subir imagenes wordpress

¿Por qué falla el cargador de imágenes Flash en WordPress? No voy a comentar todos los posibles errores por lo que puede fallar, pero si me gustaría reseñar uno.

Una de las maneras de proteger nuestra instalación de WordPress es proteger el directorio /wp-admin con contraseña mediante .htaccess (se puede hacer a mano creando un archivo .htaccess junto a un archivo passwd, o directamente tu empresa de alojamiento web te ofrecerá la opción en el panel de control de tu hosting).

Bien. Una vez que hemos añadido esta capa de seguridad a nuestro blog, el cargador de imágenes en Flash deja de funcionar… pero creo que merece la pena…



Como generar una copia de seguridad de tu blog WordPress

Todos los que trabajamos con WordPress en nuestros blogs deberíamos preocuparnos de tener siempre una copia de seguridad de los mismos, pero llegados a este punto tenemos varias opciones que voy a pasar a describir.

Si tenemos suerte y nuestro hosting nos lo permite, podremos descargar de manera automática a través de cpanel, un archivo con una copia de seguridad completa de nuestro blog (archivos, base de datos). Sin duda es la opción más cómoda. Por ejemplo, Bluehost, donde esta alojado este blog, dispone de esta opción, pero tengo otros blogs en Godaddy y allí tengo que hacerlo de una manera un poco más manual.

1.-Mediante Phpmyadmin hago una copia de seguridad de la base de datos.

Vas a la pestaña exportar y una vez allí te aseguras que esten todas las tablas marcadas -sql-; que en la sección struture estén marcadas

  • ‘Structure’
  • ‘Add DROP TABLE’
  • ‘Add AUTO_INCREMENT’ and
  • ‘Enclose table and field names with backquotes’

y que en la sección DATA solo este marcada ‘Data’. Luego sólo hay descargar el archivo. En el Codex de WordPress hay un excelente tutorial con imágenes para hacer copias de seguridad de tu base de datos.

2.-Mediante FTP descargaremos todos los archivos del blog en nuestro PC.

Bien, con estos 2 procedimientos ya tendremos la copia de seguridad de nuestro blog, pero me gustaría proponer un método alternativo que he utilizado últimamente.

Generar un archivo WordPress WXR a través del panel de administración de nuestro blog.

Es sencillo y rápido. En la sección “Herramientas” tenemos dos opciones llamadas exportar e importar. En exportar podemos generar un archivo WordPress eXtended RSS (RSS ampliado de WordPress) o WXR, que contendrá todas tus entradas, páginas, comentarios, campos personalizados, categorías y etiquetas.

Continuar leyendo



Aplicación de WordPress para dispositivos con Android

Algo que muchos estamos esperando desde hace tiempo. La aplicación oficial de los chicos de WordPress para nuestros móviles Android. ¡Queremos publicar vía movil!.

¿Por que ha surgido el rumor? Parece que han creado el subdominio android.wordpress.org, cosa que ya hicieron anteriormente cuando lanzaron las aplicaciones para iPhone y Blackberry

2010 va a ser el año de Android, sobre todo porque se prevee que Goolgle lance su propio telefono movil, Nexus One Android. No es de extrañar que WordPress se quiera subir a un carro ganador.

Vía Mashable

Creado con WordPress

Twitter Algo Entre Manos
Google+ Algo Entre Manos
Facebook Algo Entre Manos
Sitemap
Datos Legales
Estadísticas de visitas.
Licencia Creative Commons.