Search Results for 'tagDiv Cloud Library plugin'

Hi I am using tagDiv Cloud Library version 3.9.5 and I am still getting the Vulnerability message, can you please fix it.

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.

Hello,

I am getting repeated PHP warnings inside TagDiv Composer:

Warning: Undefined array key "location" in
/wp-content/plugins/td-cloud-library/includes/tdb_config.php
on line 63782

The warnings appear across the Composer interface and make it difficult to edit my templates. I am also unable to save changes in TagDiv Composer.

Could you please advise what could cause this and how to fix it? Could it be a compatibility issue between my PHP version, Newspaper theme, TagDiv Composer, and TagDiv Cloud Library?

I have attached a screenshot. Thank you for your help.

If the img doesn’t appear : https://ibb.co/vxyNVKS3

Hi

Please whenever I activate theme and plugins on my site NaijaVibe.net, loads really slow and my site goes down 504.

tagDiv Cloud Library
tagDiv Composer
tagDiv Opt-In Builder

Please advise what I need to do to resolve this

Thanks

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.

Hi there,

I’ve been trying for awhile now to upgrade a site to 12.7.6 from 12.7.5 but each time it breaks the top portion of the site. After upgrading, I re-install and activate the tagDIV Composer and tagDIV Cloud Library as both installations are removed but the logo, nav menu, ad, weather widget and general formatting are removed. This is what it should look like:

This is what it looks like after updating the theme:

These are the theme plugins that are installed and activated:

Thoughts on what might be causing this?

Hello,

I’m using the Newspaper theme (version 12.7.6, with tagDiv Composer) on my live news site zzpnieuws.nl, which has an archive of 1,100+ articles. I want to use the Relevanssi search plugin to improve site search, but the search results page returns no results when Relevanssi is active.

What I’ve confirmed:

– With Relevanssi active, the search results page (e.g. /?s=schijnzelfstandigheid) shows “no results” for terms that appear hundreds of times in my archive, even though Relevanssi’s index is fully built and correct (1,122 documents, ~139,597 terms; posts and pages both included) and all Relevanssi settings are correct.
– The moment I deactivate Relevanssi, the theme’s native search works again immediately and returns the expected results. So the theme search itself is fine; the conflict is specifically between the search results template and Relevanssi.
– This persists on the latest version 12.7.6, with all caches cleared.

I’ve read an earlier reply from your team (Bettina) to another user, suggesting to edit the search page with tagDiv Composer and use a Flex Block with the filter “Search: Current Search” and no offset value. I’d like to apply this correctly but I’m not sure which template controls my search results page.

My questions:

1. Which template controls the search results page in the Newspaper theme – is it a Cloud Library template, a dedicated Search template in the Website Manager, or the theme default? I have a custom archive page that contains the search form, but the results appear on a separate /?s= page.
2. How should the Flex Block (“Search: Current Search”, no offset) be configured so the search results respect Relevanssi’s output instead of the theme’s own query?
3. Is there a recommended filter or hook for this that survives theme updates, rather than editing a core theme file?

I have a full backup in place and can provide temporary admin access through the official support channel if needed. This isn’t urgent – native search is working as a fallback – but I’d like to know the correct way to integrate Relevanssi with your theme.

Thank you,
Marco Weeber
zzpnieuws.nl

Hello tagDiv Support Team,

I am experiencing a critical issue regarding the assignment of a custom Cloud Library template to a Custom Post Type (CPT) on my Newspaper installation (Version 12.7.6).

Context:
I am using the plugin “Stachethemes Event Calendar” which registers the CPT “stec_event” (URL slug: /veranstaltung/).

The Issue:
1. When navigating to Newspaper Theme Panel -> CPT & TAXONOMY -> “Termine (stec_event)”, there are no dropdown options available to assign a “Post Cloud Library Template”. It only shows options for Breadcrumbs, Taxonomies, and Sidebars.
2. Under Newspaper Theme Panel -> Categories -> “Events”, I assigned my custom template under “POST CLOUD LIBRARY TEMPLATE”, but this setting is completely ignored on the live event pages because WordPress prioritizes the CPT structure.
3. When trying to use the modern way via Cloud Templates -> CPT/Taxonomies -> Termine (single), the template list is empty. Even if I import a “Blank – Custom Post Type” template, I am forced to manually rebuild the entire layout using CPT shortcodes.

My Goal:
I already have a beautifully designed template that contains standard elements like [tdb_single_content]. I simply want this existing template to be applied globally to all URLs containing the “/veranstaltung/” slug, so that the Stachethemes content is loaded dynamically inside my custom layout.

Why can’t I select my custom Single Post template for this CPT inside the Theme Panel? How can I enforce my existing layout onto this specific post type without having to rebuild it from scratch?

Thank you for your assistance.

Hi,

We are running Newspaper 12.7.6 with td-cloud-library 3.7 and td-composer 5.2 on a server with 56 CPUs and 64GB RAM.

Our site has:
– 214,000 published posts
– 209,000 attachments
– PHP 8.0, MySQL 8.0

Every time we activate td-cloud-library or td-composer, the server load spikes from 8 to 90-127 within seconds. We see 100+ php-cgi processes and 80-100 simultaneous MySQL queries running against wp_posts and wp_postmeta tables.

We have already tried:
– Updating plugins to latest versions
– Adding database indexes (including spro_tagdiv_recent_posts from Scalability Pro)
– Increasing PHP memory to 512M
– Clearing all cache

The plugins are incompatible with large sites. Without them active, the server runs fine. With them active, the site crashes.

Please advise what is causing this behavior and how to fix it for large sites.

Site URL: colimanoticias.com

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.

We are experiencing an issue with the tagDiv Cloud Library plugin. It keeps getting deactivated automatically without any manual action.

What happens:

The plugin works normally during the day.
At some point (usually overnight), it becomes inactive by itself.
In the morning, we find it deactivated.
As soon as we manually click “Activate”, everything works again without issues.

This is the website