cash wrote on 41371741-10-31

It is built into core and all the plugins. Not easy to pull out and I'd guess that most sites want something like friends.

To pull out right now through a plugin requires the following:

• all friends content pages have to have their sidebar menu item removed
• unregister the friends link in topbar
• remove friend link in user hover menu
• unregister friends widget
• remove friends option from access control

To pull it out of core would require pulling out the above and ripping large chunks out of the core libs/classes.

This seems rather pointless to me. Most of the plugins would still need friends pages (unless they are all put in a friends plugin - shudder) which would create an awful web of dependencies. I think this is a clear case were the majority (assumed by me) should get the solution that matches their requirements. The minority then has to do some work to remove/rename friends. (I say this as someone who does not use "friends" language on our site.)

trac user kevinjardine wrote on 41373124-10-29

I have had clients ask me to remove the friends feature. Given the current core implementation, this is difficult to do.

If Elgg is used in corporate internal sites, then the friends feature may not make any sense. I think that it was a mistake to build it into core.

At some point I would like it to be removed completely from core with perhaps just a few internal hooks that could be used by a variety of different plugins.

Having said that, I don't think that it is urgent. Perhaps something for Elgg 2.0?

cash wrote on 41374079-03-24

Friends is not built into the database schema, but it is built into the access system and the users library (get friends, get friends' objects, add/remove friend menu, etc.). I think that's it. I do not think it is difficult to turn off the public interface to the core friends implementation through a plugin. (It's more work to turn off the friends code baked into every major plugin.)

Friends access could be implemented through the magic access id of -2 like it is now or through an access collection. Its implementation details should not affect whether it belongs in core or not.

I'll repeat my arguments:

• I think most sites want some kind of user to user relationship (whether friends or follower model)
• Pulling it out to a plugin means creating a lot of dependencies between plugins. These dependencies create an uglier end product than the current method for turning off friends functionality.

I'd rather that we look into making the friends implementation more flexible (can select between followers and friends) and making it easier to turn off than ripping it out of core.

ewinslow wrote on 41374776-08-19

For the sake of equivalent documentation: here's what a friends plugin would look like if we took it out of core:

• Register friends link in topbar
• Register friends, add friend, remove friend links in user hover menu
• register friends widget
• Add friends option to access control

All of the above seem very reasonable things to pull into a plugin. That leaves content plugins. Those that want to support friends would just have to be edited to do:

if (friends is enabled) { 
    add the relevant menu item(s) 
}

This feels like a reasonable level of dependency, if you ask me. I definitely agree that having a friends plugin "know" about all the content plugins would be the wrong way to go.

cash wrote on 41375846-04-15

Truly removing friends from core also means:

• ripping out all the get friends entity functions
• removing the Friendable interface and all implementations
• removing the friend notification code from relationships
• removing the auto friending on registration from invitation
• removing the code in page_owner that sets the page owner for friends URLs
• removing the friends picker from core
• removing support for returning friends from user picker
• removing all the functions that support friending
• rewriting how access collections are created
• removing the friends filter for activity

For core plugins, it means

• reimplementing group invitations
• ripping out friends notifications (or add a few is plugin enabled calls)
• reimplementing how messages plugin suggests people to send messages to
• adding is enabled to the members plugin for the popular list
• updating widgets that allow you to select friends content

The list for 3rd party plugins is going to be much longer and much uglier.

It is not as easy as it initially seems.

trac user kevinjardine wrote on 41375875-06-10

I think that it's OK to leave some of the Friends API in core.

In my view removing the visible Friend features Cash mentions would be a good thing, because Elgg and Elgg plugins should not assume that the Friends feature exists or if it does, behaves in one specific way.

Moving the visible stuff to plugins and rewriting those plugins to not assume that the Friends feature is active would result in a more flexible core Elgg engine more easily usable by a larger number of potential users. (Eg. corporate intranets as I mentioned before).

Everytime someone has to rip out the friends feature for a client they have to implement many of the visible changes Cash mentions anyway. I think that it would be better if it was done once.

brettp wrote on 41376972-09-21

I don't see a point of pulling friends out of core if we're leaving bits of it in. That complicates the implementation and the interface.

Those that want to support friends would just have to be edited to do:

if (friends is enabled) {
add the relevant menu item(s)
}

We strove to remove exactly this in 1.8 plugins.

I don't see the benefits of moving this to a plugin (while keeping parts of it in core) when it can more simply be hidden with an additional plugin. There's no reason that this plugin couldn't be saved or even distributed for reuse among those interested.

trac user kevinjardine wrote on 41377925-03-24

My final points:

a. there are plenty of other bits in the core API that are there but are unused by some Elgg sites (eg. geolocation). So as I've said before, if it is just API, I don't have a problem with it. Visual stuff I do.

b. it seems perverse to me to have to write a plugin that has to do a lot of work to hide bits of the public interface forced on me by core Elgg. Elgg has a plugin architecture for a reason. Ben Werdmuller once said that core Elgg should do nothing. That is what he meant I think - public interface should be supplied by plugins. The friends public interface breaks that rule.

c. as it currently stands, any "hide friends" plugin would have to take every possible plugin with a friends interface into account. This would be a mess. I know it is a mess as I have written stuff like that for clients before. If the Friends functionality was moved to a separate plugin and every plugin using it had the simple

if (friends is enabled)

test, it would make the whole thing infinitely cleaner and the Elgg engine more flexible.

I'm completely with Evan on this and I find the arguments against unconvincing and even puzzling.

Having said that, this is my last contribution to this discussion as I am at risk of repeating myself.

cash wrote on 41921952-07-06

We need to figure out what to do with this ticket. We have 4 options:

1. Pull all friends code out of core making it difficult to get any kind of consistent friends functionality with Elgg
2. Leave it all in as-is and have it be difficult to remove friends functionality for both core and 3rd party plugins
3. Make small changes to make it easier to turn off user-facing friends functionality (something as simple as a $CONFIG->friends = false would go a long way towards that)
4. Pull the user facing functionality out (widget, friending, friend page, friends access, friend notifications) as a plugin

trac user kevinjardine wrote on 41922003-05-17

I would prefer option 4 if possible in analogy to notifications which is done in a similar way. If that turns out to be too much work, option 3 would at least solve the problem some of my clients have been facing in trying to remove the functionality.

I definitely agree that 1 is not a good option. In my view the main problem is that the friends user interface is in core. I don't think that it is a problem that the API is there.

ewinslow wrote on 41922795-05-16

1 is definitely bad. 4 is my preferred route. 3 just seems like a non-standard way of implementing a plugin.

I'm working on a site rigt now where friending/following don't make sense, so this would be great to have.

cash wrote on 41923526-09-07

Evan, I think you're confusing my example of how one might implement 3 with 3 itself. I'm just saying there are probably ways to make it easier to turn off/deregister friends functionality.

ewinslow wrote on 41924745-06-19

That may be so. Either way my order of preferences is the same. Thanks for considering this, Cash!

Milestone changed to Long Term Discussion by cash on 41959370-01-13

ewinslow wrote on 42306037-12-28

Seems pretty clear to me that what was being requested was simply to remove the UI features, not the entire API, so changing the title to reflect that.

Title changed from Pull out friends into a plugin to Pull out friends UI into a plugin by ewinslow on 42306037-12-28

Hi,

I'm facing the same sort of demands from clients, ie completely disabling the friends UI from a site, and using only groups as access & relationship system.
As a plugin developper, i'll go into option 3 (disabling through a plugin), though having the UI in an external plugin (option 4) seems a rather reasonable option (benefits/efforts).

Note 1 : option 3 and 4 could actually be merged into the same plugin => enables or disables specific friends functionnalities.

Note 2 : i think adding a core hook into the get_user_friends function could help A LOT making this all issue easier to solve, by keeping the compatibility with friends functions when friends are "disabled" (hidden ?) (ie settings to replace friends with any other relationship, or return all users, etc.)

Done in #10324