Slider demo height about customizr HOT 6 CLOSED

Somewhat tied to this (tc_get_default_options to be more precise):
https://wordpress.org/support/topic/featured-pages-and-qtranslate?replies=3

What happens:
qtranslateX filters ALL the db options when in front-end (file qtranslate_frontend.php), not sure if this is a good thing but still..
And we have this:
https://github.com/Nikeo/customizr/blob/master/inc/class-fire-utils.php#L208
(Not sure why we save the option when user is_logged_in)
So, when we get the default options (fron-tend and user is logged in) qtranslate filters the theme options, and it translates (for example) featured pages texts with qtranslate tags in the customize (our option), so say
featured_text_one = '[:de]de[:zh]zh'
becomes
featured_text_one = 'de'
(if you're showing the website in german)
then we update the options and the original option gets replaced.

In this case the "issue" could be solved making that update just when:
if ( is_admin() && current_user_can('edit_theme_options') )

which makes sense to me.

Also there should be something wrong anyways, shouldn't we update the def options once?

from customizr.

About updating the options. It's been coded like that to avoid any inconsistencies when the theme is updated.
A possible solution would be to update the defaults only on 'after_switch_theme'

from customizr.

Ok, but anyways don't you think we should update them just when current_user_can edit themes options and when is_admin()?

from customizr.

yep

from customizr.

I think the issue is here:
https://github.com/presscustomizr/customizr/blob/master/inc/class-fire-utils.php#L358
which is called, mainly when displaying notices here -> https://github.com/presscustomizr/customizr/blob/master/inc/admin/class-fire-admin_init.php#L290

The thing is that when we retrieve the options, before setting a single option value, we merge the "user options" with the defaults.
So we'll have a theme option looking like:
array( user_options_merged_with_defaults, (array)defaults ) (1)
(defaults array cached in the db when retrieving the default options)
while we should have:
array( user_options, (array) defaults ) (2)
right?
The solution in the upcoming PR will keep the default options in the db (as you love them :P).
About the update of the default options.. I still think we should limit it when is_admin
but, I think is something you should decide, 'cause I have not clear why we don't already do it, there might be something I'm missing ( https://github.com/presscustomizr/customizr/blob/master/inc/class-fire-utils.php#L216 )
Not a big deal anyway.

If you then decide to not store the def options anymore let me know and I will do another PR.

From my tests, this works, though I wonder if it's enough. I mean, I made my tests on my tc_theme_options value (which I reset many times in the past), so I'm not sure it has exactly this (1) form, it might contain some other malformed option which this PR will not correct.

I think ( let me know what you think ) we might add the "tc_theme_options" ( and maybe also the theme_mods for other purposes ) to the "System Info" (maybe not always visibile, with a button to "generate" this kind of report ).

from customizr.

Mmm, ok but the PR which should fix this isn't merged, remember it ;)

from customizr.