Search Results for 'review'

I’m using the Video Block in tagDiv Composer on a page (not a post) with a self-hosted video (no YouTube, no Vimeo, just an MP4 URL).

Before the video starts, I want to show a custom poster image, the same way you can define a thumbnail on Vimeo.

I don’t see any option for this in the block settings.

– Is there a built-in way to set a poster image for a self-hosted video? If not, what’s the recommended approach?

– What image is shown by default? First frame of the video?

Thanks!

Some of the articles on our site are reviews of videogames. We use the review system built into Newspaper. In the Newspaper Theme Panel, “Enable product schema on review” is enabled.

However, Google is flagging our review articles with an error which says Invalid object type for field "<parent_node>"

You can see a live version of the issue here through Google’s Rich Results Test page: https://search.google.com/test/rich-results/result/r%2Freview-snippet?id=DfTviPc7bxH6VDh62MWi5Q

How can we fix this? Google is flagging the issue on hundreds of our reviews.

Hi,
We are not able to edit the home page content on tagdiv composer, but are able to edit the article and review pages content with composer.

We are getting – Server Error
500
Internal Server Error

Error box says – Layout sync error in Content
The editor expects 6 zones but the page is rendering 0. Usually caused by an unclosed HTML tag in a text block (e.g. <div> without </div>). View page Undo (Ctrl+Z / Ctrl+Shift+Z) to restore.

We checked the code with AI, and there are no unclosed HTML blocks.

We have tried to disable all plugins except tag divs, that did not work.
It is working fine on our other website, though. Maybe some code issue here.

Cannot understand the problem; it works on one page and does not work on home page.

Do help.

Thanks
SP
http://www.GadgetBridge.com

Hello,
I’m experiencing a layout sync error in the Header, specifically in column 1 of row 1.

Error message:
“Layout sync error in Header, column 1 of row 1. The editor expects 1 block but the page is rendering 3. Usually caused by an unclosed HTML tag in a text block (e.g. without ).”

I have already checked the content but I’m unable to resolve. I have also tried several methods to resolve the issue (including reviewing the HTML, undoing recent changes, and checking the layout structure), but the problem persists.

The issue only appears in homepage and prevents me from editing the layout correctly.

Additionally, Google has not been indexing the homepage or the articles since this issue started

Could you please help me identify where the extra blocks are coming from or how to fix the mismatch between the editor and the rendered page?

Thank you in advance for your support.

Kind regards
Antonella

We have a support contract and are seeing two issues we’d like your help resolving.

I can send further sensitive or confidential information to your contact email referencing this specific ticket.

— Issue 1: Layout sync error blocking front-page edits —

When attempting to edit the front page in tagDiv Composer, the editor displays:

“Layout sync error in Header, row 2. The editor expects 1 element but the page is rendering 0. Usually caused by an unclosed HTML tag in a text block (e.g. <div> without </div>). View page | Undo (Ctrl+Z / Ctrl+Shift+Z) to restore.”
The error points to the header ad position in Header row 2, which renders as an “EMPTY INNER COLUMN” with a red outline in the editor.

The Undo shortcut (Ctrl+Z / Ctrl+Shift+Z) does not fix the problem.

This has been an ongoing issue for multiple months and is preventing front-page edits.

— Issue 2: Sidebar preview missing in post editor —

After updating our various web sites to 12.7.6, the post editor no longer shows the sidebar reservation area — the visual cue that previously showed the authors the actual rendered width of the post content with the sidebar reservation accounted for.

This affects both the production site and the dev site. Other sites we host using prior versions of the theme are not affected and continue to show the sidebar preview correctly.

Thanks — looking forward to getting this resolved.

Hello tagDiv team,
We would like to report a recurring fatal error affecting a WordPress.com-hosted site using Newspaper and tagDiv Composer.

This issue seems to occur only when the site visibility is set to private on WordPress.com. We use the same Newspaper/tagDiv stack on other sites, but this is the only one where the WordPress.com private-site access flow is involved.

The fatal error is:
PHP Fatal error: Uncaught Error: Class “td_res_context” not found

The error is triggered from:
wp-content/plugins/td-composer/legacy/common/wp_booster/td_js_generator.php

From the stack trace, the issue happens during the wp_footer hook. In this specific WordPress.com private-site flow, WordPress.com serves an access-denied/private-site template and calls wp_footer(). At that point, tagDiv Composer runs its footer callback and tries to use the td_res_context class, but that class has not been loaded yet.

The class appears to be defined in:
wp-content/plugins/td-composer/legacy/common/wp_booster/td_css_res_compiler.php

So it looks like the Composer callback in td_js_generator.php assumes that td_res_context is already available when wp_footer runs. That assumption seems to fail in this WordPress.com private-site access-denied context.

Environment:
– Hosting: WordPress.com
– Site visibility: Private
– WordPress: 6.9.4
– PHP: 8.4.21
– Theme: Newspaper 12.7.6
– tagDiv Composer: 5.4.5
– tagDiv Cloud Library: 3.9.5
– tagDiv Standard Pack: 2.8, built on 05.05.2026 9:08

We kept this issue as a low-priority investigation for some time because, although the fatal error was recurring in the PHP logs, the site appeared to work correctly in normal usage. Both the front end and the back office were functioning as expected, and we did not observe any visible impact for regular users or administrators.
However, the error became very frequent in the PHP logs, so we investigated further.

As a temporary workaround, we added a defensive snippet that runs before the tagDiv Composer footer callback and loads the file containing td_res_context only if the class is not already available. After applying this workaround, the recurring fatal errors stopped.

This suggests that the issue could be fixed in the plugin by either:
1. Ensuring the required dependency is loaded before td_res_context is used; or
2. Adding a guard clause before calling td_res_context inside the wp_footer callback.

Could you please review this scenario and consider adding a compatibility fix for WordPress.com private sites or for cases where wp_footer is called outside the normal theme-rendering flow?

Thank you.
Best regards.

The Social Counter does not scrape the Pinterest count. I have followers, but the count is zero.

I made sure all the keys were updated for the social sites.

I asked Cursor AI, with the (Auto) model selected, to review the code. It stated that there were issues with the Social Counter code.

Hi,

Even though I’ve installed Yoast and set up the associated image, my posts don’t show any photos when I share them on Facebook.
How can I fix this?
http://www.amenteludica.it
Missing photo on https://www.amenteludica.it/unboxed/ for example

Thanks

You should ask an AI app to review the weather widget for issues. I asked the following question in Cursor AI:

Are the units used correctly? When I check the data returned from the API call, it doesn’t match up with the data on https://openweathermap.org/ for the same city.

I received the following response:

I’m going to verify the unit handling logic in your weather class against OpenWeather response fields so we can isolate exactly why values differ.

—
Short answer: not fully — there are two real unit bugs in this file.

What’s wrong
w_units handling is incorrect
Any non-empty w_units value is treated as imperial:

td_weather.php
Lines 41-48
$current_unit = 0; // 0 – metric
$current_temp_label = ‘C’;
$current_speed_label = ‘kmh’;
if (!empty($atts[‘w_units’])) {
$current_unit = 1; // imperial
$current_temp_label = ‘F’;
$current_speed_label = ‘mph’;
}
So w_units=”metric” still flips to imperial.
That explains mismatch immediately.

Metric wind label/value mismatch
API requests units=metric, where wind speed is m/s, but code labels it as kmh without converting:

td_weather.php
Lines 428-431
if (isset($api_response[‘wind’][‘speed’])) {
$weather_data[‘today_wind_speed’][0] = round($api_response[‘wind’][‘speed’], 1);
$weather_data[‘today_wind_speed’][1] = self::kmph_to_mph($api_response[‘wind’][‘speed’]);
}
today_wind_speed[0] is m/s, not kmh.
today_wind_speed[1] also assumes km/h input, but input is m/s.

Where to fix
In wp-content/plugins/td-composer/legacy/common/wp_booster/td_weather.php:

Fix unit selection around the if (!empty($atts[‘w_units’])) block.
Fix wind conversions in owm_get_today_data() around wind speed assignment.
—

Then I asked the following:

Can you show me the exact fixes I need to make in order to correct this issue?

—
Yes — make these exact edits in wp-content/plugins/td-composer/legacy/common/wp_booster/td_weather.php.

1) Fix w_units detection (currently always imperial when non-empty)
Replace this block:

$current_unit = 0; // 0 – metric
$current_temp_label = ‘C’;
$current_speed_label = ‘kmh’;
if (!empty($atts[‘w_units’])) {
$current_unit = 1; // imperial
$current_temp_label = ‘F’;
$current_speed_label = ‘mph’;
}
with:

$current_unit = 0; // 0 – metric
$current_temp_label = ‘C’;
$current_speed_label = ‘m/s’;
if (!empty($atts[‘w_units’]) && strtolower($atts[‘w_units’]) === ‘imperial’) {
$current_unit = 1; // imperial
$current_temp_label = ‘F’;
$current_speed_label = ‘mph’;
}
2) Fix wind speed conversion (OpenWeather metric wind is m/s, not kmh)
In owm_get_today_data(), replace:

if (isset($api_response[‘wind’][‘speed’])) {
$weather_data[‘today_wind_speed’][0] = round($api_response[‘wind’][‘speed’], 1);
$weather_data[‘today_wind_speed’][1] = self::kmph_to_mph($api_response[‘wind’][‘speed’]);
}
with:

if (isset($api_response[‘wind’][‘speed’])) {
$weather_data[‘today_wind_speed’][0] = round($api_response[‘wind’][‘speed’], 1); // m/s from api
$weather_data[‘today_wind_speed’][1] = self::mps_to_mph($api_response[‘wind’][‘speed’]); // imperial
}
3) Add proper conversion helper (m/s -> mph)
Replace this function:

private static function kmph_to_mph($kmph)
{
return round($kmph * 0.621371192, 1);
}
with:

private static function mps_to_mph($mps)
{
return round($mps * 2.2369362921, 1);
}
Why this fixes your mismatch
w_units=”metric” will now stay metric (instead of being treated as imperial).
Wind values/labels now match OpenWeather metric/imperial behavior.
If you want, I can apply these edits directly for you now.
—

I followed those instructions and now the weather widget is displaying more realistic data to me.

Hi tagDiv team,

I have a Flex Block 1 (configured as “Latest news” widget in the homepage left column)
that renders empty in the frontend but displays posts correctly in the Composer editor preview.

DETAILS:
– Theme: Newspaper v12.7.5 (REGISTERED)
– Demo installed: Newsweek PRO
– Site: https://eurowaypoint.com
– WordPress: 6.9.4
– PHP: 8.2.30

THE PROBLEM:
– In Composer editor: the Flex Block 1 shows the latest 5 published posts correctly
– In frontend (incognito browser, logged out): the block container is generated
(div id=”tdi_96″ class=”td_block_inner td-mc1-wrap”) but completely empty —
no child modules are rendered inside
– 24 published posts exist in the database
– Other blocks on the same homepage (Big Grid Flex 1, other Flex Block 1 instances)
work correctly and display posts
– No JavaScript errors in browser Console
– The block has no special filters configured (Category: All, all filter fields empty)

WHAT I’VE ALREADY TRIED:
– Cleared all caches (SiteGround, WP Super Cache disabled, browser hard reload)
– Restored Homepage from a 3-day-old revision (no improvement)
– Disabled all third-party plugins one by one (Wordfence, SG Optimizer, etc.)
– Verified block configuration in Composer (Filter tab, Layout tab — all default/empty)
– Forced re-save of the block (changed limit number and saved)
– Removed custom CSS that contained :has() selectors

WHAT I NOTICED:
The block was working until I made some modifications today (changed page slug from
/plans/ to /newsletter/, edited some HTML custom blocks for Subscribe links).
The Latest block stopped rendering at some point during these changes.
Restoring an older Homepage revision did NOT fix it.

Could this be a corrupted block state in the database? Is there a way to reset
the block’s internal cache or regenerate its configuration?

Thank you for your help.