milesgilmour

I can confirm the problem only occurs with an Advanced Custom Fields WYSIWYG field – the button works fine in a default classic editor in a post or page, but an ACF field with the button no longer works.

The button is broken for me as well. I’m using the classic editor.

5.0 has the same problem, 4.5 works fine.

• This reply was modified 6 days, 7 hours ago by milesgilmour.

@polevaultweb I can confirm that 6.1.3 (I missed 6.1.2) fixes the problem. Thanks for the quick response – that means the updated version of ACF can be rolled out quickly by us without any other updates required.

@lgladdy Thanks, will use the action going forward.

Yes, same here – rolling back to 6.0.7. fixed it.

I thought the problem might be something to do with my configuration or selection of fields, but I’ve been doing some debugging and the simplest single field defined via PHP doesn’t work in a super simple plugin wrapper, but exactly the same code will work if pasted into the functions.php on the same site.

We are having exactly the same issue. Links that would go to blog pages are now ending up on wordpress.com. It looks like the redirect code is failing and wordpress.com is the fallback.

It’s worse than you think – I have users who have author level access (and don’t have access to Master Slider) but it attempts to redirect them to the popup, then gets a 403 error. It basically stops them logging in.

A basic check to make sure the person was an admin before showing the nag popup would have been nice!

Apparently widget visibility should be enabled by default.

But that’s not what I’m seeing:

https://www.ads-software.com/support/topic/cant-see-widget-visibility-or-custom-css-settings-any-more/

As a workaround I’m enabling it by going to the database and copying over the Jetpack settings (look for “jetpack_active_modules” in “option_name” on your options table) from a previous Jetpack install that was configured the way I wanted.

Hi Ryan,

I can confirm they are not being activated if you run the site in local dev mode without connecting it to WordPress.com.

Also, on the debug page there is not an option I can see to enable / disable individual modules. My debug page just tells me there “There seems to be a problem with your site’s ability to communicate with Jetpack!” and the link at the bottom gives a dump of various server info?

The only way to activate them I can use at the moment is to copy the settings over in the appropriate database row!

Just looking at some other sites I have that are running earlier versions of Jetpack (4.7.1) and they are also now missing any way to enable / disable Widget Visibility. There is actually no “Appearance” section even. This was all available a week ago.

A quick inspection of the HTML indicates the config screen is a react app so I’m guessing this problem is not in the plugin but the server app somewhere in cloudland that handles Jetpack config.

Is there supposed to be any way to enable / disable widget visibility, custom CSS, etc. in Dev mode or is this a bug?

• This reply was modified 7 years, 11 months ago by milesgilmour.

Just to add some more detail to this.

Running is_active_widget via the ‘init’ action, It looks like is_active_widget doesn’t work when you are using Jetpack’s widget visibility.

Stepping through the code for is_active_widget I noticed that widgets that should appear conditionally (and does appear on the page) are missing from the array that represents the active widgets for the particular sidebar it’s actually in (so are not returned as being active by is_active_widget).

It could be there is a more appropriate / later action that we should hook into to check widget visibility when Jetpack is installed?

There are problems with the use of the “source” tag in IE7-9, See my comment here:

https://www.ads-software.com/support/topic/images-blank-in-ie?replies=7#post-4906673

First off, this is a great plugin and thanks to Noel for creating it!

It turns out that there are fundamental problems in IE7-9 with scripting the <source> element that Hammy is putting out: https://www.w3.org/community/respimg/2012/03/06/js-implementation-problem-with/

There are workarounds for IE7 & 8 that will enable the <picture> <source> approach to be used, but no sensible workaround for IE9 ??

As it happens the current W3C thinking appears to be moving away from the picture element anyway (see “Meeting Outcomes” – https://www.w3.org/community/respimg/2013/09/18/paris-responsive-images-meetup/) towards srcset on the image tag, so there is probably little to be gained chasing an IE9 polyfill for “picture”.

If you change hammy to use the jqueryimage “figure” usage then it works with IE7-9 (and everything else).