- 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
- NewsmagRequirements for Newsmag
- NewsmagHow to update the theme
- NewsmagtagDiv Social Counter tutorial
- NewsmagTop bar templates
- NewsmagAjax view count
- TutorialsWhat is Ajax preloading?
- NewspaperVideo Playlist
- Newspaper7 Days Post Sorting
- NewspaperAjax View Count
- NewspaperTop bar templates
Hi,
That isn’t a known issue. But I do have a pretty good idea about what’s happening.
Does the page maybe look like this when it happens? -> https://prnt.sc/hyCp9Ek6hrrs
That’s the mobile theme version, meaning the mobile theme plugin is active on the website. The mobile theme doesn’t load composer or cloud library resources and classes.
Normally the mobile theme is displayed on mobile. But sometimes due to the caching used on the website or provided by the hosting, it can get displayed on desktop as well. It usually depends on how the homepage is visited after the cache is cleared. If someone visits it with a mobile, then the mobile version is cached and server to everyone. By updating the page in the composer you are basically clearing the cache, and if you check with a desktop next then the problem is solved. Until by coincidence it will happen again.
I see you use litespeed, if this is the only caching used on the website, I suggest activating this option -> https://prnt.sc/gSi7feVctFPh If it’s already active and it’s still happening, then it means there is another cache active.
Or, you could deactivate the mobile theme plugin. It’s an optional plugin.
I believe that this is what’s happening, because it fits the description of the problem. I could be wrong however.
Let me know.
Thank you!
Hello,
I run the Newspaper theme (version 12.7.6, registered) with tagDiv Composer on a WordPress site hosted at WP Engine. The homepage intermittently breaks: the hero/feature grid renders as gray bands with no background images and the layout collapses. It happens every several days, with no edit or publish that I can tie to it.
I have diagnosed this fairly precisely and want to share the evidence, because it points to the Composer template failing to compose rather than a caching or browser issue.
WHAT THE BROKEN VS HEALTHY HTML SHOWS
I captured the HTML of the same homepage URL (page ID 370) in both states.
Broken state (~59 KB):
body class is MISSING: wp-theme-Newspaper, global-block-template-1, tdb-template, td-full-layout
4 td_block instances
6 style blocks, about 9.8 KB of inline CSS
0 background-image rules (which is why no hero imagery paints)
Healthy state (~899 KB):
body class INCLUDES: wp-theme-Newspaper, global-block-template-1, tdb-template, td-full-layout
324 td_block instances
41 style blocks, about 53 KB of inline CSS
about 200 background-image rules
So in the broken state the tagDiv block-builder template for the page is not composing at all. The tdb-template / global-block-template-1 output and inline CSS never generate.
WHAT FIXES IT AND WHAT DOES NOT
Purging the host cache does NOT fix it. The broken render is served even on a forced cache miss and on hard refresh, so it is not stale cache.
Re-saving the homepage in tagDiv Composer (Save, with the green Header/Footer/Content Successfully Saved confirmations) DOES fix it immediately, every time. This is now reproduced twice.
So a fresh Composer composition produces the correct page, and something later causes the page to revert to the un-composed render.
PATTERN
It stays healthy for several days, then suddenly reverts to the broken render.
One stable stretch lasted about 9 days before recurring.
A re-save fixes it for another multi-day stretch.
ONE POSSIBLY RELATED DETAIL
When the broken version was being served, the host cache had bucketed a desktop request into the mobile/iphone cache group. I mention it only in case Composer mobile/desktop template variant handling is relevant to why an incomplete render gets produced.
QUESTIONS
Is there a known issue where the Composer block-builder template fails to compose on a page regeneration, producing output without the tdb-template / global-block-template-1 body classes and without the inline CSS?
Could a periodic Composer cloud-library sync, a theme/Composer background process, or a license re-check trigger a re-render that lands in this un-composed state?
Is there a setting or maintenance step that forces the template to always fully compose, so I do not have to manually re-save in Composer every few days?
Is there a current recommended compatible pairing of Newspaper theme version and tagDiv Composer plugin version I should confirm I am on?
I can provide both full HTML captures (healthy and broken) on request.
Site: https://alstonhomes.com
Hello,
I run the Newspaper theme (version 12.7.6, registered) with tagDiv Composer on a WordPress site hosted at WP Engine. The homepage intermittently breaks: the hero/feature grid renders as gray bands with no background images and the layout collapses. It happens every several days, with no edit or publish that I can tie to it.
I have diagnosed this fairly precisely and want to share the evidence, because it points to the Composer template failing to compose rather than a caching or browser issue.
WHAT THE BROKEN VS HEALTHY HTML SHOWS
I captured the HTML of the same homepage URL (page ID 370) in both states.
Broken state (~59 KB):
body class is MISSING: wp-theme-Newspaper, global-block-template-1, tdb-template, td-full-layout
4 td_block instances
6 style blocks, about 9.8 KB of inline CSS
0 background-image rules (which is why no hero imagery paints)
Healthy state (~899 KB):
body class INCLUDES: wp-theme-Newspaper, global-block-template-1, tdb-template, td-full-layout
324 td_block instances
41 style blocks, about 53 KB of inline CSS
about 200 background-image rules
So in the broken state the tagDiv block-builder template for the page is not composing at all. The tdb-template / global-block-template-1 output and inline CSS never generate.
WHAT FIXES IT AND WHAT DOES NOT
Purging the host cache does NOT fix it. The broken render is served even on a forced cache miss and on hard refresh, so it is not stale cache.
Re-saving the homepage in tagDiv Composer (Save, with the green Header/Footer/Content Successfully Saved confirmations) DOES fix it immediately, every time. This is now reproduced twice.
So a fresh Composer composition produces the correct page, and something later causes the page to revert to the un-composed render.
PATTERN
It stays healthy for several days, then suddenly reverts to the broken render.
One stable stretch lasted about 9 days before recurring.
A re-save fixes it for another multi-day stretch.
ONE POSSIBLY RELATED DETAIL
When the broken version was being served, the host cache had bucketed a desktop request into the mobile/iphone cache group. I mention it only in case Composer mobile/desktop template variant handling is relevant to why an incomplete render gets produced.
QUESTIONS
Is there a known issue where the Composer block-builder template fails to compose on a page regeneration, producing output without the tdb-template / global-block-template-1 body classes and without the inline CSS?
Could a periodic Composer cloud-library sync, a theme/Composer background process, or a license re-check trigger a re-render that lands in this un-composed state?
Is there a setting or maintenance step that forces the template to always fully compose, so I do not have to manually re-save in Composer every few days?
Is there a current recommended compatible pairing of Newspaper theme version and tagDiv Composer plugin version I should confirm I am on?
I can provide both full HTML captures (healthy and broken) on request.
Hello,
Since updating to WordPress 7.0 today, I have detected a visual/functional issue in the builder’s CSS panel, specifically in the Margin / Padding fields of the Single Image module.
I’m leaving you a Loom video where the behavior can be seen clearly:
https://www.loom.com/share/26601c055dd3494d9745ede4635d838b
The problem is the following: before the update, within the visual margin/padding scheme, the fields allowed values of at least two characters or values with a unit to be displayed correctly. For example, if a padding value was 10%, the field allowed me to see 10 or 10%, or at least scroll inside the input in a useful way to check the full value.
Now the behavior has changed. The fields are displayed too narrow and only show one character of the value. For example, visually it may look like the padding is 1 / 1 / 1, but in reality the values are of the type 10% / 10 / 10%. When I move inside the field, instead of being able to see the full value or at least two characters, only one character is shown at a time; in this example, in order to see the %, I have to move within the field and instead of being able to see 0%, as part of 10%, only that is shown: the %.
This makes the CSS panel difficult to use, because I cannot visually check whether the real value is 1, 10, 10%, etc. The problem does not seem to be that the value has been lost, but rather that the panel input is displaying it cut off or with insufficient width. I have been using TagDiv for more than 7 years and I know what I am talking about when it comes to composition and the details of the composer.
I have tested it both in the desktop composer and in the mobile composer. I have also tested it in incognito mode, in case it could be due to browser cache. In addition, the page cache was cleared after the update.
For this reason, I understand that it could be a visual incompatibility of the builder after updating to WordPress 7.0, an internal CSS issue in the panel, a change in the width of the inputs, a rendering issue in the editor, or some incompatibility with the current version of WordPress/browser.
It is not necessarily that the page design has changed, but rather that the editor no longer displays the full values correctly inside the margin/padding fields.
The issue directly affects editing, because it makes it very difficult to review or modify margins and paddings without the risk of changing incorrect values.
Thank you. Please, I would really appreciate your help with this.
Hello,
I have a critical issue on my news site: I cannot publish new articles. When accessing the editor (Add New Post), the page stays blank.
Technical details:
WordPress: version 7.0 (latest)
Theme: Newspaper, version 12.7.6 (latest)
tagDiv Composer: latest version available
All plugins are up to date
Console error (DevTools):
edit-post.min.js?ver=28ef50b859708963e197:1 Uncaught TypeError: (0 , yt.registerLegacyWidgetBlock) is not a function
at Object.pn (edit-post.min.js?ver=28ef50b859708963e197:1:49057)
at HTMLDocument.<anonymous> (wp-edit-post-js-after:5:25)
There are also deprecation warnings related to your blocks:
Block with API version 2 or lower is deprecated since version 6.9.
Note: The block “tds/partiallocker” is registered with API version 1.
Note: The block “tds/contentlocker” is registered with API version 1.
Plus a 404 error when loading load-scripts.php.
Likely cause: the registerLegacyWidgetBlock function from the @wordpress/widgets package was removed in WP 7.0, while a script injected by your theme/Composer (wp-edit-post-js-after) is still calling it, which completely breaks the Gutenberg editor from loading.
What I’ve tried:
Temporarily deactivating other plugins (issue persists, so it’s isolated to Newspaper/tagDiv Composer)
Clearing cache (LiteSpeed Cache, full purge)
Confirmed all components are on the latest version
Please confirm if this is a known compatibility issue with WP 7.0, and let me know your estimated timeline for a fix/patch. In the meantime I’m using Classic Editor as a workaround, but I need Gutenberg working again as soon as possible since the site is active and requires frequent article publishing.
Thank you
Hello Simion,
Thanks for your respond. Yes, the plugin was deactivated as a temporary workaround.
After I activated SWIS again, the photos are cached normally.
As far as I understand with the next photos added, the cache will not update new images and they will be unavailable, as before. So let me wait until the new photo will be published on Instagram so I can try to clear cache manually and tell you the result.
In EWWW lazyload is deactivated since this is a photography site. But I will try to play with it.
I will update the thread in several hours or few days.
P.S. Looks like I forgot to post a URL to the site with the issue, but you correctly pointed it out. Thanks.
Hi,
I actually didn’t know about Swis until now. I knew that Ewww was a plugin for image optimization, but I didn’t know they also provide website optimization as well.
It definitely sounds like a caching issue, maybe also a lazyload issue if the images are not loading. Does it not display correctly if you clear the cache manually? I see there is an option https://docs.ewww.io/article/103-page-caching
At this time I see the images and the correct number of followers https://prnt.sc/nd81dyaiIv9y Is Swis inactive? What if you activate it and check in the browser console, are there any errors concerning the Instagram images?
Thank you!
Hello,
I have an Instagram activated and embedded into my page code.
It used to work normally. However, now I noted that when browsing the page in Incognito mode, the photos not showing.
If I am browsing the site from my normal signed in Google Chrome browser, the photos are showing normally.
I removed connection and reactivated it again, but it did not help.
Because in incognito mode it shows 7025 followers, while in normal mode it shows 8690 followers (actual currnt number is 8691 followers), I understand this is a cache issue.
I do have both EWWW and SWIS activated.
When I deactivate SWIS, the incognito page starts to show photos/posts normally and the number of followers raises to 8690.
So clearly SWIS and Instagram feature do not like each other.
Can you advice how can I make Instagram feature and SWIS be friends?
My web site is photography site with heavy pages, so caching is important to me.
Hello,
I’m using the Newspaper theme (version 12.7.6, with tagDiv Composer) on my live news site zzpnieuws.nl, which has an archive of 1,100+ articles. I want to use the Relevanssi search plugin to improve site search, but the search results page returns no results when Relevanssi is active.
What I’ve confirmed:
– With Relevanssi active, the search results page (e.g. /?s=schijnzelfstandigheid) shows “no results” for terms that appear hundreds of times in my archive, even though Relevanssi’s index is fully built and correct (1,122 documents, ~139,597 terms; posts and pages both included) and all Relevanssi settings are correct.
– The moment I deactivate Relevanssi, the theme’s native search works again immediately and returns the expected results. So the theme search itself is fine; the conflict is specifically between the search results template and Relevanssi.
– This persists on the latest version 12.7.6, with all caches cleared.
I’ve read an earlier reply from your team (Bettina) to another user, suggesting to edit the search page with tagDiv Composer and use a Flex Block with the filter “Search: Current Search” and no offset value. I’d like to apply this correctly but I’m not sure which template controls my search results page.
My questions:
1. Which template controls the search results page in the Newspaper theme – is it a Cloud Library template, a dedicated Search template in the Website Manager, or the theme default? I have a custom archive page that contains the search form, but the results appear on a separate /?s= page.
2. How should the Flex Block (“Search: Current Search”, no offset) be configured so the search results respect Relevanssi’s output instead of the theme’s own query?
3. Is there a recommended filter or hook for this that survives theme updates, rather than editing a core theme file?
I have a full backup in place and can provide temporary admin access through the official support channel if needed. This isn’t urgent – native search is working as a fallback – but I’d like to know the correct way to integrate Relevanssi with your theme.
Thank you,
Marco Weeber
zzpnieuws.nl
Hi,
I’m checking on your website from desktop, and it’s still not working. The ajax menu items are unresponsive and there is an error -> https://prnt.sc/QOAtiQgYCdcL
Such issues could be caused by caching and optimization plugins. I see you are using the Fastest cache plugin. I suggest checking what options are active in that plugin and maybe try deactivating the ones for the javascript (minify and combine), to see if the issue is solved. It’s most likely an issue caused by the optimization.
Thank you!
Hello tagDiv Support,
I am experiencing a serious issue with tagDiv Composer on my website using the Newspaper theme. The Composer has gradually become slower over time, and it has now reached a point where it consistently freezes whenever I attempt to add even a single element to a page. The browser eventually displays a “Page Unresponsive” message.
The issue was not present when I initially started building the website. Composer worked normally in the beginning, but performance degraded over time until it became unusable.
Here are the troubleshooting steps I have already completed:
• Switched PHP versions from 8.3 to 8.2 with no improvement.
• Confirmed PHP settings meet recommended requirements:
PHP Version: 8.2.30
PHP Memory Limit: 512M
PHP Max Input Variables: 10000
PHP Time Limit: 180 seconds
PHP Post Max Size: 1024M
PHP Upload Max Filesize: 1024M
• Created a staging site, and the exact same issue occurs there.
• Deactivated all non-tagDiv plugins, but the issue persisted.
• Checked the browser console and only found Content Security Policy report-only warnings and slow network messages. No obvious JavaScript errors were present.
• Tested Composer on multiple pages, and the freezing behavior continues.
• Cleared caches and tested after changing PHP versions.
My hosting provider is GoDaddy, and I am trying to determine whether this is related to a known issue with tagDiv Composer, a compatibility issue, or a server-related problem such as admin-ajax.php requests or ModSecurity interference.
Could you please advise if there are any known issues related to this behavior or recommend additional troubleshooting steps? If necessary, I can also provide administrator access, browser console logs, network request information, or any other details needed to diagnose the problem.
Additionally, could you let me know if there are any known compatibility issues with the current versions of Newspaper, tagDiv Composer, or GoDaddy hosting environments?
Thank you for your assistance. I look forward to your guidance on resolving this issue.
Best regards,
Jesse
traversecity.fm
Hello TagDiv Support,
I’m using the Newspaper theme with td-composer – https://www.total-motorsport.com/
On the frontend, td-composer is loading these files:
ext-language_tools.js
ext-searchbox.js
from this path:
/wp-content/plugins/td-composer/css-live/assets/external/ace/
This causes the following console errors:
Uncaught ReferenceError: define is not defined
Uncaught ReferenceError: ace is not defined
Because of these errors, two things are broken in the header:
The hamburger menu does not open on mobile.
The search function in the header does not work.
I have already tried:
Clearing all caches
Re-saving the header template in Composer
Multiple attempts to remove the Ace scripts (both via PHP and JavaScript)
None of these fixed the issue. The site is otherwise stable.
Could you please investigate why td-composer is loading Ace Editor assets on the public frontend and provide a fix?
Thank you.
Let’s recapitulate.
The post views are displayed on this website https://westfrieslandpraat.nl/ I see them here -> https://prnt.sc/Q53aurAB_5Es
That code I provided should make them invisible to visitors.
The code can be loaded in the post template via a Raw CSS element -> https://prnt.sc/7lBuPFRdC1hL
Alternatively the code can be loaded in the Live CSS -> https://prnt.sc/Fmd24EMnV0fq
Or in the theme panel -> https://prnt.sc/RWTWpDGC7Ij-
Or even in the wordpress customizer -> https://prnt.sc/nLLbT13Eln8B -> https://prnt.sc/gzryKNT_onNO
Either way you load the code, please also clear the cache if you use a caching plugin.
Thank you!
Hi guys,
I embedded a video and I add color overlay to that element in the css settings. When the page is loading, I see the colors (for a second). But the colors are not shown on the website. I cleared the cache, still no luck. What am I missing? (Consider this as a pre-sale question as my employer will then buy the Newspaper Theme)
Cheers
Carolin
I could provide a code to make them invisible to users that aren’t logged in, like regular visitors. Please try this code:
body:not(.logged-in) .tdb_single_post_views {
display: none;
}
You can add it just for posts, edit the post template with the composer and add a Raw CSS element anywhere in the post template https://prnt.sc/Wt8lOtDLl4Eh then add that code in it https://prnt.sc/P-O0VhkYCSGe
Then clear the cache and check on the website. The views should not be displayed anymore if you check in incognito mode for example, or if you log out of the website.
Please try it.
Thank you!
I see that’s an auto ad which is loaded in the header, but it displays over the content despite your exclusion from that section of the website. That’s quite unusual, I don’t think I’ve seen an auto ad being displayed on top of the content like that.
Did you maybe enter the auto ads code in the header ad spot? https://prnt.sc/PmrcpC6f4TjC Maybe it could force an ad there if that’s the case.
I could provide a code to add some space below the ad, like this https://prnt.sc/PPXnXASsrjDj
Try this code:
@media (min-width: 768px) {
.td-header-sp-recs .google-auto-placed {
margin-bottom: 280px;
}
}
Add it in the Live CSS https://prnt.sc/M5pDgCy46w9F or in the theme panel https://prnt.sc/nAyCIKVHrnme Then clear the cache and check if there is some space below the ad.
Thank you!
I see it. There is a problem with the width of the columns. While the rows in the composer limit the available space for regular posts built built with the wordpress editors, WPBakery has its own rows and design. So there are rows inside rows, each with their own layout and design.
Thankfully it’s not that much of a problem and can be fixed with some CSS. Copy the code from here -> https://pastebin.com/h5NFKKyL and add it in the theme Live CSS -> https://prnt.sc/FAacVlMRdULy Then clear the siteground cache and check the posts again. They should display properly like this https://prnt.sc/t-Ec67Uk6cY4 Let me know if that works.
If there are other issues someplace else, let me know where.
Let me know.
Thank you!
Hi,
If the website is hacked, malware can be added in pretty much any files from the website folder.
I checked the website on mobile and its still redirecting for me sometimes, I ended up on some kind of gaming website now https://prnt.sc/47GPJdHZKhtM It could be this script that loads in the head https://prnt.sc/WqC6eIHRNWDD I can’t find much about it online, or do you maybe know what that is?
Have you tried running wordfence and scanning the website with it? https://www.wordfence.com/help/scan/ Be sure to scan files outside of the wordpress installation as well, the option is in the scan settings. Wordfence should find any extra files, modified files, suspicious code, etc.
Or if your truly found the source of the malware, then maybe it’s just caching. Clearing all the caches and purging the cloudflare cache should be done again.
Thank you!
The data I mentioned is not in files. The data is kept in tables in the database.
I don’t think it’s the data from socials because that can’t get out of control.
Are you using any video playlists on the website? https://forum.tagdiv.com/video-playlist-2/ Although these should also not get out of control.
Are you using the block cache from the theme on any blocks? https://forum.tagdiv.com/use-flex-blocks-cache-option/ Normally this works with transients, and they are automatically cleared when new ones are created. There could be cases when the transients aren’t getting removed automatically and they pile up.
Then all that’s left is a log for debugging, which is disabled by default. I suggest starting with this. In the database, in the wp_options table, search for an option name called td_011_log like this https://prnt.sc/REaK59LeuNFW Delete that log https://prnt.sc/UUIL1VFCvErj Then check the system status panel to see if it loads.
Please be sure to search for and delete that exact table, td_011_log Not anything else. If you maybe have a staging site clone test it there first. Or if you try it on the main website, then please make a full database backup before doing anything.
Let me know.
Thank you!
Hi,
There are 2 cases when a post will not use the global template.
1. There is a post template set specifically for it -> https://prnt.sc/1yNWRUToAIis
2. There is a post template set for the primary category of the post -> https://prnt.sc/cNu7FP-9rla9
Other than these, all the posts should use the global template.
But if the correct post template is used after you clear the cache, then it must be some kind of caching issue. I could take a look at it, you can send an email at contact@tagdiv.com and provide a link to the website, admin login, and an example. Please also include a link to this topic in the email. I will check to see if I can find out why this happens.
Thank you!
Hi,
Thanks for your input. Unfortunately, clearing the browser cache or the theme cache doesn’t fix the issue in my case. All plugins are already updated, including Classic Editor, Yoast, and others. The problem appeared immediately after updating WordPress to 7.0 and PHP to 8.2/8.3, and it persists regardless of cache or plugin updates.
Everything on the frontend works correctly — only the System Status panel fails to load and returns a critical error. This suggests that the issue is not related to caching, but to something inside the theme’s System Status module itself.
Rolling back WordPress is not an option on this installation, so I need to identify the exact cause.
Thanks for the suggestion anyway.
Hi,
Thanks for your reply.
Unfortunately, I cannot provide cPanel or full server access, as the website runs on a dedicated machine with restricted access. However, I can check anything you need directly on the server if you tell me exactly what files, folders, or logs you want me to inspect to confirm your assumptions about the System Status panel.
Could you please specify:
– which directory or file you expect to contain the oversized data (YouTube cache, socials data, debug logs, etc.)?
– the exact path or filename you want me to verify?
– what size threshold or anomaly you want me to look for?
If direct server access is required only to inspect those elements, I can retrieve the information manually and send it to you.
Also, please let me know if admin access to the WordPress dashboard alone would be enough for you to diagnose the issue, or if server‑level access is absolutely necessary.
Thank you!
Hi,
The system status panel loads a few things, like data related to socials that are connected in the theme, the YouTube video cache, a log for debugging. All this data is small usually. But if the panel is not loading then it could mean that it’s size got out of control somehow.
I’ll have to investigate it on the website. Do you have cPanel or something similar? Please send us an email at contact@tagdiv.com with admin access to the website and also to cPanel. I will check as soon as possible.
Thank you!
There are tests that can be made.
First, let’s see if the post template has anything to do with it.
Please import any of the review templates from the cloud library https://prnt.sc/_cIa9xDU8iBl
Search for review to find them faster https://prnt.sc/ixGyLZjQT8n2
After importing one, edit a post that has a review and set the imported template just for that post https://prnt.sc/G35stt_wAAdt
Clear the cache and check in incognito mode to make sure that the post template was applied. Then check that post with the google test. Also provide a link to it so I can check it as well.
This way we can know if there’s something wrong with the post template or what’s in it.
Let me know.
Thank you!
Hi,
Some articles on the site are still displaying with the default Newspaper theme layout instead of the assigned global custom template. The issue happens randomly even though the custom Single Post template is set as Global, certain posts fall back to the default layout until the cache is cleared and then flip back again. Can we check why the global template assignment is not consistently applied across all posts?
Thank you in advance,
