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.