-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map block: fix script loading to work with FSE #19552
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped. Jetpack plugin:
|
} ); | ||
|
||
const { vendorWindow } = getVendorLoadContext( this.mapRef.current ); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Key todo with this approach is working out how to load these from local resource instead of remote
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would Jetpack's window.Jetpack_Block_Assets_Base_Url
be helpful here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that will be handy once I have worked out how to either get the webpack hashed filename, or manually set the vendor bundle hashed filename, slowly making progress on that.
If this works, seems like a great utility for Gutenberg plugin! |
loadMapLibraries() { | ||
const { apiKey } = this.props; | ||
Promise.all( [ | ||
import( /* webpackChunkName: "map/mapbox-gl" */ 'mapbox-gl' ), | ||
import( /* webpackChunkName: "map/mapbox-gl" */ 'mapbox-gl/dist/mapbox-gl.css' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that by default Webpack dynamic imports are lazy
, i.e. loaded asynchronously. Just noting in case you wanna ensure the same loading method with <script async>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. With the way this is currently setup the script tag is not injected into the iframe header until after the page has loaded so adding async may not make any difference, but will do some double checking on that.
For sure, that is the plan 😄 |
This is working well on a standalone Wordpress install. In the Site Editor on WPCOM however, the map container isn't recognised: Suspecting this line, but ran out of time for debugging. Will browser test tomorrow. 👍 |
I didn't notice that the mapbox-gl js had not been copied over to the D60271-code diff. Thanks @glendaviesnz for updating it! Works a treat now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested this in both the block and site editors in Chrome, FF, Safari (MacOS and iOS) and Edge.
Maps load as expected in the editors and on the frontend.
I cleaned up my build dir and rebuilt the project. The map dependencies are copied over to _inc/blocks/editor-assets
as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving this for now, this tests well for me. Marking the PR as on hold pending Gutenberg discussion.
There is nothing in core gutenberg at the moment that can be used in place if this approach, so probably best to merge this and then circle back if core adds some APIs for this. Will rebase and get it sorted for merging tomorrow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Smoke tested again after the rebase in the site editor (iframed in wpcom and via wp-admin
) and on a non-FSE site in the post editor. LGTM! And good idea getting this in as a shorter-term fix until there's a more general approach for handling loading 3rd party scripts in Gutenberg.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests well for me. 🚢
@jeherve the wpcom diff failed because I used |
An api was just added to core that we may be able to use for this - WordPress/gutenberg#31873, so just looking into that first, should no one way or the other tomorrow |
Noting that Jetpack supports the current version of WordPress -1, so we may not be able to use this just yet. |
@glendaviesnz Hey 👋 Is this PR ready to merge, or are you still researching? |
@samiff, @jeherve WordPress/gutenberg#31873 has been merged and will work as a better long term solution to this problem. It could be used now as Jetpack doesn't need to know about the api, it hooks into the existing enqueue hooks in the background, so the resources just wouldn't load in the site editor iframe in older versions of WP without the gutenberg plugin, but these sites are not going to be able to use the newer versions of the site editor anyway. However, given that it is only just added to trunk and as a new api may be subject to some immediate changes, I think we should just stick with this solution as is, and I will add an issue to follow up at some point in the future an refactor this to make use of the new api. |
Issue for follow up refactor added at #19896 |
Great news! One last step: head over to your WordPress.com diff, D60271-code, and commit it. Thank you! |
rWP225980 |
Description
Possible fix for: #19482
Currently the Jetpack Map block fails to load in the Site Editor context because the
mapbox-gl.js
file is loaded in the main window context, but the block editor is running in an iframe when in the site editor context.To get around this issue this PR adds a supporting library which can load editor asset files into the correct window context of the current editor.
This issue as been raised for discussion at WordPress/gutenberg#31022 in order to see if there is a broader solution that might be possible within the core Gutenberg plugin.
Does this pull request change what data or activity we track or use?
No
Testing instructions:
Please note: This is still a PoC solution and open for review on the general approach. Waiting for feedback on WordPress/gutenberg#31022 before merging