Conectar moodle y wordpress

Hay algunas tareas de estas que se convierten en titánicas y no sabes muy bien el porqué y esta lo ha sido. Así que traigo este post para que otra persona que quiera montar este sistema no tenga que dar tantas vueltas y poder hacerlo a la primera :)

Hace unos meses que estamos preparando cursos bajo la marca escueladeeuropa. Los cursos la idea es montarlos en el LMS Moodle (learning management system), pero luego quedaba la cosa como los vendíamos… nos dijimos, sería chulo que los cursos se vendiesen solos a través de la página web hecha con wordpress… y ahí empezó la carrera.

Conectar wordpress y moodle es posible gracias a dos plugins, el primero edwiser y el segundo lmsace. El primero es mucho más intuitivo pero a la que quieres empezar a conectarlo con woocommerce, paga. El segundo… ¡ay el segundo! ¡vamos a verlo!

Concepto
La idea es que en tu moodle tienes unos cursos y en tu wordpress el woocommerce. Para conectar moodle y wordpress es necesario primero de todo crear los usuarios en wordpress que luego se crearán automáticamente en moodle. Esto se llama “user enrolment”.

Para conectar ambos programas será necesario instalar 1 plugin en wordpress y (atención) 2 en moodle! todo lo que necesitas saber lo encontrarás en la wiki de lmsace.

Moodle

Empezamos con moodle, será necesario instalar los dos plugins, lmsace-connect-moodle y lmsace-connect-moodleauth. El segundo aunque en la wiki pone que es opcional, hasta que no lo he …

Gestionar wordpress por terminal con wp-cli

Lo bonito de meterte en problemas es que para salir de ellos tienes que rebanarte los sesos para encontrar soluciones. Dentro de estas soluciones suelen aparecer metodologías, programas y funcionalidades nuevas. En el post de hoy, tras el marronaco del otro día, la herramienta que reapareció en mi terminal fue wp-cli (como los libros aquellos que has oído a hablar de ellos, pero un día aparece de nuevo y te lo comes como un sabroso manjar).

Este fin de semana pasado el proyecto de kaosenalred.net se ha reconvertido a lanueve.info. En su momento hice este otro post explicando como crawlear una página web con wordpress con httrack. El cliente, en lugar de esperar unas horas mas y arreglar el problema de su wordpress, decidió montar otro wordpress. En el lapso de tiempo de la web vieja y la nueva, en el nuevo wordpress han creado la friolera de 2600 entradas nuevas. A la hora de fusionar las dos webs había varias formas, la escogida esta vez ha sido usar Herramientas Exportar, lo cual te genera un fichero .xml (WXR) con las categorías, los autores, los medios y las entradas. Mi experiencia en importaciones de este tipo en el pasado ha sido que en blogs con mucho contenido es timeout y problemas asegurados, así que otra solución es wp-cli. wp-cli es un programa para gestionar instancias de wordpress.

Para instalarlo, descargaremos el fichero wp-cli.phar, le daremos permisos de ejecución y lo guardaremos al directorio /usr/local/bin/ como wp:

root@planet3D:~# curl 

Convertir una web con wordpress a estática con httrack

Hace unos días llegó a mí una de aquellas tareas que en teoría tenía que ser poquitas horas, las poquitas horas han terminado siendo casi un mes entero de trabajo.

La tarea encomendada era la de arreglar la portada de la página web del periódico digital de contrainformación kaosenlared.net.

La web estaba usando el tema publisher y la portada estaba construida con gutenberg, además para cachear la web se estaba usando el plugin W3 total cache. Una combinación del tema y los dos plugins mencionados hacían que se descuadrase toda la página. Por suerte se disponía de una copia de seguridad de un día anterior a que se rompiese la portada. Mi tarea fue pues reestablecer la configuración del tema desde las opciones de exportación y cargar el contenido de la página de la portada. Al arreglarlo y volver a poner la página en producción, a las pocas horas, la portada se volvía a descuadrar. El cliente pidió simplemente dar de baja esta web, hacer algo con los archivos y aprovechar para crear otra nueva que ya estaban usando como web de emergencia.

Así que mi propuesta fue arreglar de nuevo el wordpress y convertir la página web a estática, ya que la página web tenía un pequeño detallito de nada, la friolera de 407.000 entradas, cosa que hacía que el consumo de recursos de la web fuese espectacular, por la gran cantidad de páginas y usuarios que visitaban diariamente el sitio.

Lo primero pues fue copiar todo el …

ip real con frontal proxy nginx, backend apache y wordpress

Por fin he encontrado la solución! otra de estas tareas pendientes que hacía que una instalación no funcionase como era esperado! en este caso me encuentro con dos frontales de nginx que actúan como proxy http y detrás de ellos está un wordpress sobre apache. Hace un tiempo, hice un post similar a éste, pero detrás estaba otro nginx.

Así que aquí dejo la solución.

Frontal nginx
En este caso tengo 2 ficheros, el de la configuración del dominio y otro con la configuración específica para los wordpress almacenado en el directorio snippets

# vi /etc/nginx/sites-available/lamardebits.org
server {
    listen 80;
    listen [::]:80;

    server_name lamardebits.org
                www.lamardebits.org;
    return 301 https://lamardebits.org$request_uri;

    #root /var/www/html/;
    include snippets/certbot.conf;
}


server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name lamardebits.org;

    include snippets/certbot.conf;

    # Aquí s'inclou el servidor intern i la protecció específica de WP
    include snippets/wordpress10.conf;

    ssl_certificate /etc/letsencrypt/live/lamardebits.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lamardebits.org/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_trusted_certificate /etc/letsencrypt/live/lamardebits.org/chain.pem;
}

Y la configuración específica para los wordpress

# vi /etc/nginx/snippets/wordpress10.conf
include conf.d/external-log.conf;
location / {
    proxy_pass http://172.31.0.145:6081;
    include proxy_params;

    location ~ \.php$ {
        proxy_pass http://172.31.0.145:6081;
        include proxy_params;

        location ~* wp\-login\.php {
            client_max_body_size 40M;
            proxy_pass http://172.31.0.145:6081;
            include proxy_params;
            include snippets/lmdb-protected.conf;
        }
    }

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    fastcgi_read_timeout 300;
    proxy_read_timeout 300;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP       $remote_addr;
    proxy_set_header  X-Forwarded-For $remote_addr;
    proxy_set_header  X-Forwarded-Host $remote_addr;

    add_header X-Frame-Options SAMEORIGIN;

}

La configuración de proxy de nginx la tengo así

# vi /etc/nginx/conf.d/proxy.conf
proxy_buffer_size         128k;
proxy_buffers           4 256k;
proxy_busy_buffers_size   256k;
client_max_body_size      32M;

proxy_read_timeout 1800;
proxy_connect_timeout 1800;
proxy_send_timeout 1800;
send_timeout 1800;             

Backend apache + wordpress

A …

WordPress: migrar sitios de un multisite a otro

Pues la de hoy (de las últimas semanas mas bien), es la de que tengo que migrar los sitios de un wordpress multisite a otro. El multisite actual lleva muchos años en funcionamiento y tras toquetear hace unos años arrastro algunos problemas que espero que se solucionen con la migración de los sitios a otro wordpress multisite nuevo. Para hacer la migración ambos wordpress deben estar en la última versión y actualizados.

El wordpress multisite de origen lleva 10 años funcionando y hay mogollón de basurilla en la base de datos, sitios que ya no existen, usuarios que pasaron a mejor vida y tablas de plugins que ya no se usan. Además aprovecho para hacer limpieza de plugins y temas que ya no se usan.

Lo primero de todo es hacer un backup del sitio de origen, tanto de la base de datos como de los datos.

A continuación instalo el nuevo en un nuevo contenedor (servidor), en mi caso, lo configuro tal como indico en este otro post que hice hace unos días sobre como montar el varnish y el apache. Anoto que para hacer la instalación del multisite es posible e incluso por mi experiencia recomendable hacerlo sobre el varnish configurado, así nos daremos cuenta de si algo está fallando desde el principio. A fecha de hoy poner PHP8 no es buena idea, hay muchos plugins y temas que aún no están adaptados a esta versión de PHP, así que mejor usar la 7.3 o la 7.4.

Lo …

WordPress + apache + varnish + frontal nginx

Hoy os traigo un post completito sobre la parte de sistemas de WordPress.

Hace ya demasiados días que tenía pendiente la actualización de las debian que alojaban mi wordpress multisite y la base de datos mysql (que las tengo en dos contenedores separados). No digo las versiones porqué se me cae la cara de vergüenza :P

El wordpress que tengo en La Mar de Bits tiene por delante 2 frontales haciendo de proxy http con nginx (donde además hago la gestión de los certificados de letsencrypt y redirección de puerto 80 a 443). Éstos apuntan al puerto expuesto de Varnish (servicio de cache) dentro del contenedor donde está el wordpress (puerto 6081). El varnish apunta en el apache y el apache sirve en el puerto 80 las páginas web de wordpress.

Vamos un cristo para llegar al wordpress que no veas :)

Voy a ir detallando las configuraciones que tengo en cada una de las partes de esta máquina

nginx (frontales)

Estas dos maquinas son las que están expuestas a internet y comparten el directorio de configuración gracias a glusterfs.

Para exponer ambas maquinas en internet en bind lo hago así:

@                               IN      A       109.69.10.251
@                               IN      A       109.69.10.241
@                               IN      AAAA    2a00:1508:6000:501::a1
@                               IN      AAAA    2a00:1508:6000:501::a2

frontal                 1H      IN      A       109.69.10.241
frontal                 1H      IN      A       109.69.10.251
frontal                 1H      IN      AAAA    2a00:1508:6000:501::a1
frontal                 1H      IN      AAAA    2a00:1508:6000:501::a2

www                     1H      IN      CNAME   frontal

A continuación, en nginx para cada sitio del wordpress tengo un fichero de configuración similar a éste …

Traducir template de wordpress

Estoy administrando un conjunto de webs multiidioma con el template panaroma, tenía toda la web traducida pero se me resistían algunos textos que vienen incrustados en el tema. El otro día buscando llegué a una página de wordpress donde estaban los ficheros de traducción de dicho tema, así que si existían traducir el template era posible, pero ¿cómo?

Simple aunque poco documentado y después de estar paseándome entre los directorios de wordpress porfín he hallado la solución! :D

En wp-content/languages/themes/ se hallan los ficheros de traducción de cada uno de los temas, algunos temas al instalarlos te los dejan ahí, pero normalmente no y tienes que añadirlos manualmente. Haz un ls antes de preguntar nada mas!

Así que simplemente nos vamos a éste directorio y nos descargamos los paquetes de idioma .po y .mo de translate.wordpress.org que corresponda a nuestro tema. Si el tema no está como proyecto (o la traducción es tan mala que mejor meterle mano uno mismo), en el directorio languages del tema encontraremos el fichero .pot (template) para traducir nosotros mismos el tema.

Recuerdo vagamente las veces que he traducido software el uso de poedit un software para traducir programas y luego que pasarlo a .mo era un coñazo, así que os dejo ésta web (po2mo.net) para pasar los .po a .mo sin muchas complicaciones :)…

WordPress multi-site + JetPack

Todos los que tengáis un wordpress sabréis las ventajas de usar los plugins “de la nuve”, aquellos que te permiten estadísticas, filtros de spam, instalación de extensiones desde el cms, etc. etc. pero también tiene sus desventajas y es que dependes de wordpress.com.
Hace ya unos días el servicio con wordpress.com era un poco malo, pero parece que finalmente han desarrollado otra plataforma para gestionar todos estos plugins, el jetpack.

Lo primero que tendremos que hacer es descargar el jetpack de forma manual (cuando iba a instalarlo automáticamente no me dejaba conectar, ya que me decía que la clave API era incorrecta).

Jetpack te agrupa las distintas herramientas de “la nuve” en un menú nuevo en la barra izquierda, pero una vez instalado falta activarlo y aquí el problema :( Todo el rato me soltaba este mensaje:

Jetpack could not contact WordPress.com: token_http_request_failed. This usually means something is incorrectly configured on your web host. name lookup timed out

Liada con el plugin wp-stats y varios sitios

Muchas veces pienso en que tendría que meter alguna operación matemática medio compleja a los botones de formulario que aparecen en mi ordenador, pero bueno, a más fallos, más soluciones. No hay mal que por bien no venga.

La cuestión es que tenemos un wordpress con un porrón de blogs y queremos activar el plugin wp-stats para saber las visitas que recibimos y cosas de estas, pero por algun motivo y por alguna cuestión esotérica, un blog ha empezado a compartir estadísticas con otro blog (por lo menos, hasta el momento sabemos que es posible hehe), pero tenemos que separarlos.

¿Cómo lo hacemos?…

Resumir los feeds en wordpress

Pues aquí vengo con una gran mejora y un gran alivio para estos planets que me siguen, a partir de ahora ya no os voy a torturar más con mis posts quilométricos ;)

El secreto está en Opciones > Reading > For each article in a feed, show > Summary

Y ale a correr.…