Skip to content

[Enhancement] Introduce Link Target in Image Block#9520

Merged
talldan merged 1 commit into
WordPress:masterfrom
nfmohit:update/image-block/9458
Oct 24, 2018
Merged

[Enhancement] Introduce Link Target in Image Block#9520
talldan merged 1 commit into
WordPress:masterfrom
nfmohit:update/image-block/9458

Conversation

@nfmohit

@nfmohit nfmohit commented Aug 31, 2018

Copy link
Copy Markdown
Member

Description

This PR closes #9458 which requests the addition of an option to open the image in a new tab under "Link Options" in the Image block.

How has this been tested?

This PR has been tested by going through the following steps:

  1. Started a new post using the Gutenberg editor.
  2. Added the "Image" block.
  3. Made sure the "Open in New Window" option shows up under "Link Options".
  4. Made sure the link target functionality works in the front-end.

Screenshots

pull-9458-min
(Apologies about the crappy screencast, had to shrink the browser down and compress for Github to accept it).

Types of changes

This PR introduces a new boolean attribute named linkTarget, which if true, applies the _blank target attribute. It adds ToggleControl in the InspectorControls, which toggles the attribute onChange.

Checklist:

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

@ajitbohra ajitbohra added [Type] Enhancement A suggestion for improvement. [Feature] Blocks Overall functionality of blocks Needs Design Feedback Needs general design feedback. labels Aug 31, 2018
@ayersc3

ayersc3 commented Sep 13, 2018

Copy link
Copy Markdown

I've seen this option for opening links in new windows for some, but not all. I've noticed it available when linking the image to the media file. But, not available when linking to a custom URL. ...Thoughts?

@nfmohit

nfmohit commented Sep 14, 2018

Copy link
Copy Markdown
Member Author

Hey @ayersc3 !

Just gave this PR another quick test and the option is showing up for me for custom URLs too. Here's a screencast:
pull-9520

If you're testing it, could you let me know some details about your environment e.g. browser, OS, console errors (if any) and such?

Thank you ❤️

@cristian-raiber

Copy link
Copy Markdown
Contributor

Tested the code and works fine. Just a suggestion: you can replace the onChange attribute of ToggleControl to:

onChange={ () => setAttributes( {  linkTarget: ! linkTarget } ) }

This way you no longer need the toggleAttribute function.

@ayersc3

ayersc3 commented Sep 17, 2018

Copy link
Copy Markdown

Sorry for the delayed response, and thanks for your responses!

@nfmohit-wpmudev :
WP v4.9.8
Browser: Google Chrome (v68.0.3440.106)
OS: Mac (v10.13.6)
Guttenberg: v3.7 (As I'm writing this, I upgraded to the v3.8, but still was missing the option to "open in new window")

@Cristian-E
Thanks for the code suggestion. I'll try that today!

screen shot 2018-09-17 at 9 39 45 am

@nfmohit

nfmohit commented Sep 19, 2018

Copy link
Copy Markdown
Member Author

Thank you so much for the tip @Cristian-E ❤️ I've included it in the latest edited commit.

About the issue you are seeing @ayersc3, I'm extremely sorry but I wasn't able to replicate it by testing it in different environments. Just to confirm, may I know how you are testing it? Are you fetching the PR branch or just copying the code? May I know if you are re-building the npm project after the PR is merged locally? Thank you for your help ❤️

@mtias mtias added the [Feature] Media Anything that impacts the experience of managing media label Oct 7, 2018
@chrisvanpatten chrisvanpatten requested review from a team and karmatosed October 16, 2018 13:27
@chrisvanpatten

Copy link
Copy Markdown
Contributor

Could we get a design review on this and potentially land it in 4.1? This and #10128 feel like easy wins for users.

@talldan talldan left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thanks for another awesome contribution @nfmohit-wpmudev 🔥🔥🔥

I've left a couple of review comments.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I wonder if we could source this attribute directly from the markup. The advantage is that the setting is correctly applied if the user pastes some html containing an image wrapped in a link into Gutenberg. It'd looks something like this:

linkTarget: {
	type: 'string',
	source: 'attribute',
	selector: 'figure > a',
	attribute: 'target',
}

the rendered element would become:

{ href ? <a href={ href } target={ linkTarget } rel={ linkTarget === '_blank' ? 'noreferrer noopener' : undefined }>{ image }</a> : image }

and the value we pass into the toggle control would have to be calculated.

@nfmohit nfmohit Oct 18, 2018

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Implemented in this commit. Thank you ❤️

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think we should make the falsey part of the ternary undefined instead of null. I believe there are some cases where null attributes in React get converted to an empty string, which would result in a property being unnecessarily added to the element:
react/react#1448

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Also, would be great to break this lengthy line up 😄

@nfmohit nfmohit Oct 18, 2018

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Implemented in this commit. Thank you ❤️

@nfmohit

nfmohit commented Oct 17, 2018

Copy link
Copy Markdown
Member Author

Implemented. Thank you so much for the review @talldan ❤️ Couldn't make it without your help in DM regarding the toggle value calculation logic ❤️

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Worth considering in core all occurrences of (opens in a new window) have been changed to (opens in a new tab), see https://core.trac.wordpress.org/ticket/43803 which will be released in 5.1 (not 5.0). Even if that string is meant for visually hidden accessible text, for consistency I'd suggest to refer to "tab" and not "window".

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Implemented in this commit. Thank you ❤️

@talldan

talldan commented Oct 18, 2018

Copy link
Copy Markdown
Contributor

@nfmohit-wpmudev This is looking really close. I just spotted one thing that I missed earlier, 'target' will need to be added to this array:
https://github.com/WordPress/gutenberg/blob/aead14ac3fd919a2fdeb510b3d492d368e506f2d/packages/block-library/src/image/index.js#L89

That ensures the attribute is parsed and set correctly. To test it you can try the following steps:

  1. Add an image block and upload an image (or select one from the media library).
  2. Choose an option under 'Link to' and set the link to open in a new tab.
  3. From the block menu, switch to Edit as HTML
  4. Copy the HTML and paste it into a new paragraph
  5. The pasted content should be transformed into a new image block.
  6. Check the sidebar 'Opens in a new tab' setting, it should be correctly enabled to reflect that the pasted html had the target="_blank" attribute.

Without the 'target' value in the array, you'll see that 'Opens In a New Tab' remains off, and when inspecting the HTML, target is stripped off.

@talldan

talldan commented Oct 18, 2018

Copy link
Copy Markdown
Contributor

It might also be good to rebase this against master - there was at least one conflict when I tested (pretty easy to resolve though). Interesting though that it's not showing in the github UI as a conflict. 🤔

@gziolo gziolo added this to the 4.2 - API freeze milestone Oct 18, 2018
@nfmohit

nfmohit commented Oct 18, 2018

Copy link
Copy Markdown
Member Author

Thank you so much for pointing out the array @talldan ❤️ It was completely out of my consideration. I've addressed that and the conflicts with master in the latest edited commit.

@talldan talldan left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is looking good to me now. Thanks for addressing all the changes so quickly, @nfmohit-wpmudev ❤️

We should hold off merging until the 4.1 milestone has been shipped, but once that's done this is good to go.

@youknowriad

Copy link
Copy Markdown
Contributor

I'd appreciate a design validation as well :)

...imageSchema,
a: {
attributes: [ 'href' ],
attributes: [ 'href', 'target' ],

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Does rel need to be here?

@nfmohit nfmohit Oct 19, 2018

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@aduth I'm honestly not completely sure but according to this comment, it seems the rel attribute gets set correctly when the HTML is copied over to a new paragraph element even without rel attribute added to the array. @talldan Any comments here?

@talldan talldan Oct 23, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

At the moment rel is ignored by the parser, butrel="noreferrer noopener" is added to any link with target="_blank" by the save function. I think that's a sensible default. I suppose some users might want a finer level of control over the attribute.

I think this is probably ok as a start, the code doesn't preclude more handling of rel being added later.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It's not clear to me as someone implementing a block with a schema why the parser would disregard rel. I'm left confused why I should or shouldn't include the attribute here.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It doesn't seem to be something mentioned in the handbook (nothing about raw transformations in general, as far as I could see), so potentially a gap in the information we provide.

@karmatosed karmatosed left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I am approving as can see it being useful but have to say that sidebar is getting really packed with options for the image block. I would encouraging future thinking about how we can reduce the options and iterate.

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Oct 23, 2018
@talldan talldan merged commit d4e097c into WordPress:master Oct 24, 2018
antpb pushed a commit to antpb/gutenberg that referenced this pull request Oct 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Feature] Blocks Overall functionality of blocks [Feature] Media Anything that impacts the experience of managing media [Type] Enhancement A suggestion for improvement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Option to open an image in a new window missing from link options