-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Allow contents of Paragraph to be "connected" to a meta custom field #53247
Changes from 17 commits
77047c3
ff12248
514a068
66a9aef
5fbf21c
a493bb1
7575b40
f8ee25e
39cb931
fa042ca
64a5f03
d7fccec
0b52159
2014934
52b4a58
cbec419
c29d885
9f0d851
1c65e74
8638dff
88dd0b5
81f9c67
60fa061
713c6df
e80effe
7640a60
f0bcb0f
6a2785f
4408e69
5cd3d22
6d00a9b
367ee0c
a45e464
84f2a08
49d5cb6
414b322
92c3cd9
ba713a4
a5b9e3b
a0bd2ca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
<?php | ||
/** | ||
* Meta Custom Source | ||
* | ||
* @package gutenberg | ||
*/ | ||
|
||
return array( | ||
'name' => 'meta', | ||
'apply_source' => function ( $block_content, $block_instance, $meta_field, $attribute_config ) { | ||
// We should probably also check if the meta field exists but for now it's okay because | ||
// if it doesn't, `get_post_meta()` will just return an empty string. | ||
$meta_value = get_post_meta( $block_instance->context['postId'], $meta_field, true ); | ||
$p = new WP_HTML_Tag_Processor( $block_content ); | ||
michalczaplinski marked this conversation as resolved.
Show resolved
Hide resolved
|
||
$found = $p->next_tag( | ||
array( | ||
// TODO: In the future, when blocks other than Paragraph and Image are | ||
// supported, we should build the full query from CSS selector. | ||
'tag_name' => $attribute_config['selector'], | ||
) | ||
); | ||
if ( ! $found ) { | ||
return $block_content; | ||
} | ||
$tag_name = $p->get_tag(); | ||
$markup = "<$tag_name>$meta_value</$tag_name>"; | ||
$p2 = new WP_HTML_Tag_Processor( $markup ); | ||
$p2->next_tag(); | ||
$names = $p->get_attribute_names_with_prefix( '' ); | ||
foreach ( $names as $name ) { | ||
$p2->set_attribute( $name, $p->get_attribute( $name ) ); | ||
} | ||
|
||
return $p2 . ''; | ||
michalczaplinski marked this conversation as resolved.
Show resolved
Hide resolved
|
||
}, | ||
); |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,136 @@ | ||
/** | ||
* WordPress dependencies | ||
*/ | ||
import { addFilter } from '@wordpress/hooks'; | ||
import { PanelBody, TextControl } from '@wordpress/components'; | ||
import { __, sprintf } from '@wordpress/i18n'; | ||
import { hasBlockSupport } from '@wordpress/blocks'; | ||
import { createHigherOrderComponent } from '@wordpress/compose'; | ||
import { useRef } from '@wordpress/element'; | ||
|
||
/** | ||
* Internal dependencies | ||
*/ | ||
import { InspectorControls } from '../components'; | ||
import { useBlockEditingMode } from '../components/block-editing-mode'; | ||
|
||
/** | ||
* Filters registered block settings, extending attributes to include `connections`. | ||
* | ||
* @param {Object} settings Original block settings. | ||
* | ||
* @return {Object} Filtered block settings. | ||
*/ | ||
export function addAttribute( settings ) { | ||
if ( hasBlockSupport( settings, 'connections', true ) ) { | ||
// Gracefully handle if settings.attributes is undefined. | ||
settings.attributes = { | ||
...settings.attributes, | ||
connections: { | ||
type: 'object', | ||
}, | ||
}; | ||
} | ||
|
||
return settings; | ||
} | ||
|
||
/** | ||
* Override the default edit UI to include a new block inspector control for | ||
* assigning a connection to blocks that has support for connections. | ||
* Currently, only the `core/paragraph` block is supported and there is only a relation | ||
* between paragraph content and a custom field. | ||
* | ||
* @param {WPComponent} BlockEdit Original component. | ||
* | ||
* @return {WPComponent} Wrapped component. | ||
*/ | ||
export const withInspectorControl = createHigherOrderComponent( | ||
( BlockEdit ) => { | ||
return ( props ) => { | ||
const blockEditingMode = useBlockEditingMode(); | ||
const hasCustomFieldsSupport = hasBlockSupport( | ||
props.name, | ||
'connections', | ||
false | ||
); | ||
// We prevent that the content is lost when the user removes the custom field. | ||
// Editing the content in the paragraph block with a placeholder is not the best solution. | ||
const prevContent = useRef( props.attributes?.content ); | ||
if ( ! prevContent.current ) { | ||
prevContent.current = ''; | ||
} | ||
if ( hasCustomFieldsSupport && props.isSelected ) { | ||
return ( | ||
<> | ||
<BlockEdit { ...props } /> | ||
{ blockEditingMode === 'default' && ( | ||
<InspectorControls> | ||
<PanelBody | ||
title={ __( 'Connections' ) } | ||
initialOpen={ true } | ||
> | ||
<TextControl | ||
__nextHasNoMarginBottom | ||
autoComplete="off" | ||
label={ __( 'Custom field meta_key' ) } | ||
value={ | ||
props.attributes?.connections | ||
?.attributes?.content?.value || | ||
'' | ||
} | ||
onChange={ ( nextValue ) => { | ||
if ( nextValue === '' ) { | ||
props.setAttributes( { | ||
connections: undefined, | ||
content: | ||
prevContent.current !== | ||
'' | ||
? prevContent.current | ||
: undefined, | ||
} ); | ||
} else { | ||
props.setAttributes( { | ||
connections: { | ||
attributes: { | ||
// Content will be variable, could be content, href, src, etc. | ||
content: { | ||
// Source will be variable, could be post_meta, user_meta, term_meta, etc. | ||
// Could even be a custom source like a social media attribute. | ||
source: 'meta_fields', | ||
value: nextValue, | ||
}, | ||
}, | ||
}, | ||
content: sprintf( | ||
'This content will be replaced in the frontend by the custom field "%s" value.', | ||
nextValue | ||
), | ||
} ); | ||
} | ||
} } | ||
/> | ||
</PanelBody> | ||
</InspectorControls> | ||
) } | ||
</> | ||
); | ||
} | ||
|
||
return <BlockEdit { ...props } />; | ||
}; | ||
}, | ||
'withInspectorControl' | ||
); | ||
if ( window.__experimentalConnections ) { | ||
addFilter( | ||
'blocks.registerBlockType', | ||
'core/connections/attribute', | ||
addAttribute | ||
); | ||
addFilter( | ||
'editor.BlockEdit', | ||
'core/connections/with-inspector-control', | ||
withInspectorControl | ||
); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,6 +7,7 @@ | |
"description": "Start with the basic building block of all narrative.", | ||
"keywords": [ "text" ], | ||
"textdomain": "default", | ||
"usesContext": [ "postId" ], | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder whose responsibility is it to do that. In other words, the block is not using the "postId" explicitly, so why add the "useContext" here. The "connection framework" should inject/filter this somehow. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean that in the context of Core blocks or custom blocks or both? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. both There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK! For now, I think that for core blocks this is fine. But you're right that for custom blocks we'll have to come up with a proper mechanism here. Are you all right with that? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I think it's part of the definition of a "custom source" to say which change it needs to make to block registration. I think we should use it for both core and third-party blocks but yeah it's fine to start without it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For now, you could update There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even though this is the first implementation and custom blocks are not supported yet, I believe it'd be better to start creating mechanisms that would work for both if possible. Mainly because we already know we will want to support that in the future. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Coming in a bit late here. The current work on partial syncing (#54233) is using the store actions/selectors for attributes to inject/update values, but it might be difficult to pull this off if block context is being used for custom fields, as I believe it uses react context in JS. While they're still proofs of concepts, the current work for custom fields/partial syncing does need to remain compatible, so it might be good to explore ways to read/write custom field values in the editor soon though so that we have a clear idea of the problems that need to be solved. |
||
"attributes": { | ||
"align": { | ||
"type": "string" | ||
|
@@ -28,6 +29,14 @@ | |
"direction": { | ||
"type": "string", | ||
"enum": [ "ltr", "rtl" ] | ||
}, | ||
"connections": { | ||
"type": "object", | ||
"attributes": { | ||
"content": { | ||
"source": "meta_fields" | ||
} | ||
} | ||
michalczaplinski marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
}, | ||
"supports": { | ||
|
@@ -41,6 +50,7 @@ | |
"text": true | ||
} | ||
}, | ||
"connections": true, | ||
"spacing": { | ||
"margin": true, | ||
"padding": true, | ||
|
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'm a bit confused about the "custom sources" naming. Is this what we are doing? Are we rendering custom sources? If I understood it correctly, we are:
get_post_meta
.html
in the case of the paragraph.In my opinion, this last step should be independent of the connections source. If I get the value from a different source, I would still have to replace the same HTML, but with a different value. Is this right?
Just to have more context, I believe in the future this distinction will be more relevant:
html
we will replace the inner content. If it isattribute
we will replace an HTML attribute.That's why it makes sense to separate the code as well.
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, that's the right abstraction of the 3 steps that we perform. As it stands right now, the 2nd & 3rd step are not separated. It makes sense that they should be.
Also, some of the naming is a direct copy from Riad's PR (#51375) which is not 100% accurate anymore.
I ll change it.
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.
The code should be better abstracted now to reflect those 3 separate steps. 1 & 3 are both inside of the same function but we can abstract it further when we add support for the Image block & other attributes. Then we can abstract the part that replaces the different attribute sources (
html
,attribute
, etc.).We should discuss consistent naming though of Step 2. Should it be:
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.
Yes, I believe the whole naming should be discussed. Another option I was thinking of was using "Dynamic data" instead of "Connections". So it could be "Dynamic data sources". But I didn't think enough about it. What doesn't quite fit me is the use of "custom". What does "custom" mean in this context? Which sources are not custom?
Do we need it for this initial experiment? Is it too difficult to change it afterwards?
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 guess "custom" means something like "different than whatever WP uses to get the content normally" but I agree that it's a bit meaningless.
I like "Connections" a little bit better than "Dynamic Data" because the latter can mean many things in many different contexts. Most data is dynamic rather than static in programming 🤓. I think "Connection Sources" sounds best so far. "Connections" alone is also a bit vague. "Connection Sources" implies "data sources" which is roughly what we are referring to 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.
Maybe "block connections" is also a good name? We're connecting stuff to blocks after all.
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.
Yep, I was thinking about names using this sentence: we are connecting block attributes to values that might change depending on the context (post_id, parent block…). But not sure yet which is the best abstraction 😄
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.
Hmm, I would just go with "block connections" as a name for the whole thing (like I use it in https://github.com/WordPress/gutenberg/pull/53247/files#diff-be8a354ce9c01e85c0fdf04c75d76880cdc6c81992db7a86a7a0515dc11a9833R135) and "connection sources" for the thing that does the connecting to meta fields/parent blocks/other DBs, etc.
We can always change it in the future.
If you don't object, then I ll go ahead and change it.
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.
Sure! We can always change the naming later if we agree on a different one.