Fallback for dropcap when __experimentalFeatures is not present #25979
Conversation
oandregal
requested review from
ajitbohra,
ellatrix,
Soean,
talldan and
youknowriad
as code owners
|
Size Change: +25 B (0%) Total Size: 1.19 MB
ℹ️ View Unchanged
|
| @@ -36,6 +36,9 @@ | |||
| "fontSize": true, | |||
| "lineHeight": true, | |||
| "__experimentalSelector": "p", | |||
| "__unstablePasteTextInline": true | |||
| "__unstablePasteTextInline": true, | |||
| "typography": { | |||
There was a problem hiding this comment.
The shape that is part of WordPress 5.5 is:
"supports": {
"anchor": true,
"className": false,
"lightBlockWrapper": true,
"__experimentalColor": {
"linkColor": true
},
"__experimentalFontSize": true,
"__experimentalLineHeight": true,
"__experimentalFeatures": {
"typography": {
"dropCap": true
}
},
"__experimentalSelector": "p",
"__unstablePasteTextInline": true
}
typography.dropCap is under __experimentalFeatures. I think we should avoid exposing typography.dropCamp under supports without any experimental mark when we know that we want to remove this from block.json. Block authors may replicate our json file.
| // when __experimentalFeatures are not present (core without plugin). | ||
| // To remove when __experimentalFeatures are ported to core. | ||
| const { getBlockSupport } = select( 'core/blocks' ); | ||
| return getBlockSupport( blockName, featurePath ); |
There was a problem hiding this comment.
We only want this for typography.dropCap but in the end, we are adding a mechanism that allows to control any feature not explicitly set on theme.json via block.json. People may start relying on this and then removing the behavior would be breaking backward compatibility.
In practice what happens is that on WordPress 5.6 there is no way a theme or plugin can disable the dropCap right? It seems to be always true without a way to change that. If that's case could our fallback be as simple as returning true all the time if featurePath is typography.dropCap?
We would have:
// 3 - Fall back for "typography.dropCap".
if( featurePath === 'typography.dropCap' ) {
return true;
}
There was a problem hiding this comment.
Implemented this at 62ac47f
There was a problem hiding this comment.
@jorgefilipecosta @nosolosw the below is true as far as I can see now that 5.6 is released.
In practice what happens is that on WordPress 5.6 there is no way a theme or plugin can disable the dropCap right
Is there any way to disable dropCap? I understand the rationale behind this PR, but removing functionality that people are actively using while providing no alternative is not particularly useful.
Edit
A developer can still disable dropcap using the WordPress block_editor_settings filter in 5.6 :)
oandregal
force-pushed
the
update/use-editor-feature-dropcap
branch
from
611248b to
62ac47f
Compare
Related: #20588
Previously: #24761, #24932
This PR makes sure the dropCap feature is available for paragraph in contexts where
__experimentalFeaturesis not present (core without the plugin, given thatlib/global-styles.phpis not ported over).Test
Make sure theme.json still works as expected:
lib/experimental-default-theme.jsonand settypography.dropCaptofalse=> load a post with a paragraph and verify that the drop cap option is not shown.Make sure it works without any theme.json:
lib/load.phpand comment the linerequire dirname( __FILE__ ) . '/global-styles.php';.