Comments (14)
Is it possible to apply these content filters on get_block_templates instead?
It looks like that applies to the template content before the blocks are parsed and rendered, so it wouldn't catch the markup from any of our server-side blocks. The nice thing about render_block_core/pattern
was that it ran after everything else was built.
I've been wondering for a while if we don't actually need a separate filter for post-processing the entire template content
Yeah, that's pretty much what I'm looking for. In fact, the_block_template_html
from WordPress/wordpress-develop#5188 would be great.
from gutenberg.
I'm curious why you chose to apply this content filtering at the pattern level, rather than somewhere else.
from gutenberg.
It seemed to be the best place for it, for our use case. On WordPress.org, the content is output via patterns, not post content (so that it can be translated and publicly version-controlled).
For example, the front page template has just a header, footer, and pattern. The pattern contains all the page content.
The same process is true for all pages on wp.org — About page template, content pattern; Features page template, content pattern; etc.
This way, the same theme can be used to render all the Rosetta sites: https://es.wordpress.org/, https://fr.wordpress.org/, and so on.
So hooking into render_block_core/pattern
was an easy way to run these content filters only once on the page content. Possibly the only way, as looking through the code I don't see any place where the block content can be filtered once it's rendered for the template-canvas.
from gutenberg.
Thanks, that helps. Is it possible to apply these content filters on get_block_templates
instead? I've been wondering for a while if we don't actually need a separate filter for post-processing the entire template content, that is separate from post-processing of post content (i.e., the_content
) as the current state of things is causing some filters to run twice (See https://core.trac.wordpress.org/ticket/55996).
from gutenberg.
I've refreshed the filter approach in WordPress/wordpress-develop#6533.
from gutenberg.
There's also #61212 which proposes a filter for the entire HTML response (down to the html
tag), which may be needed for the Interactivity API.
from gutenberg.
Just came here to note that this has broken a conditional/visibility system that I have in place, which I use when calling <!-- wp:pattern /-->
.
from gutenberg.
Just came here to note that this has broken a conditional/visibility system that I have in place, which I use when calling
<!-- wp:pattern /-->
.
Could you elaborate?
from gutenberg.
I commented on my own PR here about running the filters: #61711 (comment)
I don't understand how this isn't a problem already: once you load patterns in the editor, they'll be resolved, and disappear on the next save.
It sounds like you want to preserve these patterns on the front-end. Maybe there's a way to only replace them when getting patterns for the editor? Maybe we need to remove the resolving from get_block_templates
and get_block_template
and only resolve for the REST API endpoint(s).
from gutenberg.
Here's my new proposal: #61757
from gutenberg.
@ellatrix - The new proposal looks like it'd resolve the issue.
Yes, this is for a system that's on the front end only when used for patterns. Templates in this case are not saved in the database. I can work around it by adding the conditional feature to a wrapping Group block around the pattern, but my main concern is for folks who have deployed it on existing sites using the Pattern block.
from gutenberg.
I don't understand how this isn't a problem already: once you load patterns in the editor, they'll be resolved, and disappear on the next save.
For my case, these are patterns that are not enabled in the editor. They're only called from templates, which are never generated from the database, only theme files. The pattern hooks were just a convenient place to run some code.
That said, I believe we've moved away from switching out pattern slugs in favor of filtering the template hierarchy (which seems more in line with how it "should" work). For the other things we've attached to the pattern render hook, the_block_template_html
from WordPress/wordpress-develop#6533 works even better.
However until that merges, #61757 looks good and should let wp.org update gutenberg again.
from gutenberg.
There's also the potential for the wp/block
(old reusable/new pattern block) to reference bundled patterns via slugs in the future (like template parts do), but the difference is the block wouldn't auto-remove itself. Not sure if that would help with any of the issues being mentioned.
from gutenberg.
It sounds like we should go ahead with that fix. Could anyone approve?
from gutenberg.
Related Issues (20)
- Scaffolded block doesn't register in editor due to @wordpress/scripts version 28.0.0 HOT 1
- Pattern Overrides not rendering on Front End HOT 2
- [Flaky Test] Open the command palette and navigate to a template
- Uniform Focal point labels
- Editor: Link preview overflows with long strings and only shows postname HOT 3
- Custom CSS for block with a block style variation is not rendered to the page. HOT 1
- Editor: Text / Scrollbar flickering HOT 1
- Search Block: Settings to limit search results
- Search Block: Option to have live suggested results or word auto-completion HOT 1
- New Block: Query Results Count Block
- Disambiguate "Cover" translatable string in the context of `background-panel.js` HOT 5
- Several typo correction in doc files
- [Flaky Test] Navigates from items list to preview via TAB, and vice versa
- Dennis' list of broad and interesting things.
- Block API: Introduce abstraction for better management of inspector controls HOT 2
- Inserter: Tab-focus diverges from other tab-bars HOT 2
- Save theme style variation in options instead of in the custom global styles post
- Outline button variation not working with TT4 (and other themes) HOT 5
- Update block_header_area() to support other template parts HOT 1
- Theme CSS color vars do not update outside of canvas iframe HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gutenberg.