Open jeherve opened 1 week ago
cc @kraftbj ; I'm not sure what our best work-around should be at this point. I'd be happy to have your opinion. Maybe we should remove the is_active_widget
checks for now?
Looking at our list, this is going to impact quite a few widgets:
jetpack_display_posts_widget
gravatar-profile-widget
goodreads-widget
jetpack_social_media_icons_widget
jetpack-top-posts-widget
jetpack_image_widget
jetpack-my-community-widget
jetpack-authors-widget
eu-cookie-law-style
flickr-widget-style
jetpack-search-widget
jetpack-simple-payments-widget-style
jetpack-widget-social-icons-styles
wpcom_instagram_widget
milestone-widget
Hmm, so these checks in the impacted widgets with the result of each of these style files enqueing for any site with widgets enabled whether or not they're being used? https://github.com/Automattic/jetpack/blob/8def970e9b4c8481f580f899a41def360c539c9e/projects/plugins/jetpack/modules/widgets/top-posts.php#L76
I'm not a fan of that, but can appreciate it may be the quickest fix to restore the styling for impacted sites.
What about having a concatenated widgets.css of all of the widget CSS so at least it's only one file since they all would be enqueued anyhow with our fix?
I'd be curious if there was an alternative to is_active_widget
that we could add in for those sites until there's an upstream fix.
I'm thinking we may take a different approach. I opened #39820 for it. This is an approach we already follow for some of the other widgets, so I don't see why we couldn't do this for all widgets.
I haven't tested all the widgets I've modified yet, but if you want to give the PR a try, I'd appreciate it.
I like the direction in 39820. I left a couple comments noting it is still In Progress
Impacted plugin
Jetpack
Quick summary
This is a long-standing issue with the Elementor plugin. I reported it here: https://github.com/elementor/elementor/issues/29010
However, until #39518 this was a bug that was not noticeable since we enqueued all the CSS on all pages with the concatenated
jetpack.css
file. Now that we rely on each individual CSS file being enqueued, we're starting to notice the issue.Plugins can register WordPress widgets using the Widgets API (
register_widget
and extending theWP_Widget
class). When they do that, they can enqueue scripts and styles for their widget, by hookingwp_enqueue_scripts
. A good practice when enqueuing custom scripts and styles is to only enqueue them when the widget is present on the page. That can be checked with theis_active_widget
feature. Unfortunately,is_active_widget
does not returntrue
on pages where a widget has been added to the page via the Elementor editor.Steps to reproduce
A clear and concise description of what you expected to happen.
I would expect the
top-posts/style.css
stylesheet to be enqueued on the page.What actually happened
It is not.
Impact
Some (< 50%)
Available workarounds?
Yes, easy to implement
If the above answer is "Yes...", outline the workaround.
As a work-around, one can manually copy and paste the widget's CSS from this file into WordPress CSS editor.
Platform (Simple and/or Atomic)
Atomic, Self-hosted
Logs or notes
This was reported here: https://wordpress.org/support/topic/grid-layout-doesnt-work-in-the-top-posts-and-pages-widget/