-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[Enhancement] Introduce Link Target in Image Block #9520
Conversation
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? |
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: 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 ❤️ |
Tested the code and works fine. Just a suggestion: you can replace the onChange={ () => setAttributes( { linkTarget: ! linkTarget } ) } This way you no longer need the |
Sorry for the delayed response, and thanks for your responses! @nfmohit-wpmudev : @Cristian-E |
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 |
Could we get a design review on this and potentially land it in 4.1? This and #10128 feel like easy wins for users. |
There was a problem hiding this comment.
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.
@@ -65,6 +65,9 @@ const blockAttributes = { | |||
type: 'string', | |||
default: 'none', | |||
}, | |||
linkTarget: { | |||
type: 'boolean', |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ❤️
@@ -219,7 +222,7 @@ export const settings = { | |||
|
|||
const figure = ( | |||
<Fragment> | |||
{ href ? <a href={ href }>{ image }</a> : image } | |||
{ href ? <a href={ href } target={ linkTarget ? '_blank' : null } rel={ linkTarget ? 'noreferrer noopener' : null }>{ image }</a> : image } |
There was a problem hiding this comment.
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:
facebook/react#1448
There was a problem hiding this comment.
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 😄
There was a problem hiding this comment.
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 ❤️
Implemented. Thank you so much for the review @talldan ❤️ Couldn't make it without your help in DM regarding the toggle value calculation logic ❤️ |
disabled={ isLinkURLInputDisabled } | ||
/> | ||
<ToggleControl | ||
label={ __( 'Open in New Window' ) } |
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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-wpmudev This is looking really close. I just spotted one thing that I missed earlier, 'target' will need to be added to this array: That ensures the attribute is parsed and set correctly. To test it you can try the following steps:
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. |
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. 🤔 |
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. |
There was a problem hiding this comment.
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.
I'd appreciate a design validation as well :) |
@@ -83,7 +89,7 @@ const schema = { | |||
children: { | |||
...imageSchema, | |||
a: { | |||
attributes: [ 'href' ], | |||
attributes: [ 'href', 'target' ], |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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:
Screenshots
(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 namedlinkTarget
, which iftrue
, applies the_blank
target attribute. It addsToggleControl
in theInspectorControls
, which toggles the attributeonChange
.Checklist: