- NewsmagRequirements for Newsmag
- NewsmagHow to update the theme
- NewsmagtagDiv Social Counter tutorial
- NewsmagTop bar templates
- NewsmagAjax view count
Hi,
Optimizing a wordpress website for the best possible score can take a lot of time. Especially for mobile, where it’s more strict.
I believe you are using mod pagespeed, I very rarely see it anymore. These days the best possible combo for performance is considered Cloudflare and WP Rocket. However, you current results aren’t bad at all. I tested the website now and it’s 82 on mobile -> https://pagespeed.web.dev/analysis/https-actugeekgaming-com/c9aa1kj7cl?form_factor=mobile
What the theme offers for mobile is mobile pages. This means using a mobile version of the desktop page, same as on this demo -> https://demo.tagdiv.com/newspaper_pro/
A mobile page has it’s own content, header, footer. Usually there is a difference from using the responsive desktop page versus using a mobile page, favoring the mobile page. You could test it, create a mobile page -> https://prnt.sc/R8zzwvtFsb50 and create the header and footer -> https://prnt.sc/Lj7X4dZfzP9v Also reduce or simplify the elements in the page as much as possible. Then clear the cache and repeat the test.
Thank you!
Hi,
Normally no modifications are needed. The theme deletes the transients automatically (via wp cron), the code is in this file -> wp-content\plugins\td-composer\legacy\common\wp_booster\td_transients_manager.php This functionality was already in the code since the block cache was added as a feature. If they would not get cleared, then the database would indeed increase.
If they aren’t getting deleted on your website, maybe it’s a conflict, perhaps with a caching/optimization plugin. Or the wordpress cron is disabled. It’s not something that we can recreate or something that was reported by multiple theme users.
Thank you!
Hi,
First of all, thank you for your previous reply regarding Flex Blocks and background images.
I’m trying to optimize my website as much as possible for Google’s Core Web Vitals, especially on mobile, and I’d like to make sure I’m using Newspaper in the best possible way.
My website is:
https://actugeekgaming.com/
My latest PageSpeed report:
https://pagespeed.web.dev/analysis/https-actugeekgaming-com/aomr1s8vst?form_factor=mobile
At the moment my mobile score is around 50–60, and I’d like to improve it significantly while keeping Newspaper if possible.
Here is what I’ve already done:
Removed the homepage video background.
Replaced the hero section with a normal image.
Optimized all featured images.
Enabled WP Super Cache.
Enabled Jetpack CDN.
Upgraded to PHP 8.2.
Removed unnecessary plugins.
Added preload for the LCP image.
Contacted support regarding Flex Blocks using CSS background images.
I understand that Flex Blocks use background images by design, and you’ve suggested creating a custom Module Builder template using an element instead.
Before rebuilding my homepage, I would like to ask a few questions:
1) What are the official Newspaper recommendations for achieving the best possible Mobile PageSpeed score?
2) Which homepage modules or blocks are the most performance-friendly?
Are Flex Blocks still recommended for the first visible section, or would you recommend using a Module Builder layout instead?
3) Are there any Newspaper or TagDiv Composer settings that should be disabled to improve Core Web Vitals?
4) Do you have a performance optimization guide specifically for Newspaper?
5) Do you know of any websites using Newspaper that consistently achieve 85–90+ Mobile PageSpeed scores?
If so, could you share a demo or explain what makes them different?
6) Apart from replacing Flex Blocks, is there anything else inside Newspaper that commonly hurts LCP or overall mobile performance?
My goal isn’t simply to increase the PageSpeed score, but to build a fast, modern news website while continuing to use Newspaper.
Thank you very much for your advice!
Hey – My website https://barrettmedia.com is showing several “Active” menu items. However – if you use a cachebusting URL – the correct behavior is observed
https://barrettmedia.com?cache. This is only happening on the homepage, the inner pages are correct – is there a way to fix this?
Hello,
Since August 1, I have noticed that the WordPress administration panel has been responding more slowly than usual.
I have reviewed several possible causes and found that WordPress is currently reporting a critical Site Health issue related to autoloaded options.
Current data reported by WordPress:
– 1,326 autoloaded options.
– Approximate size shown by Site Health: 2 MB.
– WordPress indicates that this volume could affect performance.
I also checked the options table directly in the database. The current autoloaded volume is approximately:
– autoload = yes: 1.54 MB
– autoload = auto: 0.12 MB
– autoload = on: 0.11 MB
Approximate total loaded automatically: 1.77 MB.
The total number also matches the 1,326 options reported by Site Health:
– yes: 1,131 options
– auto: 164 options
– on: 31 options
– total: 1,326 options
The largest individual options related to Newspaper/TagDiv are:
– td_011_settings: 820.24 KB — autoload yes
– td_011: 164.02 KB — autoload yes
– td_011_remote_cache: 35.64 KB — autoload yes
– td_011_log: 8.18 KB — autoload yes
The td_011_settings and td_011 options alone total approximately 984 KB. Therefore, these two options currently represent more than half of all the data WordPress loads automatically.
As an additional check, I also found a residual option from an old plugin:
– wpts_compat: 287.02 KB — autoload yes
Using WP-CLI, I confirmed that it belonged to a previous WPtouch installation:
– Original serialized class: WPtouchDefaultSettingsCompat
– WPtouch is no longer installed.
– There is no active or inactive WPtouch plugin or WPtouch folder on the server.
I did not delete the option. I only changed its autoload value from yes to off in a fully reversible way.
After making this change:
– The total autoloaded size decreased from approximately 2.05 MB to 1.77 MB.
– The autoload = yes group decreased from 1.82 MB to 1.54 MB.
– The administration panel appears to respond slightly faster, although I cannot confirm with complete certainty that the improvement is exclusively related to this change.
– Site Health still reports a critical issue related to autoloaded options.
I have also reviewed other possible causes of the slow administration panel.
1. Action Scheduler
The active Action Scheduler table appears to be working normally:
– No actions are currently in progress.
– Only three actions are pending, and all of them are scheduled for future dates.
– There have been no new failed actions since August 1.
– There is no active backlog of blocked or repeatedly failing jobs.
2. WP-Cron
The WordPress cron option is approximately 12.28 KB, so it does not appear unusually large.
3. WP Rocket RUCSS and background processes
There are periodic checks related to WP Rocket SaaS jobs, but the actions are completed successfully and do not accumulate. There does not appear to be a blocked queue that would independently explain the continued wp-admin slowdown.
Therefore, I cannot confirm that Newspaper options are the only cause of the problem, but they currently represent the main remaining portion of the autoloaded data.
I would like you to review the following questions specifically:
1. Is it normal for td_011_settings to exceed 820 KB?
2. Do td_011_settings and td_011 need to remain autoloaded on every WordPress request, including wp-admin requests?
3. Is it safe to change the autoload value of either of these options to off, or does Newspaper require them during almost every request?
4. Does Newspaper provide an official process for cleaning, rebuilding, or reducing td_011_settings and removing old configuration data that is no longer used?
5. Could td_011_settings contain accumulated data from Cloud Templates, the Theme Panel, blocks, advertisements, headers, footers, or old configurations that are no longer active?
6. Is there a diagnostic tool or recommended method to identify which internal settings are responsible for the 820 KB stored in td_011_settings?
7. Would it be possible to split this option into several smaller options and avoid autoloading data that is only required on specific screens?
8. Has there been any recent change in Newspaper or TagDiv Composer that could have increased the size of these options or the amount of processing performed inside wp-admin?
I have not modified or deleted any Newspaper-related option. Before changing their autoload values or altering their contents, I need confirmation from your team regarding which options must remain autoloaded and what official procedure you recommend to reduce their size without affecting the theme or the Cloud Templates.
Thank you.
Did you rescan the website? -> https://prnt.sc/NrVG0T4YLivy If not, it displays the same results from the last scan. I scanned it now and it says that it can’t scan the website for some reason -> https://prnt.sc/pwJxUTCx8cC7
That script isn’t in the page anymore however, and since it was the only thing that was detected in the last scan, if it’s gone now, the website should be in order.
The composer doesn’t have a cache, if something is removed from the page, it’s removed from the page.
I believe the website is fine now.
Hi Simion,
Thank you for pointing out the exact location.
I opened the homepage in TagDiv Composer and removed the malicious script as well as the entire Raw HTML element from the top row, then saved the page.
However, when I run the Sucuri scanner again, it still throws the “Warning: Malware Detected” alert.
Is it possible that TagDiv Composer’s internal cache / compiled page cache is still serving the old version of the homepage, or is there another place within the composer/theme options where this needs to be cleared?
Best regards,
Mladen
Hello,
I’m using Newspaper 12.7.7 with the latest tagDiv Composer.
My homepage scores around 60 on Google PageSpeed Insights (mobile).
Lighthouse identifies the homepage LCP element as:
<span class=”entry-thumb td-thumb-css”
style=”background-image:url(…)”>
The image is rendered as a CSS background instead of an element.
Lighthouse reports:
fetchpriority=high should be applied
render-blocking CSS, especially:
td_legacy_main.css
style.css
tds-front.css
I already tested:
latest Newspaper and tagDiv Composer versions
Jetpack Image Accelerator enabled
cache enabled
manually adding a preload for the LCP image
My questions are:
Is there any supported setting or Flex Block that renders the featured image as a real instead of a CSS background?
Is there an official hook/filter to customize the thumbnail markup?
Is there a recommended way to improve LCP for Newspaper homepages?
Can td_legacy_main.css or other legacy CSS resources be safely disabled on Newspaper 12.7.7?
Website:
https://actugeekgaming.com
PageSpeed test :
https://pagespeed.web.dev/analysis/https-actugeekgaming-com/hodhlqczsz?form_factor=mobile
Thank you!
Hi Simion,
The website URL is https://mraclin.hr/
I have already completed all of those steps:
Scanned the entire database for cpajoliette (0 results).
Replaced WordPress core folders (wp-includes, wp-admin).
Updated the theme and tagDiv Composer to the latest clean versions.
Checked all theme options, headers, and custom code sections.
Ran a full Wordfence scan and verified that the files and database are clean.
Despite all files and database records being clean, external live scanners (like Sucuri) still report the injected script on the front end. Could this be caused by how tagDiv Composer caches shortcodes/elements, or is there a specific theme setting/table where this script could still be cached?
Best regards,
Mladen
Hi Simion,
Thank you for the update. I have updated the theme and tagDiv Composer to version 5.4.3.7, cleared all site cache, and re-scanned the site. However, ESET antivirus is still blocking the website.
Could you please advise if there are any specific database tables or remaining cached elements I should check, or if this might be a false positive on ESET’s end that needs to be reported?
Thanks!
The tagDiv Header Search element generates invalid ARIA markup in both desktop and mobile header instances.
The generated HTML is:
<div class=”tdb-drop-down-search”
aria-labelledby=”td-header-search-button”>
The W3C validator reports:
The aria-labelledby attribute must not be specified on any div element unless the element has an appropriate role.
The search itself works correctly. The issue is specifically the generated markup.
I confirmed the source in:
wp-content/plugins/td-cloud-library/shortcodes/header/tdb_header_search.php
The original PHP output was:
$buffy .= ‘<div class=”tdb-drop-down-search” aria-labelledby=”td-header-search-button”>’;
I changed it to:
$buffy .= ‘<div class=”tdb-drop-down-search” role=”search” aria-labelledby=”td-header-search-button”>’;
After clearing caches and revalidating, both validator errors disappeared. Desktop and mobile search continued to function normally.
This confirms that the issue is not caused by search placement, template layout, or custom CSS. It is caused by the Header Search element omitting an appropriate role from the .tdb-drop-down-search container.
Please update the plugin output to include:
role=”search”
on that container, or otherwise revise the ARIA structure so aria-labelledby is used on an element with a valid role.
The error appeared twice because the page contains separate desktop and mobile Header Search elements.
Hope this is ok to post here if not admin can delete it if prefered. My site scores 100 in the performance section using LiteSpeed Cache (wich is free) now i have a smal personal site so i also use the QUICKCloud CDN service wich is not too expensive (i put in 10 euros over a year a go and still have 3 euro left) this by itself already will boost your site speed by alot) but i wont dive into all the LiteSpeed Cache options and settings but it is a great free alternative.
So for those not using a expensive cache program like WPRocket that has a setting to preload your fonts but still would likle the benefits you can add a function to the theme’s functions.php file its best adviced to set up and do this on the Newsmag Child theme. This will also remove the font from ther Network dependency tree.
My site scored 100 already before i preloaded the font but it just adds up with all other optimizations so the Newsmag websites can really be blazing fast! DRiFT MAFIA Website
Just open the functions.php file in your prefered texteditor and ad this code at the bottom:
I could nott post the code for some reason probly safety
Hola equipo de soporte de tagDiv,
Estoy experimentando un consumo elevado de CPU y de recursos de base de datos en mi servidor (WordPress con tema Newspaper, versión 12.7.3), y logré identificar la causa mediante análisis de logs de acceso.
Hallazgo principal:
Detecté 6,202 peticiones a admin-ajax.php con el siguiente patrón exacto de query string:
admin-ajax.php?td_theme_name=Newspaper&v=12.7.3
Estas peticiones no incluyen el parámetro action=, a diferencia de otras llamadas ajax estándar de WordPress. Solo encontré 2 peticiones con action=rest-nonce en el mismo período, en contraste con las 6,202 mencionadas.
Preguntas específicas:
¿Qué función o mecanismo del tema genera esta llamada específica (td_theme_name + v sin action)?
¿Es un mecanismo de verificación de versión/licencia, telemetría, o alguna otra función?
¿Existe una opción en el panel de administración del tema para desactivar o reducir la frecuencia de esta llamada?
Si no se puede desactivar, ¿es seguro cachear esta petición a nivel de servidor (LiteSpeed Cache) sin afectar la funcionalidad del tema?
Contexto técnico adicional:
Servidor: AlmaLinux 8.10.0, cPanel/WHM, LiteSpeed (lsphp)
Plugin de caché actualmente evaluando: LiteSpeed Cache
El volumen de estas peticiones supera al de cualquier sección editorial del sitio (que rondan 150-170 peticiones cada una en el mismo período de análisis)
Gran parte del tráfico total al sitio proviene de rastreadores legítimos verificados (Googlebot, confirmado por reverse DNS), lo que sugiere que estas llamadas ajax se disparan también durante el rastreo/renderizado de páginas, no solo con usuarios humanos
Quedo atento a su respuesta. Gracias de antemano.
Saludos,
Ronny
Hi, I’m using tagDiv Composer on a page-type entry. When I add a “Column text” module inside a column and click the “Edit Content” button to open the text editor (WP Editor), the popup opens but stays stuck loading indefinitely with a spinning icon, never actually showing the WordPress editor.
Steps to reproduce:
Open the tagDiv Composer editor on an entry/page.
Add a Row with columns.
Drag the “Column text” module into an empty column.
Click “Edit Content” in the module’s settings panel.
The “WP Editor” popup opens but the content never finishes loading (infinite spinner).
Expected behavior: the WordPress text editor (WP Editor) should open so I can write/paste content, including shortcodes.
Actual behavior: the popup stays loading forever and doesn’t let me edit the module’s content.
Additional context: I specifically need this module because the “Raw HTML” module doesn’t execute WordPress shortcodes (it displays them as plain text on the frontend), and “Column text” should process them correctly.
Environment: WordPress with Newspaper theme / tagDiv Composer. Relevant active plugins: Advanced Ads, WP Fastest Cache, WPCode, Popup Maker, SEO plugin (Yoast or similar), among others.
Could you let me know if this is a known bug, or if there might be a plugin/cache conflict causing the editor not to load?
Hi,
That depends. In normal circumstances the theme font settings should apply to all the posts.
If I check some of your posts, the theme font setting applies correctly -> https://prnt.sc/xpP4ATn0UUo4 Those are clean paragraphs and they use the correct settings from the theme panel.
For other posts however, from what I see the text from the post content comes with its own font settings -> https://prnt.sc/uQWOT3r0V1eE And most of the content isn’t paragraphs, it’s span containers. There is a font family and a font size of 12pt (which is about 16px) set for them.
Such inline styles are very strong, meaning they can override the font settings from the theme -> https://prnt.sc/2-22uttCGOR2
In case you aren’t manually adding span containers with inline styles in the post content, then maybe the text is built and/or copied from somewhere else, along with it’s style from there.
The easiest fix would be to enforce the desired font size and override the inline styles to make them use the 12px font size. A code like this one should work -> https://prnt.sc/Sf-v9NpVE7ID
Please copy this code:
.single article .td-post-content span {
font-size: 12px!important;
}
And enter it either it in the theme panel custom CSS code section -> https://prnt.sc/xGyxgRA6plQC
Then clear the cache and check if the post content looks as you want.
Let me know.
Thank you!
Hi tagDiv team,
I want to set my content width to 1200px (modern news-site layout: full-bleed bars, centered 1200px content column) on zzpnieuws.nl, running Newspaper 12.7.6 with a child theme.
In this forum, your staff has described the solution as follows:
– Simion C. (Sep 2025, topic “How to customize the page width”): “So for a page like your homepage, you must edit it with the composer, click on the rows and stretch them to 1200px, it takes very little time.”
– Calin (Aug 2025, topic “banner in my header”): “you can adjust the row width using tagDiv Composer […] the row to be stretched to 1200px instead of the default.”
However, this stretch control does not appear anywhere in my tagDiv Composer:
1. When I select a Row (both on a regular Composer page and in my header Cloud Template), hovering over the left/right edges of the row in the preview shows no drag handles and no resize cursor.
2. The Row settings panel (tabs General / Divider / Layout / Css) contains no stretch or row-width dropdown. The Layout tab only has column layout, alignment, order and “occupy remaining space”. The Css tab only has a manual pixel Width field.
3. Theme Panel → Template Settings has no global site/content width setting either.
My questions:
– Where exactly is the “stretch row to 1200px” control in Newspaper 12.7.6? Is it a drag interaction in the preview, a setting, or something that must be enabled first?
– Is this feature version-, license- or configuration-dependent?
– If it is genuinely unavailable in my setup: what is your recommended, update-safe way to achieve a 1200px content width site-wide (including the default single post and category templates) without breaking the responsive grid and thumbnail calculations?
Setup: Newspaper 12.7.6 (deploy mode: deploy), child theme (originally generated on Newspaper 9), tagDiv Composer + Cloud Library active, header built as a Cloud Template, LiteSpeed Cache, hosting at Cloud86.
Screenshots attached: (1) the Row settings panel showing the four tabs without a width option, (2) a selected row in the preview where no drag handles appear on the edges. See images here: https://postimg.cc/gallery/3xm1fCyimages
Thanks,
Marco — zzpnieuws.nl
Hi,
Thank you for your help.
I found the cause and confirmed it with testing.
The issue was not caused by Redis Object Cache, OPcache, Cloudflare, LiteSpeed, WP Rocket, or another WordPress caching plugin.
The site is hosted on a self-managed VPS using WordOps with Nginx and PHP-FPM 7.4. WordOps uses an Nginx-level WP Super Cache integration:
include common/wpsc-php74.conf;
The active Nginx rule was serving WP Super Cache static HTML files directly before WordPress/Newspaper could run.
The original WordOps rule was looking for the mobile HTTPS cache file in this order:
index${mobile_prefix}${https_prefix}.html
On my server:
mobile_prefix = -mobile
https_prefix = -https
So Nginx was looking for:
index-mobile-https.html
However, WP Super Cache generates the mobile HTTPS file as:
index-https-mobile.html
Because Nginx could not find the mobile cache file, it fell back to:
index-https.html
As a result, mobile visitors were receiving the desktop cached file before WordPress/Newspaper could serve the dedicated mobile content.
This also explains why adding a query parameter made the mobile layout appear correctly, because that bypassed the direct static cache delivery.
I adjusted the Nginx WPSC rule so it now looks for:
index${https_prefix}${mobile_prefix}.html
I also prevented mobile requests from falling back to the desktop cache file if the mobile cache file does not exist.
After clearing cache, the homepage and other pages now generate separate cache files correctly:
index-https.html
index-https-mobile.html
I tested the homepage, a post, and a category page on both desktop and mobile user agents. The first request generates the cache, and the following requests are served very fast. The mobile layout now displays correctly on a real phone as well.
So the root cause was the WordOps/Nginx WP Super Cache static delivery rule, not the Newspaper theme or WP Super Cache plugin itself.
Thank you again for your assistance.
Hi,
That is very unusual. Even with the browser inspector I’m not seeing the mobile page when I check the desktop page -> https://prnt.sc/I07-OXZNZo-X I can see it if I add a parameter after the URL -> https://prnt.sc/Gna7zUnVf4yu and the page still seems to be cached by super cache. The parameter is however bypassing something if the mobile page is displayed.
The thing is, the super cache plugin has been our recommended caching plugin since the theme was released, mainly because it works correctly when using dedicated mobile content. Of course, now there are many other caching plugins, but most of them have options to create and serve separate caches desktop/mobile.
I can confirm that while using the super cache, the desktop/mobile content of the theme is always served correctly. I have never seen it fail. I saw similar cases like this before, and it always turned out that there were other caching systems active.
If I may ask, what kind of hosting are you using for the website? Are you sure there is no server cache of any kind? I can check as well in their documentation. Let me know.
Thank you!
Hi,
Thank you for your previous reply.
I made a controlled test on copied homepage pages, not on the live homepage.
Test pages:
– Desktop copy: https://bokanews.me/boka-news-2/
– Mobile copy: https://bokanews.me/boka-news-2-mobile/
WP Super Cache settings:
– Caching On
– Simple mode
– Disable caching for logged-in visitors
– Compress pages
– Cache rebuild
– 304 browser caching
– Mobile device support enabled
– Late init enabled
I also limited WP Super Cache to cache only these two test URLs, so the rest of the website is not cached.
Current test result:
1. The desktop copy is cached successfully:
wp-content/cache/supercache/bokanews.me/boka-news-2/index-https.html
2. The mobile copy is cached successfully as a separate mobile cache file:
wp-content/cache/supercache/bokanews.me/boka-news-2-mobile/index-https-mobile.html
3. When I open the mobile copy directly on a phone:
https://bokanews.me/boka-news-2-mobile/
it displays correctly.
4. But when I open the desktop copy URL on a real mobile phone:
https://bokanews.me/boka-news-2/
it opens the desktop copy and displays incorrectly. It does not switch to the mobile layout/page.
On the real homepage I also tested WP Super Cache with Mobile device support enabled. WP Super Cache created only:
wp-content/cache/supercache/bokanews.me/index-https.html
but it did not create:
wp-content/cache/supercache/bokanews.me/index-https-mobile.html
As a result, mobile visitors received the same cached homepage as desktop visitors, and the mobile homepage displayed incorrectly.
So the issue seems to be with the Newspaper/tagDiv Composer dedicated mobile homepage and WP Super Cache: even with Mobile device support enabled, the real homepage does not reliably generate and serve a separate mobile cache file.
Thank you.
Hi TagDiv Support Team,
I am experiencing a persistent error with TagDiv Composer on my website (hosted on SiteGround). Every time I try to edit or create a page—even a completely fresh, empty page—I get the following error:
“Layout sync error in Content. The editor expects 6 zones but the page is rendering 5.”
Here is what I have already checked and verified to isolate the issue:
PHP Version: The server is running on PHP 8.2.31.
Memory Limits: I have already increased limits in wp-config.php (WP_MEMORY_LIMIT set to 512M).
Plugins & Cache: The issue persists even on blank pages, with no third-party caching/minification conflicts.
System Status: In my Newspaper System Status panel, I noticed a warning regarding mod_substitute being active on Apache (“may cause a timeout error on TD Composer”). I tried tweaking the .htaccess file with SubstituteMaxLineLength and SubstituteEngine Off, but the error remains.
Since it happens even on blank pages, it’s definitely not an unclosed HTML tag in the content. Could you please let me know how to fix this rendering/sync conflict on PHP 8.2 / SiteGround?
Thank you,
Sara
Hi,
If you are using dedicated mobile content, such as the mobile theme plugin or mobile pages built with the composer, then please make sure that this setting is active -> https://prnt.sc/NKWqk2qeG5yd Or else the desktop/mobile version can get mixed up.
If that setting is active then the problem should be solved, assuming the super cache is the only cache used on the website.
Or is the problem different perhaps?
Thank you!
Hello everyone,
I’m having a license activation issue with the Newspaper WordPress Theme by tagDiv and I would like to know if anyone has experienced something similar.
I have an official Envato/ThemeForest Regular License for Newspaper Theme. The purchase is valid and the item still appears in my Envato downloads area. The license certificate confirms the purchase for:
Tema: Newspaper – News & WooCommerce WordPress Theme
Autor: tagDiv
Tipo de licença: Regular License
The theme had been working on this website for years.
The problem started after I reset the license key/domain association inside the Newspaper/tagDiv panel. After the reset, the license seems to have lost its association with the domain, and now I cannot activate it again.
Current behavior:
1. With no HTTP-blocking snippet active, WordPress Site Health does not show any warning about external HTTP requests being blocked.
2. When I try to activate the theme with the official Envato purchase code, the Newspaper activation page shows:
“Your purchase key is not valid.”
3. Earlier, when a performance snippet was active, the activation screen showed:
“Envato API is down, please try again later.”
4. That snippet was related to WP_HTTP_BLOCK_EXTERNAL, but it has already been disabled for testing.
5. With the snippet disabled and server cache cleared, the error is no longer the API error — it is now:
“Your purchase key is not valid.”
6. The key is the official purchase code from Envato, and the product is still listed in my Envato account.
It looks like the reset removed the domain association, and now the tagDiv validation system is rejecting the same official purchase code instead of allowing me to reassign it to the website.
I have already contacted tagDiv support, but I’m posting here in case someone has gone through the same situation and found a faster technical workaround.
Has anyone experienced this after resetting a Newspaper Theme license/domain association?
Is there any safe way to force the theme to re-sync the license with tagDiv/Envato, or does this require tagDiv to manually reassign the domain on their side?
Important: I am not sharing the full purchase code publicly for security reasons, but I have the official Envato license certificate and proof of purchase.
Thank you.
Hello,
I am using Newspaper 12.7.6 with WP Super Cache 3.1.1 on Nginx/PHP 7.4.
WP Super Cache works correctly and makes the site very fast, but I have a problem only with the homepage on mobile devices.
The homepage was created with the tagDiv/Newspaper mobile page layout. When WP Super Cache is enabled, the mobile homepage sometimes displays incorrectly on a real mobile phone. Articles and category pages seem to work fine.
My current WP Super Cache settings are based on your guide:
https://forum.tagdiv.com/cache-plugin-install-and-configure/
When I exclude both is_front_page and is_home from caching, the homepage displays correctly on mobile devices.
My question is: how can I safely cache the homepage with WP Super Cache without breaking the mobile homepage layout?
Should the homepage be excluded from cache, or is there a specific WP Super Cache setting recommended for a Newspaper/tagDiv mobile homepage?
Thank you.
Hi,
The issue with the sticky sidebar could be caused by optimization plugins, especially if it works when you check logged in, but not when logged out. I see you are using WP Optimize and maybe also Perfmatters. I suggest to deactivate these temporarily, then check if the sticky sidebar is working correctly for the website visitors.
The other issue is probably unrelated and could be caused by security plugins, or maybe object caching. If there is code there in the theme panel, but after modifying and saving the old code is still there, it’s most likely object caching. Besides Perfmatters and WP Optimize is there another cache active on the website, like Redis perhaps? Or maybe something from the hosting/server.
Thank you!
Please try something like this:
@media (max-width: 767px) {
div.td_block_big_grid_flex_2 .td-big-grid-flex-scroll-holder {
overflow-x: auto!important;
overflow-y: auto!important;
white-space: normal!important;
}
.td_block_big_grid_flex_2 .td-big-grid-flex-scroll-holder {
display: grid!important;
grid-template-columns: repeat(2, 1fr);
gap: 3px;
overflow-x: visible;
white-space: normal;
}
.td_block_big_grid_flex_2 .td-big-grid-flex-scroll-holder .td_module_flex_7 {
width: 100%!important;
flex: none!important;
}}
Then the Big grid flex 2 should look like this on mobile -> https://prnt.sc/BuxRJFJFWpqi
The code can be entered in the Live CSS in the admin bar, or in the theme panel custom CSS section. Maybe also clear the website cache to make sure the code applies.
Please give it a try and let me know if it worked or in case there are any problems with it.
Thank you!
