Migrar wordpress multi-site a sigle-site Blackhold

En este post de hoy vengo a cagarme con según qué tipo de clientes. Vas de persona cercana, lo explicas todo, creas contenido nuevo específicamente para ellos, ¿para qué? pues para terminar como una gilipollas y encima que te insulten.

He tenido una mala experiencia con un cliente que pidió una página web con unas características, terminaron siendo dos y la segunda 4 veces más grande de lo inicialmente pactado. Con la web terminada (porque corría prisa la cosa), le dije que sería justo que aportase un poco más y simplemente se negó. Así que yo me negué a seguir manteniendo su wordpress si no pagaba por las modificaciones que me pedía a partir de aquella fecha. Como no le gustó esto de pagar más, le di todos los datos y espabílate… el espabílate terminó siendo más mierda, porque se pilló un informático que puede ser un mega-hyper-super-crack de wordpress por delante, pero realmente como funciona por detrás, ni puta idea, además de que no sabe ni siquiera que es el fichero /etc/hosts. Lo ayudas y encima termina insultándote porque las cosas no le son fáciles como a él le gustaría. Chaval, creo que te queda bastante barro que comer y a ver si bajas un poco estos humos. Ya que he tenido que estar perdiendo tiempo explicándote como tienes que hacer tu trabajo, hago este post para explicárselo a otras personas que a lo mejor si van a valorar mucho más esta información.

No me gusta hablar mal a la gente y tengo mucha más paciencia de la que debería tener. Esta vez lo explico para que a otras personas no os ocurra lo mismo y sobre todo, cuando te estén haciendo trabajar gratis, plazos de “para ayer” y encima te insulten, mi recomendación es haz lo posible para alejarte de esto, va tu salud y prestigio en ello.

Tras este minuto de odio, empiezo:

Hace años que administro wordpress, desde sus inicios, haciendo aportaciones en las versiones 2 y 3. En este blog he ido haciendo posts sobre el tema. Hace años que vi que esto de mantener sitios de wordpress sueltos es un nido de virus y de problemas. Me venía la gente llorando porque al no tener un wordpress actualizado les habían entrado y roto su página web. ¿los backups? pues… brillando en su ausencia. En aquel entonces y con varios CMS más como drupal, mediawiki, con wordpress hice lo mismo, aún no estaba disponible la posibilidad de wordpress multisitio en aquellas versiones, pero por suerte años más tarde, apareció la posibilidad de usar varios sitios en una misma instalación de wordpress de forma nativa.

Hoy veremos dos formas de migrar un sitio que está alojado en un wordpress multi-site (multisitio) a un sigle-site (sitiounico).

Opción 1: A pelo
Lo primero será hacer un dump de la base de datos del sitio que queremos exportar, en mi caso, el número 37.

[email protected]:~# mysql wp_lmdb -N -e 'show tables like "wp\_37\_%"' | xargs mysqldump wp_lmdb > 2022_01_10-wordpress-37.sql

Exportaremos también el o los usuarios que estén vinculados a este sitio

[email protected]:~# mysqldump wp_lmdb wp_users --where="ID='1001032'" > 2022_01_10-wordpress-users.sql
[email protected]:~# mysqldump wp_lmdb wp_usermeta --where="user_id='1001032'" >> 2022_01_10-wordpress-users.sql

Atención con el segundo dump, es >>

A continuación copiamos los temas y plugins necesarios que se encuentran en el directorio [root_wordpress]/wp-content/plugins y [root_wordpress]/wp-content/themes/, siendo [root_wordpress] el directorio donde se aloja nuestra instancia de wordpress.

También copiaremos los uploads que se encuentran en /wp-content/uploads/site/37/

Ahora lo dejamos todo estructurado de esta forma:

[email protected]:~# tree -L 2
.
├── 2022_01_10-wordpress-users.sql
├── 37
│   ├── 2022_01_10-wordpress-37.sql
│   ├── plugins_temas.txt
│   └── uploads
│   ├── 2021
│   ├── 2022
│   ├── elementor
│   ├── essential-addons-elementor
│   ├── wpcf7_uploads
│   └── wp-statistics
├── plugins
│   ├── akismet
│   ├── classic-editor
│   ├── contact-form-7
│   ├── contact-form-7-to-database-extension
│   ├── cookie-law-info
│   ├── elementor
│   ├── elementor-pro
│   ├── jetpack
│   ├── multisite-plugin-manager
│   ├── query-monitor
│   ├── seo-by-rank-math
│   ├── under-construction-page
│   ├── user-role-editor
│   ├── varnish-http-purge
│   └── vcaching
└── tema └── hello-elementor

Ahora en el hosting donde vamos a montar el wordpress simple, hacemos una instalación de 0.
En la instalación nueva, el prefijo de las tablas será wp_nombretabla, en el dump que hemos hecho, las tablas se llaman wp_37_, así que tendremos que hacer un reemplazo.
Editamos el primer dump que hemos hecho y hacemos el reemplazo (hacemos lo mismo para el fichero de usuarios).

[email protected]:~/sitio_37/37# vi 2022_01_10-wordpress-37.sql
:%s/wp_37_/wp_
[email protected]:~/sitio_37/37# vi ../2022_01_10-wordpress-users.sql
:%s/wp_37_/wp_

Es posible que si estés montando el wordpress en un hosting de estos compartidos, el directorio donde se almacenarán los datos no será en el mismo que en el wordpress multi-site. En mi caso, el multi-site está en /var/www/wp/ y el del hosting compartido en /home/numerousuario/public_html/ así que tendremos que realizar otro reemplazo

[email protected]:~/sitio_37/37# vi 2022_01_10-wordpress-37.sql
:%s/\/var\/www\/wp\//\home\/v50zc4h755o8\/public_html\//g

Ahora vamos al wordpress nuevo y eliminamos todas las tablas excepto wp_config, wp_users y wp_usermeta. A continuación importamos el sql del sitio 37

[email protected]:~/sitio_37/37# mysql -f wp_lmdb 2022_01_10-wordpress-37.sql

Comentamos la parte de borrar y crear la tabla wp_options (para que el usuario actual pueda seguir modificando el sitio)

Ahora cogemos el fichero de usuarios, el segundo dump que hemos hecho y usamos solo los insert y lo importamos:

[email protected]:~/sitio_37# cat 2022_01_10-wordpress-users.sql |grep INSERT > 2022_01_10-wordpress-users-clean.sql
[email protected]:~/sitio_37# mysqldump -f wp_lmdb 2022_01_10-wordpress-users-clean.sql

Ahora copiamos el contenido de los temas, plugins y uploads en los sitios correspondientes:

[email protected]:~/sitio_37# cp -R tema/* /home/v50zc4h755o8/public_html/wp-content/themes/
[email protected]:~/sitio_37# cp -R plugins/* /home/v50zc4h755o8/public_html/wp-content/plugins/
[email protected]:~/sitio_37# mkdir -p /home/v50zc4h755o8/public_html/wp-content/uploads/sites/37/
[email protected]:~/sitio_37# cp -R uploads/* /home/v50zc4h755o8/public_html/wp-content/uploads/sites/37/

Si te fijas en la base de datos, los ficheros son almacenados en un sitio en concreto. WordPress guarda en la base de datos la ruta absoluta de los ficheros. Esto pasa tanto en los sitios multisite como en los single.

Y listos, sitio migrado.

Opción 2: Con un plugin

La otra opción es instalar un plugin que se llama prime mover. Esta opción tiene la desventaja que cierta información relativa a algunos plugins se puede perder y en realidad estás importando el sitio en lugar de migrarlo. Esta opción es mas adecuada para personas no demasiado experienciadas con el manejo por detrás de wordpress.

En el wordpress multisitio instalas el plugin y lo exportas.

Después en el wordpress simple, también lo instalas y lo importas.

Si te da errores, comprueba que la configuración del php memory_limit sea superior al tamaño total del fichero que se ha generado con el plugin.

Fuente obtenida de: https://blackhold.nusepas.com/2022/01/30/migrar-wordpress-multi-site-a-sigle-site/

Compartelo en las redes sociales

Compartir en facebook Compartir en google+ Compartir en twitter Compartir en pinterest Compartir en likedin Compartir en WhatsApp

Sobre Kamal Majaiti 1775 artículos
Administrador de sistemas e informático por vocación.

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*


Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.