texto

Resumen

  1. Status del sitio
  2. Backup con toolkit
  3. Análisis de updates
  4. Clonación
  5. Actualización
  6. Pruebas 1
  7. Sincronización
  8. Verificación
  9. Pruebas 2

Plesk

Este manual incluye las imágenes correspondientes a Plesk versión 3.18.

Nota: El color azul es el color distintivo de esta versión 3.0 aunque las imágenes pueden variar, en su pantalla por este manual te puede ayudar a resolver las mismas tareas, pero con variaciones en los nombres de las acciones según la versión de Plesk que esté corriendo tu servidor web.

1. STATUS DEL SITIO

Al verificar el estado actual de tu sitio obtendrás la información actual del estado de tu sitio.

Al momento de entrar a tu panel de control Plesk verás los accesos y versión de tus aplicaciones, sus temas y plugins así como los accesos a múltiples herramientas asignadas por dominio.

  

Con los accesos asignados por dominio y por aplicación podrás editar y conocer las versión actual en el dominio de la versión de tu plan de hosting, PHP, MySQL, y muchas otras opciones que vienen integradas en el Toolkit para WP de hospedalia. 

Sitio vulnerable y actualización de software

Si tu sitio no tiene la última actualización de versiones de WP, temas y plugins que integran tu sitio, este puede ser objeto de vulnerabilidades en los sistemas, mismos que se van resolviendo conforme se actualizan las versiones de cada software. 

Para mantener tu sitio al día y evitar ataques debes considerar actualizar los siguientes elementos constantemente y según se vayan dando sus respectivas actualizaciones. 

Importante: Antes de hacer una actualización es importante que crees un punto de respaldo de tu sitio. 

Puntos de respaldo

Generar una copia actual de tu sitio es muy sencillo usando Toolkit para WP de Plesk. Sólamente tienes que generar un punto de respaldo y una copia de tu sitio actual y su configuración se guardará para que puedas proceder con cambios y actualizaciones que tu sitio pudiera necesitar. 

Copias Guardadas

Las copias de tu sitio se guardarán automáticamente en la carpeta home /wordpress-backups de tu cuenta de hosting.

Generar copias de seguridad ocupa espacio de tu disco duro, por lo que siempre que hagas un respaldo debes verificar primero si tienes espacio para generar una imagen (respaldo) de tu sitio.

Verificar Espacio en el disco

Uso de recursos

Para verificar el uso de sus disco duro despliegue el tab “Uso de recursos” para conocer el estado de sus sistema en cuanto a los recursos ocupados y disponibles.

Recomendación para hacer un punto de respaldo o el clonado de un sitio el espacio disponible  en el host debe ser mínimo 3 veces el tamaño del sitio a clonar para poder proceder. Para conocer el tamaño de tu sitio deberás conocer el tamaño en bytes de la carpeta raíz.
(PLESK. Col. izquierda: menú principal; Col. derecha: widgets)

En el menú de la columna izquierda de Plesk, seleccionar la opción WordPress para acceder a todas las instalaciones de WordPress disponibles.






(Instalaciones de WordPress manejadas por Plesk)

NOTA: si no apareciera la instalación que necesitamos trabajar, en caso de que hubieran otras, debemos ejecutar un análizar para detectar la instalación que nos hace falta.


(Opciones. Botón ANALIZAR para detectar instalaciones WP)

  1. Dar click en Backup/restaurar.


(Opciones de Toolkit para el manejo de instalaciones WordPress)

  1. Dar click en el botón Backup o Restaurar (según se llame) 
  2. Esperar a que termine el proceso. 

El backUp estará disponible para su uso en el listado. Los respaldos se guardaran en un carpeta del sistema Plesk “wordpress-backups” 

  1. Una vez en la pantalla de listados de los puntos de respaldo o backups.
  • En caso de querer  restaurar un punto de respaldo  haga clic en el icono  
  • También puede  descargar un copia dentro de un archivo archivo haga clic .zip icono  
  • Para eliminar una copia anterior solo debe hacer clic en el icono


(Listado de copias de seguridad recientes)


(Listado de backups comprimidos en archivos .zip dentro de la carpeta wordpress-backups)

IMPORTANTE: si el backup falla, se recomienda eliminar los archivos temporales que Plesk crea, porque si intentamos otro backup, el espacio puede agotarse rápido y el servidor caer, dejando fuera de línea al sitio. Hay que revisar dentro de la carpeta .wp-toolkit la subcarpeta más reciente, verificar que contenga la copia temporal y eliminarla.



(Carpeta .wp-toolkit con subcarpetas de copias temporales de backups)

3. ANÁLISIS DE UPDATES

Verificación del status del sitio Web WP para saber cómo está actualmente en lo visual, y que UpDates se realizarán a nivel técnico.

Usando el Toolkit se hace una verificación de versiones de software y la seguridad en WP.

  • Para las Actualizaciones se muestra un listado

El botón “configuración de actualización”, por defecto muestra estos valores (recomendados)

  • De acuerdo al resultado de los UpDates necesarios se verifica la compatibilidad de versiones de software en el Host: PHP, MySQL, y parámetros solicitados por el tema: input_vars, memory_limit, etc. En Plesk se accede a la sección de PHP info.

4. CLONACIÓN

Utilice Toolkit de WP de Plesk para crear un clon del sitio actual por staging.
(según la versión de Plesk puede haber funciones no disponibles):
Clonación, sincronización (copiar datos), Restore Point, BackUp & Restore, Indexación en buscadores (debe estar deshabilitado para el clon), Ajustes automáticos de seguridad, modo mantenimiento, Auto Updates Automatizado, entre otros.

  1. Entrar al Plesk del Host y verificar el espacio en disco disponible en el host, este debe ser mínimo 3 veces el tamaño del sitio a clonar. (esta se puede ver a la derecha del panel en la sección principal)
  2. Si tenemos espacio suficiente, entrar a la sección “WordPress” (WP Toolkit)
  3. Verificar que la instalación WP actual o de producción esté etiquetada como tal. La nueva instalación (clonada) y que será de pruebas la podemos etiquetar como “test” o “pruebas” en la barra del título del sitio, la cual se puede mostrar así:



  1. Crear el clon en un subdominio disponible, usando la opción “Clonar” en la instalación deseada.
    NOTA: Por defecto las nuevas instancias de VPS en hospedalia se llaman “staging”. En caso de no haber subdominios disponibles se debe solicitar uno a Hospedalia antes de empezar a clonar.
  2. En las siguientes opciones, vamos a seleccionar “Usar dominio o subdominio existente”. Desplegar la lista con los dominios/subdominios existentes del cual tendremos que seleccionar el subdominio “staging” o el que necesitemos en caso de ser otro.
  3. Para el nombre de la base de datos vamos a usar la nomenclatura “wp_subdominio_fecha”. Aunque no se siga, es importante al menos indicar a qué instalación corresponde esta nueva base de datos. Ejs:
  • wp_dev_2020-12-02
  • wp_staging_2021-03-18 (Identificador WP+instancia+Año-Mes-Día)
  1. Damos clic en el botón “Iniciar”, y se empezarán a copiar los archivos de la instalación original, la base de datos y los archivos de configuración para la nueva instalación (clonada).
  1. Una nueva instalación aparecerá en el listado de sitios WP, obviamente el contenido de la instalación estará en el subdominio indicado antes, se etiqueta para su identificación y se procede a realizar las actualizaciones de Plugins, Temas y Core WP según se necesite y/o pueda.


5. Actualización

Las actualizaciones corresponden a  tres niveles en un desarrollo de CMS’s como WordPress:

  1. Core de WordPress
  2. Los plugins
  3. Tema en uso

Orden recomendado para aplicar actualizaciones

Aunque se pueden hacer por partes, el orden sugerido para actualizar debe ser según el grado de vulnerabilidades:

  1. Plugins
  2. Core WordPress
  3. Temas

5.1 Vía herramienta de UpDate del Toolkit de WP en Plesk

Se puede hacer una verificación y actualización desde el Toolkit y activar la función de Restore Point (punto de restauración) para hacer rollback en caso de algún problema.

NOTA: No he hecho la prueba de hacerlo desde aquí, tenemos en este Host una versión obsoleta de PHP y MySQL, por lo que descartaría el UpDate de WP y el tema, que en este caso es AVADA.

5.2 Vía directa en WP

También se puede hacer entrando al BackEnd de WP y realizar a mano los UpDates, se debe verificar primero la compatibilidad de cada componente, y realizar los UpDates que se puedan. Ciertos Themes requieren desactivar componentes antes de su UpDate como AVADA. Vea la documentación de Themefusion AQUI

  • Se pueden ir haciendo los UpDates por lotes, es decir actualizar plugins y detalles menores como: parches en temas, y plugins, sincronizar a producción, y después continuar con UpDates mayores como: Core WP, Temas, para después volver a sincronizar. Tome en cuenta que puede tener versiones de PHP diferentes en subdominios (en Hospedalia). Cerciórese de que las versiones de PHP estén configuradas como corresponda.
  • Primero deben actualizarse los Plugins antes de hacer un Updates del Core de WP y Tema(s).

6. PRUEBAS 1

Una vez realizado el proceso de actualización, se deberán realizar las pruebas mínimas antes de sincronizar a producción. Estas tareas se deben realizar en compañía del desarrollador del sitio, porque es quien sabe cómo se hizo el sitio web.

  • Carga del sitio y su correcta navegación tanto FrontEnd como BackEnd
  • Comparar la visualización o look del sitio clonado y actualizado con el sitio original o los screenshots que se lograron antes del proceso de actualización
  • Guardar cambios en páginas (ediciones aleatorias)
  • Guardar cambios en configuraciones del WP
  • Probar a hacer cambios en los theme options, verificar si se puede editar y grabar código CSS nuevo
  • Probar cambios en la configuración de plugins (aleatorio)


Verificación y mejora de Seguridad usando el Toolkit de WP en Plesk (verificar con José si vale la pena o solo con el Wordfence)

  • Usando el toolkit se activan los parámetros de seguridad más críticos, la mayoría de ellos puede revertirse (está indicado), y cada parámetro tiene detalles. Un parámetro que no es revertive a través del toolkit es “Restringir acceso a archivos y directorios” >  Si los permisos de acceso para archivos y directorios no son suficientemente seguros, es posible que los hackers puedan acceder a estos archivos y usarlos para poner en riesgo la seguridad de su sitio web. Esta medida de seguridad establece los permisos para el archivo wp-config a 600, para los demás archivos a 644 y para los directorios a 755.

7. SINCRONIZACIÓN

Toolkit permite sincronizar (copiar datos) los archivos y la base de datos juntos o por separado, del sitio de pruebas con el sitio en producción.

  1. Usando el botón de “copiar datos” de la instancia de desarrollo o pruebas (staging), se sincroniza la instalación de desarrollo a producción, seleccionado la configuración deseada: archivos y BD que cambiaron. Se puede activar la opción de Restore Point en caso de ser necesario, recuerde que ya se hizo un respaldo del sitio anteriormente.

8. VERIFICACIÓN DE CARGA DE RECURSOS

Antes de continuar con las pruebas finales, se debe verificar que los recursos siempre carguen desde el dominio en producción. 

Debemos verificar que https://produccion.com no esté cargando imágenes u otros recursos, por ejemplo, de https://staging.produccion.com u otra url. Si no verificamos esto y lo corregimos, es posible que el sitio falle o no funcione correctamente cuando se elimine del servidor el clon (staging) o subdominio utilizado para realizar el proceso de actualizaciones, ya que esos recursos no estarán disponibles, pudiendo hacer que se dañe la estética como que el sitio quede fuera de línea o se comporte extraño.

8.1 CORRECCIÓN DE CARGA DE RECURSOS

Se hará mediante un SEARCH & REPLACE de la url vieja a la url nueva en la base de datos, por medio de un plugin.

  1. Realizar un backup de la base de datos <- MUY IMPORTANTE
  2. Instalar un plugin de SEARCH & REPLACE, recomendado el de Inpsyde GmbH
  3. Ir a Tools (Herramientas) -> Search & Replace
  4. En la pestaña Search & Replace en el campo Search for: escribir la url antigua; en la pestaña Replace with: escribir la url actual (el dominio actual)
    ATENCIÓN: colocar ambas URLs con la misma estructura, por ejemplo:
    https://staging.produccion.com
    https://produccion.com
    – o –
    https://produccion.com/beta
    https://produccion.com
  5. En SELECT TABLES, activar la casilla Select all tables
  6. Dejar DRY RUN (simulacro) activado para simular búsqueda y reemplazo
  7. Click en el botón Do Search & Replace. La página se recargará
  8. Luego veremos cuántas tablas y registros serán afectados, para repetir el proceso pero esta vez haciendo cambios reales en la base de datos.
  9. A continuación quitamos el check de DRY RUN y seleccionamos Save changes to Database
  10. Dar click al botón Do Search & Replace para que esta vez se escriban los cambios en la base de datos.
  11. Al terminar el proceso, hacerlo una vez más para estar seguro de que no queden registros sin actualizarse.
  12. Revisar los links a mano, ya que en muchas ocasiones, y dependiendo del theme o plugin instalado en el sitio, algunos no se actualizan, y se tendrán que actualizar forzados manualmente. Por ejemplo, entrar en la página, editar el link o la url del recurso como imágenes de fondo que no se muestran porque se están cargando de la url antigua.
  13. Al finalizar realizar un backup POST REEMPLAZO.

NOTA: en caso de que ocurran errores 500 o supuestos del servidor, desactivar el plugin utilizado y probar con otro.

NOTA 2: Después de esto se debe vaciar el caché del tema, del servidor, y del navegador.

9. PRUEBAS 2

  • Verificación de que todo esté OK en el sitio ya actualizado en producción en BackEnd y Front End
  • Carga del sitio y su correcta navegación tanto FrontEnd como BackEnd (Navegación, contenido, Sliders, vDesktop & Móvil)
  • Guardar cambios en páginas (ediciones aleatorias)
  • Guardar cambios en configuraciones del WP, tema y plugins (aleatorio)
  • Cambio de idioma
  • Probar que funcionen correctamente los forms de contacto. Enviar pruebas al cliente
  • Que la indexación del sitio esté activa
  • Eliminación de Clon del servidor usando la función eliminar desde la sección de WP de Plesk. Se debe eliminar la BD asociada también activando esa opción. 
  • Debe hacerse una limpieza de los archivos residuales, estos son aquellos que no pertenecen al árbol original de archivos nativos de WP.
  • La eliminación del respaldo del sitio el producción que se hace al inicio se debe conservar hasta la siguiente actualización.

Nota. Se debe considerar que si se desea regresar al Restore Point, no deberán hacerse cambios al sitio, ya que podría haber discrepancias que no sean soportadas por el respaldo y este no pueda realizarse. 

Pueden descargarse los archivos comprimidos del restore point (files & DB) en la carpeta “.wp-toolkit” > areSnapshots.

  • Actualización de sheet de control
    • Fecha de UpDate y próxima fecha de actualización
    • Versiones de Software
    • Notas en caso de que quede algo pendiente, marcándolo con color y agendando el trabajo en ASANA

Clonación de WP Manual (sin toolkit de Plesk). En desarrollo

  • Entrar al Plesk del Host y verificar el espacio en disco disponible en el host, este debe ser x3 el tamaño del sitio a clonar. (se muestra a la derecha del panel en la sección principal)
  • Personalmente creo un usuario distinto pero con la misma contraseña de usuario igual al de la base de datos principal (la configuración está en wp-config.php).
  • Importa el respaldo de la base de datos principal en la base de datos utilizada para beta.
  • Entra a phpMyadmin de la base de datos beta y abre la tabla que termina en _options (por defecto wordpress tiene como prefijo de las tablas como wp, pero para estos proyectos, se utilizan prefijos personalizados). Luego cambia los urls de la columna option_value donde la columna option_name tenga el valor de site url y home. Los urls nuevos se cambiarán a donde se encuentra la carpeta beta. Ejemplo: si el url es http://misitioweb.com, los valores de option_value será http://misitioweb.com/beta
  • borra la caché del explorador o entra en modo incógnito para evitar problemas con la versión anterior
  • A veces sucede que wordpress viene con un .htaccess, si es así, hay que editarlo para que pueda entrar a la carpeta de beta y no vaya a la pagina de producción. Ve a la carpeta de Beta en el panel o por ftp, y edita el archivo .htaccess. FALTA
  • Es posible que los css y js estén asociados a la carpeta principal, así que será importante borrar estos datos de la caché de wordpress y avada. Para esto, ir al menú Avada > theme options > advanced > Dynamic css & JS y pulsar reset fusion caches.
  1. Actualizar wordpress y plugins
    • ve a escritorio > actualizaciones y actualiza wp.
    • Es probable que el editor de fusion builder no funcione, ya que este no está hecho para el nuevo editor de wordpress. Así que es necesario instalar el editor antiguo.
      ve a Plugins y busca un plugin llamado Classic Editor. Descargalo y activalo. Luego intenta editar una pagina a ver si el editor de Fusion ya funciona correctamente.
    • Luego actualiza los plugins restantes probando uno por uno para verificar que esté todo instalado correctamente. 
    • Limpieza de plugins y temas que no se estén ocupando

Checklist:

WooCommerce

Posibles errores con Avada:

Al actualizar avada y wordpress, puede suceder que al ir a Avada > Theme Options > Blog no se puedan ver las opciones del blog. Esto es un error que tiene avada y se puede solucionar agregando una función al tema hijo.

Hay que ir al link appereance > theme editor > functions.php y agregar esta sección de codigo:

add_action(‘admin_head’, ‘wp_color_result_disable’);

function wp_color_result_disable() {

echo ‘

‘;

}

A veces el editor no permite cambiar ese código puesto que está protegido. Por  lo que hay que ir a la carpeta del subchild de AVADA por ftp o el panel para poder editar el codigo.

Personalización Avanzada Avada

Avada es un tema muy versátil cuando hablamos de editar sus componentes visuales. 

Primero hay repasar un concepto esencial para la edición y aplicación de estilos o CSS (Cascade Style Sheet) conocida como “hoja de estilos” generalmente o sólo se le dice “estilos”. 

Avada contiene por su estructura e implementación con WordPress estilos que corresponden a distintas áreas. Muy importante tomar en cuenta que los estilos de los Plugins podrían venir estar en otra hoja de estilos o dentro de alguna función de otro lenguaje de programación como JS. 

Este apartado ha sido pensado para poder aplicar estilos predefinidos a cualquier elemento de la página. 

El navegador interpreta estos estilos según van apareciendo, dejando a los estilos que se leen primero inválidos si un estilo del mismo nombre sobre escribe al momento de que el navegador interpreta y aplica el estilo sobre el elemento HTML.

Ejemplo de cómo lee el navegador los estilos:

  1. Estilos de WP
  2. Estilos de Avada
  3. Estilos Personalizados de Avada
  4. Estilos por página (Esto puede hacerse desde las opciones de Fussion Builder o hay plugins que te dejan agregar scripts en el header para que puedas poner en este caso estilos o scrips de JS.
  5. Los estilos In-Line

En otras palabras Inline sobrescribe cualquier estilo anterior. Esto puede ser una solución muy práctica a la hora de editar un elemento gráfico, pero sus desventajas es que no puede hacer una regla especial para dispositivos móviles y para cambiar sus características hay que hacer en cada lado donde se declaró ese estilo in-line.

Ejemplo 

In Line (Vista en Código o  HTML)

El conejo veloz salta por la vereda.

Declarando Clase (Vista en Código o  HTML)

El conejo veloz salta por la vereda.

En este caso los parámetros de la clase “MiEstilo” deben ser declaradas en la hoja de estilos.

.MiEstilo {

color:red;
font-size:20px;

}

Declaración de Estilos

La declaración de estilos se puede hacer en diversos lugares, no obstante este documento habla sobre los dos lugares donde son más efectivos y prácticos.

Declaración en opciones de tema en Avada. Afecta todo el sitio completo. A veces no funciona.


Mi Sitio > WP-Admin > Avada > Opciones de Tema > CSS Personalizado.

Declaración en header de una hoja en particular. Afecta sólo la pagina en donde se declaró.

En las opciones de layout en Fusion Builder en cualquier edición de página.

En las opción con el icono </>.

Guardar los cambio de la página al final.