- NewsmagTheme colors introduction
- NewsmagSmart list ads
- NewsmagIntroduction
- NewsmagMain menu
- NewsmagLogo & Favicon
- NewsmagHeader ads
- NewsmagSmart sidebar
- NewsmagSharing buttons
- NewsmagCategory tag on modules/blocks
- NewsmagBackground introduction
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!
Claude for the win! – Found it — confirmed directly in the page’s DOM. The cause is a menu link URL collision, not a bug in the “active state” logic itself:
The root issue: Under each of the SPORTS, NEWS, MUSIC, and BUSINESS dropdowns, the “Writers” submenu header is set to link to https://barrettmedia.com/ — the homepage — instead of a real anchor page (probably because there’s no dedicated “Writers” landing page, so whoever built the menu left the URL pointing at home as a placeholder).
WordPress’s nav walker assigns the current-menu-item / current_page_item classes (which drive the “active” styling) by comparing each menu item’s URL to the current page’s URL. Since four separate “Writers” items all share the exact same href as HOME, all of them get flagged current/active whenever you’re on the homepage — alongside HOME itself, which is correctly active.
That’s 5 “active” items per menu instance (HOME + 4x Writers). And because the theme renders the same nav markup three times in the DOM (desktop menu, mobile menu, and what looks like a sticky/duplicate header version — all sharing the menu-fall-2025-main-menu-2 menu), it shows up 15 times total in the page.
The fix: give each “Writers” submenu parent a real destination (an actual writers/authors archive page, or at minimum a distinct # / non-matching anchor) instead of the bare homepage URL. Once those links stop matching https://barrettmedia.com/, WordPress will stop marking them current, and only HOME will show active on the homepage.
Hi,
The first thing I see is that the required composer plugin isn’t active on the website. Please install it from the theme plugins panel -> https://prnt.sc/7P2I8thU8xeb Most of the theme’s functionality and features depend on the composer, so it should be active.
Then you can choose what you want to use, a simpler basic design based on the standard pack plugin, or a more advanced and complex design based on the cloud library -> https://tagdiv.com/why-tagdiv-cloud-library-is-a-better-alternative-to-the-standard-pack/
To provide a bit of context, the theme by itself with none of the theme plugins active is basically useless. The composer plugin provides the base. Then there are 2 directions, the cloud library or the standard pack, these add the extra capabilities.
I also noticed that you are using AMP -> https://prnt.sc/yhj7NKjJtRHv I rarely see AMP used anymore. But if you want to use it, then we recommend using it together with our mobile theme -> https://forum.tagdiv.com/tagdiv-amp-plugin-tutorial/
Let me know.
Thank you!
Hi
I have your theme installed and it works well on the large screen devices but on the mobile, the hamburger menues do not work at all. Please advice.
My site:
https://erik.zalitis.se/
Dear TagDiv Support Team,
I hope you are doing well.
I am using the TagDiv Theme with WooCommerce on my website.
Website: https://grookfit.com
I have noticed a compatibility issue when enabling Razorpay Magic Checkout.
After enabling Magic Checkout:
1.The mobile product page layout becomes distorted.
2.The main product image is resized incorrectly.
3.The product gallery alignment changes.
4.The overall responsive design is affected.
When I disable Magic Checkout, the product page immediately returns to its normal responsive layout.
Additionally, Razorpay’s Buy Now feature does not appear on the product page even though it is enabled in the Magic Checkout settings.
I have attached screenshots showing the product page before and after enabling Magic Checkout.
https://prnt.sc/DxkZdCfZO2LL , https://prnt.sc/cNL45N7MpQju , https://prnt.sc/5p15SGmFamU7
Could you please check whether this is a compatibility issue between the TagDiv theme and Razorpay Magic Checkout, and let me know if there is a recommended fix or CSS/JavaScript compatibility patch?
Thank you for your support.
Hi Simion,
Yes, the extra menu was something we added while testing a few possible external solutions, but it also helped us identify the root cause of the issue.
We just wanted to let you know that the mobile menu is working correctly. The problem is that the website is loading too slowly, so until it finishes loading, it doesn’t allow the menu to open. Once the site has fully loaded, the menu works without any issues.
We are currently in contact with our server support team to find a solution. Thank you for taking the time to check our website.
Regarding the updates, we won’t be performing them this weekend because we’re expecting increased traffic. We’ll be livestreaming a cattle show in Guatemala, so we’d rather avoid making changes during that time. We will most likely handle the updates next week.
Once we determine what is causing the website to break when we update the PHP version, what would you recommend as the best order for the remaining updates? Should we:
-Update the PHP version
-Update the theme
-Install the tagDiv Standard Pack plugin
Please let us know your advice on this, as well as any other suggestions you may have regarding the update process. Thanks in advance!
Hi,
Currently I see some kind of custom mobile menu, or from a plugin, on top of the theme mobile menu -> https://prnt.sc/xr6is1rpWCft That extra mobile menu is displayed over the entire mobile header actually, meaning that I can’t click on the theme mobile menu, the logo, or the search.
If I delete that extra menu using the browser inspector, then the theme mobile menu seems to work correctly -> https://prnt.sc/tTDRcRp4z_Qw It opens correctly. So the only problem I see is that there is an extra menu in the mobile header, making it impossible to interact with the theme header.
About updating, if the website broke after updating the PHP, that can be caused by multiple things. Could be because of a plugin that doesn’t support newer PHP versions, or custom code, or the child theme as I see you use one, or an inactive extension in the new PHP version, or other causes. I suggest testing on a staging/testing clone of the main website, in order to deal with the issues there first.
From the theme perspective, if you update it just make sure to install this standard pack plugin -> https://prnt.sc/zkjDfLHkzSHy That’s a plugin we added in Newspaper 10. Normally it’s optional, but for older websites it’s required. Older websites are built with the older blocks, grids, templates, etc. and they will not display correctly without that plugin.
Thank you!
We stopped updating the theme over a year ago because it requires to update the PHP version from our 7.4 to 8.3. We could update the PHP, but when we did try to update it broke everything. All the pages got messed up and we had to roll back the site. So it either broke the WPbakery page builder or the Tag DIV. We were afraid to update again as it took hours to roll back the site. We are not sure if you started using your own builder or what, but this is a very large site and we did not want to lose everything. Not sure why now the mobile menu will not work – but it does not open. We would like to either find a way to update the site with the existing theme but NOT break everything we have; Or we will have to abandon this theme. Any suggestions? Our site is located at https://brahmanjournal.com/ Maybe we did something wrong when we updated the site. If you can help us we would appreciate it. If we need to pay for a new support I can do that, we have had this theme a long time and would like to keep it if possible.
Hi,
That’s the mobile theme version -> https://forum.tagdiv.com/mobile-theme-introduction/
The mobile theme is an optional plugin that we provide. It has it’s own design, homepage, templates. Please deactivate it if you don’t want to use it -> https://prnt.sc/4hIOpMXHN4oY Then the same content from desktop will be displayed on mobile.
Let me know if I can help more.
Thank you!
Hi,
No problem.
1. That’s possible. The active color for the links in the mobile menu can be set in the theme panel -> https://prnt.sc/JCEFjWULjfqE
2. Are you referring to the socials displayed in the mobile menu? If so, that isn’t possible unfortunately.
If you want to customize the mobile menu more, or in detail, then you could use a popup instead. Like we use on some of the demos -> https://demo.tagdiv.com/newspaper_urban_observer_pro/ On mobile the menu is a popup. A popup can be set to open a page which you can build with the composer. Then you could add the social icons in that page, and change the order of the socials -> https://prnt.sc/YnyOx4ivkzlV While it is more work, sometimes using a popup instead of the regular mobile menu can be useful.
If you want to know more about popups there is a guide here -> https://forum.tagdiv.com/modal-popup/
Thank you!
Hi,
Is there no message in the page on mobile when you check logged in? For example -> https://prnt.sc/fGKSc310dIPF
That message is displayed for pages when the mobile theme plugin is active -> https://prnt.sc/faCV1r-BgKKt
Please check the mobile theme guide carefully -> https://forum.tagdiv.com/mobile-theme-introduction/ especially the part about pages -> https://prnt.sc/weXgkmMS9AuN
So basically when the mobile theme is active, a page needs to have 2 versions, one for desktop and one for mobile. If you edit a page there should be a mobile editor section usually at the bottom -> https://prnt.sc/amy6YqhBe_DT
The important thing to note is that the mobile theme plugin is optional. So if you don’t want to build and maintain two versions for each page, then please deactivate the plugin. Then the content from desktop will be displayed on mobile as well. Or, if you want to use it and you need help with it, please let me know how I can help.
Thank you!
my website is on the newspaper theme
I. have this isuue
https://newsinamerica.com/en/about on the desktop does show perfect, but on mobile i can’t view the webpage correct.
Please help me,
best regards
Juan
Hi,
If the sticky bar you are referring to is this row displayed at the bottom on mobile -> https://prnt.sc/1LzN6S1iisda then it is indeed loaded together with the rest of the page. Making a row sticky doesn’t mean that it’s content is loaded with a delay, there’s no option for something like that unfortunately and I can’t provide instructions on how it could be done. The only load delay the theme provides is for mega-menus, popups, footer, which were made by our developers as options in the composer and theme panel.
If maybe that sticky row is needed just for tablet/mobile, you could use a mobile page to stop loading it unnecessarily on desktop -> https://prnt.sc/igZ3qKBfCvvi I see no sticky row on desktop at this time, only on mobile.
The page is already very fast on desktop -> https://prnt.sc/JOg1CSHQz3aK and on mobile -> https://prnt.sc/KGKTTUvDDi5S due to the WP Rocket optimization for CSS and JS. And I see that the automatic lazy rendering is working as well -> https://docs.wp-rocket.me/article/1835-automatic-lazy-rendering The website is very fast.
Thank you!
I’ll need an example of the issue. By default the theme is responsive, meaning the same content from desktop is displayed on mobile. So there’s not need to to anything special.
If you deactivated the mobile theme and there is a problem, please provide an example of the problem or let me know where I can see it on your website, and I will check.
Thank you!
Before I installed the mobile theme plugin the website didn’t show on mobile. Is there a way to have it show on mobile without needing the mobile plugin?
Hi,
I see you activated the mobile theme plugin. It is very important to know what that plugin does -> https://forum.tagdiv.com/mobile-theme-introduction/
There are a few major changes to the website on mobile, after activating the mobile theme.
One major change is how pages are treated -> https://prnt.sc/S0T1lLDmXQJt Each page will require entering content in a mobile editor, and that’s the content it will display on mobile. So there are 2 versions, the desktop version and the mobile version -> https://prnt.sc/6MvoohUMISim
It is also important to know that the mobile theme plugin is optional. You could simply not use it, and the content from desktop will also be displayed on mobile.
Please let me know if I can help more.
Thank you!
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!
Hullo!
Ive used the Blockchain header template and made a website and a mobile view, but I keep getting the Blockchain logo on mobile no matter what i do. I also can’t default to the mobile site Ive made, it just pulls my webpage, and this is showing the Blockchain logo.
I also cant set a mobile footer without making a completely new mobile view.
Ive been through all the theme settings, help!
au4championship.com
TIA,
Sammy
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,
I am using the **Newsmag theme** and I have a serious issue with ad impression tracking when using **Advanced Ads**.
### Problem:
Ad impressions are being **counted multiple times per single page view**.
Example:
* I open a news article once
* The ad is displayed only once on the page
* But Advanced Ads records **1-2-3-4–6… impressions for the same visit (random)**
### What I have already tested:
* Issue happens with **Advanced Ads sidebar widget**
* Also happens with **shortcodes in header**
* Tested with **WP Rocket disabled**
* Tested with **Lazy Load ON and OFF (0px / 200px)**
* Bot tracking is disabled
* GA4 is not responsible (same behavior independently)
### Conclusion:
This clearly suggests that the problem is not related to caching or plugin configuration, but to how **Newsmag renders widget areas or theme templates in the frontend**.
It seems that:
* Sidebar or header areas may be rendered multiple times (desktop/mobile/sticky/AJAX)
* Or the DOM is being rehydrated/rebuilt after page load
* Which causes Advanced Ads to register multiple impressions for a single page view
### Request:
Could you please provide a **fix or official workaround** for this issue?
Specifically:
1. Does Newsmag render widget areas more than once per page load?
2. Is there any known issue with duplicate rendering of sidebars or header areas?
3. Is there a recommended way to ensure that widget areas are rendered only once for ad tracking compatibility?
4. If this is a theme limitation, what is the correct setup for ad placement to avoid duplicated impressions?
This issue makes ad analytics unreliable and directly affects monetization accuracy.
I would appreciate a clear technical solution or configuration guidance from your side.
my website: http://www.redeweb.com
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!
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.
