Add target="_blank" attribute to "Powered by Backdrop CMS" link

[findlabnet]

Description of the need
Do not open Backdrop CMS site in same window/tab instead of currently browsing site.

Proposed solution
In the file core/modules/system/system.theme.inc line 13
instead:
return '<span>' . t('Powered by <a href="@poweredby">Backdrop CMS</a>', array('@poweredby' => 'https://backdropcms.org')) . '</span>';
should be:
return '<span>' . t('Powered by <a href="@poweredby" target="_blank">Backdrop CMS</a>', array('@poweredby' => 'https://backdropcms.org')) . '</span>';

(I am searching for issues using the word accessibility to mark as accessibility issues for an upcoming Sprint. It's not clear to me that this one would qualify. Please post a comment if you disagree. - @stpaultim 08/17/2021).

[ghost]

I'm not sure... I prefer that links to URLs not on the current domain (i.e. external links) open in a new tab, but I want this to happen for all links, so I use the External Links module to do this.

I image there are others who don't want this functionality, so I wonder if it's possible for them to disable this should we implement it by default...

I think the current system works well - all links open in the same tab by default. If you don't like this the External Links module can change that.

[findlabnet]

I can not imagine site owner who prefer open external link in the same tab (i.e. instead their site), but maybe it is only my misunderstanding. And I personally prefer to minimize the number of additional modules.

[ghost]

Then the request should be to add External Links functionality to core. I can't imagine people wanting some external links opening in a new tab but not others...

[findlabnet]

My request is related to only one specific case - to help user do not remove at all this non-configurable link to beautiful borg site.

So, more complicated way:

• for this specific link it can be done by adding checkbox to this block settings;
• same approach for menu items, but module "Menu attributes" can do it already, also good candidate to core;
• for nodes content, CKEditor link dialog already have such checkbox;
• any new themeable items - at the developer responsibility.

[klonos]

I can not imagine site owner who prefer open external link in the same tab (i.e. instead their site), but maybe it is only my misunderstanding.

I'm of the same mind. I have actually been adding target="_blank" to any in-code link that points to our docs or api.b.org shown in help text and/or messages. If there was such a functionality built in, and it was the default, it'd be less work for us 😉

[olafgrabienski]

I can not imagine site owner who prefer open external link in the same tab

I can! There are arguments (e.g. accessibility) and examples in the wild (e.g. Google search, Wikipedia) for not forcing external links in new tabs. So, no matter what direction this issue will take, I'd suggest to not implement target="_blank" without an option to disable it.

[ghost]

I'd suggest to not implement target="_blank" without an option to disable it.

Unless I'm mistaken, it's easier to add this (like with the External Links module) than it is to remove it. So I'm still for not having target="_blank" set by default.

[olafgrabienski]

it's easier to add this (...) than it is to remove it

I don't know how easy it is to implement but the following suggestion from @findlabnet sounds reasonable to me:

for this specific link it can be done by adding checkbox to this block settings

[ghost]

@olafgrabienski Yes, in this single case that makes sense, but looking at this issue from a wider perspective you see multiple places in core where there are external links (be it to documentation, etc.). Do we have to add checkboxes/settings to all of them? Or do we just add a single checkbox to core that removes this everywhere?

I'm assuming we're all in agreement that there's no point having some external links open in a new tab and others not...?

[olafgrabienski]

looking at this issue from a wider perspective you see multiple places in core where there are external links (be it to documentation, etc.)

I agree, but in a way the "Powered by Backdrop CMS" is particular (in comparison e.g. to documentation links), as it's shown by default for visitors, i.e. not only when editing or administrating the site.

[findlabnet]

Just for reference: I always use middle (scroll) mouse button to click any link to documentation page or something like, without thinking about existing attributes.
But maybe it is only my personal old experience.

[klonos]

I'm assuming we're all in agreement that there's no point having some external links open in a new tab and others not...?

I personally agree in full with this.

I always use middle (scroll) mouse button to click any link to documentation page or something like, without thinking about existing attributes.

That is very cumbersome on mobile, which relies on touch events. You need to hold-touch, then select "open in new tab" from the menu that pops up.

[findlabnet]

That is very cumbersome on mobile

Using mobile device for work?
No, thanks.
Even laptop is only acceptable as emergency tool for me.

[indigoxela]

While I actually do understand the reason for this feature request, I'm a bit surprised by it.
There are many options to solve the problem:

• Install the extlink module
• or replace the default block-system-powered-by block with something custom
• or override theme_system_powered_by with a custom theme hook (YOURTHEME_system_powered_by)

To my opinion another settings form for just the link target of a single (removable) block is somewhat overdone.
Setting the target to _blank by default for the powered link might make sense, but it seems that other CMS don't do that either.

[klonos]

There are many options to solve the problem

These all require site builders/themers to do additional work (if they are annoyed by that link opening in the same tab) ...if you make people do more work, they will take the easy path ...which in this case is to remove the block altogether ...and we don't want that, since I believe having the link there provides some SEO benefits for b.org.

If we can do the work, so that people using Backdrop do not have to, then we should.

[indigoxela]

If we can do the work, so that people using Backdrop do not have to, then we should.

Good point 😉

So, is there a consensus that we add "target=_blank" by default to that single link?

As @olafgrabienski stated, this link differs a bit, as it's the only one visible to all site visitors. (Opposed to all the documentation links, which are only visible to authenticated/admin users.)

[opi]

Open links in a new window is bad for accessibility ; I'm in favor of a optionnal block setting to implement this (bad) behavior.

See https://www.w3.org/TR/WCAG20-TECHS/G200.html & https://www.w3.org/TR/WCAG20-TECHS/G201.html, and https://accessibility.oit.ncsu.edu/it-accessibility-at-nc-state/developers/accessibility-handbook/mouse-and-keyboard-events/links/links-and-new-windows/