Si WordPress se selecciona como plataforma de destino, la preparación debe comenzar por identificar qué es realmente el sitio de origen. Una misma instalación de WordPress puede funcionar como publicación, sitio de documentación, sitio de marketing, entorno de membresía, directorio, plataforma de aprendizaje, sistema de eventos o CMS alrededor de una Store de WooCommerce. Los Posts y CMS Pages del núcleo pueden representar solo una parte del contenido operativo. Los tipos de contenido personalizados, taxonomías, metadatos, relaciones con medios, usuarios, tablas de plugins, bloques, diseños de constructores, redirecciones e identificadores externos pueden determinar si el sitio migrado sigue siendo editable y comprensible.
La preparación debe producir evidencia del origen, no suposiciones. Cada clase de registro importante necesita un propietario, un inventario o exportación, una muestra representativa y una condición de preparación. El contenido del núcleo de WordPress debe mantenerse separado de los datos de aplicaciones propiedad de plugins, y la preparación del CMS WordPress debe mantenerse separada de la preparación de Products, Customers y Orders de WooCommerce.
Confirmar el alcance de WordPress y los propietarios de los registros
Primero, defina qué registros de origen pertenecen al núcleo de WordPress, cuáles pertenecen a plugins o código personalizado, cuáles permanecen en sistemas externos y cuáles se excluyen de forma intencionada. Este límite evita que la migración trate cada fila de la base de datos de WordPress como contenido ordinario.
WordPress almacena varios tipos de contenido en la infraestructura de posts, pero el tipo de contenido sigue determinando la finalidad editorial, la administración, las plantillas, las capacidades, los archivos y el comportamiento de la API. Las taxonomías personalizadas también necesitan sus registros y relaciones con objetos; los metadatos necesitan el plugin, tema o código que interpreta sus claves y valores.
| Acción de preparación | Responsable | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|---|
| Definir la función prevista del sitio WordPress de destino | Propietario del sitio y responsable de contenido | Declaración de alcance de una página que cubra publicación, marketing, membresía, directorio, aprendizaje, comercio u otras funciones de aplicación | Cada clase principal de registros de origen tiene un propietario previsto en WordPress, un plugin, un sistema externo, un archivo o una exclusión. |
| Separar el alcance del CMS WordPress del alcance de WooCommerce u otras aplicaciones | Propietario del sitio y responsable técnico | Límite de entidades que enumere CMS Posts, CMS Pages, medios, usuarios, menús y Products, Orders, membresías, reservas o envíos propiedad de aplicaciones | Ningún registro de aplicación se considera una CMS Page o Post normal únicamente porque utilice tablas de WordPress. |
| Registrar la topología del sitio de origen | Responsable técnico | Lista de dominios, subdirectorios, sitios por idioma, red/sitios Multisite, entornos staging y URL públicas activas | El equipo puede identificar qué sitio o red es propietario de cada registro seleccionado. |
| Identificar los sistemas externos autoritativos | Responsable de integraciones | Mapa de identificadores de CRM, DAM, PIM, LMS, marketing, búsqueda, identidad o sistema documental | Las claves externas y los sistemas de registro que continuarán activos están documentados antes de comenzar el mapeo de campos. |
En Multisite, el identificador del sitio o blog forma parte de la propiedad del registro. Los usuarios pueden participar en toda la red mientras que Posts, CMS Pages, términos, opciones y muchos registros de plugins siguen siendo específicos de cada sitio. El paquete de preparación debe conservar ese alcance en lugar de combinar registros por título o ID numérico.
Asegurar el acceso al origen, las copias de seguridad y la evidencia del entorno
Una migración de WordPress requiere más que una cuenta de administrador. El contenido puede estar distribuido entre la base de datos, el directorio uploads, directorios de plugins, archivos del tema, archivos de idioma, almacenamiento de objetos, medios remotos y servicios externos. La preparación del acceso debe hacer recuperable el origen y permitir al equipo interpretar estructuras personalizadas.
| Acción de preparación | Responsable | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|---|
| Confirmar acceso de administración a WordPress | Administrador del sitio | Cuenta de administrador funcional y lista de áreas de administración restringidas | Se pueden inventariar los Posts, Pages, usuarios, medios, plugins, temas, menús y ajustes necesarios. |
| Crear una copia de seguridad completa del origen | Responsable de hosting o técnico | Copia fechada de la base de datos más archivos de wp-content, uploads, temas, plugins y referencias de configuración cuando estén disponibles |
Se registran ubicación, fecha, responsable de restauración y período de retención de la copia. |
| Capturar los detalles del entorno | Responsable técnico | Versión de WordPress, versión de PHP, versión de base de datos, tema activo, tema hijo, plugins activos, must-use plugins y servicios de servidor relevantes | El entorno de origen puede reconstruirse en la medida necesaria para comprender la propiedad de contenido y plugins. |
| Registrar procesos programados y en segundo plano | Responsable del plugin o integración | Eventos WP-Cron, planificadores externos, colas, endpoints webhook y procesos por lotes que crean o actualizan registros | Se conocen los procesos automatizados que escriben datos y no se confunden con contenido estático migrado. |
| Conservar evidencia de exportación | Responsables de contenido y técnicos | Archivos de exportación de WordPress cuando sean útiles, inventarios de base de datos/tablas, listas de archivos multimedia y exportaciones específicas de plugins | Cada área de datos seleccionada tiene un artefacto de origen recuperable o una ruta de obtención documentada. |
El exportador integrado de WordPress puede aportar evidencia útil del contenido, pero no es una copia de seguridad completa del sitio y no representa automáticamente cada tabla de plugin, opción, archivo multimedia, dependencia del tema o registro externo. Por tanto, el paquete de preparación debe diferenciar las exportaciones de contenido de la evidencia completa de recuperación.
Inventariar Posts, CMS Pages, tipos de contenido personalizados y estados del ciclo de vida
Enumere todos los tipos de contenido que contienen registros, no solo los que aparecen en el menú principal de administración. Incluya Posts y CMS Pages estándar, archivos adjuntos, revisiones cuando se conserven y cada tipo de contenido personalizado registrado. Para cada tipo, documente su finalidad empresarial, cantidad de registros, estado público o privado, funciones del editor, relaciones padre, autoría, fechas, comportamiento de archivo y plugin o código responsable.
| Área de registros | Evidencia que debe prepararse | Decisión que debe resolverse | Condición de preparación |
|---|---|---|---|
| Blog Posts | Muestras con autores, fechas, extractos, Categories, etiquetas, comentarios, imágenes destacadas y contenido insertado | ¿Qué historial, borradores, registros programados, registros privados y archivos siguen dentro del alcance? | Los estados incluidos y excluidos del ciclo de vida están definidos explícitamente. |
| CMS Pages | Mapa padre-hijo, plantillas de página, uso en menús, formularios, elementos insertados y rutas de alto valor | ¿Qué jerarquía y dependencias de plantillas deben continuar? | Cada Page importante tiene un propietario en el destino y un estado padre o de nivel superior previsto. |
| Tipos de contenido personalizados | Fuente de registro, lista de campos, taxonomías, capacidades, configuración de archivos y registros representativos | ¿El destino conserva el tipo, lo convierte o lo mantiene en otra aplicación? | Cada tipo activo tiene una representación de destino y un responsable de edición. |
| Revisiones, autoguardados y papelera | Recuentos y justificación de retención | ¿Las versiones históricas tienen utilidad operativa o son solo historial de base de datos? | La retención es intencional y no se hereda por defecto. |
| Contenido privado o protegido | Responsable del acceso, audiencia y mecanismo actual de protección | ¿El acceso pertenece a roles de WordPress, a un plugin de membresía o a otro sistema? | Los registros protegidos tienen una identidad y una dependencia de permisos documentadas. |
Evite utilizar el número de registros como único inventario. Un tipo de contenido personalizado con veinte registros puede implicar más complejidad de migración que miles de Blog Posts ordinarios si depende de varias taxonomías, campos de relación, tablas personalizadas y archivos públicos.
Preparar taxonomías, términos, menús y relaciones de archivo
Las taxonomías de WordPress clasifican objetos; los menús organizan la navegación. Deben inventariarse por separado aunque una Category o término también aparezca en un menú. Para cada taxonomía, registre si es jerárquica o plana, qué tipos de contenido clasifica, si tiene archivos públicos, qué metadatos pertenecen a los términos y si existen etiquetas equivalentes en otra taxonomía.
| Acción de preparación | Responsable | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|---|
| Inventariar taxonomías estándar y personalizadas | Arquitecto de contenido o responsable del plugin | Nombres de taxonomías, tipos de objetos registrados, jerarquía, número de términos, metadatos de términos y configuración de archivos | Cada término seleccionado permanece conectado con la taxonomía y el tipo de objeto correctos. |
| Limpiar términos duplicados u obsoletos | Responsable de contenido | Lista de decisiones de fusionar, conservar, renombrar y excluir | Las etiquetas similares no se fusionarán salvo que representen la misma clasificación. |
| Exportar estructuras de navegación | Responsable de contenido | Árboles de menús principal, footer, utilidades, contexto y por idioma con enlaces personalizados | La ubicación de los menús queda documentada por separado de la jerarquía de contenido y la pertenencia a taxonomías. |
| Documentar destinos de archivos | Responsables de SEO y contenido | Lista de URL de archivos de Category, etiqueta, taxonomía personalizada, autor, fecha y tipo de contenido personalizado | Cada archivo importante tiene una decisión de destino, sustitución o redirección. |
Los ID de términos y elementos de menú son específicos de cada instalación. Cuando metadatos o registros del constructor hacen referencia a esos ID, la evidencia de preparación debe identificar la taxonomía, término, menú u objeto de contenido referenciado, no solo el número original.
Mapear metadatos, campos personalizados, opciones y tablas de plugins
Los metadatos pueden ser un simple valor editorial, una referencia a objeto, configuración serializada, datos de diseño, un identificador externo o estado de aplicación. Cree un inventario de claves para los post meta, user meta, term meta y comment meta importantes. Agrupe las claves por propietario y finalidad en lugar de intentar conservar cada clave técnica.
Los plugins también pueden crear tablas dedicadas cuando su dominio no encaja en las estructuras centrales de WordPress. Formularios, membresías, sistemas de aprendizaje, eventos, reservas, directorios, redirecciones, analítica e integraciones suelen utilizar tablas personalizadas para definiciones, transacciones, historiales o relaciones.
| Acción de preparación | Responsable | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|---|
| Inventariar claves de metadatos críticas para el negocio | Responsable del plugin y líder de contenido | Nombre de la clave, tipo de objeto, formato de datos, valores de muestra, finalidad visible para el usuario y tipo de objeto referenciado | Cada clave retenida tiene un campo de destino, propietario de plugin o propietario externo. |
| Identificar campos que hacen referencia a objetos | Responsable técnico | Muestras de ID de posts, archivos adjuntos, usuarios, términos e ID externos almacenados en metadatos | Las referencias pueden migrarse a objetos de destino en lugar de copiarse como ID numéricos obsoletos. |
| Registrar campos serializados o estructurados | Responsable del plugin o constructor | Ejemplos de esquema, repetidores, grupos, cargas JSON/serializadas y definiciones de campos | El destino puede interpretar la estructura o existe una decisión registrada para reestructurarla. |
| Inventariar opciones del sitio y plugins | Responsable técnico | Opciones relevantes para el negocio, plugin/tema propietario, alcance de sitio y clasificación como contenido o configuración | La configuración no se clasifica silenciosamente como contenido migrado. |
| Inventariar tablas personalizadas | Responsable del plugin y administrador de base de datos | Nombres de tablas, número de filas, claves primarias, relaciones padre, fechas, estados y claves externas | Cada tabla crítica para el negocio tiene un destino explícito, un sistema externo conservado, un archivo o una decisión de exclusión. |
Las cachés técnicas, registros temporales, registros técnicos, sesiones, índices generados y datos abandonados de plugins no deben incluirse solo porque existan. Su exclusión debe quedar registrada para que una comparación posterior de bases de datos no confunda una limpieza intencional con contenido perdido.
Preparar medios, bloques, constructores, temas y contenido insertado
La preparación de medios debe conservar tanto los archivos como sus referencias. Registre imágenes destacadas, imágenes insertadas, galerías, documentos descargables, recursos alojados externamente, pies de foto, texto alternativo, metadatos de archivos adjuntos y archivos reutilizados. Identifique archivos que existen en uploads pero ya no tienen referencias y referencias cuyos archivos faltan.
La presentación del contenido puede almacenarse como bloques del núcleo, HTML del editor clásico, shortcodes, widgets, bloques reutilizables, patrones, partes de plantilla, metadatos de constructores de páginas, opciones del tema o plantillas personalizadas. La implementación WordPress de destino puede no utilizar el mismo constructor o tema, por lo que la preparación debe separar el contenido reutilizable de los datos de diseño específicos del origen.
| Área de preparación | Evidencia que debe prepararse | Responsable | Condición de preparación |
|---|---|---|---|
| Biblioteca multimedia | Inventario de archivos, registros de adjuntos, texto alternativo, pies de foto, enlaces de imágenes destacadas, galerías y URL externas | Responsables de contenido y medios | Los archivos prioritarios están accesibles y cada referencia importante tiene un archivo de origen o propietario remoto conocido. |
| Bloques del núcleo y contenido clásico | Contenido representativo con enlaces, elementos insertados, tablas, bloques reutilizables y formato complejo | Responsable editorial | Se identifican los patrones de contenido que requieren conversión o reconstrucción manual. |
| Shortcodes | Inventario de shortcodes, plugin/tema propietario, páginas de ejemplo y salida esperada | Responsable del plugin | Cada shortcode crítico tiene un renderer que continuará funcionando o una decisión de sustitución. |
| Constructores de páginas | Versión del constructor, plantillas, secciones globales, almacenamiento de campos, dependencia del tema y diseños de muestra | Responsables de diseño y técnicos | El contenido reutilizable queda separado de los datos de presentación específicos del constructor. |
| Temas y partes de plantilla | Tema activo/hijo, plantillas personalizadas, áreas de widgets, partes de plantilla y estilos globales | Responsable de diseño | El código del tema se trata como evidencia de implementación y no como contenido ordinario. |
El artículo de WordPress no exige que el diseño final esté completo. Sí exige suficiente evidencia de propiedad para evitar que los datos de constructores, el código del tema, los shortcodes y el contenido reutilizable se mezclen en un único alcance de migración indiferenciado.
Preparar usuarios, roles, autores, comentarios y registros sensibles para la privacidad
Los usuarios de WordPress pueden ser autores, editores, administradores, suscriptores, miembros, alumnos, vendedores o Customers de otra aplicación. Los roles y capacidades del núcleo definen privilegios, mientras que los plugins pueden añadir roles, capacidades, perfiles, membresías e historiales. Inventarie por separado el rol y la relación con cada aplicación.
| Acción de preparación | Responsable | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|---|
| Clasificar poblaciones de usuarios | Administrador del sitio y responsable empresarial | Recuentos y muestras por rol, tipo de aplicación, estado activo, autoría y finalidad de la cuenta | Autores, personal, miembros, suscriptores y usuarios de aplicaciones no se fusionan únicamente por correo electrónico. |
| Registrar roles y capacidades personalizados | Responsable técnico | Definiciones de roles, capacidades personalizadas, plugin/código propietario y usuarios representativos | El comportamiento de acceso necesario tiene un propietario en el destino; se excluyen privilegios obsoletos. |
| Vincular autoría y propiedad | Responsable editorial | Posts de alto valor y registros personalizados con referencias de autor/propietario | Los registros incluidos tienen autores de destino resolubles o un propietario alternativo aprobado. |
| Inventariar comentarios y reseñas | Responsable de contenido o comunidad | Estado, jerarquía, identidad del autor, contenido relacionado, reglas de spam/exclusión y propiedad del plugin | Comentarios de blog, debates, testimonios y reseñas comerciales mantienen una clasificación correcta. |
| Identificar campos sensibles para la privacidad | Responsables de privacidad y negocio | Inventario de campos, base de consentimiento, regla de retención y requisito de acceso | Los datos sensibles tienen una decisión aprobada de migración, archivo, redacción o exclusión. |
Los hashes de contraseñas y las identidades de autenticación externas del origen deben documentarse por separado de los perfiles básicos de usuario. Un registro de usuario puede estar dentro del alcance aunque la credencial de autenticación original no sea portable.
Preparar URL, metadatos SEO, redirecciones, idiomas y alcance Multisite
Cree un inventario de URL de origen para CMS Pages, Blog Posts, tipos de contenido personalizados, archivos de taxonomía, archivos de autor, medios, feeds y rutas de plugins de alto valor. Registre la estructura de permalinks, jerarquía padre, reglas de reescritura de taxonomías, alcance de dominio/subdirectorio, URL canónicas y redirecciones existentes.
Los campos SEO pueden almacenarse en registros del núcleo, metadatos, tablas de plugins o plataformas externas. Inventarie títulos, descripciones, valores canónicos, campos sociales, entradas de datos estructurados, controles de indexación y registros de redirección por propietario. No suponga que una exportación de plugin contiene todas las relaciones de rutas.
| Acción de preparación | Responsable | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|---|
| Capturar URL prioritarias del origen | Responsable de SEO | Lista de URL basada en analítica/búsqueda más estado actual e intención de destino | Cada ruta prioritaria tiene una decisión de conservar, cambiar, consolidar, retirar o redirigir. |
| Registrar lógica de permalinks y reescrituras | Responsable técnico | Configuración de permalinks, reglas de reescritura de tipos de contenido y taxonomías, endpoints de plugins y reglas de rutas/dominios de Multisite | El diseño de rutas del destino puede diferenciar registros de contenido, archivos y endpoints de aplicaciones. |
| Inventariar propietarios de datos SEO | Responsables de SEO y plugins | Mapa de claves/tablas de metadatos, archivos de exportación, reglas canónicas, reglas de indexación y fuentes de sitemap | Cada valor SEO conservado tiene un propietario en el destino. |
| Preparar relaciones multilingües | Responsable de localización | Idiomas, grupos de traducción, códigos de locale, rutas específicas por idioma y reglas de fallback | Las traducciones siguen conectadas en lugar de convertirse en contenido duplicado sin relación. |
| Registrar redirecciones existentes | Responsable de SEO o técnico | Origen, destino, estado, propietario y prioridad | Se clasifican las redirecciones duplicadas, encadenadas, obsoletas y todavía necesarias. |
En Multisite, incluya la relación red/sitio en la evidencia de URL. Slugs idénticos en sitios distintos son rutas diferentes y no deben fusionarse sin una decisión explícita de contenido.
Seleccionar muestras representativas para las pruebas de migración
La selección de muestras representativas debe reflejar la diversidad estructural del sitio, no solo registros recientes o simples. Cada muestra debe indicar las relaciones de contenido previstas, archivos vinculados, evidencia de rutas y responsable de revisión.
| Muestra | Evidencia que debe prepararse | Por qué debe incluirse en el conjunto de muestras |
|---|---|---|
| CMS Page jerárquica | Ruta padre/hijo, plantilla, bloques o datos de constructor, medios, uso en menús y campos SEO | Representa jerarquía de Pages, dependencias de presentación y enrutamiento. |
| Blog Post con relaciones | Autor, Categories, etiquetas, comentarios, imagen destacada, elementos insertados y rutas de archivo | Representa historial editorial y clasificación. |
| Un registro de cada tipo de contenido personalizado importante | Taxonomías, metadatos, medios, ruta pública, plugin propietario y registros relacionados | Expone dependencias del registro del plugin y del esquema personalizado. |
| Registro intensivo en metadatos | Definiciones de campos, ID de referencias, repetidores, valores serializados e ID externos | Expone si los valores de campos pueden seguir siendo interpretables. |
| Usuario con contexto de aplicación | Rol, capacidades, registros creados, datos de perfil y relación de membresía u otro plugin | Representa identidad sin confundir usuarios del núcleo con perfiles de plugins. |
| Registro complejo de medios/contenido | Galería, archivo descargable, adjunto reutilizado, shortcode/embed y enlaces internos | Representa dependencias entre archivos y referencias de contenido. |
| Registro multilingüe o Multisite cuando corresponda | Propiedad de sitio/idioma, enlaces de traducción, rutas y usuarios compartidos | Expone relaciones de alcance del sitio y localización. |
Un registro de muestras debe incluir el ID de origen, la URL pública cuando corresponda, el propietario del registro, los objetos relacionados, el motivo de selección y cualquier dependencia sin resolver. Los registros simples pueden confirmar la base, pero los complejos revelan si la evidencia del alcance está realmente completa.
Completar la verificación final de preparación para WordPress
Antes de la ejecución, consolide la evidencia de preparación en un único registro de preparación. Un elemento sin resolver puede permanecer abierto únicamente si tiene responsable, fecha de decisión y efecto definido sobre el alcance.
| Área de preparación | Condición de preparación |
|---|---|
| Alcance y propiedad | Cada tipo de registro seleccionado pertenece al núcleo de WordPress, a un plugin/aplicación personalizada identificados, a un sistema externo, a un archivo o a una exclusión intencional. |
| Acceso y recuperación | Se registran acceso de administrador, copia de base de datos, copia de archivos, inventario del entorno y responsable de restauración. |
| Arquitectura de contenido | Posts, CMS Pages, tipos de contenido personalizados, taxonomías, menús y estados de ciclo de vida tienen decisiones explícitas de inclusión y destino. |
| Datos personalizados | Los metadatos, opciones, tablas personalizadas, referencias de objetos e identificadores externos importantes tienen esquemas y propietarios conocidos. |
| Medios y presentación | Los archivos prioritarios están disponibles; las dependencias de constructor, bloque, shortcode, tema y plantilla están clasificadas. |
| Usuarios y privacidad | Roles, autoría, perfiles de aplicaciones, comentarios, dependencias de autenticación y campos sensibles están clasificados. |
| URL y SEO | Rutas prioritarias, lógica de permalinks, redirecciones, alcance de idioma/sitio y propietarios de datos SEO están documentados. |
| Muestras | El registro de muestras representa cada patrón material de contenido y aplicación WordPress incluido en el alcance. |
El alcance de WordPress está preparado cuando el equipo de migración puede identificar qué es cada registro seleccionado, dónde se encuentran sus datos relacionados, quién es propietario de su representación en el destino y qué evidencia del origen respalda esa decisión.
Conclusión
Preparar WordPress es un ejercicio de propiedad que abarca contenido, clasificación, metadatos, medios, identidad, presentación, plugins, tablas personalizadas, rutas y sistemas externos. Una copia de seguridad completa y un acceso de administrador son necesarios, pero no explican los tipos de contenido personalizados, las relaciones de taxonomía, las estructuras de constructores, los perfiles de aplicaciones, el alcance Multisite ni los registros propiedad de plugins.
Un paquete de preparación sólido hace explícitas esas relaciones. Separa los datos del CMS WordPress de WooCommerce u otros dominios de aplicaciones, conserva evidencia recuperable del origen, selecciona muestras representativas y resuelve cada registro importante hacia un destino, propietario externo conservado, archivo o exclusión intencional antes de comenzar la ejecución de la migración.
Preguntas frecuentes
¿Qué debe prepararse primero para una migración hacia WordPress?
Defina la función del sitio WordPress de destino y clasifique los propietarios de los registros del origen. Esto establece si cada registro pertenece al núcleo de WordPress, a un plugin o aplicación personalizada, a un sistema externo, a un archivo o a una exclusión intencional antes de comenzar el trabajo detallado de campos.
¿El archivo de exportación de WordPress es una copia de seguridad completa para la migración?
No. La exportación integrada puede aportar evidencia útil del contenido, pero un origen recuperable normalmente también requiere la base de datos, los medios y otros archivos de wp-content, detalles del entorno y registros específicos de plugins o sistemas externos que esa exportación no representa.
¿Por qué deben inventariarse por separado los tipos de contenido personalizados y las taxonomías?
Pueden compartir almacenamiento de WordPress y, al mismo tiempo, utilizar registros, capacidades, editores, metadatos, archivos, plantillas y propietarios de plugins diferentes. Conservar solo títulos y cuerpo de contenido no preservaría la estructura que hace gestionables esos registros.
¿Cómo deben prepararse los campos personalizados y los metadatos?
Registre el propietario de los metadatos, el tipo de objeto, el formato del valor, la definición del campo, los objetos referenciados, muestras representativas y el destino previsto. Los ID numéricos y valores serializados no deben copiarse sin migrar los registros o esquemas a los que hacen referencia.
¿Deben tratarse los plugins y los temas como contenido migrado?
No de forma automática. Los plugins y temas son dependencias de implementación. Sus registros críticos para el negocio, ajustes, tablas personalizadas, shortcodes, plantillas y enlaces externos necesitan decisiones explícitas de propiedad, mientras que los datos técnicos temporales u obsoletos pueden excluirse.
¿En qué se diferencia la preparación de WordPress de la preparación de WooCommerce?
La preparación de WordPress cubre CMS Posts, CMS Pages, tipos de contenido personalizados, taxonomías, metadatos, medios, usuarios, menús, rutas y límites de aplicaciones de plugins. La preparación de WooCommerce cubre por separado Products, variaciones, Customers, Orders, cupones, reseñas comerciales, HPOS, metadatos de checkout y extensiones de comercio.