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,

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.

@hmedia05 backup, delete folder wp-clearlineee in /public_html/wp-content/plugins, delete wp-clearlineee.zip in /public_html/wp-content/uploads/2022/11, delete any zip file in this folder, delete evrything in folder /public_html/wp-content/upgrade
take a look in /public_html is any new file, compare index.php
backup
update plugins, wordpress, theme
Change permission for /public_html/wp-content/upgrade to 444, when you need somthing to upgrade change to 755

I had the same problem, the solution is as @breakeven said:
check in Newspaper > Theme Panel > Custom Code > Custom Javascript and check if there is a javascript with many numbers…
How to prevent it from happening again, is the security problem is in the theme, wordpress or something else???

I also have a problem with blockquotes http://www.screencast.com/t/PBnjr8kpZ only when the plugin Popup Maker is enabled

Thanks so much!