#33495 closed enhancement (fixed)
Shortlinks are no longer useful by default
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Permalinks | Keywords: | good-first-bug has-patch |
Focuses: | administration | Cc: |
Description
Shortlinks have a few limited uses, but one of the biggest ones (Twitter character limits) is no longer relevant, as all URLs are wrapped in their own shortener and thus always count as the same number of characters as any other URL.
Given that we are quite opinionated as a project about pretty, meaningful permalinks, it seems odd that we promote ugly shortlinks, and it's not a feature for the majority.
Attachments (3)
Change History (21)
#2
@
9 years ago
It does seem conflicting that short links and pretty URLs should exist side by side. I think taking this button out will make the UI more lean and less confusing for newcomers who might be confused if they're unsure of the function given the similarity with social shorteners.
#3
@
9 years ago
- Milestone changed from Awaiting Review to 4.4
Putting this in 4.4 to force us to think about it.
#5
follow-up:
↓ 6
@
9 years ago
These could maybe done with 2 possible workarounds:
- hide the shortlink button, enable it through the Settings > Permalinks or Settings > Writing
- hide/show the shortlink button through the Screen Options
By doing that, users who really need the shortlink can easily enable it.
What do you think about this solutions?
#6
in reply to:
↑ 5
;
follow-up:
↓ 7
@
9 years ago
Replying to ibenic:
Thanks for the suggestions! My strong preference here, which also aligns with our philosophy of "decisions not options", would be for there to be no core interface for toggling this on and off, and leave it to plugins to enable. What would be smart for core to do is detect if anything has hooked into places that can alter the shortlink and continue to show UI for getting the shortlink if that's the case. We do something along those lines for the welcome panel on the dashboard.
#7
in reply to:
↑ 6
@
9 years ago
Replying to helen:
I agree with what you're saying. The button should be hidden unless a plugin hooks in it's own shortlink logic(like Jetpack does).
#8
@
9 years ago
- Keywords has-patch added; needs-patch removed
I just added a patch that checks if something is adding a filter to either 'pre_get_shortlink' or 'get_shortlink' before showing the button.
#9
@
9 years ago
- Owner set to grvrulz
- Status changed from new to assigned
Setting ownership to mark the good-first-bug
as "claimed".
#11
@
9 years ago
- Keywords needs-patch added; has-patch dev-feedback removed
Hi @grvrulz, thanks for jumping in. A few things here:
- Your patch fatals due to a missing parenthesis, please test your patches.
- As it stands, your patch attempts to hide the entire permalink area, not just the button when editing a post.
- Some people may still want the default shortlinks, which means they need a method to turn it on (via filter).
- There are two functions hooked in by default -
wp_shortlink_header()
for a PHP header andwp_shortlink_wp_head()
for an HTML link element. What happens if these are removed by default?
#12
@
9 years ago
Hi @helen,
My bad, I uploaded the wrong patch. I have uploaded the correct patch now(tested on trunk). It only hides the 'Get Shortlink' button.
If someone wants to turn this on, they can use a filter like this
add_filter( 'get_shortlink', 'my_enable_shortlink' ); function my_enable_shortlink() { return true; }
I'm still looking over the stuff in your last point.
Thanks
#13
@
9 years ago
Hi @helen,
I looked over wp_shortlink_header()
and wp_shortlink_wp_head()
, and I think these can also be disabled in absence of a shortlink enabler. What are your thoughts on this?
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
#15
@
9 years ago
- Keywords has-patch added; needs-patch removed
After some discussion in Slack, we're going to leave the headers for now.
#17
follow-up:
↓ 18
@
9 years ago
@grvrulz I went ahead and massaged the patch a bit for commit so we don't lose momentum here, and I thought I'd leave you some notes about it here. Essentially, the has_filter()
checks just needed to wrap around the existing shortlink bits - no need to get the shortlink if we're not going to use it, and the HTML that was being appended will always be appended together.
Technical thoughts:
The best approach to this is probably one of "hiding" as opposed to "removing". If we can be smart about detecting any changes to the shortlink and continuing to show the button/link in that case, that would be a good and user-friendly thing to do. People do use shortlinks for analytics and that type of thing still.