jimwright2

Appreciate the tip, I’ll test this out next chance I get. It should definitely clean things up and make updating easier.

Figured out that this is a Javascript scoping issue, and that calling bob() from outside of that function is an issue because the function is local in scope. Now I just have to put code in the right places and I think I should be good.

I think the big part of what I was having to overcome was in the way that WordPress builds the HTML page that gets presented, there is a lot of Javascript going on that runs after the initial page source loads. What would otherwise work with some simple Javascript fails to execute because of this. So I had to dig deeper into how WordPress presented and managed everything involved, which for the most part involved JQuery.

The core of what I needed to do is watch for one Customizer control to change, then update another Customizer control’s choices (Select list) with updated values. This second field would use an array built by PHP to populate these values. To get this set up, my functions.php uses this function:

function throwback_enqueue() {
   global $theFontsList;
// Other enqueue setup
   wp_enqueue_script ( 'throwback_font_js', get_template_directory_uri().'/inc/font.js?123', array('customize-controls'), false, true);

   wp_add_inline_script( 'throwback_font_js', 'const theFont = ' . json_encode( $theFontsList ), 'before' );

}
add_action( 'wp_enqueue_scripts', 'throwback_enqueue' );

My functions.php has already built $theFontsList array, so it’s declared as a global so that the wp_add_inline_script can pass this over to the Javascript side as ‘theFont’. The wp_engueue_script loads my font.js script, and has it load after the ‘customize_controls’ have been loaded. The font.js script is as follows:

( function( wp, $ ) {
    wp.customize.control( 'font-body', function( control ) {
        control.setting.bind( function( to ) {
            var selectElem = wp.customize.control( 'font-body-weight' ).container.find( 'select' );
            var fontsList = theFont[0];
            selectElem.empty();
            var option = '<option value="100">100</option>';
            option += '<option value="200">200</option>';
            option += '<option value=' + fontsList + '>Result</option>';
            selectElem.append( option );
 //           $('#select1').append('<option value="${optionValue}">${optionText}</option>');

        } );
    } );
} )( wp, jQuery );

The above is some working test code to verify the basic functionality. I use wp.customize.control to modify the font-body control, and then bind that to the font-body-weight control, so that the weight’s options are dependent on the body-font selection.

My full code will use the passed array (theFont) to populate the <option> choices, but for the test code I’m manually deleting the original choices via selectElem.empty(), setting static values of 100 and 200 for the first two options, and then setting a third option pulling a field from the theFont array (element zero) and showing that as the third option.

For anyone else looking for a starting point, the above should help out.

Just updating this to keep anyone from spending time on it, I’m making progress on this finally, I’m now able to check when a control is updated and then update another control’s options as a result. (Yay!) I can upload some sample code here when I have this completed in a day or so.

I’ve played with this some more and I’ve been able to get my code where it looks like it should be, but I still can’t get the onchange to fire within the customizer.

I’m trying a different tactic on this, new thread started to see if that avenue may work better.

Yes indeed, that was definitely an error, but not my main issue. I found that when I viewed the page source from the Customizer screen that my javascript was at the very top of the page, and it actually needs to be much lower, the very end of the html if at all possible after my controls are defined, which looking at the HTML is part of _wpCustomizeSettings.controls.

I’m getting this error now:

Uncaught TypeError: document.getElementById(...) is null

I’m using this line to enqueue the script, but it’s still coming in far too early in the HTML:

wp_enqueue_script ( 'throwback_font_js', get_template_directory_uri().'/inc/font.js', array('wp-tinymce'), false, true);

Is there some way to enqueue to be at the very end of the HTML? If not then my only other workaround would be to insert this manually after I’ve defined my controls.

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.

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.

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.

Well, didn’t take long for me to break the above code. LOL I was finally getting back to the issue of permlinks not working when I changed the format, traced that back to the apache AllowOverride directive not being set exactly right, fixed that, then suddenly the above check for $_SERVER[‘PATH_INFO’] was returning a null.

My original check there was going to be using the $wp global variable but using that within the add_filter resulted in an error when the page loaded (Undefined variable: wp), and again that check was failing. But some more testing found that $wp was usable in the PHP just before the add_filter section, which seemed very odd, but it gave me a workaround without resorting to testing $_SERVER parameters. Revised code is now as follows:

<?php
if (($wp->request) == 'category') {
   add_filter( 'document_title_parts', function( $title_parts_array ) {
   $title_parts_array['title'] = 'Custom Page Title';
   return $title_parts_array;
   } );
}
get_header();
?>

Thanks, this got me going in the right direction, but I changed it up a bit. Looking at Option A, this code basically would be executing for every page, which I was wanting to avoid. I’m kinda old school, and so any unnecessary checks should be avoided, and came up with Option A-2.

In my 404.php, index.php, and other pages, the first line is:

<?php get_header(); ?>

So, the original option would have fired every time. Instead, I put a version of the above in my 404.php page only, limiting execution only to that page.

As part of my 404, I was checking the URL to see if it was the page I was looking for using this code:

$shortURL = add_query_arg(array($_GET), $wp->request);

I tried to do this check before get_header() was called, but found it wasn’t working. As near as I can tell WP hadn’t yet created the $wp or $_GET arrays so there was nothing to check against yet. So I changed this to checking the $_SERVER variable and this did the trick. My Option A-2 code to check if the ‘category’ page was requested is as follows:

<?php
   add_filter( 'document_title_parts', function( $title_parts_array ) {
   if ($_SERVER['PATH_INFO'] == '/category') {
      $title_parts_array['title'] = 'Custom Page Title';
   }
   return $title_parts_array;
   } );
   get_header();
?>

AFAIK, there shouldn’t be any problems with this code working for others, but feedback is welcome.

My biggest challenge with what I’d like to accomplish (see screenshot above for menu goal) is workout around what WordPress offers built in plus what I’d have to do to add revised functionality or creating new Menu Items (see above screenshot) with regards to keeping the list of categories and posts up to date to display these in the menus. For me, it would be far easier to do this within the theme itself, I had already sketched out something that would offer these choices.

The choices made here would be processed by PHP code in my header.php file to build the desired menu HTML, showing the desired static pages (About, etc), then the list of categories ( via get_categories() ) and then the list of posts ( via get_posts() ) up to the desired # of entries.

Maybe I had misread something along the way and I can’t find the text I saw on this, but it was something along the lines of ‘If your theme includes menus it must be through the WordPress Menus panel.’, the gist was that menus built outside of that should not be used. If that isn’t the case and I can build my desired menu completely within the theme, then I’m good to go.

Here is an example of the type of menu I’m wanting. Recent entries update automatically with new blog posts, count of entries shown would be set via the admin interface.

And here is where I would expect that this could be controlled from:

Answering my own question… I just had to lay the control out slightly differently to fix this.

$wp_customize->add_control(
    new MT_comment($wp_customize, 'font_comment2',
    array(
        'label'       => __( 'Popular Serif Fonts
', 'MT' ) . MT_showFonts($theFontsList['serif']),
        'section'     => 'font_family-settings',
        )
    )
);

• This reply was modified 1 year, 11 months ago by jimwright2.