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

Paste: Enable space before heading text ~ handle Hex/# value #69229

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

Takshil-Kunadia
Copy link
Contributor

What?

Closes #69221

This PR updates the Markdown converter by enabling the requireSpaceBeforeHeadingText option in the showdown configuration. This change ensures that headings are only recognized when there is a space between the hash (#) and the heading text.

Why?

Previously, when hex values/hashtags (e.g. #Heading) were pasted, the # were stripped out, leading to issues as described in #69221. By requiring a space after the heading marker, the converter now adheres to standard Markdown practices, reducing rendering inconsistencies.

How?

The solution was implemented by modifying the showdown converter options. Specifically, we set requireSpaceBeforeHeadingText to true. This forces the converter to only treat strings as headings when space between "#" and the title(# Heading) is used. Subsequently, strings representing hex values/hastags remains intact.

Testing Instructions

  1. Open a post or page in Gutenberg.
  2. Test Heading Conversion:
    • Enter a hex value without a space (e.g. #ffffff). It should remain intact ~ #ffffff
    • Enter a heading with a space (e.g. # Heading). It should render as normally.

Screenshots or screencast

Before:-

Screen.Recording.2025-02-18.at.12.48.54.PM.mov

On enabling this:-

If a hex value is pasted(with no space), it retains the #.

1739855513192526.mp4

If a value with a space is pasted, it behaves as expected.

1739855543722253.mp4

@Takshil-Kunadia Takshil-Kunadia force-pushed the feat/enable-hex-value-paste branch from 73d5906 to 5b1c93e Compare February 18, 2025 08:01
@Takshil-Kunadia Takshil-Kunadia marked this pull request as ready for review February 18, 2025 08:38
Copy link

github-actions bot commented Feb 18, 2025

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Takshil-Kunadia <[email protected]>
Co-authored-by: Mayank-Tripathi32 <[email protected]>
Co-authored-by: im3dabasia <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@Takshil-Kunadia
Copy link
Contributor Author

Hi @Mamaduka here's a PR for the issue.

cc: @im3dabasia

@Mayank-Tripathi32
Copy link
Contributor

Not sure if this is intended behaviour but discovered while testing the PR

Screen.Recording.2025-02-18.at.7.26.34.PM.mov

@Takshil-Kunadia
Copy link
Contributor Author

Takshil-Kunadia commented Feb 18, 2025

Thanks! @Mayank-Tripathi32 I was able to reproduce the issue. This occurs when we undo it and paste the value again on the same line. This is a tangential case, as it occurs without this change as well.

I traced this back to the use of __unstableIsFullySelected. Which is causing the mode to change to blocks when pasting on the same line for the second time.

const isFullySelected = __unstableIsFullySelected();

When undoing the paste, the following code triggers a selection reset leading to treating it as a block,

case 'RESET_SELECTION':
const { selectionStart, selectionEnd } = action;
return {
selectionStart,
selectionEnd,
};

Not sure if this means this is expected?!

@Mamaduka Mamaduka added [Type] Bug An existing feature does not function as intended [Feature] Paste labels Feb 19, 2025
@Mayank-Tripathi32
Copy link
Contributor

Thanks! @Mayank-Tripathi32 I was able to reproduce the issue. This occurs when we undo it and paste the value again on the same line. This is a tangential case, as it occurs without this change as well.

Not sure if this means this is expected?!

I don't believe this should be the expected behavior, but someone with more experience may be able to provide more insight!

cc: @WordPress/gutenberg-core

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

Successfully merging this pull request may close these issues.

Hex codes and #Hashtags incorrectly parsed and stripped as Markdown headers
3 participants