Thanks for passing along that idea. When I turned off minify, the font showed up correctly.

Like I said, in TagDiv Composer, the font is set to Oswald in all the locations. I specified that font via the editing panel on the left side of the screen.

For the two sentences, it is set at General > Post Content > Oswald.

For the main navigation, it is set at Style > Fonts > Element Text > Oswald.

For the Image Box (buttons), it is set at General > Style > Custom Titles Text > Oswald.

In the TagDiv editor, the font displays as Oswald. After saving and viewing the live page, the font shows up as Alegreya.

I do have some custom CSS, but none of it mentions Alegreya. Here’s what the custom CSS looks like.

.entry-crumbs {
display: none;
}

.woocommerce-ordering select {
display: none;
}

.woocommerce .td-container .page-title {
margin-top: 50px;
}

.woocommerce .product .images .flex-control-thumbs li img {
cursor: pointer;
opacity: .5;
margin: 10px;
padding-right: 10px;
padding-top: 10px;
}

.woocommerce .added_to_cart {
font-size: 12px;
color: #222;
padding-left: 10px;
}

.woocommerce div.product .woocommerce-tabs ul.tabs li {
display: none;
}

.woocommerce.widget {
margin-bottom: 38px;
background-color: lightgray;
padding: 5px;
}

.tdb_mobile_menu {
z-index: 10;
}

.tdb_mobile_search {
z-index: 10;
}

.td-search-wrap-mob .td-search-input span {
font-size: 20px;
font-family: ‘Oswald’;
}

.td-search-wrap-mob #td-header-search-mob {
font-family: ‘Oswald’;
}

.td-search-wrap-mob .result-msg {
margin: 0 5%;
font-size: 20px;
font-family: ‘Oswald’;
}

.tagdiv-type ul, .tagdiv-type ol {
margin-bottom: 6px;
}

• This reply was modified 3 years by ddj.

I just did a theme update to 11.2 and turned off the backups of settings. It made a huge difference immediately on both staging and production. On production, the size of td_011_settings was at 907862, and is now at 91015. On staging, where the content is slightly different and where I took additional steps, the size went from 907922 down to 1124. The additional steps were to turn off backups, export the theme settings, reset the theme settings, and import the theme settings, and run WP-Optimize on the tables between these steps.

In all, I’d say the ability to turn off the backups made a big difference.

• This reply was modified 4 years by ddj. Reason: added one more step in the staging workflow

Are there any updates from the developers on this? Any more information I can provide?

I’d like to update this thread …

After working with tagDiv support, I’ve tried numerous things to reduce the size of the table td_011_settings, and none are working.

Today I removed one Template from the site and edited three Categories to get its settings from the Global Template. Between each of the four changes, I ran WP-Optimize to clear unused data from tables.

As I understand it, each of these activities should have resulted in a smaller table of td_011_settings.

Instead, the size of the table increased with each change. The size started at 907862 and ended at 909599.

Any ideas on what I can do to reduce the size of that settings table?

The site is on version: 10.3.9.1

Can you better define what you mean by “cleared their database”?

In the database, I have removed entries leftover from previously used plugins and run WP Optimize on it.

This is still an issue for me and I’m really trying to find a way to fix it. My hosting provider points to this as the main reason for the site slowness. Do you have any thoughts on what they say?

++++++++++

What is indeed concerning at the point is the amount of autoload data the database runs. The recommended threshold to not cause slowness and performance issues on a site is 900KB, the site is currently running 1.23MB, most of that data being set by NewsPaper and the tagDiv suite of plugins, apart from a custom set of options that I see coming up:

| td_011_settings       | 907083 |
| _transient_dirsize_cache    | 276284 |
| td_011       |  90572 |

It’d be a good idea to check with a developer if it’s possible removing any of those options, or at least divide some of them into smaller options, to take off from autoload, thus helping the site’s overall functionality.

+++++++++++++++

• This reply was modified 5 years by ddj.

Thanks — that fixed it!

Just wanted to let you know that this likely had something to do with a cached item.

After moving from child theme to parent theme and back again, and then clearing cache, the page loaded normally.

This can be closed.

I am wondering if there is any other follow-up to this final question about autoloaded data because I’ve run into the same situation.

My total db is about 1.3GB and td_011_settings accounts for about 0.8 GB of that.

If I could safely turn off the autoloaded data, it seems like the database might run faster.

My site is using Cloud Library. In the wp_options I see some larger items such as widget_td_block_21_widget and widget_td_block_7_widget. Those blocks are no longer used on the site. Do you think I could safely remove these from the database?

I second this. I’m seeing this error all the time now.

I’ll send you an email.

I see I forgot to include the screenshot. Here it is: https://www.dropbox.com/s/ufjksct5qrm9bhh/duplicate-buttons.jpg?dl=0

I will email your support team the credentials to view the staging site. The subject of the email will have the title “Page template error?”

Thanks – that fixed it!

Actually, you can disregard this. I fixed it by removing/altering the way I was deferring javascript from loading.

Credentials sent.

I reinstalled the theme, and that seemed to fix the missing icons.

However, the navigation items no longer function in any way. This is on desktop and mobile.

Regarding the retina image, the Composer no longer allows me to add images. Clicking on “remove” works, but the upload button does nothing.

I resolved the logo issue on responsive. I needed to include a retina version of the logo.

Sorry, that’s not fixing the problem.

The console shows the fonts are being called from a staging site (stage.site), instead of the production site. Why would this be? I’ve re-edited the header template on the production site.

Regarding the tips crunchify.com, I did edit the .htaccess file on both sites. There is not a CDN to adjust.

Second, it does address the question of the logo.

• This reply was modified 5 years by ddj.

Thanks, I did start using that method and it works pretty good.

I was looking for the flexibility of adding something like a Flex Box to a widget and then controlling the visibility. It looks like that’s not available.

Thanks for your help on this. I tracked my issue down to a plugin causing this issue. Here’s the plugin that caused the problem: https://wordpress.org/plugins/wunderground/

I am seeing this problem today too. It did begin happening after a long day of development work, so it could be a result to additional plugins.

All the widgets kept moving to the Inactive area. This happened 3 times. On the 4th time, I don’t see any widgets in that area.

One additional detail … when I would add the widgets back to where they should be, I could not set the Visibility (Jetpack feature). However, the widgets did appear with the right visibility so it must have kept the details in the database.

I’m upping the memory allocations to see if that helps.

If you have any other thoughts, please pass them along.

The site is still in development: https://fishbaldwin.dream.press/

Nice work! This worked perfectly!