Remove Link/Bookmark API form Core: Phase 2

[desrosj]

In WordPress 3.5, the Link Manager was disabled in Core by default in new installs, and hidden entirely when no links were present on a site updating (see #21307).

The intention was to return to this later and remove the Bookmark/Links API from Core entirely. However, no one returned to that second phase. This ticket is to explore removing this long hidden API from Core.

[desrosj]

Here is some fact finding and rough back of napkin thoughts in no particular order:

• It's been 10+ years now since #21307.
• There are just under 50,000 sites with the ​Links Manager plugin active.
• Moving all related code into the plugin and releasing an update seems like an easy way to somewhat seamlessly make these changes, given the site is using the plugin to re-enable the feature (the plugin is currently a 1 line add_filter()).
• Sites have had 10 years to activate this plugin if they truly want this functionality. It's safe to say the overwhelming majority of sites that want this feature have this plugin active.
• Only ​1 theme and ​50 plugins have the pre_option_link_manager_enabled filter. Only 3 have 10k active installs (Link Manager is first with ~50k).
• Some searches of the plugin directory show that calling the related functions in the wild is not 0, but also not significant (lots of these results are either false positives, or custom implementations):
  • get_bookmark(): ​67 plugins, 107 matches, 5 over 50k installs.
  • get_bookmarks(): ​176 plugins, 402 instances, 4 over 50k installs.
  • Loading wp-admin/includes/bookmark.php directly: ​87 plugins, 488 instances, 2 over 50k installs.

It seems reasonable to:

• Move all related functionality into a new release of the Link Manager plugin defensively with the use of (function|class)_exists() checks.
• Add a notice within the dashboard for users with the activate_plugins capability when the Link API appears to be active and links exist that they should update the plugin.
• Potentially add _deprecated_function() notices to the related functions when the Link Manager is not active and at the correct version recommending the user installs or updates the plugin.
• Publish developer notes and an awareness campaign to make folks aware this will happen.
• Allow 1 full major release to pass before removing all related code from Core.
• Remove the functions from Core in a following release.

[desrosj]

Also, this should be accompanied by a proposal posted to Making WordPress Core, which I intend to draft in the coming weeks.

[johnbillion]

+1 on all the points in your proposal.

[desrosj]

I'm moving this to 6.1. I'd like to get this done sooner rather than later to avoid what happened previously.

[jrf]

Sites have had 10 years to activate this plugin if they truly want this functionality. It's safe to say the overwhelming majority of sites that want this feature have this plugin active.

To be honest, it's the first I've ever heard of the plugin and for "old" sites which were using the functionality when the API was deprecated, the option was turned back on automatically, so they never had the need to install the plugin.

I don't remember ever seeing a notice about turning on the plugin in the dashboard either, so I suspect there are a lot more sites out there which still use the API and have no clue that they were expected to turn on a plugin.

As site-owners often skip a number of WP releases when updating, I think only allowing one major with the dashboard notice is cutting things a little too fine.

That is, of course, unless the dashboard notification telling people to turn on the plugin is backported all the way back to WP 3.7.

[desrosj]

Replying to jrf:

I don't remember ever seeing a notice about turning on the plugin in the dashboard either, so I suspect there are a lot more sites out there which still use the API and have no clue that they were expected to turn on a plugin.

As site-owners often skip a number of WP releases when updating, I think only allowing one major with the dashboard notice is cutting things a little too fine.

That is, of course, unless the dashboard notification telling people to turn on the plugin is backported all the way back to WP 3.7.

I was thinking of going the opposite way. Instead of backporting the notice, the first major release after moving the necessary code to the plugin would include an admin notice that displays when sites appear to be using the API without the plugin instructing them to install the plugin because the API will be removed in a future release. Paired with __deprecated_function() notices, this would hopefully be enough feedback/heads up.

Totally open to waiting more than 1 release if that's the consensus. But I think the approach I described above could allow for 1 or 2 major releases.

Time is running out on 6.1, though, so I'm going to focus on this next release.

[mukesh27]

This ticket was discussed in the recent bug scrub.

Ticket need feedback from the dev so added the workflow keyword.

Props to @costdev

[desrosj]

I haven't been able to give this the attention it needs so far this cycle. Going to punt to Future Release until some progress can be made.

[aristath]

+1 from me.
WP includes a lot of functionality that hasn't been used in many years, and we should be doing some house cleaning.
We should find a viable strategy to remove code like this... Deprecating functions and adding an admin notice sounds reasonable to me

[jrf]

Just a heads-up: I just wanted to try and install the plugin on a site which is still using the Links module, but as the plugin hasn't been updated in 11 (!!!) years, it will not show up when a user searches for it from the WP admin panel.

Of course, I can download the plugin and then install it via an upload or via FTP, but that's besides the point.

What my point really is, is that the plugin hasn't been updated in 11 year.

This raises the following questions:

1. Will the plugin as-is still work with WP 6.2+ ?
2. Will the plugin as-is still work with more recent PHP versions ? (think: PHP 5.5 and higher as PHP 5.5 wasn't released yet 11 years ago...)

Additionally, I worry that an official recommendation to install a plugin which hasn't had an update in 11 years, would undermine all efforts which try to teach admins to look critically whether plugins are still maintained etc to prevent security issues.

I believe that at the very least we should make sure the plugin gets a thorough once over for WP and PHP compatibility issues and a new point release, which will allow end-user admins to install the plugin from the comfort of the admin dashboard.

I'd also recommend that the plugin be set up with a repo on GitHub to allow for future maintenance of it in a more accessible way.

[jrf]

Ouch.. also just realised that the officially available version is 0.1-beta which also doesn't instill much confidence...

[jrf]

Never mind... I just realize I overlooked the following line:

the plugin is currently a 1 line add_filter()

In other words, the plugin needs to be build properly before any other action can be taken.