- NewspaperHow to use the Flex Blocks cache option
- NewspaperCache plugin – install and configure
- NewspaperWP Rocket and Newspaper Theme: Optimization Guide
- NewspaperFlex Block Settings Guide
- NewspaperGeneral Options that May Interfere with the Newspaper Theme
- NewspaperThe Newspaper Mobile Theme: Introduction
- NewspaperAutoptimize Plugin – install and configuration
- NewspaperHow to update a plugin
- NewspaperCloudflare (CDN)
- NewspaperFacebook Share
- NewspaperVideo Playlist
- Newspaper7 Days Post Sorting
- NewspaperAjax View Count
- NewspaperTop bar templates
- NewspaperHow to Update the Newspaper Theme
- NewspaperHow to Install Newspaper via FTP
- NewspaperHow to Install Newspaper via WordPress
- NewspaperRequirements for Newspaper
- NewspaperHow to Make the Site Faster
Hello,
I am experiencing the “Layout sync error” (The editor expects 6 zones but the page is rendering 0) when trying to use tagDiv Composer on my homepage.
My hosting provider has already increased the server limits to meet your requirements, but the issue persists. Here is my current System Status:
PHP Version: 8.2
WP Memory Limit: 512M
PHP Max Input Vars: 5000 (Set in Plesk)
Max Execution Time: 300
Upload Max Filesize: 64M
Troubleshooting already done:
ModSecurity has been disabled.
AMP plugin is deactivated.
I tried creating a new page with “Page Builder Root” template, but the error remains.
Permalinks have been resaved.
Browser cache and theme CSS cache have been cleared.
Could you please help me identify what is blocking the editor from synchronizing the zones?
Thank you in advance.
I have checked in another browser also but its the same and also its not showing the responsive theme. Already the mobile theme app is deactived from my end and also cleaned the cache. Could you help. Also as per your screen there is floating menu with the demo logo, how can I change it ?
Hi,
I’ve checked the website, and it appears that the responsive header and footer are now loading correctly. However, based on your screenshots, it looks like the tagDiv Mobile Theme plugin may still be installed and active.
Please verify this on your side. If the plugin is installed, kindly disable it, then clear all cache. This should resolve the issue.
I am experiencing a persistent Facebook Sharing Debugger / Open Graph issue on a website using the Newspaper theme by TagDiv:
The Facebook Debugger consistently returns HTTP 403 and fails to properly retrieve Open Graph metadata from article pages.
Before suggesting generic hosting/firewall checks, please note the following:
Technical context:
What has already been verified:
Important observation:
Another WordPress site (mine, personal) hosted on the exact same server successfully returns proper Open Graph data and is scraped correctly by Facebook.
This strongly suggests the issue is related either to:
The Facebook Debugger currently retrieves incomplete OG data and sometimes only partial metadata such as:
Could you please provide technical insight specifically related to Newspaper/TagDiv behavior with Facebook crawlers, rather than generic hosting or firewall suggestions?
Thank you.I am experiencing a persistent issue with Facebook sharing/scraping on my website serenissima.news, which uses the Newspaper theme by TagDiv.
I have already performed a deep cleanup of the database and verified the server configuration. Before suggesting the usual “contact your hosting provider to whitelist Facebook in the firewall,” please consider the following:
I am the hosting provider. I own and manage the server (DirectAdmin based).
The firewall is NOT the issue. There are dozens of other websites on the same server (same IP) that share perfectly on Facebook without any blocks.
The issue is site-specific. Only the installation using the Newspaper theme is failing to provide the correct metadata or is being blocked/rejected during the scrape.
What I have checked so far:
Metadata: Standard OG tags are present, but the Facebook Debugger is not pulling them correctly.
Plugins: Performed a cleanup of caching plugins (WP Super Cache removed) and optimized the wp_options table.
Isolation: As mentioned, other sites on the same server work flawlessly, ruling out any server-side IP blacklisting or Firewall (CSF/LFD) interference.
I suspect there is a specific conflict within the theme’s header output or a built-in SEO/Open Graph setting in TagDiv that is clashing with Facebook’s crawler.
Please provide technical insights that don’t involve “whitelisting” as that has already been ruled out.
Hi,
Please do not share the license key on the forum, as it can be viewed by other users with forum access.
Could you please provide a few more details regarding the issue you are experiencing? Are the website fonts changing automatically without any modifications being made?
If so, the issue may be related to cache settings. Please check any cache or optimization options related to fonts, as they may be configured to block or disable Google Fonts loading.
Thank you!
Hi RENATO,
I understand that this situation is frustrating.
From what I can still see, the cache does not appear to be functioning correctly. Since I do not know the exact configuration or behavior of LiteSpeed Cache (and this is not a tested plugin), I cannot confirm whether the issue is directly related to that plugin, server-side cache, CDN configuration, or another caching layer. There are multiple possible factors involved.
At the moment, the mobile page you created with fewer blocks, smaller thumbnails, and more optimized content should normally provide significantly better mobile performance. However, because the dedicated mobile version is not loading, visitors are instead receiving the responsive desktop version, which is heavier and not fully optimized.
Unfortunately, there is not much more I can assist with from the support side. I have already provided all the recommendations and guidance available, even though performance optimization and PageSpeed improvements are outside the standard scope of support. We still did our best to help, despite the fact that the support period has not been extended for more than 8 years.
If you would like this issue to be investigated further and fully resolved, I recommend submitting a custom work request to services@tagdiv.com. Please include all relevant details and temporary wp-admin and cPanel access. The team responsible for custom services will review the situation and let you know what can be done, along with the associated costs.
Thank you for your understanding.
Hi,
There are a few possibilities:
– the article is set in multiple categories
– there is a cache or object cache applied to the home or directly on the bloc
Hello,
I have the same problem and it does not seem to resolve with cache purging…
@Calin, You know what’s happening, the theme is ignoring the post made for mobile (there’s a separate mobile theme), you can see it here: https://ibb.co/DgpbbLbT. It loads the desktop page on the phone, analysis: faint blue header and an ad like this (it’s for desktop), there’s no ad on mobile, the ad is only for desktop. Remember you told me to activate this? https://ibb.co/Rkjbv6bP It’s activated. Even so, the theme is loading the desktop theme on mobile, it doesn’t know how to separate them and isn’t separating them. The cache is correct https://ibb.co/JRVBbRqz it’s activated to generate mobile cache, look at this loading from https://ibb.co/TBT7jJLr, I mean, I did this last year, separate mobile theme, look at this https://ibb.co/x8c0yx07 everything is correct. I ask for a solution to fix this. You saw the performance is bad, horrible, because of this. I think the theme developer needs to create a plugin to redirect pages created on the mobile theme, so that when you open the mobile theme, you only open the desktop theme, and only the desktop theme, to avoid this mess. I’m asking for help; if you can’t help, talk to the person who created this theme and ask for guidance. I’m losing audience and rankings because of this.
Hi,
The SELECT SQL_CALC_FOUND_ROWS wp_posts.ID are used for rows and blocks (our theme stores the settings from rows and elements in database and the mentioned sql is one of those that make a request to them).
– how to use the Flex Blocks cache option
– use a cache for database, object cache should help.
– reduce the number of rows (rows and inner rows) from pages and cloud templates.
– reduce the number of blocks.
Thank you!
Hi,
The situation you are facing is usually related to the cache. Please clear all cache and object cache. If a CDN is used, purge the CDN, and teh situation will be resolved.
Thank you!
Hi,
Error 522 (Connection Timed Out) indicates that Cloudflare is unable to establish or complete a connection to the origin server. This typically occurs when the server is unavailable, under heavy load, or actively blocking Cloudflare IP ranges. The error is triggered either when the initial TCP handshake is not completed within 15–19 seconds, or when the server fails to respond to a request within 90 seconds.
Please test the site using only the theme’s required plugins (td plugins). If a child theme is currently active, switch to the main theme. Ensure that all caching mechanisms, including page cache and object cache, are fully disabled during testing.
In the majority of cases, this issue is caused by a third-party plugin. If the site functions correctly with only the theme plugins enabled, proceed by reactivating the remaining plugins one at a time, verifying functionality after each step. This process will help identify the plugin responsible for the issue.
Review the error logs from both WordPress and the hosting environment to identify any underlying issues. If error log is not currently enabled, activate debugging and error log, then reproduce the issue to capture relevant errors. Once completed, analyze the logs for any newly recorded entries that may indicate the root cause.
Hi,
Yes, that’s very likely Facebook often caches old data. It can take some time for the updated image to appear.
You can speed it up by using Facebook’s Sharing Debugger to force a refresh.
Hi,
I will forward this to our developers, and they will check it out.
Also, I want to let us know that using a mobile page/template will still load teh tagDiv Composer and cloud library (because those are used to create those pages and cloud templates for the mobile version). Normally, this option should be used when you need to have different content on mobile pages and mobile templates, maybe a smaller page with fewer elements, blocks, and for a different layout. Having the same layout and content will be better to use the responsive version, instead of the mobile page/template.
Here are a few additional recommendations you can try. For some users, all themes work without issues, while for others, only certain ones function properly. This can vary depending on the extra plugins in use, as well as any caching or optimization plugins installed.
-> Footer delayed load https://prnt.sc/FS34hBno40sx (under the theme panel > footer > footer delayed load)
-> MINIFY INLINE CSS and AGGREGATE INLINE CSS – https://prnt.sc/en14t6CQChM- (under the theme panel > block settings> inline css)
-> Don’t load on mobile/desktop, this option is only on the cloud header for HEADER MENU https://prnt.sc/udlAW4icvSPP on HEADER MENU STICKY https://prnt.sc/9pKnilQdWyex on MOBILE MENU https://prnt.sc/ff7fRQvTnaXt and on MOBILE MENU STICKY https://prnt.sc/Mm-4mbC4WB68
-> Flex Blocks cache – https://forum.tagdiv.com/use-flex-blocks-cache-option/
Also, it is recommended to use a good cache plugin and even Cloudflare (CDN)
Thank you!
Hello @Calin
I am writing to you after a deep technical audit that lasted two days, conducted by a Senior Infrastructure Engineer and Web Performance Specialist. We had to take this measure because our PageSpeed scores are stuck between 31% and 41% on mobile, despite running on a high-end VPS with persistent cache (Redis/Object Cache) and every possible server-side optimization.
Google has officially notified us regarding this poor performance, stating that our site is no longer a priority in search rankings due to failing Core Web Vitals. After a thorough investigation of the source code and database, we have pinpointed the root cause: The Newspaper theme is loading both Desktop and Mobile assets simultaneously on mobile devices.
Even with dedicated mobile pages (separate IDs), the theme “stacks” the entire desktop framework on top of the mobile one. This redundancy is killing our performance.
I need you to take this diagnostic to the tagDiv development team immediately. We need to know if and when a fix will be released. If this architectural flaw is not resolved, I will be forced to migrate to another theme or develop a custom one, as I cannot afford to lose my SEO ranking due to theme bloat.
Technical Diagnostic:
Problem: Mobile pages heavier than desktop pages
Date: 03/05/2026
Theme: Newspaper 12.7.5
Plugin: td-composer
Server: VPS Ubuntu — CyberPanel — LiteSpeed
CONTEXT
The site glostv.com uses the Newspaper 12.7.5 theme with the td-composer plugin and has a system of separate pages for mobile and desktop, where each version was built individually in the Newspaper visual editor (tagDiv Composer). The site owner reported that pages on mobile are significantly heavier than on desktop, even though there are separate and optimized mobile pages already built.
MOBILE SYSTEM ARCHITECTURE
The following pages were created as mobile templates inside the tagDiv Composer itself and are marked in the database with the flag tdc_is_mobile_template = 1:
ID 7584 — tv ao vivo Brasil (mobile version)
ID 7617 — POPULARES TOP (mobile version)
ID 8700 — Estados (mobile version)
ID 8872 — Homepage (mobile version)
ID 9944 — Política de Privacidade (mobile version)
ID 9948 — Termos de Uso (mobile version)
ID 10581 — Sobre Nós (mobile version)
ID 10597 — Política de Cookies (mobile version)
TECHNICAL PROBLEM IDENTIFIED
Problem 1 — td-composer loads assets WITHOUT any device distinction
Confirmed directly in the file:
wp-content/plugins/td-composer/legacy/common/wp_booster/td_wp_booster_functions.php
Line 362 — Composer JS loads for ALL devices:
add_action(‘wp_enqueue_scripts’, ‘load_js_composer_front’, 1000);
Line 430 — Full Newspaper CSS loads for ALL devices:
add_action(‘wp_enqueue_scripts’, ‘load_front_css’, 1001);
Line 744 — Full theme JS loads for ALL devices:
add_action(‘wp_enqueue_scripts’, ‘load_front_js’);
None of these functions have any device check. They load for both desktop and mobile equally, without any condition whatsoever.
Problem 2 — The mobile engine loads ON TOP of the desktop engine
Confirmed in the file:
wp-content/plugins/td-composer/mobile/functions.php
Line 149 — Mobile CSS loads ON TOP of the desktop CSS already loaded:
add_action(‘wp_enqueue_scripts’, ‘tdm_load_front_css’);
Line 173 — Mobile JS loads ON TOP of the desktop JS already loaded:
add_action(‘wp_enqueue_scripts’, ‘load_front_js’);
Line 184 — Mobile specific script loads ON TOP of all previous ones:
wp_enqueue_script(‘td-site’, TDC_URL.’/mobile/js/tagdiv_theme.min.js’);
Problem 3 — The flag tdc_is_mobile_template does NOT remove desktop assets
Confirmed in the file:
wp-content/plugins/td-composer/includes/tdc_state.php
Line 42:
private static $is_mobile_template = false;
Line 202:
public static function set_is_mobile_template($is_mobile_template) {
self::$is_mobile_template = $is_mobile_template;
}
This flag only serves to let the visual editor know it is on a mobile page. It does not execute any removal of desktop CSS or JS. It is purely an internal state variable with no effect on asset loading.
Problem 4 — Proof: Zero wp_dequeue for mobile anywhere in td-composer
I ran the following command directly on the server via terminal:
grep -r “wp_dequeue|deregister” wp-content/plugins/td-composer/ -n | grep -i “mobile|desktop|css|js”
The only result found was the removal of Visual Composer scripts in the backend administrative editor, not in the frontend. Throughout the entire td-composer codebase, there is not a single wp_dequeue_style() or wp_dequeue_script() instruction conditioned on mobile device detection in the frontend.
WHAT THE MOBILE BROWSER IS ACTUALLY DOWNLOADING
When a user accesses the site from a mobile device, the browser downloads all of this before rendering the mobile page:
From the desktop engine (which should NOT load on mobile):
Full legacy CSS of Newspaper
td-composer frontend JS (desktop visual engine)
tagdiv_theme.min.js desktop version
td-cloud-library CSS
td-standard-pack CSS
td-multi-purpose/style.css
Desktop version fonts
From the mobile engine (which loads ON TOP of the desktop):
Newspaper mobile CSS
tagdiv_theme.min.js mobile version
Mobile specific scripts
Fonts loaded again
The mobile browser is downloading the complete Newspaper framework twice. Once for the desktop layout that is discarded and once for the mobile layout that is actually used. This directly explains why mobile pages feel heavier and slower than desktop pages. DIRECT QUESTION TO SUPPORT
Does td-composer 12.7.5 have any native mechanism to remove desktop engine assets—specifically the functions load_front_css, load_js_composer_front, and load_front_js located in td_wp_booster_functions.php—when the page being served is already marked with tdc_is_mobile_template = 1 in the database?
If yes, in which file and on which line does this asset cleanup occur?
If no, when is the development team going to release an update to fix this? It is unacceptable that a high-end theme like Newspaper forces a mobile device to download the entire desktop framework AND the mobile framework simultaneously. My server-side analysis confirms that even when using dedicated mobile pages, the theme simply “stacks” assets instead of “swapping” them.
This redundancy is causing a massive performance overhead and killing our Core Web Vitals. We have separate pages for a reason, and the theme should NOT be loading desktop junk on a mobile-dedicated template. We need a clear position on when this will be resolved so that tdc_is_mobile_template = 1 actually triggers a wp_dequeue of unnecessary desktop resources.
Thank you – that is really helpful.
I can’t seem to get here: https://forum.tagdiv.com/use-flex-blocks-cache-option/ – if I open my post template I don’t see anything w flex blocks? I tried also on my home page where i use Block 3 but don’t see caching there either.
Hi,
Here are a few additional recommendations you can try. For some users, all themes work without issues, while for others, only certain ones function properly. This can vary depending on the extra plugins in use, as well as any caching or optimization plugins installed.
-> Footer delayed load https://prnt.sc/FS34hBno40sx (under the theme panel > footer > footer delayed load)
-> MINIFY INLINE CSS and AGGREGATE INLINE CSS – https://prnt.sc/en14t6CQChM- (under the theme panel > block settings> inline css)
-> Don’t load on mobile/desktop, this option is only on the cloud header for HEADER MENU https://prnt.sc/udlAW4icvSPP on HEADER MENU STICKY https://prnt.sc/9pKnilQdWyex on MOBILE MENU https://prnt.sc/ff7fRQvTnaXt and on MOBILE MENU STICKY https://prnt.sc/Mm-4mbC4WB68
-> Flex Blocks cache – https://forum.tagdiv.com/use-flex-blocks-cache-option/
Also, it is recommended to use a good cache plugin and even Cloudflare (CDN)
Thank you!
Hello,
“Performance Optimization
Among the most anticipated features are options to minify and aggregate inline CSS of blocks, accessible directly from the Theme Panel. Additionally, you can now hide the mobile menu and mobile search functions, offering a cleaner user experience on mobile devices.” – here is how you can enable those options:
-> Footer delayed load https://prnt.sc/FS34hBno40sx (under the theme panel > footer > footer delayed load)
-> MINIFY INLINE CSS and AGGREGATE INLINE CSS – https://prnt.sc/en14t6CQChM- (under the theme panel > block settings> inline css)
-> Don’t load on mobile/desktop, this option is only on the cloud header for HEADER MENU https://prnt.sc/udlAW4icvSPP on HEADER MENU STICKY https://prnt.sc/9pKnilQdWyex on MOBILE MENU https://prnt.sc/ff7fRQvTnaXt and on MOBILE MENU STICKY https://prnt.sc/Mm-4mbC4WB68
-> Flex Blocks cache – https://forum.tagdiv.com/use-flex-blocks-cache-option/
“The Newspaper Theme has leveled up its performance by optimizing the Theme Panel’s color settings through CSS variables. Moreover, JavaScript files will only be loaded when they are needed, which should noticeably improve the website’s speed.” – yest this is apply as long you are using cloud tenmplates, so if you do not have the tagDiv STandard pack plugin in used (this is loading all css and js even if is not need), then it will load only the js and css that will be used on that page/template.
Also, it is recommended to use a good cache plugin and even Cloudflare (CDN)
Thank you!
Hi Calin, thanks again.
In fact, I managed to find a fairly simple solution: instead of using wp_die for 404 pages, I simply use this code:
status_header(410);
nocache_headers();
get_header();
echo “page has gone”;
get_footer();
exit;
This is enough to ensure the page matches the site’s design.
Thanks again and best regards, Luca
Hi tagDiv team,
I have a Flex Block 1 (configured as “Latest news” widget in the homepage left column)
that renders empty in the frontend but displays posts correctly in the Composer editor preview.
DETAILS:
– Theme: Newspaper v12.7.5 (REGISTERED)
– Demo installed: Newsweek PRO
– Site: https://eurowaypoint.com
– WordPress: 6.9.4
– PHP: 8.2.30
THE PROBLEM:
– In Composer editor: the Flex Block 1 shows the latest 5 published posts correctly
– In frontend (incognito browser, logged out): the block container is generated
(div id=”tdi_96″ class=”td_block_inner td-mc1-wrap”) but completely empty —
no child modules are rendered inside
– 24 published posts exist in the database
– Other blocks on the same homepage (Big Grid Flex 1, other Flex Block 1 instances)
work correctly and display posts
– No JavaScript errors in browser Console
– The block has no special filters configured (Category: All, all filter fields empty)
WHAT I’VE ALREADY TRIED:
– Cleared all caches (SiteGround, WP Super Cache disabled, browser hard reload)
– Restored Homepage from a 3-day-old revision (no improvement)
– Disabled all third-party plugins one by one (Wordfence, SG Optimizer, etc.)
– Verified block configuration in Composer (Filter tab, Layout tab — all default/empty)
– Forced re-save of the block (changed limit number and saved)
– Removed custom CSS that contained :has() selectors
WHAT I NOTICED:
The block was working until I made some modifications today (changed page slug from
/plans/ to /newsletter/, edited some HTML custom blocks for Subscribe links).
The Latest block stopped rendering at some point during these changes.
Restoring an older Homepage revision did NOT fix it.
Could this be a corrupted block state in the database? Is there a way to reset
the block’s internal cache or regenerate its configuration?
Thank you for your help.
Hi,
Yes, here are some quick things to check when AdSense ads don’t show in the Newspaper theme:
1. Ad approval (most common issue): Make sure your AdSense account + ad units are fully approved. New sites or units can take time (hours to days) before ads appear.
2. Low or no traffic: If the site has very low traffic, AdSense may not serve ads consistently yet.
3. Ad blocking / cache:
– Clear all caches (plugin + server + CDN if used)
– Disable ad blockers while testing
– Test in incognito mode
4. Incorrect ad code placement: Double-check that the AdSense code is pasted correctly in:
Newspaper → Theme Panel → Ads, or the correct Ad Box element in tagDiv Composer
5. Auto ads vs manual ads conflict: If Auto Ads are enabled, they may override or delay manual placements. Try disabling Auto Ads temporarily for testing.
6. Privacy / consent (GDPR): If you use a consent plugin, ads will not show until consent is given.
7. Theme caching / delay in rendering: Sometimes Newspaper + cache plugins delay changes. Purge cache and wait a few minutes.
Hi,
First, make sure you have a complete backup of your website and database. After that, clear the cache and disable all plugins except the required td plugins and the cache plugin. Then clear the cache again and check if the issue persists.
Also, verify whether you’re using the main theme or a child theme. If a child theme is active, switch to the main theme and test again.
I wish I knew how to do that. How do I do a test using only the theme, theme plugins, and the cache plugin?
Kindly explain sir.
Thanks for your support
Regards
Hi,
I checked the website and it appears that most of the time it is taking about 50 seconds to refresh the homepage, so this is most likely a different problem. Could you please do a test using only the theme, theme plugins, and the cache plugin?
Let me know the results!
Thank you!
I forgot to mention that the news360.info website is already connected to Cloudflare with all the necessary settings. I only uninstalled WP Super Cache and installed and activated WP-Optimise. The site seems slow still.
Kindly advise and assist.
Thank you
