Search Results for 'cache'

Hi Calin – I disabled Object Cache (the site is hosted by WPEngine), and the issue resolved.

Thank you for your help!

Hi, it’s not a multisite, it’s just a site that has different headers on some pages.
We are getting errors like “Cannot find source for file 37556<-(the header ID) in path/to/page/with/messed/up/header.

It could be cache, but I disabled caching on those pages to try to diagnose the issue and it didn’t work.

Thanks for your help.

This is the debugging log.

[28-May-2022 17:12:56 UTC] PHP Deprecated: Function create_function() is deprecated in /volume1/web/wordpress/wp-content/themes/Newspaper-child/functions.php on line 80
[28-May-2022 17:12:56 UTC] PHP Notice: Constant WP_POST_REVISIONS already defined in /volume1/web/wordpress/wp-config.php on line 87
[28-May-2022 17:12:56 UTC] PHP Fatal error: Uncaught Error: Call to undefined function gzencode() in /volume1/web/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php:2275
Stack trace:
#0 /volume1/web/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php(1962): wp_cache_get_ob(‘\nDeprecated: Fu…’)
#1 [internal function]: wp_cache_ob_callback(‘\nDeprecated: Fu…’, 9)
#2 /volume1/web/wordpress/wp-includes/functions.php(5275): ob_end_flush()
#3 /volume1/web/wordpress/wp-includes/class-wp-hook.php(307): wp_ob_end_flush_all(”)
#4 /volume1/web/wordpress/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(”, Array)
#5 /volume1/web/wordpress/wp-includes/plugin.php(476): WP_Hook->do_action(Array)
#6 /volume1/web/wordpress/wp-includes/load.php(1102): do_action(‘shutdown’)
#7 [internal function]: shutdown_action_hook()
#8 {main}
thrown in /volume1/web/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 2275
[28-May-2022 17:12:58 UTC] PHP Deprecated: Function create_function() is deprecated in /volume1/web/wordpress/wp-content/themes/Newspaper-child/functions.php on line 80
[28-May-2022 17:12:58 UTC] PHP Notice: Constant WP_POST_REVISIONS already defined in /volume1/web/wordpress/wp-config.php on line 87
[28-May-2022 17:12:59 UTC] PHP Fatal error: Uncaught Error: Call to undefined function gzencode() in /volume1/web/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php:2275
Stack trace:
#0 /volume1/web/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php(1962): wp_cache_get_ob(‘\nDeprecated: Fu…’)
#1 [internal function]: wp_cache_ob_callback(‘\nDeprecated: Fu…’, 9)
#2 /volume1/web/wordpress/wp-includes/functions.php(5275): ob_end_flush()
#3 /volume1/web/wordpress/wp-includes/class-wp-hook.php(307): wp_ob_end_flush_all(”)
#4 /volume1/web/wordpress/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(”, Array)
#5 /volume1/web/wordpress/wp-includes/plugin.php(476): WP_Hook->do_action(Array)
#6 /volume1/web/wordpress/wp-includes/load.php(1102): do_action(‘shutdown’)
#7 [internal function]: shutdown_action_hook()
#8 {main}
thrown in /volume1/web/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 2275

Reference
To avoid confusion, please note that separate error pages such as 404 and 502 are coded to redirect to the main homepage.

• This reply was modified 1 year by leejaehak.

Hi Calin,

We are using object / redis cache on our websites.

As you have mentioned about flex block, but on the Homepage we are not using flex block, we are using only Blocks and there is not option of cache in that.

So, how can we set cache on block things?

Thanks & regards,
Prathimesh

Gracias por los tips, pero no es la idea desactivar todo para que la Plantilla no consuma tanto recurdo de un Hosting o VPS. El problema de News Paper es que tiene un alto consumo de CPU cuando el administrador entra al editor Gutenberg. En algún momento de la edición del post llega a 60% o más cuando guarda el Post y ese problema es 100% del editor gutenberg con tagdv. Leí que hay un plugin Tagdv que sireve para cache pero no lo encontré en el Pack de la plantilla que se descarga de la página. Luego de Muchas pruebas en News Paper creo que no es la plantilla en en el FronEnd es más su plugin tagdv y Gutenmber que consumen mucho recurso a partir de las 5.000 publicaciones

Thank you as always, you’re truly an invaluable resource.

I cleared the cache and deactivated the SiteGround “Speed Optimizer” plugin, and now the image galleries are working perfectly on both the desktop and mobile versions.

I’ll now look into whether I can continue using the SiteGround plugin with different settings.

Have you encountered this issue before? Do you have any suggestions or best practices to ensure compatibility between Speed Optimizer and the Newspaper theme?

Thanks again, you’re amazing! 😊
Alessandro.

• This reply was modified 1 year by Alessandro.

Asunto: Problemas persistentes con carga AJAX – Caché en bloques no fue efectivo

Estimado equipo de soporte de tagDiv,

Gracias por su respuesta anterior. Después de probar la solución recomendada de activar el caché para los bloques Flex, lamento informar que no produjo mejoras significativas en el rendimiento del servidor.

Actualmente operamos un sitio de noticias de alto tráfico con más de 10.000 publicaciones, y nuestra infraestructura incluye:

VPS optimo

Nginx, PHP 8.1 (FPM), Redis como caché de objetos

WP Rocket (totalmente optimizado), Cloudflare activo, y la última versión del theme Newspaper

No usamos WooCommerce ni funciones de suscripción – es un sitio exclusivamente de publicaciones

A pesar de tener todas las capas de caché activas y optimizadas, seguimos observando un alto consumo de CPU incluso en momentos sin visitas. Tras una revisión más profunda, la causa principal parece ser el uso de AJAX, especialmente:

admin-ajax.php?action=as_async_request_queue_runner

tareas en segundo plano generadas por el theme/plugins (probablemente vía Action Scheduler)

llamadas generales a admin-ajax generadas por el theme y el constructor

En este contexto, no es viable desactivar funcionalidades críticas o plugins simplemente para reducir la carga del servidor, especialmente considerando que muchas llamadas AJAX provienen de la estructura misma del theme (incluyendo tagDiv Composer y bloques dinámicos).

Necesitamos una solución técnica concreta y viable para reducir la sobrecarga de AJAX sin sacrificar funciones esenciales.

Agradeceríamos su orientación sobre lo siguiente:

¿Existe algún mecanismo interno o actualización en desarrollo para minimizar las consultas AJAX en segundo plano?

¿Es posible configurar tagDiv Composer o componentes del theme para reducir su dependencia de admin-ajax en entornos productivos?

¿Tienen prácticas recomendadas o configuraciones avanzadas específicamente para sitios con gran volumen de contenido que utilicen Newspaper?

Esperamos su orientación experta, ya que esta situación está afectando el rendimiento y la escalabilidad de nuestro sitio en producción.

hola compañeros, nosotros estamos en nuestra web en una configuración muy parecida a la vuestra, también con muchas mas de 10000 publicaciones, también somos un medio de comunicación, tenemos un servidor sobredimensionado para intentar mitigar el impacto del tema sobre el rendimiento. Algo que a nosotros, creemos, nos ha servido, ha sido configurar nuestro plugin de cache, “wp super cache”, en modo “experto” para que sea nginx quien atienda las peticiones de cache, para liberar a php un poco de carga, también optimizar la “OPcache” que estaba rozando el limite máximo, de todas formas, seguimos experimentando picos de carga en momentos aleatorios y a horas que no hay visitas, no somos los únicos por este foro con este problema concreto…

Espero que se encuentren bien. Me gustaría exponer detalladamente las pruebas de rendimiento y la configuración de los plugins de optimización realizadas en el sitio http://www.itvpatagonia.com, con el fin de ofrecerles un contexto más claro sobre las conclusiones técnicas a las que hemos llegado respecto al rendimiento del theme Newspaper y el uso del plugin tagDiv Composer.
1. Plugins de Optimización Instalados

En el sitio web de http://www.itvpatagonia.com, hemos instalado y configurado los siguientes plugins de optimización para mejorar el rendimiento y la carga de las páginas:

WP Rocket: Configurado para la optimización de caché, precarga de caché, compresión de archivos estáticos, optimización de bases de datos, y optimización de scripts JavaScript y CSS.

Cloudflare: Usado como CDN y servicio de mitigación de ataques DDoS, con reglas específicas para excluir el backend de la caché y optimizar la entrega de contenido estático.

Redis: Configurado para optimizar la caché de objetos en el servidor, lo que ha ayudado a reducir los tiempos de respuesta de las consultas a la base de datos.

tagDiv Cloud Library: Plugin proporcionado por Newspaper para acceder a plantillas prediseñadas y optimizar el uso de recursos de la web.

Smush Pro: Usado para la optimización de imágenes, comprimiendo y redimensionando las imágenes para mejorar la velocidad de carga.

EWWW Image Optimizer: Complemento para optimizar aún más las imágenes y garantizar que estén en los formatos más ligeros posibles (incluyendo WebP).

2. Pruebas de Rendimiento y Revisión

A lo largo de este tiempo, hemos realizado diversas pruebas de rendimiento con herramientas como GTmetrix y Google PageSpeed Insights, así como evaluaciones internas utilizando New Relic y Query Monitor, para examinar el impacto de los plugins y la estructura del sitio.
Pruebas clave realizadas:

Rendimiento de carga: Con un volumen de alrededor de 10,000 publicaciones, observamos que la carga del sitio se ve afectada negativamente, especialmente al trabajar con tagDiv Composer y Newspaper.

Uso de CPU y memoria: Durante la carga masiva de contenido y la generación de nuevas páginas, experimentamos picos de uso de CPU, que no se lograron reducir completamente incluso después de optimizar todos los plugins de rendimiento mencionados.

Tiempo de respuesta del servidor: El tiempo de respuesta del servidor también se incrementa significativamente cuando el número de publicaciones excede las 10,000, independientemente de la optimización de caché y otros ajustes.

Problemas con tagDiv Composer: El plugin tagDiv Composer muestra un rendimiento inconsistente y no se comporta de manera óptima cuando se trabaja con grandes volúmenes de contenido. Esto afecta directamente la experiencia del usuario y la administración del sitio.

3. Conclusión Técnica

A pesar de la implementación y configuración de los mejores plugins de optimización disponibles, hemos llegado a la conclusión de que el tema Newspaper y su plugin tagDiv Composer no son capaces de funcionar de manera óptima con un volumen de contenido superior a 10,000 publicaciones. Este comportamiento se mantiene consistente a pesar de las múltiples configuraciones y ajustes en los plugins de rendimiento y cache.

Por tanto, la consulta técnica original no estaba relacionada con recomendaciones generales sobre qué plugins de optimización utilizar o qué tipo de hosting es el mejor. Ya hemos realizado todas las pruebas posibles en este sentido, y estamos en busca de una solución más profunda y técnica que considere los problemas de rendimiento inherentes al uso de Newspaper en sitios con grandes volúmenes de contenido.

Agradecería que, en lugar de proporcionar recomendaciones genéricas, pudiéramos recibir una revisión técnica detallada o incluso una actualización o mejora en los plugins/funcionalidades de Newspaper y tagDiv Composer que puedan garantizar el rendimiento adecuado en este tipo de sitios.

Quedo atento a su pronta respuesta.

I’ve been building websites since 1995 and FTP has *always* been the best way to update themes due to various localized file permissions, folder ownerships, how WordPress was installed (eg., WP can behave differently if installed via Plesk panel, etc.); time outs on your system during updates causing missing file, unzip issues at server level, mix of old/new files in some cases if server/domain/site/wp does not first properly remove the old files prior to install new ones; caching issues (are you disabling cache prior to updating?) causing mixed content; conflicting plugins, etc.

Just giving some friendly advice from an elder webdev who has “seen it all” over the years and we run in paranoia mode over here.

Good luck! (I don’t work here; but have used Tagdiv products since they launched). Not meaning any insult or anything, just some friendly feedback.