WordPress.org

Make WordPress Core

#21307 closed task (blessed) (fixed)

Remove Link Manager from core

Reported by: nacin Owned by:
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (3)

link-manager.diff (229.5 KB) - added by wonderboymusic 21 months ago.
First pass at moving code into a plugin
21307-ut.diff (541 bytes) - added by ryan 21 months ago.
21307-default_option.diff (533 bytes) - added by ryan 21 months ago.

Download all attachments as: .zip

Change History (77)

comment:1 sillybean22 months ago

  • Cc steph@… added

comment:2 ocean9022 months ago

  • Cc ocean90 added

comment:3 scribu22 months ago

  • Cc scribu added

comment:4 sirzooro22 months ago

  • Cc sirzooro added

comment:5 kovshenin22 months ago

  • Cc kovshenin@… added

comment:6 Viper007Bond22 months ago

  • Cc viper007bond added

Very interested in this. :)

comment:7 Japh22 months ago

  • Cc japh@… added

comment:8 nvwd22 months ago

  • Cc nowell@… added

comment:9 follow-ups: Viper007Bond22 months ago

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.

comment:10 Mamaduka22 months ago

  • Cc georgemamadashvili@… added

comment:11 in reply to: ↑ 9 jkudish22 months ago

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

comment:12 in reply to: ↑ 9 ; follow-up: nacin22 months ago

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.

comment:13 in reply to: ↑ 12 jkudish22 months ago

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.

comment:14 bpetty22 months ago

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.

comment:15 bpetty22 months ago

  • Cc bpetty added

comment:16 follow-up: ryan22 months ago

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.

comment:17 Viper007Bond22 months ago

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

comment:18 azaozz22 months ago

+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.

comment:19 sabreuse22 months ago

  • Cc sabreuse@… added

comment:20 williamsba122 months ago

  • Cc brad@… added

comment:21 toscho21 months ago

  • Cc info@… added

comment:22 ev3rywh3re21 months ago

  • Cc jess@… added

comment:23 boonebgorges21 months ago

  • Cc boonebgorges@… added

comment:24 tollmanz21 months ago

  • Cc zack@… added

comment:25 in reply to: ↑ 16 greenshady21 months ago

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

comment:26 jackdewey21 months ago

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.

comment:27 aaroncampbell21 months ago

  • Cc aaroncampbell added

comment:28 obenland21 months ago

  • Cc konstantin@… added

comment:29 DrewAPicture21 months ago

  • Cc xoodrew@… added

comment:30 kawauso21 months ago

  • Cc kawauso added

comment:31 thee1721 months ago

  • Cc charles@… added

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.

comment:32 thee1721 months ago

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

Version 0, edited 21 months ago by thee17 (next)

comment:33 mbijon21 months ago

  • Cc mike@… added

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.

comment:34 follow-up: scribu21 months ago

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/

Last edited 21 months ago by scribu (previous) (diff)

comment:35 in reply to: ↑ 34 mbijon21 months ago

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/

comment:36 DH-Shredder21 months ago

  • Cc mike.schroder@… added

comment:37 azizur21 months ago

  • Cc azizur added

comment:38 hughwillfayle21 months ago

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

comment:39 Hekos21 months ago

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

comment:40 Hekos21 months ago

  • Cc marko@… added

comment:41 jackdewey21 months ago

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.

comment:42 Viper007Bond21 months ago

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.

comment:43 thee1721 months ago

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

comment:44 follow-up: wonderboymusic21 months ago

  • Keywords has-patch added

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.

comment:45 in reply to: ↑ 44 kawauso21 months ago

Replying to wonderboymusic:

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

comment:46 kawauso21 months ago

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.

Last edited 21 months ago by kawauso (previous) (diff)

comment:47 wonderboymusic21 months ago

reattached with bookmark.php included

wonderboymusic21 months ago

First pass at moving code into a plugin

comment:48 Shapeshifter 321 months ago

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.


comment:49 scribu21 months ago

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.

comment:50 follow-up: wonderboymusic21 months ago

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

comment:51 betzster21 months ago

  • Cc j@… added

comment:52 wycks21 months ago

  • Cc bob.ellison@… added

comment:53 prionkor21 months ago

  • Cc sisir@… added
  • Keywords has-patch removed

comment:54 prionkor21 months ago

  • Keywords has-patch added

comment:55 nacin21 months ago

In [21500]:

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

comment:56 nacin21 months ago

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.

comment:57 prionkor21 months ago

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.

ryan21 months ago

comment:59 markmcwilliams21 months ago

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?

comment:60 follow-up: jamescollins21 months ago

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.

comment:61 scribu21 months ago

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.

comment:62 scribu21 months ago

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.

Last edited 21 months ago by scribu (previous) (diff)

comment:63 in reply to: ↑ 60 markmcwilliams21 months ago

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! ;)

ryan21 months ago

comment:64 nacin21 months ago

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.

comment:65 nacin21 months ago

In [21536]:

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

comment:66 nacin21 months ago

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.

comment:67 nacin21 months ago

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.

comment:68 thee1721 months ago

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.

comment:69 in reply to: ↑ 50 mdgl20 months ago

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?

comment:70 follow-ups: avcascade19 months ago

  • Cc avcascade@… added

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.

comment:71 MikeLittle19 months ago

  • Cc wordpress@… added

comment:72 in reply to: ↑ 70 mdgl19 months ago

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.

comment:73 in reply to: ↑ 70 knutsp19 months ago

  • Cc knut@… added

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 pluginhttp://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.

comment:74 nacin19 months ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.