WP.com Block Editor: Enqueue missing common styles on the front-end.

[kwight]

Up to now, both the script and styles for the common module have been enqueued on the enqueue_block_editor_assets hook; this left out necessary styles for justified text from being displayed on the front-end.

This PR splits out the styles from enqueue_scripts, and enqueues them for both the editor and the front-end.

Editor

Front-end

Testing instructions

• Switch to this branch.
• Create a new post, add multiple lines of content to a Paragraph block.
• Format the content as "Justify", and verify it formats the content properly in the editor.
• Publish the post, and verify the text is justified on the front-end too.

Proposed changelog entry
[BUG] Fixed Justify styling for the WP.com Block Editor.

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: December 3, 2019.
Scheduled code freeze: November 26, 2019

Generated by 🚫 dangerJS against f25842e

[jeherve]

Would there be a way to not load this on each and every front-end page as soon as Jetpack is connected to WordPress.com? Ideally we'd only use it when the buttons are used in a post that's being displayed.

If that's not an option, maybe we should move those common styles to a stylesheet that's already loaded on each front-end page by Jetpack, such as the concatenated jetpack.css.

[gwwar]

Would there be a way to not load this on each and every front-end page

@jeherve The current size of http://widgets.wp.com/wpcom-block-editor/common.min.css is only 670B. Can we please follow up on this in another issue? There more to think through with either alternative approach.

[kwight]

Would there be a way to not load this on each and every front-end page as soon as Jetpack is connected to WordPress.com?

Good point! @gwwar I can add a has_block check to keep this more tidy.

[jeherve]

I'm afraid I'm still getting fatal errors:

Fatal error: Uncaught Error: Call to undefined function get_current_screen() 

The current size of http://widgets.wp.com/wpcom-block-editor/common.min.css is only 670B.

I'm less worried about the file size, and more about the added CSS enqueue, especially coming from a module that can't be easily disabled by most site owners and when the enqueue is not hosted on the site so can't be handled by most concatenating / caching plugins. Some folks monitor the different enqueues on their site very closely, and will not be happy to see us adding a file without an easy way to dequeue it (short of doing it via code).

Since the file includes so little, wouldn't we better served by hosting it locally in Jetpack, and adding it to this list so it gets concatenated in jetpack.css for everyone:

jetpack/class.jetpack.php

Line 53 in ade7b28

* @var array The handles of styles that are concatenated into jetpack.css.

As a result there won't be any additional enqueue, and we won't have to worry that the file is enqueued on all pages since jetpack.css is already enqueued on all pages.

[kwight]

@jeherve With the latest updates, it'll only be enqueued if:

• the WordPress.com user is connected, and
• the user is in the block editor, or
• the front-end is displaying blocks that use the justify setting.

This way, it's only enqueued when truly needed, and we're not adding stuff to jetpack.css for those that'll never need it. Would that work for you?..

[jeherve]

This is just what we needed, thank you. It should be good to merge!

[gwwar]

❤️ Thanks @jeherve and @kwight !