Remove Link Manager from core

[nacin]

The proposed 3.5 scope includes removing the Link Manager from core. This is not as straightforward as it sounds, and comes with a number of considerations. Here are two ways for us to "remove" it:

Hide the menu. For new installs, stop inserting default links and hide the menu, only. (Also the default widget.) For old installs, remove default links if those are the only ones they have. Hide the menu if they have no links. In this situation, we could make it so the menu does remain accessible, which means they could go in, insert a link, and suddenly the feature would come back to life.

Pros: Focuses on our main goal here, which is UI bloat.

Cons: Ignores code bloat and required future maintenance of essentially dead code.

Move everything to a plugin. For new installs, everything is gone. No more table, no more API. For old installs, on upgrade, install a compatibility plugin that contains the API, if they have any links. Remove the table on upgrade if they don't have any links beyond the default one.

Pros: Handles both UI and code bloat in one big swing.

Cons: Backwards compatibility nightmare. Functions are removed rather than deprecated. Even just truncating these functions and conditionally defining them could result in fatal errors from plugins expecting different return values. Sites not relying on the automatic upgrade could break.

Clearly, we need some kind of middle-ground approach. We should probably do an accounting of all code (off the top of my head, it'd be bookmark.php, bookmark-template.php, link-add.php, link-edit.php, link-manager.php, edit-link-form.php, admin/includes/bookmark.php; code in the schema; code in the taxonomy API). Then, figure out what our goals are for 3.5.

[Viper007Bond]

Very interested in this. :)

[Viper007Bond]

I like the idea of removing all of the code from core and replacing the functionality with a plugin that uses a custom post type to recreate the functionality. It wouldn't be too hard to migrate the data over either.

The hardest part as mentioned would be backwards compatibility with code that is trying to use the bookmarks/links functions. I wonder how hard it'd be to port all existing functions into the plugin but have them use the new API. For example the existing get_bookmark() function could be added to the plugin and operate similarly without using any of the existing code.

Food for thought.

I'll see if I can go through and make a listing of all the places we have bookmarks/links code, unless someone beats me to it.

[jkudish]

Replying to Viper007Bond:

I like the idea of removing all of the code from core and replacing the functionality with a plugin that uses a custom post type to recreate the functionality. It wouldn't be too hard to migrate the data over either.

+1

[nacin]

Replying to Viper007Bond:

I like the idea of removing all of the code from core and replacing the functionality with a plugin that uses a custom post type to recreate the functionality. It wouldn't be too hard to migrate the data over either.

I'm not sure that's the best approach. Most of the linking functionality and data isn't very useful, and if done right, could potentially become a large control for a single widget. But creating a plugin and porting over data is one possibility.

I think we would have an easier time with backwards compatibility concerns if we stuck to the existing storage schema (the extra table) and the same API. Otherwise, deprecation is going to be a pain, that migration could potentially be really costly on sites, and plugins could break.

[jkudish]

Replying to nacin:

Replying to Viper007Bond:

I like the idea of removing all of the code from core and replacing the functionality with a plugin that uses a custom post type to recreate the functionality. It wouldn't be too hard to migrate the data over either.

I'm not sure that's the best approach. Most of the linking functionality and data isn't very useful, and if done right, could potentially become a large control for a single widget. But creating a plugin and porting over data is one possibility.

I think we would have an easier time with backwards compatibility concerns if we stuck to the existing storage schema (the extra table) and the same API. Otherwise, deprecation is going to be a pain, that migration could potentially be really costly on sites, and plugins could break.

I think that if we keep the current schema and functions, we're basically stuck having to support old code/architecture for a long time, it just moves to a plugin instead of being in core. By migrating over to CPTs, we're moving things forward, in a way that other developers can then better extend the link functionality and make it useful via their own plugins. As Viper007Bond said, it shouldn't be that complicated to migrate the data and the benefits should be worth it, IMO.

[bpetty]

It's probably worth mentioning that if this is broken out into a new plugin and it's decided to offer an automated migration in the regular WP update (in the case where links were actually used), then this means that the plugin will *need* to be included with WP itself since some installations won't be able to automatically download and install the plugin from the directory.

If it's not, it could end up adding another step to the update where users will be required to manually install the plugin during the WP update depending on the installation type and configuration.

[ryan]

To support multisite where schema rollouts can take days you need code that can read both the old and new schema and upgrade on the fly (but not during a front page visit).

Changing the schema seems pointless busy work to me. Lose the current UI, that's what we're really after. Retain the schema. Deprecate all bookmark functions and make them pluggable. Create a plugin that replaces the UI as phase 1. Phase 2 can be creating replacements for the pluggable functions that can handle on the fly migration from links table to CPT. Phase 3 can be killing the core functions. Personally, I wouldn't bother with anything but phase 1.

[Viper007Bond]

Fair enough. Seems like basically a copy/paste job into a plugin then.

[azaozz]

+1 to Ryan's approach. No need to drop tables, only stop creating the table on new installs and let the plugin handle the rest as needed.

[greenshady]

Replying to ryan:

To support multisite where schema rollouts can take days you need code that can read both the old and new schema and upgrade on the fly (but not during a front page visit).

Changing the schema seems pointless busy work to me. Lose the current UI, that's what we're really after. Retain the schema. Deprecate all bookmark functions and make them pluggable. Create a plugin that replaces the UI as phase 1. Phase 2 can be creating replacements for the pluggable functions that can handle on the fly migration from links table to CPT. Phase 3 can be killing the core functions. Personally, I wouldn't bother with anything but phase 1.

+1

[jackdewey]

Adding my vote to moving the code to a plugin. As someone who authors a plugin based on links (Link Library) that has a fair amount of users, I think that it makes sense to keep a "standard" data structure for links and functions to access that data. With no guidance, many link-related plugins would end up creating their own CPTs and that would quickly become a mess.

[thee17]

For what I have used links for in the past, was initially to do custom menus, now I use the menus function. The second thing I used them for was to put a list of links in a widget. I now use menus for it now too. The only missing piece is to have images for the links if i use menu.

I'm thinking that if we used Vipers approach that we could reuse all the existing Menu code and functionality for links as well, as a more ideal interface.

[thee17]

I have looked up a lot of where code lives, here is most of what I found.

All of the following files:

wp-includes/bookmark.php
wp-includes/bookmark-template.php
wp-admin/link-add.php
wp-admin/link-manager.php
wp-admin/link-parse-opml.php
wp-admin/link.php
wp-admin/includes/bookmark.php

wp-includes/default-widgets.php

class WP_Widget_Links extends WP_Widget {

wp-includes/depreciated.php

function get_linksbyname
function wp_get_linksbyname
function get_linkobjectsbyname
function get_linkobjects
function get_linksbyname_withrating
function get_links_withrating
function wp_get_links
function get_links
function get_links_list
function links_popup_script
function get_linkrating
function get_linkcatname
function get_link

wp-includes/taxonomy.php

register_taxonomy( 'link_category',

wp-admin/options-writing.php

Setting for Default Link Category

[mbijon]

Who will own the Links Plugin that results from this ticket?

We don't have a documented concept of community ownership yet ... and one shortcoming of the current .org Plugin library is that it's very hard to change ownership of plugins. When the authors of major plugins move on this hurts the community. I know that it's easy to fork a plugin, but this breaks the one-click update path in WP and creates an extra education hurdle when devs or clients aren't actively involved in the community.

Currently: Matt is the owner of major community-owned plugins, like BuddyPress, ​http://wordpress.org/extend/plugins/bbpress/

Suggestion: The WordPress Foundation should have an account on .org and own these in the repo (Matt & active contributors should also be owners). These plugins should also be listed on the Foundation's project page, ​http://wordpressfoundation.org/projects/.

Why?: I think this would start to clarify where the Foundation contributes and help reassure users that even as Plugins, these major pieces of functionality should have more consistent ownership and support in the future. This may raise the bar for someone to build a commercial plugin that competes, but I think it's a good thing to force high standards of support onto anyone commercializing Plugins like this.

[scribu]

The Link Manager plugin can be owned by the wordpressdotorg user, which also owns the importers and the bundled themes:

​http://profiles.wordpress.org/wordpressdotorg/

[mbijon]

Replying to scribu:

The Link Manager plugin can be owned by the wordpressdotorg user, which also owns the importers and the bundled themes:

​http://profiles.wordpress.org/wordpressdotorg/

That's exactly what I was looking for & I totally agree with that. Apologies for only searching for Foundation-specific users or more-general Plugins.

If this isn't Foundation-worthy, could we note this "level" of ownership in the Make Manual? It's nice to see these things in webtext so Google can find them: ​http://make.wordpress.org/core/handbook/licensing-and-copyright/

[hughwillfayle]

I'd like to help with the plugin. It would be nice, that the removal from the core is done by a core developer ;)

[Hekos]

Finally a good opportunity to show how to make a simple custom post/taxonomy plugin the right way.

[jackdewey]

One thing to consider when migrating links data over to the post table as a CPT is that some link-related plugins rely on the current link IDs. In the case of my plugin, I created a separate custom database table to extend the links data model. This table uses the same link IDs as its primary key and to associate data with the links table.

I suggest storing the old link ID as a post meta data field to facilitate backwards compatibility.

[Viper007Bond]

See nacin's and ryan's comments above. The solution that is likely being used is moving all the code to a plugin and retaining the custom table rather than moving to a custom post type.

I think it'd be a great idea for a separate plugin to implement a link manager via a CPT for users who haven't previously used the link functionality, but for users who are already using the link manager, the plugin that will likely spawn out of this ticket will exist just to continue to provide that functionality to them.

In short, this plugin will likely just be a backwards compatibility plugin to avoid losing functionality rather than to extend and provide new functionality.

[thee17]

List of other Links/Bookmarks trac tickets: #8733, #10581, #11581, #12264, #14020, #18356, #19695, #20130, #20790, #21159

[wonderboymusic]

There is link code everywhere in core, but it really doesn't do too many crazy things. There were a few places I needed to add a filter or action, and there are some really weird back-compat actions that I doubt are ever used, but Links actually work well in a plugin.

My code assumes that WP core creates the table and that WP will alter the table in the future. I also didn't port any of the legacy DB upgrade code for the table.

My code is lacking documentation, but that can come later.

I kept the same menu "slugs" (link-manager.php and link-add.php, etc) for the admin pages so plugins should remain compatible with the admin menu.

[kawauso]

Replying to wonderboymusic:

Is the plugin's bookmark.php intentionally excluded from the patch?

[kawauso]

Also the CSS selector .toplevel_page_link-manager in link-manager.php should be #toplevel_page_link-manager as browsers don't handle a mix of underscores and hyphens in class names properly (#21421). As it stands, all non-core menu items are being affected by this CSS selector.

[wonderboymusic]

reattached with bookmark.php included

[wonderboymusic]

First pass at moving code into a plugin

[Shapeshifter 3]

Good Morning,

I currently use the ​http://wordpress.org/extend/plugins/wp-render-blogroll-links/ and ​http://wordpress.org/extend/plugins/hierarchical-link-categories/ plugins to maintain most of the pages on my website. These plugins use Categories and ID numbers to be successful. The first plugin has had 57,000 downloads and second one 2,700. So I know I'm not the only person using them. I also continually use the Link Manager while maintaining my website.

If the Link Manager is removed; what tool(s) will be dependably, and immediately available, for me to maintain my website?

How long will it take for Link Management plugin developers to catch up with new proposals, and will current Wordpress users (who have sites such as mine) have their sites damaged?

Please accept my apologies IF this is not the correct venue for MY concerns, BUT I wanted to make sure Core Development was aware of potential problems for the user.

[scribu]

will current Wordpress users (who have sites such as mine) have their sites damaged?

No, they will not be "damaged".

The exact solution is still being debated, but the goal is for link manager users to not loose functionality when upgrading to WordPress 3.5.

[wonderboymusic]

FYI - here are all of the files that get touched / zapped:

wp-includes/admin-bar.php
wp-includes/category.php
wp-includes/taxonomy.php
wp-includes/default-widgets.php
wp-includes/bookmark-template.php
wp-includes/bookmark.php
wp-includes/link-template.php
wp-includes/formatting.php
wp-includes/deprecated.php
wp-includes/ms-functions.php
wp-includes/category-template.php
wp-settings.php
wp-admin/users.php
wp-admin/admin-ajax.php
wp-admin/includes/plugin.php
wp-admin/includes/list-table.php
wp-admin/includes/bookmark.php
wp-admin/includes/class-wp-links-list-table.php
wp-admin/includes/class-wp-terms-list-table.php
wp-admin/includes/ajax-actions.php
wp-admin/includes/upgrade.php
wp-admin/includes/admin.php
wp-admin/includes/deprecated.php
wp-admin/includes/meta-boxes.php
wp-admin/includes/update-core.php
wp-admin/includes/template.php
wp-admin/includes/user.php
wp-admin/includes/ms.php
wp-admin/edit-tags.php
wp-admin/admin.php
wp-admin/edit-link-form.php
wp-admin/edit-tag-form.php
wp-admin/network/users.php
wp-admin/menu.php
wp-admin/link-add.php
wp-admin/options.php
wp-admin/link.php
wp-admin/css/colors-fresh.dev.css
wp-admin/css/colors-fresh.css
wp-admin/link-manager.php
wp-admin/link-parse-opml.php
wp-admin/options-writing.php

[nacin]

In [21500]:

Stop adding default links and the 'Blogroll' link category on install. props wonderboymusic. see #21307.

[nacin]

In [21501]:

Hide the link manager from the UI on upgrade, if the site has no links. New DB option, link_manager_enabled.

Enforce this by denying the 'manage_links' capability, which hides the All Links, Add New Link, and Link Categories screens. Hide WP_Widget_Links and the UI for the default_link_category as well.

Convert all references to 'posts and links' when handling reassignment on user deletion to just 'posts'.

see #21307.

[prionkor]

Taking consideration above discussion. Here is some ideas:

1. Removing the link table on Database. And make a plugin that ship with wordpress.
2. When database upgrade all links moves to post table using new CPT via a upgrade script.
3. Moving all bookmarks functions to plugin. The plugin auto activates on install on database upgrade. Those bookmarks function will be needed rewritten so they work with CPT.
4. For new installations we don't include the link plugin/leave it deactivate.

[ryan]

​[UT968]

[markmcwilliams]

Maybe I've missed something, but running Trunk (after upgrading a 3.4 install), and deleting all the links that did come default with WordPress, I still can't get rid of the stupid Links tab from the menu! I wondered if it was because of the default Blogroll Category, but upon trying to delete it (using the Bulk Actions), it doesn't delete? - Not had time to look at the problem. Wrong place to be asking?

[jamescollins]

Looking at [21501], the link manager is disabled by default but during the 3.5 upgrade if there is any link data in the database, then the link manager is permanently enabled.

If you deleted the link data after the upgrade, you'd have to manually change the "link_manager_enabled" wp_option record to "0" to disable the link manager feature.

[scribu]

I would just like to say that just hiding the Link Manager in new installs is the safest, but also the least flexible.

If the code is moved into a plugin, users can stop/start using the Link Manager at their convenience.

[scribu]

We can even avoid any additional checks or flags:

A) New WP instance? No Link Manager.

B) Upgrading WP instance? You get the Link Manager plugin automatically installed and activated, which you can then turn off.

[markmcwilliams]

Replying to jamescollins:

Looking at [21501], the link manager is disabled by default but during the 3.5 upgrade if there is any link data in the database, then the link manager is permanently enabled.

If you deleted the link data after the upgrade, you'd have to manually change the "link_manager_enabled" wp_option record to "0" to disable the link manager feature.

Ah yes, I'm with you now, I should have removed all the Links first.

Got to say, after the above, I agree with what Scribu said. Now fair enough I know how to change things in Databases, but for people who don't, they'd need to stick with things just the way they were. On a plus side though, it's looking good with the reduced Menu! ;)

[nacin]

21307-default_option.diff​ looks good as a way to enable the link manager if there's no link_manager_enabled entry in the DB. This is important for before a DB upgrade has run (as may be the case for multisite networks). I use a similar technique in #19235.

[nacin]

In [21536]:

Disable the Link Manager on any future upgrade if it is still enabled but there are no links. see #21307.

[nacin]

In [21537]:

If the DB upgrade hasn't yet been run, assume the Link Manager is disabled. Important for multisite installs. props ryan. see #21307.

[nacin]

​http://wordpress.org/extend/plugins/link-manager/. At the moment, it simply forces link_manager_enabled on. In the future, this can be where the code in core is ported.

[thee17]

Perhaps an optimum method of migration would be to move all the back-end part to the plugin but leave all the template tags and walker in core as depreciated then in 3.6 move the rest to the plugin. Perhaps even put a banner at the top of admin to prompt installing the plugin if there are links in the database.

[mdgl]

Replying to wonderboymusic:

FYI - here are all of the files that get touched / zapped:

[...]

I know Link Manager isn't quite dead yet, but what about file /wp-links-opml.php? Shouldn't this be on your list for some attention?

[avcascade]

Why does Link Manager need to be removed from core? Why not keep it, but allow it to be disabled? That, to me, is the best solution... though if I had my druthers, I wouldn't mess with Link Manager at all. Don't "fix" what isn't broken.

The Link Manager has been part of WordPress for a long time. It makes blogrolls and link lists easy to manage and it's totally theme-independent.

I appreciate that not everyone uses it. But then, that's true for other functionality within WordPress as well. Many people are using WordPress to build sites that are somewhat static in nature (meaning content doesn't change often). A majority of WP sites out there right now many not have any posts, or at least no other posts besides the default "Hello, world!" Does that mean we should take the blogging aspects of WordPress out of core, and put them into a plugin? No way.

I think it makes sense for tools like importers to be officially-maintained plugins (with the exception of the WordPress importer, which I think could reasonably belong in core). But I don't support making Link Manager into a plugin. Let's keep it in core. We should provide an option to enable or disable it, but let's not scrap it.

[mdgl]

Replying to avcascade:

Why does Link Manager need to be removed from core? Why not keep it, but allow it to be disabled? That, to me, is the best solution... though if I had my druthers, I wouldn't mess with Link Manager at all. Don't "fix" what isn't broken.

I think there are two reasons why Link Manager is being removed from core:

1) The idea of "blogrolls" and lists of links is seen as rather old-fashioned these days, with "search" becoming the dominant way of finding content. Yes, you still see lists of links around these days, but much less frequently as a few years ago.

2) The is a lot of special code within WP just to handle links, because they are stored in the "wp_links" database table rather than "wp_posts" like the rest of the site content. The direction that WP is going as a CMS means that everything is becoming a [custom] post type so that we can share all of the code for managing them. This will make WP smaller, faster (probably), more reliable (hopefully) and easier to maintain.

A plugin could quite easily be created to define a custom post type for "external link" and replicate the old Link Manager functionality using the main body of the WP code.

See also #14339 and #18781.

That said, what WP is really missing as a CMS is the ability to handle "internal" links properly. Presently, the currently assigned permalink is copied every time you make such a link. This means that the links are broken if a post is subsequently renamed/deleted or if the site is rehosted or exported/imported to a different location. A proper CMS would (IMHO) manage these links against the internal database and only expand them when the page is rendered for display (with internal links to "external link" post types being automatically de-referenced). You could do this with a shortcode today but it would not be integrated with the rest of the WP admin tool.

[knutsp]

Replying to avcascade:

Why does Link Manager need to be removed from core?

With navigation menus you have the ability to add custom items. These may be external links. A menu does not need to be part of the theme, it's just saved as a "post type" and the name of the menu is a special taxonomy term. Such menus may be shown in a widget or on pages using a special template. The day menus was introduced to core, the classic link manager got it's death sentence, because core then already has a more modern link managing feature.

If you still prefer the classic link manager there is a plugin​http://wordpress.org/extend/plugins/link-manager/. Install it now to keep link manager when upgrading beyond 3.5. For 3.5, sites that already uses link manager (has custom links) will not loose it, even without this new plugin. The actual removal of link manager from core will happen later, and the complete code included in the plugin.

[SergeyBiryukov]

In 47227:

Import: Remove "Blogroll" import option (for links in OPML format) from the list of popular importer plugins.

Link Manager is disabled for new installations since WordPress 3.5, so core should not encourage importing links.

See ​#meta4706 for the corresponding WordPress.org API change.

Props Ipstenu, hareesh-pillai, DrewAPicture, nacin, karmatosed, dd32, garrett-eclipse.
Fixes #22994. See #21307.