Widget visibility settings not preserved

[Blackhawke]

Changes to widget visibility settings that are neither all off or all on are erratically changed upon close/save of the visibility pop-up. I've tried to save specific page display settings for widgets on two different browsers (FireFox and Chrome) and both produce the same result:

If a widget is to display only on pages A, B, C, and D; what is stored is randomly, A, C, E, F, G, and L. Or maybe A, B, C, G M, N, and P. Who knows. If all pages are off, they'll stay off. If all pages are on, they stay on.

In the same vein, paging through the lists screws up items selected items on each page too. All de-selected items will be re-selected when you go to another page.

[westonruter]

Hi. Widget Visibility is actually a feature of Jetpack, not core. So a Trac ticket actually shouldn't be made unless a bug was introduced in 4.9 specifically. Does the issue happen in 4.8.3? If so, I suggest opening a GitHub issue instead: ​https://github.com/Automattic/jetpack/issues

[Blackhawke]

It's actually a feature of several available plugins. In that, I did make a mistake in that I forgot to disable a plugin to check before posting, and that plugin was a part of the problem. But changing to a different plugin that is compatible with WP 4.9 has not completely eliminated the issue.

The randomness is gone, but even with a plugin that otherwise works well, there is instability, like a widget persistently not showing up on one, and only one of the pages/posts on which it's supposed to be visible.

And no, I'm not using JetPack. For one thing, it's currently not compatible with WP 4.9.

[westonruter]

While Jetpack still says that it has been tested up to 4.8.3, it actually is compatible with 4.9. The 5.5 release was done specifically to add 4.9 compatibility. I just tried Widget Visibility in Jetpack and it is working as expected in 4.9. I can make a widget hidden or only shown on the posts page.

Widget Visibility isn't a core feature, so you'll need to list out which specific plugin you're using to reproduce the issue. Please also test in 4.8.3 to confirm whether or not it is a regression or something that existed prior to 4.9. Providing a screencast video of the problem would be particularly helpful.

[hellofromTonya]

Hello @Blackhawke,

Is this still a problem for you today?

Were you able to do the steps Weston mentioned:

• Make a list of the "specific plugin you're using to reproduce the issue"
• Test "in 4.8.3 to confirm whether or not it is a regression or something that existed prior to 4.9"
• And then make "a screencast video of the problem" and upload it to this ticket

Please advise to help us further investigate.

I'm marking this ticket as a close worksforme candidate. Please don't be alarmed. We mark tickets for close consideration when we are unable to reproduce and suspect the problem is not due to WordPress core. However, when more information is given, we reevaluate.

[Blackhawke]

Wow! This was 3 years ago. I'd completely forgotten about it, so its safe to say it's not a problem.

[hellofromTonya]

Thanks for replying @Blackhawke. I'm glad it's no longer an issue.