Restore setting from Database

Hi guys, is there a way to restore the theme settings from database?

I just have a database backup. All my settings are blank now. Theme activation prompts again.

Hope can you help me.

Regards,

Mauricio.

I’ve tried to overwrite the values for “td_011” and “td_011 settings” option names in “wp option” table, but this get overriden again when WordPress runs.

Theme panel Import/Export for backup not working.

This is seriously disappointing. Why on earth can it not be restored on the database side?

Why MUST it use the backend form? An exact copy of the options tables for your theme, doesn’t work, it’s madness. All the form seems to do is decompile a base64 string of the settings that are in the database.

I’ve been trying to inject the settings from a staging system into the database ready for a live website upgrade. Same data, version etc…

Why can this not be done like this?

I’ve wasted more than a week on this exact problem as I need to import the settings into a multipress setup with a dozen subsites and this was a critical part of my bespoke automated upgrade script.

Copying widgets works, just not the settings. SMH

• This reply was modified 5 years by PFC.

Hello Calin, sorry you can address me as Richard, PFC is simply the acronym for the charity that owns the license.

Environment: Multipress WordPress with 12 sites, each site is a separate language version of the main site.

Here’s the issue explained in much greater detail:

I’ve manually injected pages and even manually translated block names ect… No issues, all restore as I want.

Same with widgets, including translations for them. No issues. All restore as I want.

It is ONLY the main theme settings that have an issue!

Injecting td_011 and/or td_011_settings does NOTHING! Like the OP found and first reported. Even injecting every newspaper-related field from wp_options back into the database does nothing for the colours, logo’s etc… It’s as if I never set these options. (except it’s clearly in the database, and snapshot dates show in theme panel, but not useable/clickable) the front page is just black and white.

SQL query “WHERE option_name LIKE ‘%td_%'” will give you all the table entries. See Appendix.

I am doing them all, including transients, caches, you name it ANYTHING tagdev related is recovered back into the database on the same domain, same version. I did them all as I wasn’t getting anywhere with just td_011 and td_011_settings. Recovering an exact 1:1 of all your database stored data should work.

So I make all the changes in my little dev-clone and I manually export all the table options I need (see appendix), re-importing these back into a new clone does nothing (see method), only when I use the theme panel importer tool does it work and logo’s colours ect… all show properly? (I had an older copy of the export hash)

It seems you know why, as you’ve stated it MUST be done through the exporter/importer when the OP said he couldn’t recover td_011_settings.

A 1:1 copy of all the database data related to Newspaper should theoretically just work, mitigating the need to use the importer tool.

Here are some questions:

1) what’s the difference between td_011 and td_011_settings, I think td_011 is a store of what’s active or not active in the themes state, plugins, demo’s et al. There seems to be some duplication of data within both fields.

2) Why will recovered td_011 and td_011_settings exactly as is via the database directly not work unless base64 encoded and put through your importer?

3) Since Tagdev is actively supporting further third-party development via an API, could an import/export endpoint please, be made in the future? We need a programmatical method.

4) I wanted to streamline the development and efficiency of not storing multiple copies of the same logos/assets in each subsite independently. So I made an images folder in the child theme and put the exact url to get this media in the theme settings. WARNING: It doesn’t work, clearly you must be using wp_posts ID somewhere. This needs to be made known as its more common practice to do as I was attempting.

5) td_011_settings is an autoload field, yet has all copies of the settings (backups/snaphosts), within this same field as just another index of an array in the serial blob. This is horribly inefficient for a user’s system. Why not just create a backups field like td_011_snapshots and pop an array in there without autoload set. (this has been mentioned before)

To others reading this: Autoload means it will load on every page load each time a database call is made to construct any page. If you have 10 backups, it’s now loading 10x the amount of data on every page load with 90% being completely unnecessary and redundant. It doesn’t matter if it’s 30KB, 300KB, or 1.3MB. This really should be addressed in my opinion.

I love your theme, it’s the best-selling theme of its kind for a reason. What am I possibly missing that stops a recovery of theme settings via the database directly actually working without the importer tool? I am I possibly missing a fieldname from the appendix?

Thank you for your time and response. It will be appreciated by more than just me that I am sure of.

Method:
1) Creating a local clone of live site, sed replacing old_domain with new_domain on sql dump prior to import. (new working clone)
2) Manually copying over theme files and child theme files, plugin files.
3) Activate and enable network-wide the theme plugins using wp-cli
4) Activate and enable network-wide the child theme using wp-cli
5) Ensure that needed media is imported into the system via wp-cli and that media names and uri’s match within database table entries (see appendix)
6) Inject all database table entries for tagdev stuff from the prior development cycle.
7) use wp-cli to restore widgets information

Pages on all subsites work beautifully, Widgets show correctly, just the colours, logo’s are missing! If I manually reimport using your importer on every subsite everything works like magic. It’s not missing media as they’re already imported and waiting.

Appendix:
_transient_td_update_theme_Newspaper
_transient_timeout_td_update_theme_Newspaper
td_011
td_011_remote_cache
td_011_settings
td_covid19_data
td_playlist_video_channel_id
td_playlist_video_video_ids
td_playlist_video_video_ids
td_playlist_videos_pool
widget_td_block_1_widget
.
.
.
widget_td_block_25_widget
widget_td_block_ad_box_widget
widget_td_block_author_widget
widget_td_block_authors_widget
widget_td_block_exchange_widget
widget_td_block_image_box_widget
widget_td_block_instagram_widget
widget_td_block_pinterest_widget

• This reply was modified 5 years by PFC.
• This reply was modified 5 years by PFC.

I apologize, I’ve been dealing with a monster of a website that’s over 25GB in size and it’s taken its toll. I’ve gone through, more than 50 iterations of complex development already and manually doing the theme settings is tedious at best on a site this size so many times.

I let my frustrations out and that’s unprofessional.

It’s not my place to ask anything of tagdiv, you’ve provided a working export/import tool that works for 99% of your customers. Doing something so bespoke is outside of acceptable support. There are numerous reasons why a database import/export may not work as could generally be expected.

My reason for initially adding to this thread is to add a warning, that a simple database import/export won’t work for the actual settings. As the OP found out, but likely under different circumstances. Saving other developers in the future some lost time, thinking they can.

If a feature request can be offered, please can an export/import endpoint be considered for your API. This would save that 1% a tremendous amount of work and their sanity.

Thank you for producing an awesome theme, it’s truly exceptional!