RicRey

Una regla de firewall permite cierto tráfico; no inicia la aplicación que debe recibirlo. Empieza comprobando si el servicio está activo y escucha en la dirección y puerto previstos. Una aplicación enlazada solo a la interfaz local puede funcionar dentro del VPS y no desde Internet. Prueba primero desde el propio servidor y después desde un equipo externo controlado. Anota protocolo, destino, puerto, hora y resultado. Distingue una conexión rechazada de un tiempo de espera; son pistas, aunque ninguna identifica por sí sola toda la causa. Revisa el firewall realmente activo. En Ubuntu con UFW, status verbose y status numbered permiten consultar su estado y reglas; la documentación también explica reglas limitadas por origen y la opción dry-run. No mezcles gestores sin conocer cómo se aplican en ese sistema. Comprueba además reglas de la plataforma, grupos de seguridad, direccionamiento y ruta de retorno. Si el servicio utiliza UDP, una prueba TCP no valida su disponibilidad. Mantén el acceso administrativo existente mientras revisas cambios de red. Autoriza únicamente los orígenes y puertos necesarios. Abrir todo el tráfico dificulta aislar el problema y amplía la exposición. Tras la corrección, repite la prueba funcional y retira reglas temporales. Para escalar, entrega resultados y reglas depuradas, sin credenciales ni información de otros clientes. Fuentes: Ubuntu Server — Firewalls.

En una página hipotética que desborda en móvil, el primer paso es reproducir el problema con el ancho donde aparece y localizar qué caja supera el espacio disponible. El inspector del navegador permite recorrer imágenes, tablas, filas y contenedores, comparando su ancho calculado con el de sus antecesores. Conviene comprobar también el viewport y repetir la prueba con textos largos y contenido realista. Si la responsable es una imagen, max-width: 100% limita su tamaño al contenedor y height: auto suele conservar su proporción. Se revisan además reglas que impongan un ancho o un mínimo fijo al propio contenedor: reducir la imagen no corrige una caja exterior demasiado ancha. El texto alternativo debe mantenerse. Para una fila de tarjetas o controles se decide si puede envolver sus elementos, cambiar a una columna o reducir un mínimo de tamaño que impida encogerlos. Una tabla de datos necesita conservar la relación entre encabezados y celdas; cuando requiere anchura, puede ser preferible un contenedor con desplazamiento horizontal localizado y una indicación comprensible. Hay que comprobar que las personas que usan teclado puedan acceder a su contenido. Aplicar overflow: hidden al cuerpo puede esconder el síntoma y recortar texto, controles o indicadores de foco. La corrección debe responder al elemento responsable y conservar la información. La validación final incluye orientación vertical y horizontal, aumento de texto, navegación con teclado y varios anchos próximos al punto de fallo. También se revisa un teléfono real cuando sea posible: una captura inmóvil no permite comprobar interacción ni lectura completa. Fuentes: Diseño web adaptable y Propiedad overflow.

Una cifra alta de memoria utilizada no prueba por sí sola que el VPS necesite más RAM. Linux usa parte de la memoria para caché de archivos y puede recuperar páginas según su tipo y necesidad. Conviene observar disponibilidad, procesos y comportamiento durante el mismo intervalo. Registra una medición en reposo y otra durante el problema. En herramientas que muestran esos campos, distingue memoria libre de disponible y revisa el uso de intercambio. El indicador MemAvailable de /proc/meminfo estima cuánto puede utilizarse para nuevas aplicaciones sin recurrir a intercambio; no equivale a memoria completamente vacía. Relaciona las cifras con latencia, errores y crecimiento de procesos. Revisa los registros del sistema si algún proceso desaparece o reinicia: un evento del mecanismo de falta de memoria aporta evidencia distinta de una simple barra de uso elevada. Busca patrones antes de ajustar límites: una tarea concreta, demasiados trabajadores simultáneos, una consulta o un crecimiento sostenido. Cambia una variable en pruebas y compara el mismo trabajo. Vaciar cachés de forma periódica no demuestra que hayas corregido la causa. Si solicitas ayuda, incluye hora, carga de trabajo, memoria disponible e información depurada del evento. Evita publicar listados con argumentos que contengan contraseñas. Decide el dimensionamiento con varias mediciones representativas y margen operativo, en lugar de una única captura. Fuentes: Linux Kernel — Memory concepts · Linux Kernel — proc filesystem.

En un proyecto administrado con Composer, prepara la actualización en una copia de desarrollo y conserva composer.json, composer.lock, código propio, archivos subidos y base de datos. Identifica si buscas una actualización dentro de la misma rama o un salto de versión mayor: este último requiere revisar su guía específica y las incompatibilidades previstas. Comprueba el informe de estado y las restricciones del proyecto. Ejecuta primero una simulación cuando el comando la admita y revisa qué paquetes cambiarían. El procedimiento para un proyecto con drupal/core-recommended puede diferir del que utiliza solo drupal/core; no copies un comando sin comprobar esa estructura. Después de actualizar el código en la copia, aplica las actualizaciones pendientes de base de datos con Drush o el mecanismo web documentado y reconstruye las cachés. Revisa el informe de estado, los registros, permisos, formularios, contenido y funcionalidades de módulos propios. Conserva los errores completos en privado y comparte solo fragmentos depurados. Si el proyecto administra configuración mediante exportación, sigue su flujo: algunas actualizaciones pueden modificar su estructura. Revisa los cambios y prueba de nuevo antes de llevarlos a producción. Para desplegar, utiliza los archivos de dependencias que ya probaste y el proceso de instalación del proyecto, evitando resolver versiones nuevas directamente en el servidor público. Genera una copia final coherente, limita escrituras durante la intervención y vuelve a aplicar los cambios de base necesarios. Volver únicamente al código anterior puede no revertir una modificación de esquema. El plan de recuperación debe contemplar también base de datos y archivos, junto con cualquier contenido recibido desde el respaldo. Verifica una restauración en pruebas antes de depender de ella. Fuentes: Drupal con Composer · Desplegar una actualización.

Identifica el nombre exacto de la unidad y el último cambio realizado. En un sistema que utiliza systemd, systemctl status muestra su estado y un resumen reciente; journalctl permite ampliar los mensajes de esa unidad. Consulta ambos antes de reiniciar otra vez. Delimita la ventana temporal y relaciona el error con un intento concreto de arranque. Busca el primer fallo útil: sintaxis, archivo ausente, permiso, puerto ocupado o dependencia no disponible. Los avisos posteriores pueden ser consecuencias del mismo problema. Guarda una copia del archivo modificado. Revisa qué usuario ejecuta el servicio, el comando de inicio y las rutas que declara la unidad. Un programa que funciona desde una terminal puede recibir otro directorio o entorno al iniciarse como servicio. Utiliza el comprobador de configuración del propio programa cuando exista, antes de aplicar la corrección. Si cambiaste una unidad de systemd, sigue su procedimiento de recarga; editar el archivo de configuración de la aplicación puede requerir una acción distinta. No asumas que reiniciar y recargar son equivalentes. Después de corregir una sola causa, inicia el servicio y comprueba tanto su estado como una operación real. Un proceso activo todavía puede fallar al atender peticiones. Para pedir ayuda, comparte unidad, hora y mensajes depurados, retirando variables con secretos y datos internos que no sean necesarios. Fuentes: systemd — systemctl · systemd — journalctl.

Empieza por confirmar el producto y el ámbito de tienda. Un valor guardado para una vista concreta puede diferir del valor predeterminado. Comprueba también visibilidad, asignación a sitios web, estado y cualquier regla relacionada con el dato que estás observando. Conserva un ejemplo de antes y después para repetir la prueba. Si el ámbito es correcto, distingue los datos indexados de la caché de la página. Un indexador prepara estructuras para consultas; la caché reutiliza resultados. Limpiar una no equivale a reconstruir la otra. Con acceso autorizado a la consola y desde la raíz del proyecto, puedes consultar bin/magento indexer:status y bin/magento indexer:show-mode. Ejecuta los comandos como propietario del sistema de archivos, según indica Adobe. Si un indexador funciona por programación, revisa cron y sus errores; reconstruirlo manualmente una vez no corrige una tarea automática averiada. Después consulta bin/magento cache:status. Si procede limpiar una caché, limita la operación al tipo afectado y usa el procedimiento documentado. Distingue cache:clean de cache:flush: vaciar el almacenamiento puede tener un alcance mayor. Antes de hacerlo, identifica si ese backend comparte datos con otros consumidores. Repite la consulta desde una sesión de visitante y revisa por separado las capas externas, como un proxy o CDN. Registra estado de indexadores, hora de cron y encabezados de la respuesta para comparar. Evita usar «reindexar todo y vaciar todo» como solución habitual. Puede ocultar la causa y aumentar la carga. Cuando el cambio vuelva a aparecer mediante el funcionamiento normal, comprueba otro producto y confirma que el proceso automático sigue avanzando. Fuentes: Administrar indexadores · Administrar caché.

Crea un inventario sencillo: aplicación, base de datos y usuario que debe utilizarla. En cPanel, el usuario de base de datos se crea por separado de las cuentas de correo y de los administradores de la web. Crear una base y crear un usuario tampoco establece automáticamente todos sus vínculos. En Manage My Databases, selecciona el usuario y la base en Add User To Database. La pantalla siguiente permite asignar privilegios. Consulta los requisitos de la aplicación para decidir cuáles necesita durante la instalación y durante el funcionamiento normal; algunos procesos de actualización requieren cambios de esquema. Utiliza un usuario propio para la aplicación cuando el entorno lo permita. Así puedes retirar su acceso sin alterar las credenciales de otro sitio. Conserva el nombre completo que muestra el panel, incluidos los prefijos que aplique, y guarda la contraseña mediante el mecanismo de secretos del proyecto. Verifica la conexión con la aplicación y una operación habitual en una copia controlada. Si cambias una contraseña compartida por una instalación existente, actualiza su configuración de forma coordinada para evitar interrupciones. No elimines usuarios para experimentar ni concedas acceso a todas las bases ante cualquier error. Primero compara nombre, host y vínculo de privilegios. Al solicitar ayuda, entrega el mensaje depurado y la operación que falla, sin publicar contraseñas, volcados ni archivos de configuración completos. Fuentes: cPanel — Manage My Databases.

La comparación debe hacerse en la parte pública del sitio: que una cuenta administrativa pueda editar un artículo no demuestra que una persona invitada deba verlo. En este supuesto se abre la URL exacta sin sesión y se registra si falta el enlace, aparece una petición de acceso o se muestra otro error. Son síntomas distintos. Joomla separa los niveles de acceso para ver contenido de los permisos para realizar acciones, como editar o administrar. Para un artículo destinado a todo el público, se revisa su campo Acceso y la composición del nivel correspondiente. En la configuración habitual, Public permite verlo con o sin sesión; Guest está pensado para visitantes sin iniciar sesión. Un sitio puede tener niveles personalizados, por lo que también conviene comprobar los grupos incluidos. Después se recorre la ruta completa: categoría del artículo y sus categorías superiores, elemento de menú que lo presenta y módulo que muestra ese menú. El acceso de un enlace y el del contenido al que apunta pueden diferir. Un menú visible no concede automáticamente acceso al artículo. La corrección se limita al objeto cuyo nivel no corresponde al público previsto. Dar permisos globales de edición o administración al grupo Public no resuelve adecuadamente un problema de visualización. También se confirma que el artículo esté publicado y dentro de sus fechas de publicación. Tras guardar, se compara la URL directa con la navegación habitual, sin sesión y con una cuenta de prueba. Si hay caché, se revisa la variante afectada y se conserva un registro de los niveles anteriores para poder revertir el cambio. Fuentes: Control de acceso en Joomla y Restricción de acceso a artículos.

FTP, FTP con TLS y SFTP utilizan protocolos distintos. Cambiar únicamente el puerto en el cliente no convierte una cuenta FTP en una cuenta SSH. Anota el protocolo seleccionado y el error, sin compartir la contraseña. En cPanel, las cuentas adicionales de FTP se administran desde FTP Accounts y pueden limitarse a un directorio. La documentación de SFTP señala que una cuenta FTP no sirve para iniciar una sesión SFTP; este acceso usa un usuario SSH autorizado. Confirma con el administrador si la cuenta y el servicio tienen ese acceso habilitado. Solicita los datos correctos: nombre del servidor, protocolo, puerto y método de autenticación. Verifica también la identidad del servidor mediante la huella o certificado correspondiente al protocolo. No aceptes un cambio inesperado de identidad sin comprobar su causa. Si el trabajo requiere dar acceso a una sola carpeta, acuerda un mecanismo que respete ese alcance. Compartir el acceso principal de la cuenta para resolver un fallo de login puede conceder más permisos de los necesarios. Una llave privada también debe permanecer bajo control de su titular. Prueba primero la conexión y el listado del directorio autorizado. Después transfiere un archivo pequeño y retíralo. Conserva el registro depurado del cliente si necesitas ayuda. Al terminar una colaboración, revoca el acceso específico y revisa los archivos modificados conforme al procedimiento del sitio. Fuentes: cPanel — FTP Accounts · cPanel — Configure your SFTP client.

El aviso de actualización es el punto de partida. La decisión depende de la versión de origen, de la de destino y de las extensiones que utiliza el sitio. Una actualización dentro de la misma rama y un salto de versión mayor pueden requerir procedimientos distintos. Consulta la documentación de esa ruta concreta; no des por compatible una extensión porque todavía funcione en la instalación actual. 1. Anota las versiones del núcleo, PHP y base de datos. Contrástalas con los requisitos oficiales de la versión de Joomla que quieres instalar. La tabla de requisitos distingue mínimos y recomendaciones; confirma también las necesidades de cada extensión. 2. Haz un inventario de plantilla, componentes, módulos y plugins de terceros. Revisa las declaraciones de sus desarrolladores y los avisos previos de actualización. Una extensión sin información de compatibilidad necesita investigación o una prueba; la ausencia de avisos no demuestra que vaya a funcionar. Si debes deshabilitar o retirar alguna, ensaya primero cómo afecta al contenido y conserva su configuración. 3. Prepara una copia de archivos y base de datos, guárdala fuera del sitio público y verifica que puedes restaurarla. Usa esa copia en un entorno de pruebas protegido. Reproduce allí el procedimiento y comprueba acceso administrativo, navegación, búsquedas, formularios, permisos y páginas que dependan de extensiones. Una tienda o integración externa requiere además aislar correos y operaciones reales. En la intervención definitiva, utiliza el componente oficial de actualización y atiende sus comprobaciones previas. Guarda los mensajes y el registro si falla; evita repetir instalaciones a ciegas o mezclar archivos de distintas versiones. Reserva una ventana, limita los cambios de contenido durante la copia final y define el punto de restauración. Si aparecen errores, comparte versiones y mensajes depurados, sin contraseñas ni archivos de configuración completos. Que la portada abra es una comprobación útil, pero no basta para dar la actualización por verificada. Fuentes: Joomla — Technical Requirements · Joomla — Version Update.

Empieza en Domains y consulta Document Root para cada nombre. La raíz documental indica qué carpeta utiliza el dominio; dos nombres que comparten esa ruta pueden mostrar los mismos archivos. Comprueba también si alguno es un alias o tiene una redirección configurada. Registra las rutas actuales y haz una copia de la web afectada. No muevas el contenido de public_html suponiendo que pertenece a un único dominio: puede ser la raíz de otro sitio de la cuenta. Si existe una configuración del CMS con rutas absolutas, también necesitará revisión. Cuando la interfaz permita cambiar la raíz del dominio adicional, utiliza una carpeta preparada y revisa las indicaciones de Manage the Domain. cPanel aclara que cambiar esa ruta no mueve los archivos existentes. Confirma las limitaciones del dominio principal y las funciones habilitadas en tu cuenta. Prueba con un archivo de comprobación inocuo y de nombre único, que después puedas retirar. Verifica el dominio, su variante www y el contenido esperado. Si una capa externa devuelve la misma página, revisa su respuesta antes de duplicar archivos otra vez. La separación de carpetas organiza la publicación, pero conviene comprobar también bases, configuración y destinos de formularios. Para pedir ayuda, comparte los nombres y rutas depurados. Evita eliminar el dominio o su directorio hasta identificar todos los sitios que utilizan esos datos. Fuentes: cPanel — Domains · cPanel — Manage the Domain.

El código 500 indica un fallo del lado del servidor; no señala automáticamente falta de memoria ni un problema del alojamiento. Guarda la URL, hora, acción realizada y último cambio conocido. Reproduce el caso una vez y consulta el error de aplicación y el registro PHP correspondiente a ese momento. La opción más útil suele ser reproducirlo en una copia protegida con el mismo módulo y configuración. Allí puedes activar temporalmente la depuración con el procedimiento de tu versión. PrestaShop documenta el ajuste del panel de rendimiento y la constante _PS_MODE_DEV_; comprueba primero la rama de documentación apropiada. La información detallada puede mostrar rutas y otros datos internos. Busca el primer error relevante de la petición, no solo mensajes secundarios. Anota excepción, archivo, línea y versión del módulo. Si el problema comenzó tras actualizarlo, compara su compatibilidad y las instrucciones de su desarrollador. Prueba una desactivación reversible en la copia y observa si cambia el resultado; no elimines sus tablas ni reinstales la tienda como primer intento. Cuando tengas una hipótesis, cambia una sola cosa y repite la misma acción. Comprueba también otra página equivalente que funcionaba. En versiones que dispongan del comando about, su salida ayuda a confirmar entorno y estado de depuración; revísala antes de compartirla para retirar información interna. Al terminar, desactiva la depuración y recupera la configuración de rendimiento prevista para producción. Si necesitas ayuda, entrega un fragmento depurado del error y los pasos mínimos para reproducirlo. Excluye contraseñas, tokens, datos de clientes y pedidos. Una captura de «error 500» sin el registro asociado rara vez permite distinguir la causa. Fuentes: Configuración y depuración · Comando about.

Una página que dice «mantenimiento» puede devolver 200 aunque el servicio esté temporalmente indisponible. Comprueba el estado HTTP real, además del texto visible. Para una indisponibilidad temporal, 503 comunica que el servidor aún no puede atender la petición. Prepara un aviso sencillo con contexto útil y una estimación solo cuando exista. Retry-After permite indicar cuándo volver a intentarlo; no conviene inventar una hora de recuperación. Evita incluir rutas internas, detalles de la base de datos o mensajes de depuración. Define el alcance antes de activar el modo. Una tienda puede necesitar pausar escrituras, pagos o tareas que modifiquen datos; ocultar la portada no garantiza esa pausa. Mantén un acceso administrativo controlado y un procedimiento de salida comprobado en pruebas. Valida la respuesta en varias rutas públicas, incluyendo páginas interiores y recursos necesarios para leer el aviso. Comprueba los encabezados de caché: una capa intermedia podría conservar el error después de terminar el trabajo. La documentación de HTTP advierte que las respuestas 503 normalmente no deberían almacenarse. Al finalizar, desactiva la regla, comprueba estados y funciones básicas y vuelve a revisar desde una sesión de visitante. Si sigue apareciendo el aviso, compara el origen con las capas de caché. Anota inicio, final y resultado para que otra persona pueda entender la intervención sin acceder a información privada. Fuentes: MDN — 503 Service Unavailable · MDN — Retry-After.

Prepara una copia protegida de la tienda y decide cómo aislar sus integraciones antes de probarla. Cambiar únicamente el dominio no impide que un módulo envíe correos, contacte con logística o utilice credenciales de producción. En esa copia emplea los entornos de prueba que admitan las pasarelas y los demás servicios. Anota la versión de PrestaShop, PHP, tema y módulos. Confirma la ruta de actualización y los requisitos de la versión de destino con la documentación correspondiente. Comprueba compatibilidad con los desarrolladores de los módulos; una actualización del núcleo no demuestra por sí sola que una personalización funcione. Ensaya el procedimiento con una copia de archivos y base de datos que puedas restaurar. Después comprueba, al menos: - Catálogo, combinaciones, imágenes, precios, impuestos y monedas. - Registro e inicio de sesión con cuentas de prueba. - Carrito, descuentos, gastos de envío y finalización del pedido. - Resultado de pagos de prueba y retorno correcto a la tienda. - Correos, estados de pedido y conexión con otros sistemas, dentro del entorno aislado. Revisa tanto el panel administrativo como la tienda pública. La lista oficial posterior a una actualización también propone comprobar acciones como crear una cuenta, realizar un pedido y añadir productos. Verifica qué módulos siguen activos y cuáles requieren atención. Para intervenir producción, establece una pausa de pedidos y tareas que escriban datos, genera la copia final y reserva tiempo de comprobación. Define cuándo restaurar y cómo preservar pedidos nuevos si fuese necesario. No habilites pagos reales en la copia por comodidad: demuestra primero la integración mediante el método de pruebas de cada proveedor y confirma su configuración final al volver al entorno público. Fuentes: Actualizar PrestaShop · Comprobaciones posteriores.

Un 403 indica que el servidor entiende la petición y rechaza atenderla. No demuestra por sí solo que falte un archivo ni que todos los permisos sean incorrectos. Anota la URL exacta, la hora y si ocurre con un archivo concreto o solo al pedir una carpeta. Compara la respuesta con un recurso público que sí funcione. Si el archivo abre directamente y la carpeta no, revisa el documento de índice y la política de listado de directorios. Una carpeta sin índice no necesita exponer su contenido para servir correctamente el resto de la web. Consulta el registro asociado a esa petición. Busca una regla de autorización, propietario inesperado, acceso denegado al recorrido de directorios o intervención de una capa de seguridad. El mensaje ayuda a elegir la siguiente comprobación. Conserva cualquier archivo de configuración antes de editarlo. Revisa permisos y propiedad conforme al modelo de ejecución del alojamiento. Aplicar 777 de forma recursiva amplía el acceso y puede dejar el error original sin resolver. Si hay una regla deliberada para proteger archivos privados, mantén su propósito y cambia únicamente la ruta pública prevista. Repite la prueba como visitante y con el recurso afectado. Para escalar, comparte el fragmento del registro depurado y los cambios recientes. No publiques archivos de credenciales ni desactives globalmente las restricciones para que desaparezca el aviso. Fuentes: MDN — 403 Forbidden · Apache — Configuration sections.

A staging copy that looks correct has passed a visual check, but launch also depends on behavior and data. For this hypothetical handover, build a short acceptance list from what visitors and editors actually do. Test navigation, search, login, permissions, publishing, media, forms and any checkout or membership workflow that exists. Include a mobile viewport and an anonymous session, then verify that submissions reach the intended test destination. Review external integrations individually: email delivery, payment mode, API keys, webhooks, scheduled tasks, analytics and remote storage. A copy can retain production credentials or callback URLs. During testing, isolate integrations that could send messages or change real records. Before launch, explicitly confirm which settings must become production settings and who will verify them. The data plan matters just as much. Identify new orders, registrations, comments and editorial changes created on the live site since staging was copied. Replacing the live database wholesale could discard them. Decide whether to deploy files only, transfer selected changes or coordinate a controlled final synchronization, using a method appropriate to the site's data. Also check the final domain, HTTPS, redirects, stored URLs and cache behavior. Migration tools must handle WordPress data structures correctly rather than applying an indiscriminate text replacement. Keep a recent backup and a practical rollback procedure with clear checks for success. After traffic moves, repeat the critical workflows and inspect errors and external deliveries. Record what was tested so that an attractive homepage is not mistaken for complete acceptance. Sources: WordPress search and replace and Migrating WordPress.

Prepara un inventario del DNS antes del cambio: servidores autoritativos, registros de la web y registros que utiliza el correo. Exporta la zona o guarda una copia legible. Mover la web y mover los buzones son operaciones que pueden planificarse por separado. Identifica los registros A, AAAA y CNAME que llevan al sitio. Después revisa los MX y las direcciones de sus destinos. Un MX puede apuntar a un nombre cuyo A coincide con el de la web; cambiar ese A también cambiaría indirectamente el destino del correo. No decidas únicamente mirando el nombre del registro. Conserva las entradas de autenticación y verificación del servicio de correo. Si cambias los servidores DNS, reproduce allí los registros necesarios antes de modificar la delegación y contrasta las respuestas autoritativas. Revisa además el enrutamiento local del alojamiento nuevo. En cPanel, Email Routing determina si el servidor considera el correo local o remoto. Su detección automática se basa en la zona local y no sustituye una consulta pública; confirma la opción adecuada para ese dominio. Termina con pruebas identificables de entrada y salida desde cuentas controladas, incluidas las notificaciones de la web. Guarda hora y resultado. Mantén disponible el acceso a los buzones anteriores hasta verificar el recorrido acordado, sin borrar cuentas ni alterar contraseñas como parte de una simple migración web. Fuentes: Cloudflare — DNS record types · cPanel — Email Routing.

An invalid JSON message describes the response the editor could not process. In this hypothetical case, preserve the draft locally before repeating the save, then open the browser's Network panel and identify the request that fails. Record its method, destination, status, response type and a sanitized excerpt of its body. Do not publish cookies, authorization headers or nonces. The response provides the next lead. An HTML login page suggests investigating authentication or redirects. A 403 response calls for checking the returned error and the relevant access or firewall logs. A 404 points toward the requested route and routing configuration. A 5xx response warrants correlation with server logs. These are directions for investigation, not definitive diagnoses based on status alone. For requests made inside a logged-in WordPress session, REST cookie authentication also uses a nonce, and the account still needs the capability required by the operation. Re-authenticating and reloading the editor can help distinguish an expired session from a reproducible application problem. Opening the REST index successfully does not prove that an authenticated save request succeeds. If a security rule blocks the request, correlate its timestamp or request identifier with the rule log. Any trial exception should be limited to the necessary operation, reviewed by the administrator and removed if it does not explain the result. A staging copy can isolate plugin conflicts without removing protection across the live site. Confirm the fix by saving and reopening a draft and reviewing the actual successful response. Sources: WordPress REST authentication and HTTP response status codes.

Registra primero la URL inicial y la secuencia de respuestas. Un bucle puede alternar HTTP y HTTPS, dos nombres de dominio o dos rutas. El certificado y el código de la aplicación son piezas distintas del recorrido; renovar uno no corrige automáticamente una regla contradictoria. Revisa las redirecciones configuradas en el proxy, el servidor y el CMS. Guarda sus valores antes de tocar nada. En las herramientas de red del navegador, conserva la petición y observa cada respuesta y su cabecera Location. Busca el primer destino que vuelve a un punto anterior. Comprueba también cómo se comunica el proxy con el origen. Por ejemplo, Cloudflare documenta que Flexible conecta por HTTP al servidor; si este obliga a volver a HTTPS, puede crearse un ciclo. La solución debe mantener una configuración de cifrado coherente, con el certificado necesario en el origen. No basta con cambiar opciones al azar. Ensaya una sola corrección y repite exactamente la misma URL. Prueba además las variantes con y sin www y una página interior. Si hay redirecciones permanentes almacenadas, compara una sesión nueva. Para pedir ayuda, comparte la cadena de estados y destinos depurada, junto con las capas implicadas. Retira cookies y parámetros privados. Una captura del aviso final no muestra cuál de las capas introdujo el salto incorrecto. Fuentes: Cloudflare — Too many redirects · MDN — Redirections in HTTP.

In this hypothetical move, the message establishes that WordPress could not connect; it does not identify a damaged database. Start by confirming that the requested domain reaches the intended installation. Keep a recoverable copy of the configuration and database before making changes. Compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php with the destination service details. A database account from the old server may not exist on the new one. The host can also require a different hostname, port or socket. Check values privately rather than posting the file, a connection string or a screenshot containing secrets. The next useful distinction is whether the database service can be reached from the application environment. An administrator can test the same database and account through an approved client using protected credential entry. Record a sanitized error and timestamp. A connection refusal, an authentication failure and access denied to a particular database suggest different areas to investigate; none alone justifies broadening access to every database. If authentication succeeds, verify that the intended database was imported, its expected tables exist, and the account has the permissions required for that installation. Check service availability, connection limits and relevant server logs with the operator. Avoid repeatedly resetting passwords without updating the application configuration consistently. Once the connection works, test both the public site and administration area. Database repair is a separate action for evidence of table damage, with its own backup and recovery plan; it should not be the first response to a connection error. Sources: Common WordPress errors and How WordPress parses DB_HOST.

En Drupal, el formato de texto determina cómo se procesa y muestra el contenido mediante una serie de filtros. El editor visual y su barra de herramientas son otra parte de la configuración. Que un botón permita insertar una etiqueta no sustituye comprobar qué admite el formato seleccionado y quién puede utilizarlo. Revisa Configuración > Autoría del contenido > Formatos de texto y editores. Identifica el formato del campo afectado, sus filtros, su orden y los roles autorizados. Cada formato tiene un permiso asociado. La documentación reserva Full HTML para usuarios de confianza porque no restringe las etiquetas permitidas; concederlo ampliamente puede permitir contenido peligroso y crear riesgos de ejecución de scripts en el navegador. Define primero qué presentación necesita el equipo. Si basta con unas pocas etiquetas o funciones, prepara un formato que permita solo lo necesario y pruébalo con una cuenta representativa. No elimines filtros de seguridad únicamente para conservar un fragmento pegado de otra web. Revisa también cómo se representa el resultado para una persona visitante. Ensaya cambios en una copia y conserva ejemplos de contenido existente. Drupal almacena el texto original y aplica filtros al mostrarlo, por lo que modificar un formato merece comprobar tanto publicaciones antiguas como nuevas. Documenta quién mantiene cada formato y revisa sus permisos al incorporar roles. Resolver una necesidad de edición mediante un ajuste limitado ayuda a conservar el control sobre el contenido admitido. Fuentes: Drupal — Filter module overview · Drupal User Guide — Text Formats and Editors.

Para una actualización hipotética de PHP, la prueba útil reproduce las funciones del sitio y las condiciones del servidor. Se empieza con un inventario de WordPress, tema, plugins, código propio, versión actual de PHP y extensiones necesarias. La compatibilidad declarada por WordPress no garantiza automáticamente la de todos los componentes. También se revisa qué versión admite cada responsable y si existe una actualización mantenida. Se prepara una copia independiente de archivos y base de datos, protegida del acceso público y con una restauración comprobada. Los correos, pagos, webhooks y sincronizaciones deben utilizar destinos o modos de prueba. Así una comprobación funcional no produce efectos sobre personas o sistemas reales. Tras verificar que la copia funciona con la configuración inicial, se cambia PHP y se repite una lista concreta: inicio de sesión, edición y publicación, carga de medios, formularios, búsquedas, tareas programadas y cualquier operación propia del sitio. También se recorren páginas anónimas y autenticadas. Un análisis automático puede orientar, pero ni una pantalla inicial correcta ni la ausencia de avisos garantizan compatibilidad completa. Se revisan los registros para distinguir errores fatales, advertencias y comportamientos que cambian sin mostrar un fallo visible. Si algo falla, se aísla el componente en la copia y se consulta a su responsable. El paso a producción queda preparado cuando hay resultados registrados, una copia reciente y una forma conocida de restaurar tanto el entorno PHP como los datos. No se necesita fijar una versión universal: debe elegirse una opción soportada y comprobada para ese conjunto de componentes. Fuentes: Preparación de la actualización de PHP y Copia de desarrollo de WordPress.

El peso del archivo y el espacio reservado son cuestiones distintas. Comprimir una imagen puede acortar su descarga, pero el navegador sigue necesitando conocer su proporción para organizar el contenido antes de mostrarla. Observa la página con una carga lenta y localiza qué elemento aparece justo antes del desplazamiento. Revisa el HTML de las imágenes afectadas. Los atributos width y height, con valores coherentes con su proporción, permiten calcular espacio durante la carga. Pueden combinarse con CSS adaptable, como un ancho máximo adecuado y height: auto, para conservar la proporción sin obligar a que la imagen ocupe su tamaño original en todas las pantallas. Otra opción es reservar espacio mediante aspect-ratio en el contenedor apropiado. Comprueba el resultado en varios anchos. Si se usan recortes diferentes según la pantalla, revisa sus proporciones específicas; copiar dimensiones de otra variante puede introducir otro salto. Inspecciona también las imágenes que aparecen al desplazarte, porque retrasar la carga no elimina la necesidad de reservar su espacio. Repite la medición con las mismas condiciones y compara la posición del texto antes y después. Si persisten movimientos, investiga otros elementos que se insertan tarde, como anuncios o contenido incrustado, en el punto donde ocurre el cambio. Evita asignar una altura arbitraria a todas las imágenes para ocultar el síntoma. La corrección debe reflejar el diseño y mantener contenido, controles y proporciones utilizables. Fuentes: web.dev — Optimize Cumulative Layout Shift · MDN — img element.

WP-Cron comprueba las tareas pendientes cuando WordPress recibe las peticiones que lo disparan; no permanece ejecutándose continuamente como un planificador del sistema. En una web hipotética con pocas visitas, una publicación puede quedar pendiente hasta una petición posterior. Eso explica un retraso posible, pero no descarta errores de ejecución. Conviene comparar la hora prevista y la hora real, la zona horaria del sitio y el evento asociado. También se distingue una tarea registrada pero vencida de otra que el plugin nunca programó. Si hay acceso a WP-CLI, wp cron test comprueba el disparador y wp cron event list muestra los eventos; la persona administradora debe ejecutarlos sobre la instalación correcta. Los registros de PHP y del plugin ayudan a saber si el evento empezó y falló. Ejecutar manualmente una tarea que envía correos, cobra o sincroniza datos requiere conocer sus efectos: no es una prueba inocua y podría repetir acciones. Una copia con integraciones de prueba facilita aislar ese comportamiento. Antes de cambiar el planificador se revisa si existe una desactivación intencional de WP-Cron, restricciones de peticiones internas o un proceso externo que ya lo invoque. Añadir otro disparador sin ese inventario puede duplicar trabajo. Si hace falta una frecuencia más constante, se prepara una tarea del sistema y se comprueba que dispara y registra la ejecución correctamente antes de retirar el mecanismo anterior. Esa sustitución mejora la regularidad del disparo; no arregla por sí sola un error del código de la tarea. Fuentes: Funcionamiento de WP-Cron y Comandos de WP-CLI para cron.

Empieza por dar a cada control una etiqueta que describa su propósito. El texto visible dentro del campo puede desaparecer al escribir; conserva una etiqueta visible y asociada al control. En HTML, una opción habitual es que el atributo for de label coincida exactamente con el id único del campo. Comprueba también casillas, selectores y botones. Explica los requisitos antes del envío: qué campos son obligatorios, el formato esperado y cualquier límite relevante. Un ejemplo breve junto a una fecha evita que la persona tenga que adivinar cómo introducirla. Mantén la instrucción cerca del campo al ampliar la página o usar una pantalla pequeña. Cuando haya un error, indica qué campo necesita atención y cómo corregirlo. No dependas únicamente de un borde rojo. Puedes ofrecer un resumen con enlaces a los campos afectados y mensajes específicos junto a ellos. aria-describedby permite asociar un campo con su explicación o error cuando se implementa correctamente. Prueba el recorrido completo con teclado: entrar, completar datos, provocar un error, corregirlo y recibir confirmación. Comprueba que el foco permite localizar el problema y que no se pierden innecesariamente las respuestas válidas. Revisa también la experiencia con un lector de pantalla, incluidos los mensajes que aparecen después de enviar. Valida estas mejoras en el formulario real y con sus distintos estados. Una etiqueta añadida al diseño visual no demuestra por sí sola que la asociación programática exista. Fuentes: W3C WAI — Labeling Controls · W3C WAI — User Notifications.