Planeta WordPress

Aviso que este artículo no es para novatos, pues lo primero es que debes tener acceso total a tu servidor, mediante la interfaz de comandos, en este caso el shell.

Eso si, cuando pasas ese pequeño susto, que no inconveniente, se te facilita la vida sobremanera, pues todo es más rápido por SSH.

Así que, miedos fuera, si ya vimos hace tiempo como instalar WordPress por SSH, e incluso como actualizar WordPress con subversion, hoy toca actualizar WordPress por SSH, y vamos a ver un par de modos de hacerlo.

1. Actualizar WordPress por SSH

En los siguientes comandos se asume siempre que se están haciendo en el directorio de tu WordPress (miweb en el ejemplo). Así que ya dejando esto claro lo primero que haremos es descargar la última versión y extraerla, lo haremos así:

wget http://wordpress.org/latest.tar.gz
tar xfvz latest.tar.gz

A continuación borraremos los directorios ‘wp-admin‘ y ‘wp-includes‘ antiguos:

rm -rf ./wp-admin
rm -rf ./wp-includes

Para, a continuación, ir a la carpeta “wordpress” donde extrajimos la última versión de WordPress y mover todos los archivos al directorio de nuestro WordPress:

cd wordpress
mv * ../miweb/

Cuando comience el proceso el shell te preguntará si quieres sobreescribir algunos archivos y carpetas, también dentro del directorio ‘wp-content’, ahí ya tu decides lo que sobreescribes y lo que no, mi consejo de siempre ya lo sabes, ni se te ocurra con ‘wp-content‘.

Cuando termine el proceso salimos de la carpeta “wordpress” y borramos el directorio y el archivo ‘latest.tar.gz‘:

cd ../
rm -rf ./wordpress/
rm -f latest.tar.gz

El paso final es acceder a tu escritorio y actualizar la base de datos si te lo pide WordPress.

2. Activar SSH2 para actualizar WordPress

Una posibilidad de WordPress que quizás no conozcas es que puedes usar SSH para actualizaciones e instalaciones de plugins y temas. Lo primero que hay que hacer es comprobar si tu alojamiento tiene la extensión SSH2 instalada en PHP o no. Para comprobarlo ejecuta el siguiente comando PHP:

var_dump( extension_loaded( 'ssh2' ) );

Si el resultado es afirmativo (true) entonces eso significa que está instalado, sino es que no, como es lógico. Si no estuviera instalado y quieres tenerlo, una de dos, pides a tu proveedor de hosting que te lo instale, o si tienes un VPS o servidor dedicado instálalo tu mismo. En este último caso el modo sería el siguiente:

Lo primero es crear una serie de claves públicas y privadas que usaremos para identificar al usuario. Para crearlas usaremos el siguiente comando en tu cliente SSH:

ssh-keygen

Te preguntará el nombre del archivo. Puedes dejarlo en blanco o poner cualquier nombre que se te ocurra. Si lo dejas en blanco los nombres de archivo serán id_rsa.pub y id_rsa. También puedes establecer aquí una contraseña para añadirle seguridad extra, o si lo prefieres dejarlo también en blanco.

A continuación toca añadir las claves necesarias al archivo authorized_keys. En nuestro ejemplo las claves SSH se crean y guardan en el directorio ‘.ssh‘, dentro del directorio raíz.

cd .ssh
cp id_rsa.pub authorized_keys

Lo siguiente es cambiar los permisos para que WordPress pueda acceder a estas claves:

cd ../
chmod 755 .ssh
chmod 644 .ssh/*

Por supuesto, tendrás que cambiar el usuario del directorio si estás ejecutando PHP como otro usuario.

Ahora que ya tenemos SSH2 configurado y en marcha tendrías que ver la siguiente pantalla cuando actualices o instales un plugin o tema:

En esta pantalla el usuario es el nombre de usuario SSH que usaste para acceder y llevar a cabo todos los comandos, y la clave es la contraseña que te pidió cuando ejecutaste el comando ssh-keygen. Si no elegiste ninguna contraseña entonces deja el campo en blanco. Si, además, no quieres tener que repetir este paso cada vez que actualices entonces añade lo siguiente al fichero wp-config.php:

define('FTP_PUBKEY','/home/user/.ssh/id_rsa.pub');
define('FTP_PRIKEY','/home/user/.ssh/id_rsa');
define('FTP_USER','tuusuario');
define('FTP_PASS','tucontraseña');
define('FTP_HOST','tudominio.com');

Por supuesto, cambia las rutas por las tuyas, con especial atención a las rutas absolutas de las líneas 1 y 2, recuerda que esto es un ejemplo, no debes copiarlo y pegarlo tal cual sino adaptarlo a tus credenciales e instalación.

A partir de que guardes los cambios WordPress realizará las operaciones de transferencia de archivos en actualizaciones usando SSH.

¿Que no es para ti esto?, pues entonces puedes actualizar automáticamente WordPress al modo normal, o a lo bestia.

Como el otro día comenté algo sobre Varnish y un nuevo plugin, y alguno ya preguntasteis en los comentarios, creo que ya iba siendo hora de explicar lo que es  Varnish, un sistema de cache realmente potente, fantástico para instalaciones WordPress con mucho tráfico, y que como ya puedes imaginar uso aquí en Ayuda WordPress.

Vamos a ello pues …

¿Qué es Varnish?

Varnish Cache es un acelerador web, o un sistema de cache HTTP de reverse proxy. Se instala en cualquier servidor que sirva (vale, es redundante) HTTP y se configura para que cachee sus contenidos. Según algunos estudios acelera el servicio en un 70%.

Cachear una web, por si alguien no lo sabe aún, es almacenar una copia de la misma para que sea la que vean los visitantes futuros. En el caso de Varnish y WordPress, lo que consigue es servir páginas cacheadas (almacenadas) de tu WordPress para que no tenga este que hacer llamadas a la base de datos cada vez que alguien visita tu web. Esto reduce la carga del servidor ya que simplemente sirve una copia única de las páginas a todos los visitantes sin tener que buscar las mismas imágenes y servicios para cada contenido y cada visitante.

Además, Varnish cachea las páginas en memoria virtual, para que tu sitio cargue mucho más rápido, lo que de paso mejora tu SEO, pues Google tiene estimado que por cada medio segundo de tiempo de carga adicional de una web esta recibe una media de un 20% de menos visitantes (fuente). De este modo, reduciendo con Varnish de manera importante el tiempo de carga de página pueden aumentar tus visitas y mejorar tu ranking en los buscadores, algo siempre a tener en cuenta.

La gente de Varnish ha publicado un vídeo muy simple, al tiempo que explicativo que seguro te ilustra sobre lo que hace …

Instalando Varnish

Varnish es un software libre así que no tienes excusas para instalarlo ahora mismo. Se ejecuta en Linux, preferiblemente en FreeBSD, pero puede funcionar igualmente en otras plataformas. Una vez lo instales puedes personalizarlo para definir cuantas peticiones entrantes gestionará mediante el Idioma de Configuración de Varnish (Varnish Configuration Language o VCL).

Varnish está pensado para que sea flexible, para que lo instales pensando en un sitio concreto en mente, y lo adaptes de manera personalizada a el.

Lo ideal es empezar con una configuración básica de Varnish, para más adelante ir probando pequeños cambios y ver como afectan al rendimiento del sitio concreto. Hay varias subrutinas que le dicen a Varnish como responder a las peticiones entrantes y salientes, a los errores, etc.

Así que vamos a empezar con una configuración básica, para luego echar un vistazo a las funciones básicas del VCL y luego ya tu lo tuneas a tu gusto.

Paso a paso

Poner en marcha Varnish es bastante sencillo. Partiendo de una base de, digamos, Apache en un sistema Debian (la mayoría de los servidores Linux), aunque también funciona en el resto, empezaríamos con este comando:

apt-get install varnish

Primero  hay que configurar Apache para que “escuche” el puerto 8080 de localhost. Varnish podrá entonces escuchar el puerto 80 (por donde vienen las visitas). En el archivo /etc/apache2/ports.conf, edita estos ajustes:

NameVirtualHost 127.0.0.1:8080
Listen 127.0.0.1:8080

Para que se inicie Varnish (por defecto no lo hace), edita lo siguiente en el archivo /etc/default/varnish

START=yes
DAEMON_OPTS=”-a DIRECCION_IP_EXTERNA:80 \
	-T localhost:6082 \
	-f /etc/varnish/default.vcl \
	-S /etc/varnish/secret \
	-s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G”

Reemplaza DIRECCION_IP_EXTERNA con la IP de tu dirección IP externa. También puede ser una dirección interna si tu servidor está tras un balanceador de carga o algo como NGINX. Este ajuste controla qué dirección IP y puerto quieres que Varnish escuche y vigile.

Una vez echo lo anterior edita el archivo /etc/varnish/default.vcl, que debería ya existir, con mucho de su contenido comentado (no activo). Empiezaremos por cambiar el backend default.

backend default {
	.host = “127.0.0.1”;</p>
	.port = “8080”;</p>
}

Ahora Varnish ya sabe que Apache está escuchando el puerto 8080 y la interfaz de localhost, para que podamos empezar a usar las funciones. La mayoría del trabajo se  hará con vcl_recv y vcl_fetch, y si no llamas a una acción en esta subrutina y Varnish llega al final, ejecutará el código que encuentre en el archivo default.vcl.

Note: no cachees nunca wp_admin, wp_login, o rutas similares.

Así es como trabaja – las 4 básicas subrutinas de tu configuración de Varnish que necesitas para gestionar peticiones serán:

sub vcl_recv

Esta llamada se hace al comienzo de una petición, y le dice a Varnish qué hacer con esa petición en concreto: si tiene que servirla, cómo servirla, y qué respaldo usar.

Varnish recibe una petición de tu navegador, y entonces vcl_recv decide hacer una de 3 costs con ella: vcl_hash, vcl_pass, y vcl_pipe (ahora lo explico). Puedes cambiar la petición si quieres, alterar las cookies o quitar la cabecera de la petición.

sub vcl_fetch

A vcl_fetch se la llama después de que se haya recuperado un documento con éxito. Usas esto para alterar las cabeceras de respuesta, lanzar el procesamiento ESI o para tratar de alternar entre servidores de respaldo si falla la petición.

El objeto solicitado, req, está todavía disponible, y ahí también  hay una respuesta de respaldo, beresp, que contiene las cabeceras HTTP del respaldo.

sub vcl_hash

Puedes llamar al hash_data del dato que quieras añadir al hash. Esta subrutina puede terminar con una llamada a return() con una de estas keywords: hash o proceed.

sub vcl_deliver

Llamas a esto antes de que el objeto cacheado se entregue al cliente. Esto puede terminar con deliver, error code, o restart. Deliver entrega el objeto al cliente, error devuelve el código de error específico al cliente y abandona la petición, restart reiniciará la transacción e incrementará el contador de reinicio.

Acciones

Hay ciertas acciones que puedes realizar en cada subrutina cuando personalizas Varnish:

pass

Pasa la petición y su consiguiente respuesta hacia el servidor de respaldo, sin cachear. Puedes llamar a pass tanto en vcl_recv como en vcl_fetch.

lookup

Se hace la petición desde vcl_recv para entregar contenido desde la cache aunque la petición indique que debe pasarse la misma. Puedes llamar a lookup desde vcl_fetch.

pipe

Desde vcl_recv, pipe cortocircuita al cliente y las conexiones de respaldo, y Varnish simplemente se queda ahí pasando los datos a un lado y a otro, registrando los datos, así que los registros serán incompletos. Ten cuidado ya que un cliente HTTP 1.1 puede enviar varias peticiones en la misma conexión, y así podrías hacer que Varnish añada una cabecera “Connection:close” antes de hacer la llamada a la pila de conexiones.

deliver

Entrega el objeto cacheado al cliente. Normalmente se le hace la llamada desde vcl_fetch.

esi

Hace un proceso ESI del documento adquirido.

Si quieres saber más sobre VCL no te pierdas este tutorial, que también contiene funciones que puedes realizar en tu sitio.

Configuraciones de ejemplo

Espero que estés aprendiendo algo (o mucho) de Varnish, pero la mejor manera de empezar a jugar con el es ver algunos ficheros de configuración de ejemplo.

La web de la comunidad de Varnish tiene una enorme colección de configuraciones de ejemplo, que son un buen sitio para empezar a hacer las tuyas. Incluso hay algunas configuraciones de ejemplo estupendas para WordPress de fetch y receive en Github.

Creo que llegado este punto huelga decir que Varnish es muy personalizable, y que puede hacer maravillas para cualquier instalación WordPress, especialmente las de alto tráfico. También, hay que reconocerlo, tampoco es para cualquiera, al menos hay que tener conocimientos de conexión con servidores mediante Linux.

Lo mejor es que, con poco esfuerzo y gratis, puedes configurar una cache realmente potente con Varnish, basándote en los permisos de usuario, en el tipo de usuario o lo que se te ocurra.

Si quieres más pruebas del poder de Varnish, no solo Ayuda WordPress lo usa, también Facebook, y creo que no hay mejor prueba de web de alto tráfico que esta tremenda red social ¿no crees?.

Plugins WordPress

Hay, como ya comenté hace días, plugins WordPress que te permiten configurar o gestionar el comportamiento de Varnish en WordPress, los que encontrarás serán estos:

• Varnish HTTP purge – simplemente limpia la cache de cualquier contenido que modifiques, para entregar la última versión.
• Varnish purges – muy similar al anterior
• WP Varnish – otro gestor de la cache de Varnish
• WordPress Varnish – otro plugin que vacía la cache de Varnish cuando añades o actualizas contenido de tu sitio.
• WordPress Varnish as a service – estupendo plugin, del que ya hemos hablado

Bueno que ¿te animas a probar Varnish o ya lo has usado?

Nos avisa Matt que han sufrido un importante ataque que ha comprometido los servidores de WordPress.com a nivel de "root", o sea, de superadministrador, o dicho de otro modo que alguien se ha metido hasta la cocina.

Lo malo de esta irrupción es que no se sabe cual es el alcance posible del mismo, pues cuando uno entra a ese nivel puede acceder a todo, absolutamente todo, y nada es seguro, solo dependes de las intenciones del atacante.

Matt alega que están haciendo cambios para impedir que esto pase de nuevo pero la realidad es que llevan una racha delicada en cuestiones de seguridad, suponemos que a nivel de los servidores.

Solo espero que blinden a tope WordPress.com para no comprometer la increíble ascensión de este servicio, cada vez mejor.

Hace tiempo hablé ya de como solucionar a nivel de servidor el problema que surge cuando programas una entrada y esta, en vez de publicarse a la fecha y hora que habías definido, se queda en “programación perdida”.

Este es un problema que suele ocurrir en algunas actualizaciones y, eventualmente también, en cambios de horario locales. Pues bien, si no tienes acceso por SSH o prefieres acabar con el problema en pocos clics puedes usar el plugin Missed Schedule.

Funciona con las últimas versiones de WordPress, normales o multisitio, y tanto en servidores dedicados como compartidos o VPS. No hay nada más que hacer que instalarlo y activarlo, si usas habitualmente la programación de entradas lo dejas activo y ya está.

¡Que lo disfrutes!

Hace tiempo hablé ya de como solucionar a nivel de servidor el problema que surge cuando programas una entrada y esta, en vez de publicarse a la fecha y hora que habías definido, se queda en "programación perdida".

Este es un problema que suele ocurrir en algunas actualizaciones y, eventualmente también, en cambios de horario locales. Pues bien, si no tienes acceso por SSH o prefieres acabar con el problema en pocos clics puedes usar el plugin Missed Schedule.

Funciona con las últimas versiones de WordPress, normales o multisitio, y tanto en servidores dedicados como compartidos o VPS. No hay nada más que hacer que instalarlo y activarlo, si usas habitualmente la programación de entradas lo dejas activo y ya está.

¡Que lo disfrutes!

Llevo tiempo buscando un buen cliente o más bien frontend para SSH en Mac OS X, ya que todos sabemos que por defecto tenemos una genial consola Unix en todos los OS X, pero yo personalmente necesito algo como SecureCRT en Windows.

Hasta ahora lo más parecido que he encontrado es JellyfiSSH un gestor de marcadores para conectar a servidores Unix/Linux a través de Telnet, SSH1 o SSH2, siempre haciendo uso del terminal del sistema operativo.

Es una buena solución pero no me permite almacenar la contraseñas de ninguna forma, ni segura ni insegura para evitar tener que buscar las claves de cada servidor cuando necesito acceder. Conocéis alguna alternativa mejor para Mac OS X.

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

Cliente SSH para Mac OS X

Seguramente te habrá sorprendido que, según el servidor en que te encuentres, unas veces se te piden datos de acceso FTP para instalar y actualizar plugins o temas, y otras veces el proceso es automático sin preguntarte nada.

Pues bien, si te parece un engorro tener que andar poniendo los datos de ftp, que de paso es un fallo de seguridad si usas un ordenador compartido ya que el navegador almacena las contraseñas, puedes evitarlo de dos maneras, tu eliges cual:

Auto FTP

Con este plugin, una vez lo instalas y activas, solo tienes que añadir tus datos de acceso FTP para que ya no tengas que volver a introducir estos datos cada vez que quieras instalar o actualizar plugins y temas. Ahora bien, el problema de seguridad sigue ahí, pero en comodidad ganas un rato.

WP Config

Mucho mejor es definir unas variables nuevas en el fichero de configuración de WordPress wp-config.php. Solo tienes que añadir las siguientes líneas:

Como siempre, tu eliges.

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía Windows Live Writer

¿Te gustó este post? ¡Compártelo!

Bueno, ya sabemos que hay que hacer copia de seguridad con regularidad ¿no?. Lo que pasa es que hay veces que se nos olvida. Pero imagina que te cargas algo y no dispones de un backup reciente ¿a que duele?.

Principalmente, como hemos dicho en varias ocasiones, hay que hacer copia de seguridad – preferentemente – de dos cosas:

• la base de datos, que es donde están las configuraciones y el contenido
• la carpeta wp-content, donde están los plugins, los themes y los archivos que hayas subido.

Si dispones de acceso a phpMyAdmin en tu servidor puedes hacer backups muy fácilmente. PhpMyAdmin tiene una función de Exportar que hace copia de toda la base de datos, una tabla, lo que quieras.

Eso si, si tu base de datos es muy grande entonces deberías usar otra herramienta de backup, normalmente disponible en el lado del servidor, si tienes acceso a sistemas como CPanel o Plesk.

Por otro lado, para los más avanzados, puedes usar SSH, del que ya he hablado, y que una vez controlas facilita enormemente las copias de seguridad, y otras acciones.

Para hacer backup con SSH solo tienes que acceder con tus datos (normalmente los datos FTP), moverte en línea de comandos a la carpeta donde quieras hacer backup y, una vez ahí, ejecutar este comando:

mysqldump –opt -u dbuser -p dbname> dbname.sql

Con esto reemplazas el dbuser y dbname con el tuyo. Ahora solo queda comprimir el backup:

gzip -c dbname.sql>dbname.sql.gz

Una vez hecho esto ya queda menos, pero también puedes hacer los dos pasos anteriores en solo uno así:

mysqldump –opt -u dbuser -p dbname> dbname.sql | gzip > ficheroresultante.sql.gz

Ahora ya tienes hecho el backup de la base de datos. Si hiciste bien los pasos anteriores la tendrás en un zip y en SQL

Lo siguiente es comprimir la carpeta wp-content:

zip -r wp-content-backup-Dec-3.zip wp-content/

Esto pone todo lo que haya en wp-content dentro de un zip. El modificador '-r' es precisamente el que usamos para que “recoja” todas las subcarpetas.

Luego podemos subir el zip a la carpeta de backups, por ejemplo:

mv wp-content-backup-Dec-3.zip ../backups

Si hacemos esto de vez en cuando, y no te preocupes por los comandos, puedes copiarlos y pegarlos en la ventana de comandos, tendrás backup de tu sitio a buen recaudo.

¿Te gustó este post? ¡Compártelo!

Son muchas las ocasiones en que surgen problemas provocados por unos permisos inadecuados de carpetas o archivos en WordPress, es por ello que he creído interesante hacer esta pequeña aclaración de los permisos correctos y/o recomendables que deben tener los mismos.

La regla básica sería esta:

1. Para garantizar la seguridad de los archivos mantenlos en 644
2. Para garantizar la seguridad de las carpetas mantenlas en 755
3. Si por algún motivo debes modificar un fichero o dar permisos de escritura a una carpeta cámbialos a 666 y comprueba que funciona
4. Si falla lo anterior pon el archivo o carpeta en 777 y haz lo que tengas que hacer
5. Una vez hayas terminado SIEMPRE devuelve los permisos a 644 o 755, según el caso
6. Hay algunas excepciones a tener en cuenta

Los modos de cambiar los permisos serían los siguientes:

• Panel de tu proveedor de alojamiento

Casi todos los proveedores de hosting facilitan algún explorador de carpetas mediante el cual puedes cambiar permisos a ficheros y carpetas, además de realizar tareas de edición y algunas otras cosas.


• Cliente de FTP

Normalmente mediante el menú de clic derecho o barra de menús puedes acceder a la información de archivos y carpetas y ahí cambiar los permisos. En el caso de Transmit, el que yo uso, se cambian así:


• Línea de comandos

Usando el comando chmod, si tienes acceso SSH a tu alojamiento, puedes cambiar los permisos de cualquier archivo y/o carpeta con el siguiente comando:

chmod [modificadores] permisos archivo/directorio

Tienes información completa de como hacer el chmod en este enlace del CODEX.

¿Te gustó este post? ¡Compártelo!