-
Notifications
You must be signed in to change notification settings - Fork 799
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
Blocks: load each block from a separate file, take 2 #11312
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
This already needs a rebase, on it soon. |
611b94a
to
742e263
Compare
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: March 5, 2019. |
As we work to add several new modules, the existing module/blocks.php is updated quite often. It causes a few issues: - The file keeps getting longer and longer. - The longer the file, the longer it takes to skim through it. - Everyone working on that file ends up having to rebase frequently because we are merging changes to that file often. - Keeping the file in sync with WordPress.com can be more work if someone does not commit their matching WordPress.com diff immediately after merging a Jetpack PR. Splitting things into different files makes things easier to maintain for everyone. This commit switches to only loading a block file if: - Gutenberg is available on the site. - Gutenpack is enabled on the site. - the block is available in the block list (index.json) The directory structure was chosen so in the future, it can be used to host the blocks' source code as well. For further discussion about this, see: pafL3P-io-p2
742e263
to
12fa4fd
Compare
jeherve, Your synced wpcom patch D24147-code has been updated. |
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.
Tested on WP v5.0.3 with Gutenberg plugin v5.0 active and inactive.
Checked that all the blocks appear at block picker,
that I don't see beta blocks when beta constant is disabled,
that forms block has its children blocks,
that on frontend I get assets for tiled gallery and related posts blocks. 👍
I love how we've thought a bit ahead next steps when thinking naming conventions and yet not optimized too much for the future (that sometimes doesn't end up happening).
I'd encourage you to double check WP 4.9 without Gutenberg before merging and I've left some minor notes but feel free to ship! 🚢
Thanks a ton for doing this, you're making everyone's work so much easier with this!
* | ||
* @since 7.1.0 | ||
*/ | ||
public static function load_independent_blocks() { |
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.
There's something funky about term "independent" 🤔 ...that said I don't have anything else to suggest and I'm ok with this. 😄
I have an inkling we'll eventually one day make all our blocks module-independent and re-visit this by renaming it to load_blocks()
. 😄
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 may be my ESL at play :)
I wanted to denote that those blocks aren't linked to any module. Happy to change that of course, I just can't think of a better word right 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.
We actually do have module dependent block(s) in that folder:
class_exists( 'Jetpack_Photon' ) && Jetpack::is_module_active( 'photon' ) |
I'd be up moving rest of the module-dependent blocks here too and do something similar, e.g. this could be good to move:
jetpack/modules/related-posts/jetpack-related-posts.php
Lines 71 to 78 in 02e53f8
if ( function_exists( 'register_block_type' ) ) { | |
register_block_type( | |
'jetpack/related-posts', | |
array( | |
'render_callback' => array( $this, 'render_block' ), | |
) | |
); | |
} |
(related p9dueE-vJ-p2, cc @aldavigdis )
...but that's for another day and PR. :-)
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.
You're right. It would make even more sense once we move the blocks themselves in there; it will be better and easier for everyone to have everything in one place.
Once this gets merged, I'll take a look at this.
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.
Getting this started in #11325
See #11312 (comment) We can add this back once the move happens.
77cecb1
to
02e53f8
Compare
jeherve, Your synced wpcom patch D24147-code has been updated. |
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 Jeremy, this is looking great!
Did some smoke testing (inserting blocks and checking them on the frontend).
Also downgraded to WP 4.9.9 to verify that there are no fatals 😅
I took a quick look at the blocks I'm involved with (Map|Mailchimp|Slideshow|Gif) and all looks good. |
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.
It works well in my tests. LGTM 🚢
Following the changes we've made in #11312, I think it now makes sense to bring block registration closer to where the block's code will eventually live, when possible. See #11312 (comment)
Following the changes we've made in #11312, I think it now makes sense to bring block registration closer to where the block's code will eventually live, when possible. See #11312 (comment)
Changes proposed in this Pull Request:
As we work to add several new modules, the existing module/blocks.php is updated quite often. It causes a few issues:
Splitting things into different files makes things easier to maintain for everyone.
This commit switches to only loading a block file if:
About the chosen structure
I highlighted the new directory structure in a readme file here:
https://github.com/Automattic/jetpack/blob/742e263436dd2b29fd9d7592dd5c2452943f3273/extensions/readme.md
It was chosen so in the future, it can be used to host the blocks' source code as well. When that happens, things should look like this:
If the extension happens to not be a block, but a plugin for example, it can be placed in
/extensions/plugins
.For further discussion about this, see:
#11286
pafL3P-io-p2
Testing instructions:
Proposed changelog entry for your changes: