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

Editor: offer the option to convert to HTML on invalid blocks #2807

Merged
merged 1 commit into from
Sep 28, 2017

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Sep 27, 2017

This PR adds a way to convert to a simple HTML block on invalid blocks.
This also fixes the invalid warning buttons (it was not possible for me to click the buttons)

This will help move forward with #2794

Screenshots

screen shot 2017-09-27 at 10 10 22

Testing instructions

  • Edit a block in the text mode and make it invalid
  • Get back to the visual mode
  • Click the "convert to HTML"
  • The broken HTML should be kept and the block converted to an HTML block

@youknowriad youknowriad added [Type] Bug An existing feature does not function as intended [Type] Enhancement A suggestion for improvement. labels Sep 27, 2017
@youknowriad youknowriad self-assigned this Sep 27, 2017
@codecov
Copy link

codecov bot commented Sep 27, 2017

Codecov Report

Merging #2807 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #2807      +/-   ##
=========================================
- Coverage   33.81%   33.8%   -0.02%     
=========================================
  Files         190     190              
  Lines        5678    5680       +2     
  Branches      992     992              
=========================================
  Hits         1920    1920              
- Misses       3181    3183       +2     
  Partials      577     577
Impacted Files Coverage Δ
...ditor/modes/visual-editor/invalid-block-warning.js 0% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5a949b7...765428a. Read the comment docs.

@@ -59,7 +59,6 @@
&.has-warning .editor-visual-editor__block-edit {
position: relative;
min-height: 250px;
pointer-events: none;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had to remove this to fix clicking on the buttons. Any reason for this @aduth?

Copy link
Member

Choose a reason for hiding this comment

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

I think the original reason was to prevent people from interacting with the preview behind the overlay.

Copy link
Member

Choose a reason for hiding this comment

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

This regressed in #2618 with moving the warning into the invalid block.

https://github.com/WordPress/gutenberg/pull/2618/files#diff-5cb891cd3125ad3b221777433a61a524

The style should only apply to the preview, not the warning.

Copy link
Member

Choose a reason for hiding this comment

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

This change can be omitted during rebase given #2811.

@@ -24,17 +24,20 @@ import {
*/
import { replaceBlock } from '../../actions';

function InvalidBlockWarning( { ignoreInvalid, switchToDefaultType } ) {
function InvalidBlockWarning( { ignoreInvalid, switchToBlockType } ) {
const htmlBlockName = 'core/html'; // hard-coded by maybe replace by an API similar to getUnknownTypeHandlerName
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we add another getHtmlBlockName API? or maybe we don't mind hardcoding this special case

Copy link
Member

Choose a reason for hiding this comment

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

I don't think I mind doing core/html.

Copy link
Member

Choose a reason for hiding this comment

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

Could we remove the comment or convert it to having a TODO prefix with whatever we decide here? I would probably be fine with explicitly setting core/html as well, particularly because we're still testing that the desired block type is registered before presenting it as an option.

@jasmussen
Copy link
Contributor

Works stellarly 👍 👍

I think @mtias had some thoughts on how this dialog could be slightly redesigned. In such a redesign it would be good to explore making those buttons smaller. Perhaps "Convert" becomes a dropdown or something.

@mtias
Copy link
Member

mtias commented Sep 27, 2017

Yes, I was thinking we could move the dialog/warning to the top of the block (where the toolbar lives) instead of over the block. That way you could see the actual content better to make a more informed decision. And it might allow us to show you a before/after too in the future.

@mtias
Copy link
Member

mtias commented Sep 27, 2017

One suggestion for the button label: "Edit as HTML block".

isLarge
>
{
sprintf( __( 'Convert to %s' ), htmlBlockType.title )
Copy link
Member

Choose a reason for hiding this comment

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

We might want to check the output of npm run gettext-strings to see if this is treated as a separate string from the one above, or if we need to explicitly copy the translators: comment here to ensure that they're merged.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The comment was being removed (probably it takes the last translation into account), so I just added the comment on both. I don't know if it's worth an issue or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Update: I ended up dropping the duplicated translation. I updated the text with Matìas's suggestion.

Copy link
Member

Choose a reason for hiding this comment

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

I don't know if it's worth an issue or not?

I'm not sure what the expected behavior is, honestly. I think it may be that duplicating is expected, though perhaps if duplication doesn't occur at least including both (not just latest). For core documentation of actions, there's "hints" which allow developers to avoid the duplication, but I don't believe this exists for i18n:

/** This action is documented in wp-admin/admin.php */

@@ -24,17 +24,20 @@ import {
*/
import { replaceBlock } from '../../actions';

function InvalidBlockWarning( { ignoreInvalid, switchToDefaultType } ) {
function InvalidBlockWarning( { ignoreInvalid, switchToBlockType } ) {
const htmlBlockName = 'core/html'; // hard-coded by maybe replace by an API similar to getUnknownTypeHandlerName
Copy link
Member

Choose a reason for hiding this comment

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

Could we remove the comment or convert it to having a TODO prefix with whatever we decide here? I would probably be fine with explicitly setting core/html as well, particularly because we're still testing that the desired block type is registered before presenting it as an option.

@@ -59,7 +59,6 @@
&.has-warning .editor-visual-editor__block-edit {
position: relative;
min-height: 250px;
pointer-events: none;
Copy link
Member

Choose a reason for hiding this comment

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

This change can be omitted during rebase given #2811.

@youknowriad youknowriad merged commit eb5f014 into master Sep 28, 2017
@youknowriad youknowriad deleted the update/invalid-block-warning branch September 28, 2017 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug An existing feature does not function as intended [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants