JB Christy

I manually applied the pull request you referenced above, and that seems to make the plugin honor the custom output directory setting. So thanks for that.

I temporarily made my local dev site serve over http (not https with a self-signed cert), and things appeared to work with the twentyseventeen theme. So the spectacular part of the failure is now resolved.

However:

I switched back to my custom theme, which is a child theme of another custom theme I developed. The plugin generates and populates a tree structure for the parent theme, but it does not seem to take any note of the theme that’s actually activated, i.e. the child theme. No directory structures for the child theme is even created, let alone populated. Is this a known limitation of the plugin?

I can probably work around the child theme issue. At this point we rarely make changes to the child theme’s assets, so I can probably just manually populate the necessary theme files in S3 and things will work ok. But of course it would be nice if the plugin handled child themes automagically.

Hi Leon,

I updated to the latest version of twentyseventeen, switched my site to run that, and I see the same behavior – this is all that’s created:


2018
└── 01
└── wp-static-html-output-1-1516913949-jbchrsty
└── wp-content
└── themes
└── twentyseventeen
└── assets
├── css
├── images
└── js

9 directories, 0 files


I’m testing this plugin out on my local dev environment:

Mac OS Sierra 10.12.6
MAMP Pro 4.2.1
Apache
MySQL 5.6.35
PHP 7.1.8 (I also tried with PHP 5.6.31 and got the same results)
Browser: Chrome 63.0.3239.132

One peculiarity about my local dev environment is that it’s served over HTTPS with a MAMP self-signed cert. This is because the production site I’m mirroring is forced to HTTPS, and I don’t want to fiddle with local changes to the config files stored in git. I might be able to temporarily serve my local site over http just to see if that’s the issue. But this will need to work on a site that’s served over https with a (very slightly wonky) SSL cert.

@sirulli,

It turns out the original image may have been slightly corrupted. I had difficulty opening it in a couple of image editors. I was able to open it PhotoShop and saved a compressed version of it. Once I uploaded the compressed version PhotoShop created, all worked as expected.

Thanks again for your swift reply. Thanks also for a fantastic plugin! This is so helpful!

-JB

Hi @sirulli,

Thanks for your swift reply. However, image size is not the issue. The original image I uploaded is 4288×2848. None of the manual crops create retina images, including one that’s only 575×360. A @2x version of that crop would be 1150×720. There are more than enough pixels in the original to create a @2x version of a 575×360 crop.

Any other thoughts?

For the record, I’m using Version 0.1.5 of YoImages, and Version 4.8.0 of WP Retina 2x.

Thanks in advance for your help.

-JB

Oh, nevermind. I now realize that “crops” that don’t force an aspect ratio aren’t actually cropped at all – they’re just resized. So I guess it really doesn’t make sense to edit those “crops”.

Nikola, you’re AWESOME! I was able to schedule a time slot without touching my mouse. Phew! I think this means I’ll be able to use this plugin.

I recommend adding some screen-reader text here and there to ensure screen-reader users know what to expect when they click on various links. That’s quite important, but I don’t think it’s an actual show-stopper, in the way that not being able to use the scheduling tool at all stopped the show.

Thanks so much for addressing my issue, and so quickly!

Best,
-JB

Hi @loncar,

Thanks for the swift reply! I haven’t done thorough testing of all cases, but yes, the time value is the only issue I’ve found so far, and it’s a show-stopper for me.

I fiddled around myself and found that if I changed

next_element.append('<div class="time-value' + classAMPM +'" data-val="' + element.value +'">' + element.show + '</div>');

to

next_element.append('<a tabindex="0" class="time-value' + classAMPM +'" data-val="' + element.value +'">' + element.show + '</a>');

tabbing became possible. Unfortunately, after inserting next_element into the DOM, tabbing reverts to the first day in the calendar with available time slots, rather than proceeding to the newly added time slots. I was just fiddling with where to place .focus() when my boss told me to stop working on it. ??

Note that I had to explicitly add tabindex="0" in order for the browser to pick up the newly added element.

Anyway, if you could fix this in the next release of the plugin, that would be stellar. Thanks, Nikola!

• This reply was modified 7 years, 10 months ago by JB Christy.

Awesome! Thanks so much, Justin! I really appreciate your swift and helpful responses.

Wow, that’s pretty good service! Thanks!

2 questions:

1. Just ballpark, approx when might these changes be officially released – days, weeks, months or years? If I go with CMB2, I would be deploying it to a production site (news.stanford.edu), so I don’t want to get too far afield from an official release.

2. I see cmb.trigger( 'cmb_media_modal_select', selection, media );, and cmb.trigger() does $document.trigger( evtName, args ); . So I’m thinking my code should be $(document).on('cmb_media_modal_select', function( selection, media ) { ... }); . Is that right? The event will ultimately be triggered on $(document)?

Thanks again for the quick reply and fresh code!

Yes, we’re using the Flexible Posts Widget too. Support for custom taxonomies was mandatory.

The code in the function that adds all the sections and controls was not wrapped in is_admin(), but attaching the function to the customize_register action was, i.e.

if ( is_admin() ) {
add_action('customize_register', array($this, 'admin_theme_options'));
}


When I moved that add_action() call outside the if everything works again.

THANK YOU!!! I would’ve never thought of that.

Actually, that didn’t do it. Still trying.

Upon further investigation, it appears hiding all my stuff by default was “an improvement in 4.0”. See the Contextual Controls section of the Customizer Improvements in 4.0 article. Apparently now, for every control I add, I need to pass an active_callback function that returns true when the user is previewing a “context” in which I want my control to be active. For some unfathomable reason, if I fail to provide that callback, say, because it never existed before, the default return value for active() is false. Meaning all my custom stuff disappears by default. Not exactly backwards compatible there. ??

Yes, I’m running on a development site and all plugins are deactivated. Somehow every section and every control I manually created is being perceived as not “active”.

When the page loads, my sections initially display, but then the ‘ready’ event is triggered on the api.PreviewFrame, and its passed some ‘data’ that has elements activePanels, activeSections and activeControls. All of WordPress’s native panels, sections and controls are in that data structure and none of mine are. That data structure seems to be emitted by WP_Customize_Manager::customize_preview_settings(), but when I view source on the page the data structure doesn’t look at all like I think it should look based on that PHP code. And yet when I step into the Javascript code data has the expected structure.

It looks like in 4.1 a new method was added to WP_Customize_Section, active(). Looking at the PHP code I’m guessing that I have to add a filter for customize_section_active to say the my sections are active. Maybe I have to do the same for all my controls as well. If that’s true, what a royal PITA it is.

After further testing, I’ve learned that Appearance > Customize worked in 4.0.2 and failed in 4.1.2. I see that admin/js/customize-controls.js changed in 4.1.1, so I presume that’s where the bug was introduced.