Search Results for 'css'

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!

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.

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!

Hello Support Team,

We’ve been having issues with images in the Table block for some time now. We insert them as inline images and then set the column to center alignment. However, they aren’t being centered.

As one of our developers has now noticed, this is likely due to the theme. He told me the following:

It appears that the CSS from the Newspaper theme is overwriting the settings from the editor (this is td-post-content img) — https://i.imgur.com/4DUjF9U.png

Our environment:
WordPress: 7.0.2
Newspaper: 12.7.6

I’m currently redesigning a news website that I manage, and I’ve run into an issue.

No matter what I try, I can’t change the color of the post titles in the news blocks using TagDiv Composer.

For example, I select Block 21, go to the General tab, and set the Title Text Color to white (#ffffff). I save the changes, but the new color is not applied on the frontend.

I’ve already checked whether there’s a CSS class or custom style overriding this setting, but I haven’t been able to find anything that would prevent the color change.

I’m using Newspaper theme version 12.7.7 with the Magazine PRO demo installed.

Could you please help me identify what might be causing this issue?

Thank you in advance for your help!

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.

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,

we have Accordion Pro on our site http://www.vpz.hr…the problem is with this site for example…https://www.vpz.hr/zupanijska-uprava/upravni-odjel-za-graditeljstvo-zastitu-okolisa-i-imovinsko-pravne-poslove/

and then tab Oglasna ploča….

on desktop its ok….but on mobile its not…there’s some “custom css” code in front of the actual code that works what I entered in that particular accordion…

that “custom css” code wasnt here before…it just appeared somehow hmm

They said this:

Last wordfence security team alert us to minor security issue for outputting script and style may cause security issue,

we are now using wp_kses function to escape accordion content, which causing strip all style and scripts from 3rd party shortcode,
to solve this issue, third party plugins authors must update their plugin to load style and script to header or footer not via old style via content.

I hope you understand, you may report to plugin author that you are using via accordion plugin content.

WHAT CAN WE DO !??

Currently setting up Newspaper on my staging site. Security plugin is flagging wp-includes/js/thickbox/thickbox.min.css as a suspicious file in the WordPress core and recommending removal. Is this a vital file of the theme to be left alone? Wanting to make sure that I don’t have any issues and Newspaper is the only thing recently added to the staging site.