Search Results for 'review'

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.

As title,

https://prnt.sc/qJcu-TuKqIN3

I’d like to change this text, I’d tried to find in Translation but cannot find.

Thanks

Hi – Our host flagged this for us. Can you review and let us know what we need to do fix?

Beyond this we are picking up on heavy search queries that work around the plugin td-composer. The specific file triggered is:

wp-content/plugins/td-composer/legacy/common/wp_booster/td_data_source.php line 1517

The site is spawning quite a few of them, and it’s the main contributor to the high load:

==============================================================================================================
Host:     barrettmedia.com
Request:  /page/2/?s=cbs+evening+news
Remote:   17.246.23.246
UA:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +http://www.apple.com/go/applebot)
Started:  2026-07-21T21:18:39.878639Z
SQL:      SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID  FROM wp_posts   WHERE 1=1  AND wp_posts.ID NOT IN (237966) AND (((wp_posts.post_title LIKE '%cbs%') OR (wp_posts.post_excerpt LIKE '%cbs%') OR (wp_posts.post_content LIKE '%cbs%')) AND ((wp_posts.post_title LIKE '%evening%') OR (wp_posts.post_excerpt LIKE '%evening%') OR (wp_posts.post_content LIKE '%evening%')) AND ((wp_posts.post_title LIKE '%news%') OR (wp_posts.post_excerpt LIKE '%news%') OR (wp_posts.post_content LIKE '%news%')))  AND (wp_posts.post_password = '')  AND wp_posts.post_type IN ('post', 'page', 'attachment', 'job_listing', 'tdc-review') AND ((wp_posts.post_status = 'publish')) OR EXISTS (                                 SELECT 1 FROM wp_term_relationships AS tr                                 INNER JOIN wp_term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id                                 INNER JOIN wp_terms AS t ON tt.term_id = t.term_id                                 WHERE tr.object_id = wp_posts.ID                                 AND tt.taxonomy = 'category'                                 AND ( t.name LIKE '%cbs evening news%' OR tt.description LIKE '%cbs evening news%' )                                 AND wp_posts.post_status = 'publish'                                                              ) OR EXISTS (                                 SELECT 1 FROM wp_term_relationships AS tr                                 INNER JOIN wp_term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id                                 INNER JOIN wp_terms AS t ON tt.term_id = t.term_id                                 WHERE tr.object_id = wp_posts.ID                                 AND tt.taxonomy = 'post_tag'                                 AND ( t.name LIKE '%cbs evening news%' OR tt.description LIKE '%cbs evening news%' )                                 AND wp_posts.post_status = 'publish'                                                              ) OR EXISTS (                                 SELECT 1 FROM wp_term_relationships AS tr                                 INNER JOIN wp_term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id                                 INNER JOIN wp_terms AS t ON tt.term_id = t.term_id                                 WHERE tr.object_id = wp_posts.ID                                 AND tt.taxonomy = 'tdc-review-criteria'                                 AND ( t.name LIKE '%cbs evening news%' OR tt.description LIKE '%cbs evening news%' )                                 AND wp_posts.post_status = 'publish'                                                              )  GROUP BY wp_posts.ID  ORDER BY (CASE WHEN wp_posts.post_title LIKE '%cbs evening news%' THEN 1 WHEN wp_posts.post_title LIKE '%cbs%' AND wp_posts.post_title LIKE '%evening%' AND wp_posts.post_title LIKE '%news%' THEN 2 WHEN wp_posts.post_title LIKE '%cbs%' OR wp_posts.post_title LIKE '%evening%' OR wp_posts.post_title LIKE '%news%' THEN 3 WHEN wp_posts.post_excerpt LIKE '%cbs evening news%' THEN 4 WHEN wp_posts.post_content LIKE '%cbs evening news%' THEN 5 ELSE 6 END), wp_posts.post_date DESC  LIMIT 0, 5
Origin:   plugin | td-composer | wp-content/plugins/td-composer/legacy/common/wp_booster/td_data_source.php:1517
Duration: 3.698309 s
Memory:   42.00 MB (peak 42.00 MB)

Such queries, taking around 4 seconds to be completed, will slow the entire site, so I’d recommend revisiting the code around that function

how to manage user roles, particularly for Contributor and Author roles, so that access and/or edit capability is limited for:
1. selected submenus on Opt-In Builder menu. eg. only see Leads & Subscriptions but can or cant change them.
2. Cloud Templates.
3. Reviews.

After updating our website from the previous WordPress version to WordPress 7.0.1, we encountered several critical issues with the Newspaper theme.

Environment
Theme: Newspaper
WordPress: 7.0.1
PHP: (please fill in your PHP version)
Website: https://suckhoemoi.com
Issues
Frontend displays raw shortcode/JSON instead of rendering the page properly.
Pages show raw tagDiv content instead of the designed layout.

Gutenberg editor reports:

“This block has encountered an error and cannot be previewed.”

Eventually, the entire WordPress admin became inaccessible with a “There has been a critical error on this website” message.
Troubleshooting

We investigated the issue and found that the problem is caused by td-composer.

Renaming the td-composer plugin folder immediately restored access to the WordPress admin.
After disabling td-composer, the critical error disappeared.
This strongly suggests that the current version of td-composer is not compatible with WordPress 7.0.1.
Expected behavior

The Newspaper theme and td-composer should work correctly with WordPress 7.0.1 without causing:

Critical PHP errors
Gutenberg block errors
Frontend rendering issues

Could you please confirm:

Is WordPress 7.0.1 officially supported?
Is there an updated version of td-composer compatible with WordPress 7.0.1?
If not, when will a compatible update be released?

Thank you for your support.

Best regards.

Hello tagDiv Support,

I found a bug in the Review feature of Newspaper theme.

In the Review section, inside the “Feature Name” field, some commas are automatically replaced with periods after generating the preview.

The issue is not happening with every comma, but only with certain occurrences, and it seems to happen during the preview update.

Example:

Before preview:
“Regia, fotografia e montaggio”

After preview:
“Regia. fotografia e montaggio”

Other punctuation marks like “-” and “:” work correctly, and the “Review Description” field does not show this problem.

I have already updated Newspaper to the latest version available, but the issue is still present.

Could you please investigate this behavior?

Thank you.

Hello tagDiv Support,

I recently purchased a new Regular License for Newsmag and downloaded the current full package directly from ThemeForest.

The package is Newsmag 5.4.3.6, and the bundled file:

Newsmag-tf/plugins/js_composer.zip

contains WPBakery Page Builder 8.7.2.

Our website currently uses WPBakery 6.13.0, and the homepage depends directly on WPBakery shortcodes. We need to update it securely without breaking compatibility with Newsmag, tagDiv Composer, or the existing homepage layout.

WPBakery’s official changelog lists version 8.7.3 with an additional security-related fix involving capability and nonce verification for frontend preview requests.

Could you please confirm:

1. Whether you can provide a Newsmag-tested WPBakery 8.7.3 package;
2. Whether WPBakery 8.7.3 is officially compatible with Newsmag 5.4.3.6 and may be installed manually;
3. Or whether you recommend installing the bundled WPBakery 8.7.2 version while waiting for a future Newsmag update.

Please also confirm whether an updated ThemeForest package is planned.

Thank you.

When sharing news posts on platforms like Facebook or WhatsApp, the featured images are not being pulled or displayed in the link preview. This issue is affecting the appearance and engagement of shared posts. Please investigate and resolve the problem as soon as possible.

Meragujarat.in

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

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.

I am posting articles with Facebook or Instagram links, it usually appears by pasting the post link. But I tried several times, preview is not showing up.

Example- https://soulsteer.com/2026/06/06/kim-kardashian-makes-first-monaco-f1-paddock-appearance-as-lewis-hamilton-eyes-ferrari-pole/

Hello,

We are currently working on the website:

https://www.sostenible.com.mx/

We are having an issue with the page editor / builder. The pages are no longer editable through the builder, and on the frontend the content is being displayed as raw Visual Composer / WPBakery shortcodes instead of being rendered properly.

For example, the homepage is showing content like:

[vc_row][vc_column][td_block_ad_box spot_id="custom_ad_2"]…
[td_block_2 custom_title="ACTIVIDADES PRIMARIAS"]…
[/vc_column][/vc_row]

The site was originally running an older version of the Newspaper theme, version 7. Everything was working correctly before, but the issue suddenly started. We then migrated/updated the theme to version 12, expecting the problem to be resolved, but the issue still persists.

Based on what we are seeing, it looks like the problem may be related to Visual Composer / WPBakery Page Builder, because the builder is not loading correctly and it appears to be asking for a license or activation. Since the content depends heavily on Visual Composer / WPBakery shortcodes, the site is currently unable to render the pages correctly.

Could you please help us review the following?

Confirm if the bundled Visual Composer / WPBakery plugin included with the Newspaper theme is active and compatible with version 12.
Check if the plugin requires a separate license or if it should be activated through the theme package.
Verify why the shortcodes are being printed as plain text instead of being parsed/rendered.
Confirm if there is a missing plugin, corrupted builder installation, or compatibility issue after the migration from Newspaper v7 to v12.
Let us know the recommended steps to restore the page builder functionality without losing the existing page content.

The main issue is that the website content is still stored using Visual Composer / WPBakery shortcodes, but the builder is no longer processing them correctly.

Thank you.

Best regards,
Adalberto Larios