[WIP] Enqueue only required frontend styles - V2 #6200
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 29 commits
April 8, 2018 21:27
Added a class "WP_Parsed_Block_Types_Registry" to manage the storage of block types parsed from the HTML (while stripping block comments)
Core block types parsed from the HTML may not contain 'core/'. Added a function gutenberg_prefix_core_namespace_if_not_found() to do the same.
…required-frontend-styles
…required-frontend-styles
…required-frontend-styles
This is work in progress and will be completely overhauled. Just committing it so that I don't lose it.
…required-frontend-styles
…e enqueued The new logic checks if the current requested web page is in the frontend. And if it's page or a post. If the answer is yes to both, it only enqueues styles for blocks which are present in the post/page.
…required-frontend-styles
…required-frontend-styles
Renamed gutenberg_prefix_core_namespace_if_not_found() to gutenberg_normalize_block_type() Removed '$match = Array()' since we don't need to declare a variable for preg_match() Fixed syntax to suit coding standards
…blocks Our rendering algorithm for dynamic blocks was stripping block comments after rendering those dynamic blocks. Disabled that functionality since block comments are needed to find out block types present in the page later.
…required-frontend-styles-v2
get_last_error() function in Block Type Validator was referencing $errors as a local variable, whereas it should have referenced it as a class variable. Have fixed it in this commit.
Removed _doing_it_wrong() notices from Block Type validator class since the same are being called in the caller class.
…required-frontend-styles-v2
…ments and other changes Renamed gutenberg_strip_block_comments to gutenberg_process_block_comments Used gutenberg_normalize_block_type() in function which renders dynamic blocks Improved documentation blocks for some functions
…n which enqueues scripts and style handles
4 tasks
added 9 commits
April 16, 2018 17:21
…required-frontend-styles-v2
…required-frontend-styles-v2
Earlier, we were parsing block types from the HTML and saving them to the registry even for pages like category / archive pages (which contain multiple posts). Have disabled this functionality for such pages now since the registry is only needed for intelligent enqueueing of assets (which is needed for single post / page types as of now).
aduth
added
[Status] In Progress
|
This pull request appears to have languished and will not be easily reconciled with master. Please feel free to reopen and rebase against the current master, or open a new pull request. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a proof of concept for #5445. It only enqueues front-end styles for
block typespresent in the current page/post.Dependencies
core blocksaren't registered on server side (as of now, in master), it depends on [WIP] Update/build individual blocks #6087 to be merged first.Version 2 (enqueues styles inside
<head>)This branch reads the current post's content on the
wp_enqueue_scriptsaction (much earlier thanthe_content). Therefore, it enables us to be able to enqueue required styles inside the<head>section.An issue with this approach is that if a plugin adds a
core blockusing a filter onthe_contentlater, our code isn't able to enqueue styles for thatblock typesince we already have read the post's content much earlier. Maybe we can try re-parsing the post's content to enqueue styles for anyremaining block typesafter all filters onthe_contenthave executed.Version 1 (enqueues styles inside
<body>)#6166 hooks a filter on
the_contentto getblock typespresent in the page while stripping block comments from the HTML.Since filters hooked to
the_contentare executed much later in the lifecycle (after actions hooked towp_enqueue_scriptsare executed), the stylesheets get enqueued in the<body>section.To Do