5

I have what seems to be a rather troubling issue with the get_theme_mod function in the latest version of Wordpress. Only on particular servers (of which meet all Wordpress requirements) the function won't return the saved value that I can see stored in the database. However if I specify a default value for the function, it will always return the default value from the second argument.

I am really at a loss here because the servers are all running PHP 5.3 and more than required MySQL versions. All environments are PHP and Apache with nothing in-front or in-between. This doesn't seem to be a consistent error, it's only on particular servers this seems to be happening.

I am utilising the Wordpress Theme Customization API in my project and on the offending servers have noticed the following things:

  • When making changes in the Theme Customization API preview pane, they are reflected. However, navigating to a different part of the site in the preview pane (clicking a link or whatnot) and it'll revert back to its default value. Hitting refresh also sets everything back to its default values.
  • Inspection of the AJAX request via Chrome Developer Tools "Network" tab shows the data is correctly being sent and the server is sending back a response code of 200 insinuating everything is fine.
  • Inspecting the appropriate database table row that stores the serialized data that has been saved shows that it is in-fact being saved correctly, but when using the get_theme_mod() function it is not returned.
  • I tried dumping the contents out from the function "Get_theme_mods()" to see what it would return and I get nothing (absolutely nothing is returned). Doing this on a working server however returns the appropriate contents.
  • All Theme Customization API values are defined as per the documentation suggests and I have even tried setting the setting type to, "theme_mod" to no avail (even though theme_mod is the default anyway).
  • When trying to call the get_theme_mod() if I add a set_theme_mod before the function call and set a value manually myself, it saves and the get_theme_mod function gets the value saved just before it. This means that changes appear to be acting like they're only temporarily being saved (even though the DB says otherwise).

I also have no plugins installed or activated that could be overwriting any of the theme options or preventing them from being returned. My only conclusion is that it relates to some kind of web host level caching (APC perhaps) or perhaps Wordpress itself caching the options (I presume get_theme_mod) is cached much like the get_option function is elsewhere.

If you require any code, just let me know what you require (as I am not sure).

Edit **

I did a var_dump on the contents of the get_theme_mod functions being called and got the following (did it for quite a few, not all of them). The labels in front with the colon are for showing what value is what.

Texture: string(4) "none" 
Background Color: string(0) "" 
Theme Color: string(7) "#FF0000" 
Body Font: string(0) "" 
Heading Font: string(0) "" 

Out of frustration I tried the following code as well and nothing is returned:

$options = get_option("theme_mods_aphrodite");

var_dump($options);

The result I get from this is bool(false).

Another thing I tried was using the default Twenty Twelve theme customizer and it worked, so something somewhere in my theme is destroying the options row and preventing it from working. But what makes that strange is that the theme I am having issues with works mostly fine on other servers I try, it's only particular isolated incidents and the database table is in-tact.

Edit #2 **

As suggested below I pasted in my theme customisation code into another theme (I picked Twenty Twelve because it works out of the box) and it appears my register code breaks the customiser and I can't work out why.

6
  • Please go into core, do a var_dump() in the (core-)file, upload it and see what happens inside. At least this is what I'd do to get some quick debug info.
    – kaiser
    Mar 15, 2013 at 1:13
  • Thanks for the response Kaiser. Which "core-" file do you speak of sorry? I'm not aware of such a file. Mar 15, 2013 at 1:24
  • The one where get_theme_mod() is defined. Dump the hell out of the get_/set_theme_mod() functions. Then upload those files and see what happens. It's like xray-ing your core.
    – kaiser
    Mar 15, 2013 at 1:30
  • No worries mate. I've edited my question with the results of var_dumping and other things I tried as well. Mar 15, 2013 at 1:38
  • After reading your edit: Can you plug out the part that wraps around the customizer and add it to a new theme? Just to get an isolated test case. Btw: I assume you got WP_DEBUG to true, etc. etc.?
    – kaiser
    Mar 15, 2013 at 1:44

3 Answers 3

3

I had the same issue.. using type=option and then get_option din't work either.

Testing with another option item and works.. and testing with MYTHEMENAME_THEME_OPTION without the bracket for item and got an Array so I guess is the right way.

So just a tip for those who found this post but still got blank value.. when you use this code:

$wp_customize->add_setting('mytheme[mytext]', array(
    'default'        => 'some value you want default',
    'capability'     => 'edit_theme_options',
    'type'           => 'option',
));

$wp_customize->add_control('textControl', array(
    'label'      => __('LabelText', 'mytheme'),
    'section'    => 'parameters_thrive',
    'settings'   => 'mytheme[mytext]',  ));

then to get work you need to use each setting as a individual value,

$wp_customize->add_setting('mytext', array(
    'default'        => 'some value you want default',
    'capability'     => 'edit_theme_options',
    'type'           => 'option',
));

$wp_customize->add_control('textControl', array(
    'label'      => __('LabelText', 'mytheme'),
    'section'    => 'parameters_thrive',
    'settings'   => 'mytext',   ));

Where setting = myText, then is not more an array (before wasmytheme[mytext]) now is like a single item/value, a string. The go ahead and use the get_option() function to use the value whatever you want.

1
  • Welcome to the site and thanks for answering. Your solution is pretty nice actually, it's a nice compromise. I never did work out what was causing it, but this answer helps, so I've marked it as accepted. Oct 8, 2013 at 4:20
2

I never worked out why get_theme_mod did not work, I however did find a nifty little fix to resolve this annoying bug in-case someone else finds themselves in a similar situation.

You have to change all of your settings to type => 'option' and then you can no longer use get_theme_mod any more and instead have to use get_option (as far as I know). A find and replace on get_theme_mod to get_option shouldn't hurt. It worked for me.

I will update this if I find a better way.

1
  • Thanks for this! I have spent hours trying to work out a way around this problem!
    – Kaspar Lee
    Feb 14, 2017 at 21:00
1

If you use this code:

$wp_customize->add_setting('mytheme[mytext]', array(
    'default'        => 'some value you want default',
    'capability'     => 'edit_theme_options',
    'type'           => 'option',
));

$wp_customize->add_control('textControl', array(
    'label'      => __('LabelText', 'mytheme'),
    'section'    => 'parameters_thrive',
    'settings'   => 'mytheme[mytext]',  ));

You can retrieve the value by just executing get_option('mytheme')['mytext']

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.