RicRey

El objetivo es localizar dónde aparece la diferencia. En este supuesto se introduce un cambio pequeño y reconocible, se confirma que está publicado y se compara exactamente la misma URL, idioma y estado de sesión. Una vista previa del editor no equivale necesariamente a lo que recibe una persona visitante. La pestaña Red del navegador permite revisar el documento HTML y sus recursos. Se anota si la respuesta procede de memoria o disco y se repite con la caché del navegador deshabilitada mientras las herramientas están abiertas. Si así aparece el cambio, existe una pista local; una ventana privada también sirve como comparación, aunque puede recibir otra variante por sus cookies. Si continúa la versión antigua, se revisan cabeceras como Cache-Control, Age y las marcas de caché documentadas por la infraestructura. Age puede indicar reutilización en una caché compartida; la ausencia de esa cabecera no demuestra que no haya caché. Los nombres particulares de cabeceras tampoco son universales. A continuación se purga solo la URL afectada en una capa cada vez: caché de página de WordPress, caché del servidor y CDN, anotando el resultado tras cada acción. La caché de objetos almacena datos y merece una comprobación distinta del HTML de página. No conviene vaciar todo repetidamente sin registrar qué cambió. Cuando se identifica la capa, se revisa su invalidación al publicar y el tiempo de conservación. Una prueba final con una sesión anónima confirma que la corrección alcanza la variante pública esperada. Fuentes: Caché en WordPress y Caché HTTP.

Write down the intended publication date, time and timezone together. “09:00 tomorrow” is ambiguous for a team working in different places. Compare that intention with the timestamp saved on the post and the timezone configured for the website. WordPress uses the timezone in Settings > General for publishing schedules. Review that setting with someone authorized to change site configuration. The documentation allows choosing a city in the relevant timezone or a UTC offset. A city entry is useful when local time follows seasonal clock changes; a fixed offset should be chosen deliberately. Save an approved adjustment and check the displayed local time. Next reopen the scheduled post and review its actual date and time. Changing a site setting should not replace checking each affected schedule. Confirm the calendar date as well as the hour, especially when a conversion crosses midnight. The date and time display formats are presentation choices and should not be confused with the timezone itself. For a controlled test, schedule an ordinary test post for a clearly stated future time and agree who will observe the result. Avoid repeated changes to important scheduled content while people are comparing evidence. If the stored schedule matches the intended timezone but publication still does not occur, record that as a separate symptom. Keep the original and revised values so another administrator can follow the comparison. Sources: Learn WordPress — Scheduling posts and pages · WordPress — Settings General screen.

Una portada accesible y entradas con 404 pueden indicar un problema de encaminamiento, aunque también conviene descartar que falten contenidos. Para este caso hipotético, se comprueba primero que una entrada publicada existe y conserva su identificador. Abrir su URL simple, con el formato ?p=IDENTIFICADOR, ayuda a comparar el acceso directo con el enlace legible habitual. Si ambos fallan, la investigación debe incluir la importación, el estado del contenido y el sitio que está respondiendo. En Ajustes → Enlaces permanentes se anota la estructura original y se guarda sin cambiarla deliberadamente. Después se prueban varias entradas y categorías. Si WordPress no pudo escribir las reglas, se conserva ese aviso para revisar la configuración; no hace falta dar permisos amplios a todos los archivos. La comprobación siguiente depende del servidor real. En Apache se revisan las reglas aplicables, el módulo de reescritura y si la configuración permite utilizar .htaccess. En Nginx esas reglas se encuentran en la configuración del servidor: copiar un .htaccess no las activa. También importa si WordPress quedó en un subdirectorio o si existe un proxy delante. Antes de editar se guarda la configuración vigente y se confirma qué bloque atiende el dominio. La persona administradora debe validar su sintaxis y disponer de una forma de volver atrás. Finalmente se comparan las respuestas HTTP y los registros; cambiar permanentemente todas las URLs puede ocultar el fallo y romper enlaces existentes. Fuentes: Enlaces permanentes y WordPress con Nginx.

Start with the symptom, the affected action and its time. Site Health adds context, but a long configuration report alone does not explain what failed. Under Tools > Site Health, the Status tab groups checks by severity, while Info lists technical details such as WordPress, themes, plugins, media handling and server configuration. Read the specific warning and expand its details before taking action. Record its exact wording and compare it with the visible problem. A recommended improvement is a lead to investigate; it does not prove that it caused the symptom. Avoid changing several unrelated settings simply to reduce the number of notices. The Info tab includes an option to copy information. Paste it into a private document first and review every section. For a public question, extract the relevant versions, the precise warning and a short reproduction sequence. Remove personal details, internal paths, private addresses and any sensitive values that another component may add. Review screenshots as carefully as text. Use a private support channel if the investigation genuinely needs more context. Never add passwords, authentication links or configuration files merely because a report was requested. After an authorized correction, repeat the original action and the relevant health check. State what changed and what remains reproducible. This makes the report useful to the next person investigating without exposing unnecessary site details. Sources: WordPress — Site Health screen.

Que el fallo aparezca después de una actualización orienta la investigación, pero no demuestra por sí solo qué componente lo provoca. En este escenario hipotético conviene anotar la hora, el plugin actualizado y qué rutas fallan, y conservar una copia de archivos y base de datos antes de modificar nada. Si WordPress envió el correo de recuperación a la dirección administrativa, su enlace permite entrar en una sesión donde el componente afectado queda pausado. El aviso puede identificar el archivo y el error. Esa pausa se aplica a la sesión de recuperación; para recuperar el servicio general hay que corregir o desactivar el componente y comprobar después el acceso normal. Cuando no llega el correo, el registro de PHP del alojamiento puede aportar el error fatal. En una copia de pruebas también se puede habilitar temporalmente WP_DEBUG y WP_DEBUG_LOG, manteniendo WP_DEBUG_DISPLAY en false y guardando el registro fuera de una ubicación pública. Interesa el primer error relacionado con la petición y su hora, no publicar el registro completo. Si los datos señalan un plugin concreto, renombrar únicamente su carpeta permite probar una desactivación reversible sin borrar sus archivos. Después se verifica el escritorio y una función pública importante. La reparación definitiva se ensaya en pruebas; si hubo cambios en la base de datos, sustituir archivos por una versión anterior puede resultar insuficiente. Al terminar se retira la depuración temporal. Fuentes: Modo de recuperación y Depuración en WordPress.

Yes. The search engine visibility setting requests that search engines avoid indexing the site; WordPress documentation explicitly says it still allows normal visitors. Someone with the URL may therefore open a public page. Treat the checkbox as an indexing preference, rather than evidence that access requires authorization. First decide the intended audience. For an individual post or page, WordPress offers public, password protected and private visibility options. These have different effects, so test the chosen option with an account that represents the intended reader and again while signed out. A password protected page shares access with anyone who knows its password; it is not the same as assigning access to named users. For a whole development site, ask the administrator to configure an appropriate access restriction and demonstrate it from a separate signed-out session. Check direct page URLs and file URLs as separate cases. Do not upload confidential documents until the intended restriction has been verified for the material involved. Before launch, record which access controls and indexing settings should change, who will change them, and how the result will be tested. Removing the checkbox does not establish when a search engine will discover or index a page. When requesting help, share the expected audience and an ordinary test URL. Keep passwords, private files and invitation links out of public discussion. Sources: WordPress — Settings Reading screen · WordPress — Set blog content visibility.

Conservar el dominio simplifica la migración, pero no sustituye una prueba del destino. Prepara un inventario breve: versión de WordPress, plugins, tema, PHP, base de datos, tamaño de uploads, tareas programadas y correo asociado. Ese inventario sirve para comparar ambos entornos y detectar dependencias antes del cambio. No actualices todo a la vez: conviene poder atribuir un fallo a una modificación concreta. 1. Genera una copia de los archivos y de la base de datos, identificada con fecha y hora. Incluye configuración, temas, plugins y contenidos subidos; una exportación de entradas no equivale a una copia completa del sitio. Guarda el respaldo fuera del directorio público y ensaya su recuperación en un entorno aislado. 2. Copia los archivos e importa la base en el destino. Si cambian nombre, usuario o contraseña de la base de datos, ajusta wp-config.php en esa copia. Manteniendo las mismas direcciones del sitio normalmente no hace falta un reemplazo global de URL. Evita un reemplazo SQL indiscriminado: algunos datos de temas o plugins están serializados. 3. Prueba el destino conservando el nombre real del sitio mediante un método local controlado, como una entrada temporal en el archivo hosts de tu equipo. Retírala al terminar. El destino debe reconocer ese dominio y disponer del HTTPS correspondiente; una URL temporal puede ocultar problemas de redirección o recursos. Protege la copia frente al acceso público y desactiva allí correos, cobros y otras acciones externas. Revisa portada, administración, enlaces permanentes, imágenes, búsquedas y formularios con datos de prueba. Después acuerda una pausa de escrituras y una sincronización final de base y archivos antes de cambiar DNS. Esto importa especialmente con pedidos, reservas y comentarios. Conserva el origen hasta confirmar el resultado y define cómo volver atrás sin sobrescribir datos nuevos. La prueba local verifica tu equipo; no confirma todavía qué servidor verá cada visitante. Fuentes: WordPress — Backups · WordPress — Migrating WordPress.

Define primero las tareas: redactar, subir imágenes, publicar, editar contenido ajeno o administrar el sitio son necesidades diferentes. Asigna una cuenta individual para poder revisar y retirar su acceso sin compartir la contraseña de otra persona. En los roles predeterminados, Colaborador puede escribir y gestionar sus entradas, pero no publicarlas; Autor puede publicar las propias; Editor puede gestionar también publicaciones ajenas. Administrador dispone de funciones de administración del sitio y no es una elección adecuada solo para resolver una dificultad al redactar. La documentación de WordPress describe capacidades concretas: los nombres de los roles no representan simplemente una escala de confianza. Comprueba las capacidades efectivas de esta instalación, porque plugins o código propio pueden modificarlas. Haz una prueba con una cuenta del rol previsto: crear un borrador, intentar adjuntar un archivo y enviar el contenido a revisión. Verifica además que no pueda realizar acciones fuera de su encargo. Si falta una capacidad necesaria, documenta el caso antes de ampliar el acceso. Revisa también el rol predeterminado de nuevas altas si el sitio permite registro. No asumas que cambiarlo modifica automáticamente las cuentas existentes. Acuerda quién publicará y qué ocurrirá cuando termine la colaboración. Retirar o reducir permisos forma parte del mantenimiento habitual; antes de eliminar una cuenta, revisa el tratamiento de su contenido. Conserva una relación de responsables y accesos para evitar cuentas olvidadas. Fuentes: WordPress — Roles and Capabilities.

Prepara una hoja de intervención con objetivo, responsable, horario, duración prevista y condición para volver atrás. El resultado debe poder comprobarse: «reinició» dice poco si la web vuelve sin la base de datos o los trabajos pendientes se ejecutan dos veces. Antes de la ventana, confirma el acceso administrativo y la vía de recuperación del servidor. Revisa espacio, estado del almacenamiento, copias recientes y posibles dependencias externas. Si hay base de datos, utiliza su método de respaldo y verifica que la copia se puede recuperar; copiar su directorio activo sin un procedimiento compatible puede no bastar. Anota una línea de base: servicios necesarios, puertos esperados, versión del kernel y una operación sencilla de la aplicación. Después organiza el trabajo: 1. Limita escrituras y detén de forma ordenada los procesos que lo requieran. Ten en cuenta colas, importaciones y tareas programadas. 2. Aplica el cambio previsto y guarda su resultado. Evita añadir actualizaciones ajenas a la intervención. 3. Reinicia utilizando el procedimiento del sistema operativo y observa el arranque. 4. Confirma montajes, red, base de datos, servidor web y trabajos automáticos. 5. Ejecuta la misma prueba funcional inicial y revisa errores nuevos antes de reabrir el servicio. En sistemas con systemd, consulta el estado de las unidades y los fallos; una unidad activa no garantiza que una operación de negocio funcione. Comprueba también desde fuera del servidor. Si la intervención supera el criterio acordado, aplica el plan de recuperación y documenta los datos que podrían quedar fuera del respaldo. La duración y las prestaciones de acceso remoto dependen del servicio concreto; deben verificarse antes de empezar. Fuentes: systemctl · PostgreSQL: recuperación y copias.

Revisa primero una muestra de comentarios recientes y distingue pendientes, aprobados y marcados como spam. El objetivo es reconocer un patrón concreto, como enlaces repetidos, sin convertir una palabra común en una prohibición general. Conserva ejemplos depurados que no incluyan correos ni direcciones IP de participantes. En Ajustes > Comentarios puedes exigir aprobación manual o permitir ciertos comentarios de autores previamente aprobados. También puedes retener comentarios según el número de enlaces o términos de moderación. Estas opciones controlan la cola; no sustituyen una revisión periódica. Las coincidencias de términos pueden aparecer dentro de otras palabras, de modo que una entrada demasiado corta puede afectar mensajes legítimos. Cambia una regla cada vez y envía un comentario de prueba con contenido normal y otro que reproduzca el patrón previsto. Comprueba dónde termina cada uno. Revisa además el ajuste de comentarios de las entradas afectadas: la política general y una publicación concreta pueden requerir comprobaciones distintas. Antes de ampliar listas de bloqueo, observa la cola durante un periodo acordado y corrige falsos positivos. En la pantalla de comentarios puedes recuperar un mensaje clasificado erróneamente como spam mediante la opción correspondiente. Define quién revisará los pendientes y con qué frecuencia. Si se incorpora una herramienta adicional, evalúa sus resultados y su tratamiento de datos. Ninguna regla garantiza eliminar todo el spam sin supervisión. Fuentes: WordPress — Settings Discussion screen · WordPress — Comments in WordPress.

Trata el aviso como una incidencia de almacenamiento y conserva la evidencia antes de tocar el arreglo. «Degradado» no identifica por sí solo la unidad que debe retirarse ni garantiza que todos los datos estén sanos. Primero determina si utilizas RAID por software, una controladora o una solución administrada. Reúne estos datos con herramientas de consulta: - Nivel RAID, estado del arreglo y cantidad de miembros presentes. - Dispositivo lógico, identificadores persistentes y número de serie de cada unidad. - Bahía física correspondiente, registros de errores y hora del primer aviso. - Estado de las copias externas y fecha de la última restauración comprobada. En Linux MD, el estado y los contadores permiten observar la degradación y la recuperación. Con una controladora, utiliza su documentación y utilidad correspondientes. Los nombres como /dev/sdb no sustituyen una identificación física: pueden cambiar y no indican por sí solos qué disco retirar. Confirma el respaldo y prepara el procedimiento específico antes de sustituir hardware. Verifica compatibilidad de la unidad, capacidad y condiciones de conexión o extracción en caliente. Una reconstrucción puede tardar y competir con la carga normal; monitoriza su avance y cualquier nuevo error. No recrees el arreglo, formatees miembros ni fuerces su ensamblado para borrar el aviso. La documentación del kernel advierte de riesgos especiales en ciertos arreglos simultáneamente degradados y sucios. Esa situación requiere evaluar la recuperación antes de escribir. Si el servidor es administrado, entrega los identificadores y registros al responsable del hardware. Da la incidencia por resuelta cuando el arreglo recupere su estado esperado y se verifiquen datos y alertas. El RAID aporta disponibilidad frente a fallos concretos; no recupera por sí solo una eliminación accidental. Fuentes: Linux MD · Red Hat: administración de RAID.

Empieza desde la dirección de acceso conocida del sitio y comprueba que utilizas HTTPS y el dominio correcto. El enlace de contraseña perdida permite iniciar la recuperación con el nombre de usuario o el correo de la cuenta. Revisa también spam y las reglas del buzón si el mensaje no aparece; repetir solicitudes continuamente no ayuda a identificar un problema de entrega. Utiliza el mensaje de recuperación únicamente en una sesión de confianza. No publiques su enlace, capturas con códigos ni la nueva contraseña en un foro. Si existe otra cuenta administradora autorizada, puede ayudar a restablecer el acceso desde la gestión de usuarios, tras confirmar qué cuenta corresponde a la persona solicitante. Si tampoco hay acceso al correo o a otra cuenta administradora, documenta qué accesos legítimos conservas y solicita ayuda por un canal privado. La guía oficial contempla varios métodos según esos accesos. Las modificaciones de archivos o datos requieren identificar la instalación correcta y disponer de recuperación; evita copiar instrucciones de otra web sobre una tabla que no has comprobado. Al recuperar la cuenta, establece una contraseña larga y exclusiva, guárdala en un gestor y comprueba el correo del perfil. Activa autenticación adicional si la solución instalada la ofrece. Si aparecen cambios desconocidos, conserva evidencias y revisa el incidente: recuperar la contraseña por sí solo no explica quién pudo entrar. Fuentes: WordPress — Reset your password · WordPress — Hardening WordPress.

Antes de decidir, pregunta qué incluye exactamente cada herramienta. La palabra «instantánea» puede referirse a discos, a una cadena de imágenes o al estado de una máquina completa. Su ubicación y sus dependencias importan tanto como la fecha. No presupongas que una instantánea almacenada junto al disco constituye una copia independiente. Para una actualización, una instantánea puede facilitar el regreso a un punto anterior. Para recuperar una pérdida del almacenamiento original necesitas una copia utilizable fuera de ese fallo. Comprueba si puedes exportarla, qué discos incluye, cuánto espacio requiere y cómo se restaura. La documentación de libvirt diferencia las operaciones de respaldo y sus requisitos; no todos los paneles exponen las mismas funciones. La coherencia de los datos merece una comprobación separada. Copiar archivos de una base de datos mientras escribe puede no producir una recuperación válida. Utiliza un método admitido por el motor, una pausa coordinada o mecanismos de instantánea que cumplan sus condiciones. PostgreSQL, por ejemplo, documenta requisitos específicos para las copias a nivel de sistema de archivos. Un resultado correcto en un motor no valida automáticamente otro. Haz una prueba de restauración en una red aislada. Confirma arranque, acceso, registros recientes y funcionamiento de la aplicación. Evita que esa copia envíe correos, ejecute cobros o atienda el mismo tráfico que producción. Por último, acuerda cuánto dato puedes perder y cuánto tiempo puedes tardar en recuperar. Si vuelves a una instantánea tras recibir pedidos nuevos, esos pedidos pueden quedar fuera del estado restaurado. Documenta ese límite antes de intervenir, conserva la copia independiente y establece una retención acorde con tus necesidades. Fuentes: libvirt: copia completa de discos · PostgreSQL: copias del sistema de archivos.

Registra primero el tamaño exacto del archivo, su tipo y el mensaje de rechazo. Prueba una copia pequeña del mismo formato para distinguir un límite de tamaño de otro problema. Que una imagen comprimida funcione no demuestra que un archivo mayor pueda procesarse. WordPress calcula su límite inicial tomando el menor valor entre upload_max_filesize y post_max_size; además permite que otros componentes filtren ese resultado. El primero limita cada archivo y el segundo limita el conjunto de datos de la petición. PHP indica que post_max_size debe ser mayor que upload_max_filesize, por lo que conviene dejar margen para los demás datos del envío. Consulta los valores efectivos del PHP que atiende la web mediante las herramientas disponibles para esa instalación. Un archivo de configuración editado o el PHP de consola pueden no reflejar la configuración utilizada por la petición web. Anota los valores anteriores antes de solicitar un cambio autorizado. Si los valores parecen suficientes, pide comprobar la restricción que aplica la infraestructura al envío concreto y aporta hora, tamaño y error depurado. Evita publicar un informe completo del servidor. Aumentar límites sin identificar cuál rechaza la petición puede no resolverla. Después de cualquier ajuste, repite una subida controlada y comprueba que aparece correctamente en la biblioteca. Para imágenes destinadas a una página, revisa también si realmente necesitas sus dimensiones y peso originales. Fuentes: WordPress — wp_max_upload_size() · PHP — Directivas post_max_size y upload_max_filesize.

La capacidad pasa por varias capas: disco virtual, tabla de particiones, volumen si existe y sistema de archivos. Ampliar la primera no obliga a las demás a ocupar el espacio nuevo. Antes de ejecutar herramientas de escritura, prepara una copia recuperable y confirma el acceso a consola. Empieza con una inspección de solo lectura. En Linux, lsblk -f ayuda a ver dispositivos, sistemas de archivos y montajes; df -hT muestra la capacidad del sistema de archivos montado. Si utilizas LVM, revisa además sus volúmenes físicos, grupos y volúmenes lógicos. Compara estos datos con el tamaño que el sistema operativo reconoce para el disco. El resultado determina la intervención: - Si el invitado todavía ve el tamaño antiguo, falta resolver la detección del disco según la plataforma y la distribución. - Si el disco creció y la partición no, hay que evaluar su posición, el espacio contiguo y las capas que contiene. - Si el volumen ya tiene capacidad, puede quedar pendiente ampliar el sistema de archivos. Las herramientas dependen del formato. XFS y ext4 tienen procedimientos distintos; no intercambies sus comandos ni confundas ampliar con reducir. También puede haber cifrado, RAID o un diseño sin particiones que cambie el orden. No copies un ejemplo con /dev/sda suponiendo que corresponde a tu raíz. Identifica dispositivo, montaje y formato reales y consulta la guía de tu distribución. En una raíz activa, decide de antemano si hacen falta mantenimiento o reinicio. Al finalizar, confirma tamaño, montaje, espacio utilizable y ausencia de errores. Conserva el inventario anterior y posterior. La diferencia entre capacidad anunciada y visible también puede incluir unidades de medida y espacio reservado. Fuentes: Red Hat: sistemas de archivos · Ampliación de XFS.

Distingue estructura y contenido antes de preparar el traslado. Drupal trata como configuración elementos como tipos de contenido, campos y vistas. Los artículos concretos y sus archivos pertenecen a otros datos del sitio; una exportación de configuración no constituye una copia completa. Define qué cambio quieres desplegar y revisa la diferencia exportada. Un nuevo campo puede necesitar su definición, ajustes de presentación y dependencias. No presupongas que copiar un solo archivo YAML reúne todo lo necesario. Conserva el conjunto probado en el flujo de versiones del proyecto. La sincronización completa está pensada para entornos del mismo sitio y comprueba su UUID. Si aparece una discrepancia, investiga el origen de las instalaciones antes de alterar identificadores para superar el control. Comprueba también cambios de configuración realizados directamente en producción que podrían sobrescribirse. Ensaya la importación con una copia reciente y una base respaldada. Revisa las operaciones propuestas, sobre todo eliminaciones de campos o tipos, y valida qué ocurre con los datos existentes. La configuración puede tener efectos sobre la estructura que utiliza ese contenido. Si necesitas trasladar artículos o imágenes, prepara una migración o un procedimiento específico para esos datos, con sus referencias. Al terminar, prueba creación, edición y visualización. Guarda evidencia depurada del cambio y un plan de recuperación; no sustituyas la base pública por la de pruebas para mover únicamente una estructura. Fuentes: Drupal — Managing site configuration · Drupal — Configuration and other information.

La carga media de Linux no es un porcentaje de uso de CPU. Incluye tareas ejecutables y tareas en espera no interrumpible, así que puede subir mientras parte de los procesadores permanece libre. Para interpretar el dato necesitas conocer el número de CPU y observar una ventana de tiempo, no una sola captura. Recoge muestras durante la lentitud y durante un periodo normal. Relaciona la hora con peticiones, copias, consultas de base de datos y trabajos programados. Después compara: - CPU por núcleo y procesos que consumen tiempo de cálculo. - Memoria disponible, actividad de intercambio y mensajes de procesos terminados por falta de memoria. - Latencia, cola y actividad de disco, junto con procesos que esperan operaciones de entrada y salida. Si el kernel y la configuración lo permiten, los archivos de /proc/pressure/ muestran presión de CPU, memoria y entrada/salida. Ayudan a reconocer tiempo perdido por contención, pero no identifican por sí solos el programa responsable. La información de /proc también permite contrastar carga, memoria y estadísticas del sistema. No concluyas que falta RAM solo porque haya poca memoria libre: Linux utiliza memoria para cachés. Tampoco atribuyas toda la espera de disco a una avería; una copia o una consulta intensa pueden producirla. Una vez identificado el proceso, revisa su comportamiento y modifica una sola variable. Pausar una tarea prescindible en una ventana controlada puede ayudar a confirmar la relación. Evita reiniciar antes de recoger evidencia si el servicio sigue accesible, porque perderías el estado que intentas explicar. Para pedir ayuda comparte intervalos, recursos asignados y métricas depuradas, sin volcados con datos privados. Fuentes: Linux: /proc · Linux: presión de recursos.

Anota la última ejecución que muestra el sitio y qué tarea concreta parece retrasada. Drupal utiliza cron para trabajos periódicos; los módulos pueden añadir tareas propias. El hecho de que una petición web responda no demuestra que ese mantenimiento se haya completado. Revisa la configuración de cron y el mecanismo que utiliza el proyecto: ejecución automatizada dentro de Drupal o programación externa. No añadas un segundo disparador sin identificar el existente. Si la frecuencia depende de visitas, compara esa condición con el tráfico real y la necesidad del sitio. Con acceso administrativo autorizado, realiza una ejecución controlada desde la interfaz que documente tu versión y guarda la hora. Comprueba el resultado y los registros cercanos al intento. Si Database Logging está habilitado, los mensajes recientes permiten seguir eventos y errores; otros proyectos pueden enviarlos a un registro externo. Busca límites de tiempo, una excepción de módulo o una tarea que no termina. Evita repetir el botón continuamente: varios intentos pueden ocultar la secuencia y aumentar la carga. Reproduce la causa en una copia cuando sea posible. Después verifica tanto la marca temporal como el resultado esperado de la tarea. Para escalar, comparte versión, método de ejecución y error depurado. Mantén privadas las URL con claves de cron y cualquier contenido de correos o colas. Un cambio de frecuencia no sustituye corregir una tarea que falla. Fuentes: Drupal — Cron automated tasks · Drupal — Database Logging overview.

Conserva una sesión administrativa abierta mientras preparas el cambio y comprueba que dispones de una vía de recuperación independiente, como la consola del servidor, si el servicio la ofrece. Antes de desactivar contraseñas debes haber demostrado que puedes entrar con tu llave desde una segunda conexión. 1. Crea o utiliza una llave personal protegida y añade su clave pública a la cuenta prevista. La clave privada permanece en tu equipo. Comprueba propietario y permisos según la documentación de tu distribución. Si necesitas administrar el sistema con esa cuenta, verifica también su acceso autorizado a elevación de privilegios. 2. Abre una conexión nueva y confirma que la autenticación realmente utiliza la llave. Revisa la configuración efectiva: archivos incluidos y bloques Match pueden cambiar el comportamiento para usuarios o direcciones concretos. Guarda una copia de los archivos antes de modificarlos. 3. Configura las opciones de autenticación que correspondan a tu política. Desactivar solo PasswordAuthentication puede dejar disponible la autenticación interactiva por teclado; revisa también ese método y cualquier requisito de varios factores. Valida la sintaxis con el modo de comprobación de sshd antes de recargar el servicio, usando la ruta y el procedimiento de tu distribución. Vuelve a conectar desde otra sesión después de aplicar el cambio y confirma que el acceso esperado funciona. No cierres la sesión inicial hasta completar esa prueba. Si falla, restaura la configuración desde la sesión conservada o la consola y revisa los registros. Cambiar el puerto no reemplaza la autenticación segura ni las actualizaciones. Fuentes: OpenSSH: configuración · Ubuntu: servidor OpenSSH.

Guarda el error completo y la ruta que no puede escribirse. Comprueba qué usuario ejecutó la intervención y cuáles utilizan el servidor web, cron y la consola del proyecto. Un archivo creado por otro usuario puede impedir operaciones posteriores aunque el código no haya cambiado. Adobe distingue el propietario del sistema de archivos y el usuario del servidor web. En una configuración con dos usuarios, documenta el uso de un grupo compartido y permisos adecuados. Las necesidades también dependen del modo de ejecución y del proceso de despliegue. Compara los propietarios y permisos de la ruta afectada con una instalación o configuración conocida del mismo proyecto. No copies una receta recursiva sin confirmar su raíz y modelo de usuarios. Permitir escritura a cualquiera en todo el árbol no resuelve correctamente la coordinación entre procesos. Aplica la corrección mediante el procedimiento de administración acordado, conservando los valores anteriores. Los comandos de Magento deben ejecutarse con el usuario que indique el proyecto y la documentación. Evita normalizar el uso de root para tareas rutinarias. Después verifica una petición pública, una operación administrativa y la siguiente ejecución automática relacionada. Revisa que el código que debe permanecer protegido conserve ese alcance. Para pedir ayuda, entrega ruta, error y propietarios depurados; excluye archivos de configuración con secretos. Documenta el usuario correcto para que la siguiente intervención no repita el problema. Fuentes: Adobe Commerce — File systems access permissions · Adobe Commerce — File ownership and permissions.

Cron ejecuta un comando en un contexto distinto de tu terminal interactiva. Puede cambiar el directorio inicial, el entorno y el ejecutable encontrado. Empieza por guardar el comando exacto y la programación actual; después prueba con el mismo usuario que ejecutará la tarea. No uses privilegios adicionales solo para ocultar un error de permisos. 1. Utiliza rutas absolutas para el intérprete y para el script. Si el programa espera archivos relativos, configura explícitamente su directorio de trabajo o ajusta sus rutas. En PHP comprueba la versión y el archivo de configuración del ejecutable CLI; no asumas que coincide con el PHP del dominio. 2. Redirige temporalmente la salida estándar y los errores a un registro privado que puedas consultar. Usa un nombre y una ubicación fuera de la raíz pública, con espacio disponible y permisos adecuados. Registra inicio, fin y código de salida. Evita enviar contraseñas como argumentos o volcarlas en el registro. 3. Revisa la frecuencia y la duración. La documentación de Cron Jobs recomienda dejar tiempo suficiente entre ejecuciones para evitar que una comience antes de terminar la anterior. Si el trabajo puede tardar de forma variable, utiliza el mecanismo de exclusión o bloqueo que admita tu aplicación y prueba su comportamiento. Comprueba también la zona horaria utilizada para interpretar el horario y los permisos para leer configuración, escribir resultados y conectar con servicios externos. Una ejecución manual satisfactoria no valida todavía su horario automático. Cuando hayas localizado la causa, realiza una prueba programada y confirma un único resultado completo. Retira la captura detallada de depuración y conserva un registro breve con rotación. Si no puedes observar la ejecución desde tu cuenta, comparte comando sin secretos, horario, hora esperada y error; esos datos permiten revisar la configuración sin adivinar. Fuentes: cPanel — Cron Jobs · PHP — Command line usage.

Identifica el SKU y el stock asociado al sitio web desde el que se consulta. En Inventory Management, tener unidades en un origen no equivale por sí solo a tener esa cantidad disponible para cualquier canal. Revisa primero asignaciones y configuración del producto. Las reservas afectan a la cantidad vendible. Adobe documenta que un pedido puede reservar unidades antes de que se descuenten físicamente al enviarlo, y que eventos posteriores generan compensaciones. Por eso las cantidades físicas y vendibles pueden diferir durante el recorrido normal de un pedido. Busca un ejemplo controlado y revisa sus estados y movimientos. Considera también el umbral de falta de existencias y la configuración de pedidos pendientes. No elimines reservas ni reasignes orígenes solo para que una cifra parezca correcta: podría afectar a pedidos que todavía requieren esas unidades. Si la diferencia persiste tras completar el recorrido previsto, revisa los procesos automáticos y las herramientas de diagnóstico de la versión instalada con una persona que conozca el proyecto. Conserva una copia y ensaya cualquier corrección fuera de producción. Valida con un producto de prueba y un canal concreto, sin generar cobros reales. Para solicitar ayuda, comparte SKU ficticio, configuración relevante y secuencia depurada. Excluye datos de compradores. El objetivo es explicar el cálculo y su actualización, no forzar una cantidad mediante modificaciones directas de tablas. Fuentes: Adobe Commerce — Source algorithms and reservations · Adobe Commerce — Reservations.

Los registros que cuentan para los receptores son los publicados por el DNS autoritativo. Si el dominio utiliza servidores de nombres externos, guardar una recomendación solo en la zona local de cPanel puede no cambiar la respuesta pública. Antes de editar, identifica dónde se administra la zona y conserva sus valores actuales. 1. En Email Deliverability, si está habilitado, revisa el nombre y el valor sugeridos para DKIM y SPF. cPanel indica que, cuando no es autoritativo, esos datos deben publicarse también en el proveedor de DNS correspondiente. Copia el registro público, nunca la clave privada DKIM. 2. Haz un inventario de los emisores legítimos: correo del servidor, plataforma transaccional y cualquier otro servicio que realmente envíe usando ese dominio. No reemplaces el SPF existente por una recomendación sin comprobar qué autorizaciones perderías. Para el mismo nombre no deben publicarse varias políticas TXT que comiencen por v=spf1; el resultado puede ser un error de evaluación. Integra únicamente las autorizaciones documentadas y revisa el límite de búsquedas DNS del protocolo. 3. Comprueba el nombre completo que pide cada selector DKIM. Algunos paneles añaden automáticamente el dominio, así que revisa el resultado final para evitar repetirlo. Respeta el formato indicado por el proveedor y consulta después el registro público. Envía una prueba desde cada emisor y examina los resultados de autenticación del mensaje recibido. Que un registro aparezca correcto no garantiza la bandeja de entrada: también intervienen otras políticas, reputación y contenido. Conserva la hora de la modificación y el resultado de las consultas. No endurezcas una política DMARC como sustituto de este inventario. Antes de aplicar rechazos, verifica la alineación y los flujos legítimos. Si pides ayuda, comparte nombres de registros y resultados depurados; excluye claves privadas y credenciales SMTP. Fuentes: cPanel — Email Deliverability · RFC 7208 — SPF.

Confirma primero que existen dos artículos equivalentes y que cada uno tiene asignado su idioma. Instalar un paquete de idioma traduce elementos de la interfaz, pero la relación entre contenidos se configura aparte. Joomla llama asociación al vínculo entre elementos equivalentes de varios idiomas. Abre la pestaña de asociaciones del artículo y selecciona su equivalente correcto. La guía oficial indica que el idioma All no sirve para estas asociaciones. Revisa títulos y contenido para no vincular por accidente una página que solo tenga un nombre parecido. Comprueba también las categorías y los elementos de menú que conducen a esos artículos. Joomla ofrece asociaciones para varios tipos de elemento; un enlace de navegación necesita una revisión propia. Anota la ruta que sigue el selector desde una página interior, además de la portada. Prueba sin sesión y con cada idioma disponible. Confirma que el destino está publicado, es accesible para el público previsto y representa el mismo contenido. Una relación lingüística no concede permisos ni traduce automáticamente el texto. Si el enlace sigue llevando a una página inesperada, registra URL de origen, idioma seleccionado y destino exacto. Cambia una asociación cada vez y conserva el valor anterior. Para una consulta pública, usa páginas de ejemplo y capturas sin información editorial privada; evita rehacer toda la estructura multilingüe antes de localizar el vínculo concreto. Fuentes: Joomla — Edit Associations · Joomla — Languages.

Primero confirma si realmente estás cambiando un dominio independiente. Varias direcciones pueden compartir archivos, configuración o una aplicación. Guarda la versión actual y la configuración relevante, identifica la raíz de documentos y prepara una copia recuperable de la web y su base de datos. Haz el ensayo en un entorno de pruebas equivalente. 1. Consulta los requisitos del CMS y de sus extensiones. Selecciona una rama de PHP con soporte vigente y compatible con la aplicación; que una versión aparezca en el menú no garantiza que siga recibiendo actualizaciones de seguridad. La tabla oficial de PHP indica los periodos de soporte. 2. Si MultiPHP Manager está disponible, revisa la selección por dominio y la opción de heredar la versión del sistema. El menú depende de lo instalado y permitido para la cuenta. Anota el estado antes de aplicar un cambio y selecciona únicamente el dominio previsto. La documentación también advierte que modificar PHP-FPM en dominios con la misma raíz de documentos afecta a todos los que la comparten. 3. Comprueba extensiones PHP, límites necesarios y registros de errores en la copia. Prueba inicio de sesión, formularios, subida de archivos, tareas programadas y acciones administrativas. El PHP que utiliza una tarea por terminal puede ser diferente del que sirve la web; comprueba ambos contextos por separado. Prepara una ventana para el cambio definitivo y un criterio de reversión. Si aparece un error, conserva el mensaje y vuelve a la configuración anterior cuando siga disponible y sea apropiado. Después corrige la incompatibilidad en pruebas. Si una política del servidor impide regresar a la versión previa, resuélvelo antes de intervenir. No dejes un archivo público con información detallada de PHP como prueba permanente. Registra versiones y resultados de forma privada y comparte únicamente el error depurado que permita investigar. Fuentes: cPanel — MultiPHP Manager · PHP — Supported Versions.