get_theme_mod not pulling updated value within Customizer without Publishing

Until you publish, nothing is saved, so getting a theme mod only gets you the old saved value. One solution would be to immediately save any change via Ajax, but such unexpected behavior could confuse users. The other is anytime a field is changed, JavaScript immediately updates all other corresponding fields accordingly.

This is why having the same setting in multiple places isn’t a good idea. Are you sure this is really necessary?

As I said, this isn’t the same value in multiple places, the first option enables other settings to be configured. I’ve also just done a test to echo back the get_theme_mod value for the field being changed in the Customizer, and when a change is made, that field isn’t refreshing on the same panel. I actually didn’t think it would work on the same page, but tried it anyway.

To add more context on what I’m doing, this is for font customization. In one area I’m having the user select a choice from Google Fonts. Then the user can select from the provided font weights for that font. Not every font has the same weights available, and so I’m doing a query to only pull the valid selections.

But for purposes of example, say this is a color selection, user selects RED or BLUE, and is consequently given choices in another setting for Dark_Red, Cherry_Red, Royal_Blue, or Sky_Blue. Selecting Red only shows the red options, selecting Blue would only show the blue options. I need to be able to see what the current Customizer choice is to set the right options.

Thanks for clarifying, that makes a lot more sense than what I thought your were doing ?? You are describing a classic cascading dropdown (or similar selection input) situation. The example has hardcoded the selection possibilities within a JS object. A common variation is to make an Ajax or API request to get relevant data based on the previous field’s selected value. You’ll need to adapt things to work in a customizer context, but the concept remains the same. On change of the previous field, the next field is populated accordingly.

Your suggestion makes the most sense, I tend to avoid adding such code though whenever possible, I was trying to stick with straight PHP and WordPress code as much as possible.

I’ve gone through several iterations of things to try to work around this, but once the initial PHP has run it seems that the Customizer view is basically static and doesn’t get refreshed, so any variable changes and such aren’t picked up until the next time Customizer loads up and the PHP code refreshed.

If you wanted to do everything with PHP, you need to save the current state or somehow pass it back to the server so on reload the fields still reflect the proper state. The customizer isn’t intended to work that way. It’s intended to be more interactive, which means some sort of client side scripting: JS, jQuery, REACT, etc.

WP is leaning more and more on client side scripting. A fact I’m personally not entirely excited about, but it is what it is. It’s best if we start embracing it. Resistance is futile ??

Resistance is never futile, but is sometimes pointless. LOL

I’ll bang on this a bit more just to see if I can find a clever way to do what I’m wanting, but you’ve given me the info I needed.