Search Results for 'footer templates'

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.

I own a news portal and have 2 hubs that require a special header and footer, I achieved to setup with custom templates for archive files and single files but i missed the same to search files, in your theme options when selecting by category couldn’t find a field to change the template of the search results. I think it should be easy for you consider it insome of your upgrades. Tnks

Hi, I added a new footer design using a footer templates, but I’m having some issues. The new footer is visible when previewing, but when I edit its content using Td Composer, I don’t see the footer content or any elements within Td Composer. Furthermore, the footer is not visible on the website’s front end and doesn’t appear on the website itself.

https://drive.google.com/file/d/1tBP8O-lk7_uPV1qfstIY3NUi0ZQt1dXx/view?usp=drive_link

Hello,
i just imported the Pre-designed Templates for my Newspaper theme (Default PRO) from the Cloud Library and i noticed a difference between the “Default PRO” and “Default RTL PRO” templates (header, footer, etc.): opening the templates with the TD Composer, the “Default RTL PRO” templates displays a line of code (CSS code), while the “Default PRO” templates don’t. To properly use my theme’s original template (“Default PRO”), which of the two templates do you recommend? Could the lack of code (CSS code) in the “Default PRO” templates be a problem? (I’ve always noticed problems with my site’s indexing)
Thanks a lot!

I am using Newspaper theme with the Default Pro layout. In my Cloud Templates, I have a “Header Template – Default PRO” and a “Single Post Template – Default PRO”. Under Page templates, there is a “Homepage – Default PRO” but no single Page template in my Cloud Templates. In my Single Post Template, I added a row to the top of the page that will show ads below the navigation and above the post content. I would like to do the same to all my existing pages, but I do not have a pages template that I can edit. Right now, my pages look exactly like my posts, with the same layout, navigation, sidebar, and footer, however they do not contain the ad row that my posts have. How can I add this to all existing pages? Alternatively, is there a way to add a row to the “Header Template – Default PRO” under the logo and navigation part that collapses in mobile? I tried adding a new row to the bottom of the header template under the navigation, but when the navigation switches to mobile menu, the row disappears.

Hello Support,

I am contacting you because I am running into what looks like a compatibility or translation-handling issue between WPML and the Newspaper theme by tagDiv.

My setup is:

WordPress

Newspaper theme (Today News PRO demo/import)

tagDiv Composer / Cloud Library

WPML

Secondary language: German (/de)

Default language: English

What I am trying to achieve is straightforward:
I want to have an English footer on the English site and a German footer on the German site. The footer content was created with the tagDiv Composer as a footer template / Cloud Template.

The issue is that I cannot create or manage the translation workflow for these Cloud Templates correctly, and as a result the German footer keeps showing English text for posts.

Here is what I observed:

In WPML → Settings → Post Types Translation, I set the Cloud Template post type to:
“Translatable – use translation if available or fallback to default language”

However, in the Cloud Templates area in the WordPress backend, I do not see the WPML translation controls I would expect, such as the language columns or the “+” translation icon for German.

Because of that, I cannot create a proper German translation of the footer template through WPML.

I also checked WPML String Translation and Translation Dashboard / Other texts (Strings), but the footer text does not appear there.

The footer text is not coming from a normal theme option or a menu string. It is content inside a tagDiv footer block created in the tagDiv Composer.

I tried creating a copied/duplicated footer and also a copied single post template as a workaround, but that led to additional problems:

changes in the copied version affected the English version as well, or vice versa

at some points, post formatting broke for both languages

I had to manually restore several pages/templates in tagDiv Composer

some templates disappeared or behaved inconsistently in the backend, even though the frontend still partially worked

Another related symptom:
In English posts, I can select the template “Single Template – Today News PRO”.
In German posts, I only see “Default”, not the same Single Template option.
This makes me think WPML may not be recognizing or linking the tagDiv Cloud Templates correctly for the secondary language.

At one point, setting Cloud Templates to a stricter translation mode caused header/footer/template behavior to break more severely, so I reverted to the fallback setting above.

At the moment, the frontend is mostly restored, but one core problem remains:
the German version — all posts — of the site still displays the English footer text, and I have no reliable WPML-based way to translate the footer Cloud Template.

From my perspective, the main issue is:
WPML seems not to expose the translation UI for tagDiv Cloud Templates in this setup, and the footer content is also not available through String Translation.

Could you please help me with the following:

Is this a known compatibility issue with Newspaper/tagDiv Cloud Templates?

Should WPML show translation icons / language columns for these Cloud Templates in the backend?

Is there a recommended WPML workflow for translating tagDiv footer templates created with tagDiv Composer?

Why would the English Single Template be selectable in English posts, but only “Default” appear in German posts?

Is there any additional configuration, compatibility plugin, or troubleshooting step required so WPML recognizes these Cloud Templates properly?

I can provide screenshots of:

WPML Post Type Translation settings, the Cloud Templates backend screen where no translation icons appear and
the footer output on the German frontend

See here:

https://ibb.co/M5p25kGH
https://ibb.co/s9MCdJFY
https://ibb.co/tTF1dXHN
https://ibb.co/dJsgKd69
https://ibb.co/hxGqZZk0

Thank you in advance for your help.

Best regards,
Marcus

PS here’s the response by WPML support:

Hello there,

Thanks

Hello tagDiv Support,

I need help with a serious issue that started after updating Newspaper. I have spent hours troubleshooting this and I want to give you a clear, detailed summary so you can understand exactly what is happening.

My site:
MarryCaribbean.com

Theme:
Newspaper

Problem summary:
After the update, my single post pages began crashing and showing the WordPress critical error message. At the same time, several layout behaviors changed unexpectedly, including my post hero styling and category/archive display.

Here is what I observed and tested.

1. Single posts started failing after the Newspaper update

Before the update, my single posts were working normally.

After the update:

* Single post pages began showing “There has been a critical error on this website.”
* This was happening under Newspaper, while the site worked under a default WordPress theme.
* Category pages and other parts of the site were not failing in the same way at first, which made this look specific to the Newspaper single post rendering path.

2. Debugging pointed to td-composer

I enabled WordPress debug logging and found fatal errors pointing to td-composer, specifically memory exhaustion in this path:

/wp-content/plugins/td-composer/legacy/common/wp_booster/td_util.php

I also saw repeated notices for translation loading from other plugins, but those did not appear to be the main cause of the front-end post failure.

The key fatal I saw was memory exhaustion inside td-composer.

3. Default WordPress theme worked

To isolate the issue, I temporarily switched to a default WordPress theme.

Result:

* The single posts loaded
* The content itself was fine
* This suggested the problem was not with WordPress core or the post content itself, but with Newspaper/tagDiv rendering

4. Backup restore did not solve the issue

I restored a backup using UpdraftPlus, including:

Database
Plugins
Themes

However, this did not restore the previous Newspaper behavior on its own. The single post issue remained. What actually made individual posts load again was manually opening them and explicitly selecting a post template such as FROM PANEL or DEFAULT and then updating the post.

5. tagDiv Composer / Cloud Library behavior was inconsistent

After the restore:

* tagDiv Composer and tagDiv Cloud Library had to be reactivated
* Header/footer/custom appearance behavior changed depending on whether these plugins were active
* At one stage, single posts worked with Composer off, but the custom header/footer/design was degraded
* With Composer on, other design pieces came back, but single post behavior was still unstable or altered

6. The biggest discovery: post template behavior changed

This appears to be the most important clue.

I found that many posts would work again only after I manually opened the post and explicitly selected a post template, for example:

* FROM PANEL
or
* DEFAULT

If I manually selected one of those and updated the post, the post would usually load again.

This strongly suggests the update changed or broke how post template settings were being inherited or interpreted.

What is especially concerning is that this appears to affect many posts, not just one or two.

7. “From Panel” is not consistently broken, but behavior changed

I originally thought FROM PANEL itself was broken, but after more testing I found:

* Some posts work on FROM PANEL
* Some posts work on DEFAULT
* Some posts needed to be manually touched and saved before they would work at all

So the issue does not seem to be as simple as “FROM PANEL is broken.”
It feels more like the update disrupted how template/layout assignments are being inherited or loaded on a per-post basis.

8. My hero/header layout on single posts changed

Even after I got the posts loading again, the visual layout is not what it was before.

Before:

* My post hero had a stronger designed look
* The title, author, tags, and hero image styling appeared more integrated/overlaid
* There was more of a styled hero presentation

Now:

* The posts may load, but the hero/header presentation is simplified or degraded
* The featured image sits more plainly
* The old styled hero treatment appears to be missing

So even when the post works, the layout is not the same as before the update.

9. Article Display View options appear to be missing

In the Theme Panel, under areas where I remember having many layout/style choices, the “Article Display View” area appears blank or missing its usual options.

I specifically remember having many appearance/layout choices there before. Now those options do not appear to load properly.

This makes me think some template/module UI in Newspaper is no longer loading correctly after the update.

10. Category/archive behavior also changed

After the update:

* My category/archive sections changed layout
* I had 3 items per row before, but now it is showing 2
* I also started seeing little comment count boxes with “0”, which I never wanted and did not have before

I checked Block Settings and global module meta settings. Show Comment Count appears to be off globally, but the archive/category output is still not matching what I had before.

This makes it seem like the archive/module style or template behavior changed during the update as well.

11. Cloud Templates screen appears empty

In Cloud Templates, I currently do not see cloud templates assigned in the way I expected. For example, the Single Templates area appears empty.

That is confusing because I know my site had a more customized appearance before, and the current theme behavior no longer matches it.

12. Main concern

My biggest concern is that this update appears to have:

* broken or altered post template inheritance
* changed single post rendering behavior
* removed or failed to load layout options I previously had
* changed archive/category display unexpectedly

On a larger site, this kind of behavior is extremely disruptive because it can force manual repair of many posts.

What I need from you:

1. Help identifying exactly what changed in Newspaper that caused single post template behavior to break or stop inheriting correctly
2. Help restoring the original post hero/layout behavior I had before the update
3. Help restoring the archive/category display so it matches the previous layout
4. Help understanding why the Article Display View choices appear missing/blank
5. Guidance on whether this is a known issue in the current version and whether there is a patch or recommended fix

I would appreciate a serious look at this, because this has taken a lot of time to troubleshoot and it clearly appears connected to the Newspaper/tagDiv update path rather than WordPress itself.

Thank you,
MarryCaribbean.com

Hello tagDiv Support Team,

I hope you are doing well.

I am using the **Newspaper theme** with the **latest versions** of WordPress, the theme, and the **tagDiv Cloud Library** plugin. However, my WordPress dashboard is still showing a **security/vulnerability warning** for the tagDiv Cloud Library.

In my case, the plugin is required because my **mobile header and footer are created using Cloud Library templates**, so I cannot deactivate it.

Could you please confirm:

1. Whether this vulnerability warning is a **false positive or low-risk issue**
2. If a fix or update is planned to address this warning
3. If there are any **recommended security precautions** we should take in the meantime

For reference, I am also using **Wordfence Security with Firewall and 2FA enabled**.

Thank you for your support. I look forward to your guidance.

Best regards,
Janan