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).
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.