PHP – Blog SitiosHispanos.Com

Divi: Las razones detrás del error “Divi Builder not saving changes”

¿Le salta el error “Divi Builder not saving changes” en su sitio web?

Es el peor escenario. Realizó un gran cambio en su sitio web o creo una página desde cero después de horas de trabajo; así que ya es momento de guardar la tarea realizada, cerrar el Divi Builder y ver el resultado final en el sitio web. Pero, cuando hace clic en el botón de Guardar, un pequeño pop-up se abre y le marca: “Your Save Has Failed”.

Sabemos lo amargo de esta experiencia. Nadie quiere tener este problema en su trabajo. Por suerte se pudo descubrir cuatro razones por la cual esto sucede; en pos de poder evitar este error en el futuro.

Las razones por las cuales Divi no está guardando los cambios.

Si empezamos a investigar este problema, podemos encontrar estas cuatro razones por las cuales surge este error:

Falta de recursos en el plan de alojamiento.
Errores en la configuración de código.
Disputas entre diferentes cachés.
Conflictos con un plugin o un theme.

Cómo resolver la falta de recursos.

La mejor manera de chequear este problema es revisar los recursos del plan de alojamiento que posee. Lo más simple aquí es también saber los requerimientos mínimos que exige Divi para funcionar correctamente, los cuales son:

PHP Version = 7.4 mínimo (Se recomienda: 8.0+).
Database = MySQL versión 5.7 o mayor; MariaDB versión 10.2 o mayor.
WordPress = 5.3 o mayor.
WordPress memory_limit = 128MB
memory_limit a nivel plan de alojamiento = 256MB
post_max_size = 128MB
max_execution_time = 300 segundos
upload_max_filesize = 64MB
max_input_time = 600
max_input_vars = 6000

Esto puede controlarlo desde Divi Settings, en la siguiente ruta:

WordPress Dashboard => Divi => Support Center => System Status => Show Full Report

Este reporte muestra el estado del sistema. Si algún recurso está marcado con un círculo rojo implica que la falta del mismo hace que Divi no pueda guardar los cambios.

Cómo resolver los errores de código.

Este problema ocurre con errores de sintaxis en el código. Un código corrupto puede ser el responsable de que Divi no pueda guardar correctamente los cambios. Abajo, un error común que lleva a problemas en el código:

Controle errores de sintaxis en el código CSS. El código CSS que agrega puede estar con errores de configuración, quizás con errores de puntuación como que falte un paréntesis, o que haya escrito mal una variable.

Puede confirmar si el problema está ocurriendo por alguna edición manual del código CSS removiendo todo ese código editado de su Divi. Puede hacerlo desde el panel de su WordPress, en: Divi> Theme Options => General => Custom CSS.

Allí, puede ver todo el código agregado a su sitio. Remuevalo a todo. Si esta acción resuelve el conflicto, entonces busque el error en el código agregado.

De manera similar a los descripto aquí arriba, debería buscar errores de código HTML de su sitio web.

Cómo resolver las disputas entre diferentes cachés.

Cachear data es un mecanismo beneficioso. Mejora la velocidad de carga del sitio; reduce el consumo de ancho de banda. Aún así, hay veces que su navegador retiene versiones de caché que entran en conflicto con su Divi Builder.

Los navegadores usualmente guardan imágenes, HTML, CSS, Javascript, etc. en el disco de su computadora cuando visita un sitio web por primera vez. Así, puede recuperarse más rápido la información al volver a ingresar al sitio web.

Lo que puede hacer aquí es abrir el dominio con una ventana de incógnito o usar otro navegador web. Si aquí ve los cambios en el sitio aplicados de manera correcta, entonces está teniendo un problema de caché en su navegador de uso regular. Pruebe entonces borrar la caché de su navegador.

De manera similar, si posee un plugin que realice una tarea de Caché, deberá dirigirse al panel de dicho plugin y hacer un refresh o limpieza de caché. Puede incluso que sea necesario que deba desactivar dicho plugin.

Cómo resolver conflictos con un plugin o theme.

Puede suceder que este problema surja porque dos o mas plugins no trabajan correctamente de manera conjunta.

Puede activar el “Safe Mode” desde su panel: Divi => Support Center => Safe Mode. Plugins de terceros son desactivados en este modo. Así, puede detectar si el conflicto lo genera un plugin.

También, puede desinstalar todos los plugins. Si todo fuciona correctamente después de esto, entonces un plugin es el responsable del problema. Debe entonces activar todos los plugins, de a uno. Asegúrese de abrir el sitio web en una ventana de incógnito cada vez que activa un plugin, para corroborar si ese es el conflictivo.

Cuando descubra cual es, puede reemplazarlo por otro o directamente eliminarlo de su sitio web.

De igual manera, un theme secundario puede estar causando conflicto. Para esto, reactive a Divi como el theme principal; así, los archivos del theme secundario no tendrán mas efecto sobre el sitio. Si esto soluciona su conflicto, he aquí que el theme secundario era el problemático.

¿Algún otro conflicto?

Puede que existan algunas otras causas que conlleven a el problema de no poder guardar los cambios en Divi. Puede que la sesión de timeout, ya que sin darnos cuenta nos logueamos hace tiempo y nuestra sesión se desconectó de la base de datos. También puede ser posible que debamos controlar las versiones de WordPress; del Theme y de los plugins que estamos usando. Los mismos deben estar siempre actualizados a sus últimas versiones.

Fuente: https://diviflash.com/divi-builder-not-saving-changes/

¿Sabes qué son los max children?

¿Alguna vez has sentido que tu sitio web en WordPress está lento o que en ocasiones se cae y vuelve? Y cuando te comunicas con el soporte, te responden diciendo: “Has excedido los límites de max children”.

Lo primero que debemos saber es que los max children están asociados a las solicitudes PHP. Por lo tanto, si tu sitio web está desarrollado en PHP o utiliza un CMS como WordPress, es posible que en algún momento te encuentres con los max children excedidos.

Cuando se habla técnicamente sobre los max children, nos referimos al número de solicitudes o procesos de PHP-FPM que pueden ejecutarse de manera simultánea en un servidor. Este parámetro tiene valores por defecto o valores predeterminados.

¿Cuáles son las consecuencias de los max children?

Un exceso de los max children provoca una ralentización del sitio web. Puede que en tu navegador se muestre una pantalla en blanco, errores o este latente al intentar acceder al sitio. Es importante recalcar y tener en cuenta que esto, solo ocurre si las páginas o sitios web están escritos en PHP.

Por lo general, este tipo de incidentes se pueden solucionar sin intervención de soporte técnico.

Prevención y recomendaciones

Siempre es importante corregir y optimizar el código PHP utilizado en nuestro sitio web, adecuándose a la versión de PHP más reciente. Si utilizas WordPress, es ideal que los temas y plugins sean compatibles con la versión utilizada por el WordPress instalado. Esto puede evitar que los límites de max_children sean excedidos.

También se deben utilizar los plugins necesarios y que realmente hagas usos de los mismos.

Debes tener en cuenta que cada plan de hosting utiliza un valor predefinido para max_children. Si necesitas aumentar el parámetro de max_children, puedes considerar cambiar de plan de hosting.

Para conocer lo que incluyen nuestros planes de hosting visita: Sitios Hispanos

Cómo arreglar el “500 Internal Server Error” en WordPress

¿Estás viendo un error de servidor interno 500 en WordPress? El error interno del servidor es uno de los errores más comunes de WordPress. Dado que el error no brinda ninguna otra información, muchos principiantes lo encuentran bastante frustrante. En este artículo, le mostraremos cómo corregir fácilmente el error interno del servidor en WordPress.

Cómo reparar el error interno del servidor en WordPress

¿Qué causa el error interno del servidor en WordPress?

El error interno del servidor no es específico de WordPress. Puede suceder con cualquier sitio web que se ejecute en un servidor web. Debido a la naturaleza genérica de este error, no le dice nada al desarrollador.

Preguntar cómo solucionar un error interno del servidor es como preguntarle a su médico cómo solucionar el dolor sin decirle dónde está el dolor.

Ejemplo de un sitio web de WordPress que muestra un error interno del servidor

El error interno del servidor en WordPress a menudo es causado por funciones de complementos o temas. Otras posibles causas de error interno del servidor en WordPress que conocemos son: archivo .htaccess corrupto y límite de memoria PHP.

También hemos escuchado un error interno del servidor que solo aparece cuando intenta acceder al área de administración mientras el resto del sitio funciona bien.

Dicho esto, ahora echemos un vistazo a cómo solucionar el error del servidor interno en WordPress.

Comprobación de archivos .htaccess dañados

Lo primero que debe hacer al solucionar el error del servidor interno en WordPress es buscar el archivo .htaccess dañado.

Puede hacerlo cambiando el nombre de su archivo .htaccess a algo como .htaccess_old. Para cambiar el nombre del archivo .htaccess, deberá iniciar sesión en su sitio mediante FTP o la aplicación Administrador de archivos en el panel de control de cPanel de su cuenta de alojamiento.

Una vez que se haya conectado, el archivo .htaccess se ubicará en el mismo directorio donde verá carpetas como wp-content, wp-admin y wp-includes.

Edición del archivo .htaccess en WordPress

Una vez que haya cambiado el nombre del archivo .htaccess, intente visitar su sitio para ver si esto resolvió el problema. Si lo hizo, entonces date una palmadita en la espalda porque solucionaste el error interno del servidor.

Antes de continuar con otras cosas, asegúrese de ir a la página Configuración » Enlaces permanentes en el área de administración de WordPress y haga clic en el botón Guardar sin realizar ningún cambio. Esto generará un nuevo archivo .htaccess para usted con las reglas de reescritura adecuadas para garantizar que sus páginas de publicación no devuelvan un error 404 .

Si la búsqueda de la solución del archivo .htaccess corrupto no funcionó para usted, entonces debe continuar leyendo este artículo.

Aumentar el límite de memoria de PHP

A veces, puede ocurrir un error interno del servidor si está agotando su límite de memoria PHP.

Si aumentar el límite de memoria solucionó el problema por usted, entonces solo ha solucionado el problema temporalmente. Todavía necesita encontrar la causa que está agotando su límite de memoria.

Esto podría ser un complemento mal codificado o incluso una función del tema. Le recomendamos que le pida a su empresa de alojamiento web de WordPress que busque en los registros del servidor para ayudarlo a encontrar los diagnósticos exactos. Usted mismo también puede rastrear el problema activando el modo Debug en el WordPress Toolkit.

Si aumentar el límite de memoria de PHP no solucionó el problema, entonces tendrá que solucionar más problemas.

Desactivar todos los complementos

Si ninguna de las soluciones anteriores funcionó para usted, lo más probable es que este error se deba a un complemento específico. También es posible que sea una combinación de complementos que no funcionan bien entre sí.

Lamentablemente, no hay una manera fácil de averiguarlo. Tienes que desactivar todos los complementos de WordPress a la vez.

Si al deshabilitar todos los complementos se corrigió el error, entonces sabrá que es uno de los complementos el que está causando el error.

Simplemente vaya al área de administración de WordPress y haga clic en ‘Complementos’. Ahora necesita reactivar un complemento a la vez hasta que encuentre el que causó el problema. Deshágase de ese complemento e informe el error al autor del complemento.

Volver a cargar archivos principales

Si la opción del complemento no solucionó el error interno del servidor, vale la pena volver a cargar la carpeta wp-admin y wp-includes desde una instalación nueva de WordPress.

Esto NO eliminará ninguna parte de su información, pero puede resolver el problema en caso de que algún archivo esté dañado.

Primero deberá visitar el sitio web de WordPress.org y hacer clic en el botón Descargar.

Esto instalará el archivo zip de WordPress en su computadora. Debe extraer el archivo zip y dentro de él encontrará una carpeta de wordpress.

A continuación, debe conectarse a su sitio web de WordPress utilizando un cliente FTP. Una vez conectado, vaya a la carpeta raíz de su sitio web. Es la carpeta que contiene las carpetas wp-admin, wp-includes, wp-content.

En la columna de la izquierda, abra la carpeta de WordPress en su computadora. Ahora debe seleccionar las carpetas wp-includes y wp-admin y luego hacer clic derecho y seleccionar ‘Cargar’.

Su cliente FTP ahora transferirá esas carpetas a su servidor. Le preguntará si desea sobrescribir los archivos. Seleccione ‘Sobrescribir’ y luego seleccione ‘Usar siempre esta acción’.

Su cliente FTP ahora reemplazará sus archivos antiguos de WordPress con copias nuevas y nuevas. Si sus archivos de WordPress estaban dañados, este paso solucionará el error interno del servidor por usted.

Pregunte a su proveedor de alojamiento

Si todos los métodos no logran corregir el error interno del servidor en su sitio web, entonces es hora de obtener más ayuda. Póngase en contacto con su equipo de soporte de alojamiento web y podrán verificar los registros del servidor y localizar la causa raíz del error.

Fuente:

https://www.wpbeginner.com/wp-tutorials/how-to-fix-the-internal-server-error-in-wordpress/

PHP. Versiones del mismo. Cómo se clasifican.

Algo que sucede normalmente en el mundo del desarrollo de software, es el continuo avance para mejorar y optimizar el código, los proyectos y aplicaciones.
Existen muchas formas de asignar una versión al software, puede variar dependiendo de la empresa; pero como todo en este mundo se busca generar unas reglas y pautas que sirvan como guía.

Es importante tener en cuenta que existen diferentes maneras para asignar versiones y cada quien puede seguir las que desee.

Versiones por número.

Algo común es realizar el manejo de versiones mediante 3 números: X.Y.Z y cada uno indica una cosa diferente:

El primero (X) se le conoce como versión mayor y nos indica la versión principal del software. Ejemplo: 1.0.0, 3.0.0
Versión mayor o X, es cuando se agregan nuevas funcionalidades importantes, puede ser como un nuevo modulo o característica clave para la funcionalidad.

El segundo (Y) se le conoce como versión menor y nos indica nuevas funcionalidades. Ejemplo: 1.2.0, 3.3.0
Versión menor o Y, es cuando se hacen correcciones menores, cuando se arregla un error y se agregan funcionalidades que no son cruciales para el proyecto.

El tercero (Z) se le conoce como revisión y nos indica que se hizo una revisión del código por algun fallo. Ejemplo: 1.2.2, 3.3.4

Por ejemplo, la version de PHP 7.3 (7.3.33-1.1.1) es la última versión con ese formato y cuando fueron necesarias nuevas funcionalidades para el funcionamiento de Apache y PHP, el resultado de ese trabajo fue la version de PHP 7.4.0.
Cuando se decidió hacer modificaciones de mayor envergadura en el software; se terminó pasando de la version de PHP 7.x.x a PHP 8.0.

Este proceso de desarrollo y actualización es constante, por lo menos en PHP. Esto trae como resultado que muchas versiones de PHP hayan quedado obsoletas y no tengan mas soporte por parte de la mayoria de los paneles de control (Como cPanel, Plesk, etc.).
Por eso es necesario, para evitar problemas de seguridad y de compatibilidad, trabajar en los sitios para que los mismos sean compatibles con la última versión de PHP estable.

Versiones por estabilidad.

Además de tener las versiones por números se puede agregar una clasificación por estabilidad del proyecto.

Las opciones que tenemos para esto son: Alpha, Beta.

Alpha es una versión inestable que es muy probable que tenga muchas opciones que mejorar, pero se quiere que sea probada para encontrar errores y poder poner a prueba funcionalidades, en la mayoría de los casos se puede decir que esta casi listo el producto.

Beta una versión mas estable que Alpha en la que contamos con el producto en su totalidad, y se desea realizar pruebas de rendimiento, usabilidad y funcionamiento de algunos módulos para ver cómo funciona bajo un ambiente no tan controlado. Aquí aperece el nombre de Beta Tester que escuchamos mucho en el mundo del software.

El siguiente paso es RC (Release Candidate), que es el último toque fino del software antes de salir y después de pasar por Beta.

Versión de parche.

En el caso de los parches podemos agregar un dígito para señalar el parche, ya teníamos algo así: X.Y.Z y ahora tendríamos algo así: X.Y.Z.P así que P sería el número del parche:

Ejemplo: 1.2.5.2, 02.03.03.01

En conclusión, lo mas importante a la hora de armar un sitio web, es no solo hacer que el mismo sea compatible con la última versión estable de PHP; sino estar concientes de que es necesario trabajar y actualizar el mismo para que siempre tengamos la web trabajando en la versión de PHP que se considera en ese momento como la versión más nueva y estable de PHP.