Skip to content
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

Run wp.oldEditor.removep() when transforming shortcodes #8077

Merged
merged 5 commits into from
Jul 27, 2018
Merged

Conversation

danielbachhuber
Copy link
Member

Description

Multi-line shortcodes transformed to Shortcode Blocks end up with <p>
in awkward places. Thanks to @pento's quick thinking, we can use some
existing WordPress magic to solve the immediate problem without falling
into the deeper rabbit hole.

Fixes #3900

How has this been tested?

  1. Create a post in the Classic Editor with the following text:
[column]

I daresay that Fry has discovered the smelliest object in the known universe! For the last time, I don't like lilacs! Your 'first' wife was the one who liked lilacs! No argument here. A true inspiration for the children.

[/column]
  1. Open the post in Gutenberg and click "Convert to Blocks"

  2. You should see the shortcode converted into a Shortcode Block without paragraph tags:

image

The prior behavior looked like this:

image

Types of changes

Bug fix.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@danielbachhuber danielbachhuber added [Type] Bug An existing feature does not function as intended [Feature] Paste [Feature] Shortcodes Related to shortcode functionality labels Jul 20, 2018
@danielbachhuber danielbachhuber added this to the 3.3 milestone Jul 20, 2018
@danielbachhuber danielbachhuber requested a review from a team July 20, 2018 11:58
aduth
aduth previously requested changes Jul 20, 2018
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use removep and autop from the @wordpress/autop package instead of relying on the global? (Should also then add wp-autop as a script dependency of the wp-core-blocks handle)

@danielbachhuber
Copy link
Member Author

Can we use removep and autop from the @wordpress/autop package instead of relying on the global?

Yep e81c6ab

@danielbachhuber danielbachhuber requested review from a team and aduth July 20, 2018 13:02
@aduth aduth removed this from the 3.3 milestone Jul 20, 2018
@pento pento added this to the Try Callout milestone Jul 25, 2018
@pento
Copy link
Member

pento commented Jul 25, 2018

I've added an extra check removep() when saving a single freeform block.

When Gutenberg saves a freeform block, it doesn't wrap it in the comment delimiters. When there's a single freeform block in the post, there's no way to tell that the post has been touched by Gutenberg, so Gutenberg needs to clean up after itself.

This should possible be a seperate PR, but let's make this one the "fix the two issues reported #3900" PR.

@danielbachhuber
Copy link
Member Author

This should possible be a seperate PR, but let's make this one the "fix the two issues reported #3900" PR.

@pento Could you clarify what you mean by this? Are we going down the path of landing this and also recreating unbalanced / broken paragraph tags on the inner content prior to rendering the shortcode?

@danielbachhuber
Copy link
Member Author

@gziolo I'm not sure what's remaining on this. Do you know?

@pento pento dismissed aduth’s stale review July 26, 2018 07:29

Changes requested done in e81c6ab.

@pento
Copy link
Member

pento commented Jul 26, 2018

I've turned core/shortcode into a dynamic block, so we can make sure it's correctly autop-ed when it's rendered.

Includes unit tests and such.

danielbachhuber and others added 5 commits July 26, 2018 17:35
Multi-line shortcodes transformed to Shortcode Blocks end up with `<p>`
in awkward places. Thanks to @pento's quick thinking, we can use some
existing WordPress magic to solve the immediate problem without falling
into the deeper rabbit hole.
@pento
Copy link
Member

pento commented Jul 26, 2018

Also, I rebased/force pushed this branch, to get the latest version of the server fixtures, which I didn't really need to do, because server-registered.json only cares about dynamic blocks that register attributes. 🙂

@danielbachhuber
Copy link
Member Author

💯 I tested this locally and it works exactly as expected.

@danielbachhuber danielbachhuber modified the milestones: Try Callout, 3.4 Jul 26, 2018
@danielbachhuber danielbachhuber removed their assignment Jul 26, 2018
@danielbachhuber
Copy link
Member Author

@WordPress/gutenberg-core This is ready for a final review/merge per #3900 (comment) All issues are addressed.

Copy link
Member

@pento pento left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@pento pento merged commit 68519eb into master Jul 27, 2018
@pento pento deleted the 3900-unautop branch July 27, 2018 01:22
@@ -1,6 +1,7 @@
/**
* WordPress dependencies
*/
import { removep, autop } from '@wordpress/autop';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

core-blocks does not have a dependency defined for wp-autop, so its existence is purely incidental and this could be prone to future breakage.

@@ -46,7 +47,7 @@ export const settings = {
text: {
type: 'string',
shortcode: ( attrs, { content } ) => {
return content;
return removep( autop( content ) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not evident why we're doing this. An inline code comment would have been appropriate.

return serialize( getBlocks( state ) );
const blocks = getBlocks( state );

if ( blocks.length === 1 && blocks[ 0 ].name === getUnknownTypeHandlerName() ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not evident why we're doing this. An inline code comment would have been appropriate.

import { __ } from '@wordpress/i18n';
import { moment } from '@wordpress/date';
import deprecated from '@wordpress/deprecated';
import { removep } from '@wordpress/autop';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

editor does not have a dependency defined for wp-autop, so its existence is purely incidental and this could be prone to future breakage.

* Test that shortcode blocks get the same HTML as shortcodes in Classic content.
*/
function test_the_content() {
add_shortcode( 'someshortcode', array( $this, 'handle_shortcode' ) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not as familiar with PHP testing, but should we be tearing down anything we create, i.e. a complementing remove_shortcode?

*/

/**
* Performs wpautop() on the shortcode block content.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be improved to explain why we're autop-ing, not simply expressing that we are, which is already evident in the code itself.

Alternatively, it could be considered an implementation detail that the block's render applies autop, not necessarily appropriate for the callback function. In other words, this function should be documented along lines of "Renders the shortcode", and the implementation detail explained by an inline code comment.

@aduth
Copy link
Member

aduth commented Jul 30, 2018

None of my comments are blocking for Try Callout, but could be considered for further improvement.

@aduth
Copy link
Member

aduth commented Jul 30, 2018

Also noting that the getEditedPostContent selector is not the only place we serialize blocks (search), but as implemented here is the only place where we adopt this behavior of applying autop to the freeform-only content. It's not clear to me whether this is a "good thing", but the inconsistency seems prone to future unintended consequences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Paste [Feature] Shortcodes Related to shortcode functionality [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1.9.1: Gutenberg breaks "classic" posts w/ shortcodes by carelessly wrapping shortcodes into <p> tags
3 participants