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.