Exoplanet loses personalization after importing the database.

[valmir]

This problem has already been a month. But how had it happened with my copy that I was installing on my localhost. I ignored the problem of after much searching and asking for help.

I would launch my platform based on the theme May 1st. Then I made the update from http to https. The problems that the exoplanet requests for the settings after you import the data have returned.

Let’s face the problems we need to solve.

1) In the optins table the exoplanet stores the configuration data with
Three content
A) field (option_name) = theme_mods_exoplanet-pro (No problem)
B) field (option_value) = a: 1: {s: 18: “custom_css_post_id”; i: -1;} (problem)
My content in this field is about three pages, mine to update in the database. All that I preach F5 it again puts this content (a: 1: {s: 18: “custom_css_post_id”; i: -1;})
C) field (autoload) = yes (no problem).

2) In the posts table the exoplanet continues to armzenar the configurations and has problems in this way of the query below
SELECT post_content, post_excerpt, post_password, post_name, to_ping, pinged, post_content_filtered, post_parent, guid, menu_order, post_mime_type, comment_count FROM soa_posts

[valmir]

My problem is everyone working with Exoplanet pro.

The theme is wonderful, but it’s no use if you need to do a database update it lose everything.

I have two solutions:
1) Leave everything behind and start with another theme, but it may be that up there I have another problem.
2) My idea and we try to work together to solve this problem that will be everyone’s sooner or later.

Everything is ready to launch our platform (www.soamigo.com.br) on May 1st. But now we ask for all our configuration.

So help you save me from this situation. I have plenty of time to research this problem, so please help with any questions.

[Yazmin]

a: 1: {s: 18: “custom_css_post_id”; i: -1;}

This is how WordPress core stores this value in the database for all themes, not just Exoplanet.

for example in the options table (usually ‘wp_options’ but I see yours is named ‘soa_options’ as you are using ‘soa’ as the prefix), if you look at the Twenty Seventeen or Twenty Sixteen theme mods you will see that they are the same:
SELECT * FROM soa_options WHERE option_name = 'theme_mods_twentyseventeen' OR option_name = 'theme_mods_twentysixteen'
run the above SQL query and you will see that these themes also contain a: 1: {s: 18: “custom_css_post_id”; i: -1;}

If you switch theme to Twenty Sixteen do you still see the same error?
Can you take a screenshot of your screen where you are seeing ‘exoplanet requests for the settings’ please?
You can upload images here in your posts.

[valmir]

The problem exists and we will not come up with anything new.

Performing a new database upgrade. The data is correct when I tell you to update the page it adds the data to.

[valmir]

You did not read my messages or did not understand my problem. I need to talk to someone who understands some program so that I can help myself and not put blame on others.

[Andy]

As this issue is not related to the theme, I am going to close this topic and contact you via email to try and help you resolve the issue with your WordPress setup or the database table structure.

[Author]

Posts