¿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?

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’);

# 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.

Vamos a intentar hacer nuestra instalación de WordPress un poco más seguro añadiendo unas cuantas lineas de codigo en nuestro archivo .htaccess

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

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.

• Tutorial: Tuning MySQL Performance with MySQLTuner
• Significado de los datos obtenidos con mysqlreport
• Tuning Primer es el ofrece los datos más claros y los consejos más especificos

¡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.

“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).

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

Vídeos en el iPad:

También me he encontrado problemas para encontrar el código html necesario para incrustar vídeos en los post cuando estamos trabajando en nuestro iPad. Tienes que entrar en YouTube en su versión normal, no en la móvil, y además no hacerlo desde la aplicación que viene instalada en el iPad, sino a través de Safari.

Desde allí, ya puedes dejar el presionado el dedo en el cuadro donde se encuentra el código, y pasados unos segundos te aparecerá la opción de copiar todo el código.

Noticias: Fuentes RSS en el iPad

Por supuesto, es imprescindible tener un buen programa de gestión de fuentes RSS en el iPad. Yo recomiendo Reeder, sobre todo porque te guarda los artículos en cache y por la multitud de opciones que tiene para ‘exportar’ los artículos (Safari, Instapaper, ReadItLater, Delicious, Twitter…)

Procesador de textos para el iPad

También es interesante tener en nuestro iPad algún procesador de textos por si queremos escribir nuestro post allí o simplemente guardar nuestras notas para un futuro post. Aquí no hay discusión, Pages es el mejor.

Esperemos que en un futuro las aplicaciones para publicar en nuestros blog mediante el iPad mejoren y nos hagan la vida más fácil. Sin duda, el iPad es el perfecto compañero de viaje para todos aquellos que no queremos cargar con un trasto a todas partes…

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? 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…

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.

En mi caso, tuve problemas con una de mis bases de datos y no podía actualizar worpress a su última versión debido a que tenía una de las tablas completamente inservible… Genere este archivo y luego lo importe a una versión completamente limpia de wordpress, eso sí, dejando en el servidor completamente intactos todos los archivos de la carpeta wp-content.

Sólo una pega, si vuestro blog es muy grande, tendréis problemas al importar el archivo (o porque vuestro servidor no os deja subir archivos de más de x megas, o porque el importador no reconoce tal cantidad de datos y se deja entradas sin copiar), por lo que tendréis que partirlo en varios:

Cada archivo deberá siempre empezar por

<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:wp="http://wordpress.org/export/1.0/"
>
<channel>
Aqui se incluye toda la información de categorias, tags etc... justo antes de del primer <item>

Y el archivo deberá terminar por:

</channel>
</rss>

Entre medias, deberán estar todos los post comprendidos entre <item> y </item>

¿Cual es la única pega de este método? Pues que no guarda la información del tag ‘gallery’ que genera las galerías de fotos de wordpress. ¿Cómo lo resolví? Consultando la cache que genera Google de mi blog y copiando el código de la galería directamente. Fue lo más tedioso del proceso.

¿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