Posted by planetawordpress on noviembre 19, 2012 Comentarios desactivados
Bueno, aviso que esto de WordPress en línea de comandos es friki, pero muy friki, nada para todos los públicos pero en cualquier caso una posibilidad más del ecosistema en que se ha convertido WordPress.
La interfaz de comandos para WordPress, o wp-cli, es una serie de comandos para gestionar instalaciones de WordPress y más cosas. Y es que con wp-cli puedes actualizar plugins, instalar WordPress, publicar entradas, prácticamente de todo y creciendo.
Ah, y no es un plugin, es un sistema que requiere una instalación propia que puedes hacer de varias maneras, a saber …
git clone --recursive git://github.com/wp-cli/wp-cli.git ~/git/wp-cli
cd ~/git/wp-cli
sudo utils/dev-build
Donde puedes reemplazar ~/git/wp-cli con lo que tu quieras.
Y en MAMP, XAMP, etc.
Si no hay un comando php disponible puedes tratar de encontrar un binario desde el que hacerlo:
./utils/find-php
Luego creas una variable de entorno llamada WP_CLI_PHP con la ruta que encuentre find.php
En un entorno UNIX podrías hacerlo añadiendo la línea siguiente a tu archivo .bashrc:
WP_CLI_PHP=/path/to/php-binary
Vale, muy bien, ya lo tengo instalado pero … ¿esto como se usa?
Pues vas a la carpeta raiz de WordPress:
cd /var/www/wp/
Si tecleas wp deberías ver una salida similar a esto:
Available commands:
wp blog create|delete
wp cache add|decr|delete|flush|get|incr|replace|set|type
wp comment create|delete|trash|untrash|spam|unspam|approve|unapprove|count|status|last
wp core download|config|is-installed|install|install-network|version|update|update-db
wp db create|drop|reset|optimize|repair|connect|cli|query|export|import
wp eval-file
...
See 'wp help <command>' for more information on a specific command.
A partir de ahí podemos, por ejemplo, instalar un plugin desde WordPress.org. Para no complicar el ejemplo elegimos el inútil Hello Dolly:
wp plugin install hello-dolly
Y lo que veremos será esto:
Installing Hello Dolly (1.5)
Downloading install package from http://downloads.WordPress.org/plugin/hello-dolly.1.5.zip ...
Unpacking the package ...
Installing the plugin ...
Plugin installed successfully.
Como ves, los comandos, una vez instalado, son realmente sencillos e intuitivos.
Otro ejemplo sería una instalación de Multisitio, donde tendríamos que darle a wp-cli el parámetro --blog par que sepa sobre qué sitio de la red se supone que debe actuar:
wp theme status --blog=localhost/wp/test
Y si es en una instalación en subdominio sería algo así:
wp theme status --blog=test.example.com
Si estás trabajando en el mismo sitio casi todo el tiempo puedes poner la url de ese sitio en un archivo llamado 'wp-cli-blog' que crearás en la carpeta raíz de tu WordPress:
echo 'test.example.com' > wp-cli-blog
A partir de este momento ya puedes llamar a wp sin el parámetro --blog:
wp theme status
La lista completa de comandos la tienes aquí, e incluso puedes crear más comandos en la cocina de wp-cli.
Bueno, como te avisé no es algo para usar a diario por cualquiera, pero si un modo genial de administrar un WordPress desde línea de comandos, por ejemplo a través de SSH, así que guarda por ahí el enlace para cuando tengas unos días tontos en los que no sepas en qué enredar con WordPress.
Posted by planetawordpress on octubre 16, 2012 Comentarios desactivados
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.
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:
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.
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:
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.
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.
Posted by planetawordpress on abril 13, 2011 Comentarios desactivados
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.
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á.
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á.
Posted by planetawordpress on mayo 14, 2010 Comentarios desactivados
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.
Posted by planetawordpress on marzo 29, 2010 Comentarios desactivados
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:
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.
Posted by planetawordpress on diciembre 3, 2009 Comentarios desactivados
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í:
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.
Posted by planetawordpress on agosto 5, 2009 Comentarios desactivados
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:
Para garantizar la seguridad de los archivos mantenlos en 644
Para garantizar la seguridad de las carpetas mantenlas en 755
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
Si falla lo anterior pon el archivo o carpeta en 777 y haz lo que tengas que hacer
Una vez hayas terminado SIEMPRE devuelve los permisos a 644 o 755, según el caso
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: