search

Elgg / Elgg

A social networking engine in PHP/MySQL
https://elgg.org
Other
1.64k stars 666 forks source link

Decide either to remove or fully support multisite #7372

Closed juho-jaakkola closed 7 years ago

juho-jaakkola commented 10 years ago

Elgg has never officially had a full multisite support. There are however both core features and open issues about it.

Let's decide either to:

Neither necessarily needs to happen anytime soon, but it would be nice to have a clear direction.

jeabakker commented 10 years ago

cc: @jdalsem

jdalsem commented 10 years ago

Maybe we first should decide what Multisite means:

  1. Separate installs using the same DB?
  2. 1 install using 1 DB but selecting correct site based on url?

Do the sites share anything (functional) between the sites (other then db and software)

beck24 commented 10 years ago

I've never attempted a multisite with Elgg, though I did with Drupal a long time ago. With Drupal it was a fairly easy process - plugins in the default plugin directory were available to all sites, but a namespaced directory could also hold plugins specific to that site. Core codebase and database was shared, so option 2 in @jdalsem 's question above. Sites did not share anything functional other than shared codebase/database/server resources

Pros - easy to keep core updated for many sites at once, easy to keep shared plugins updated for many sites at once Cons - needed to test all sites plugins for compatibility before upgrading

This was before I started using git so much, now upgrading is one-line command so the benefit of a multisite isn't as enticing to me. Do we have any idea of how useful or in demand multisite is? I haven't heard much in the way of requests for support for it. I think I would lean towards dropping it without further info, but I could be convinced otherwise.

hypeJunction commented 10 years ago

I understand multisite as option 2 listed by @jdalsem I see several use cases:

  1. Eliminate the need for web services between sister sites. One of the projects we have worked was spread across two domains, one with walled garden paid access, second as a public directory. The public directory had to rely on webservices to pull data from the members-only site. With multisite, we could have used just one install with one database, and used regular ege* with site_guid.
  2. Context-based content distribution (channels) Let's say we have a geographically driven content distribution service, where content outside of the specific area is irrelevant to other users. Multisite would allow us to deliver content to users that are based or subscribed to certain sites (channels). I think that's what Minds does heavily.
beck24 commented 10 years ago

Eliminate the need for web services between sister sites I forgot about that, that would have been much easier

lianglee commented 10 years ago

+1

ewinslow commented 9 years ago

OK, I'll throw in my -1. Reason being that I want to free us up to work on more common use cases without the complexity of multi site.

But then I understand that some of us (ColdTrick) are already heavily invested in multi site, so maybe that's a moot point...

rhisss commented 9 years ago

Wordpress has Multisite - and it is very widely used. This enables registered users on my site to each have his or her own blog complete with its own theme. This means a service like blogger.com or wordpress.com can be done by a single installation by one web-master (even if a hobby site). This is actually fantastic and one of the top reasons why many users choose Wordpress+Buddypress over Elgg. In Elgg (1.9.x), every user's blog look alike - may be some previous plugin could allow each one user an individual theme but with multisite Wordpress its out-of-the-box. However, its not just limited to themes - the site superadmin can also determine individual resources and plugins for individual users - this means some users can have enabled plugin A,B,C,D while others E,F,G etc. You get the point.

Users in WP+BP can have their own sites like userA.domain.com or userB.domain.com if multisite is installed with subdomain support.

ewinslow commented 9 years ago

Do you have a reference for "one of the top reasons people choose buddypress over Elgg?" What makes you say that?

ewinslow commented 9 years ago

I see the potential features. But I see no acknowledgement or assessment of costs. I'm not comfortable moving forward without a thorough examination of both and I think it should be up to those who want this feature officially supported to do the research on costs.

rhisss commented 9 years ago

@Ewinslow - Thanks. Its not that essential. I am extensively following social net scripts including the social net flavors of WP and Drupal for the past ten years or more. Numerous forums - numerous discussions - many people want WP integration into Elgg / Phpfox / SocialEngine / Socialstrap for the WP multisite possibilities. References are many - googling Elgg + WP integration will show. When many people do not find this inegration they go to WP+BP instead - many WP, Drupal forum posts support this. Every script has it takers - so has Elgg also. So not to worry.

"no acknowledgement or assessment of costs" - this cannot be done often at the beginning of something. When the very first version of Elgg or Drupal or WP was created "acknowledgement or assessment of costs" was not done. True Elgg has come a long way - but multisite Elgg (as multisite as WP) will be that "first version". Anyway this was just discussion. More important than multiste in WP way, being multsite like FB will be huge gain. That is, if any Elgg site can allow other sites to have Elgg Comments and Elgg Likes. You may ask why to mimic FB - its not mimiking but an important feature that Google Plus, Twitter, FB all have. Ten years ago, open source projects lead in features and creation - now if Elgg can create that Multisite (in a FB way) and may be some more which people will feel "how we have been doing without this feature so long" open source projects can rule again. True scenario has changed in the last decade - money and livelihood is important - and no more projects like Elgg, WP or Drupal will be created again. For sure! FB is such a monopoly that folks aged 18-30ish do FB only rather than trying to create own php scripts or trying out open source projects. Exceptions may be there but the trend has undergone a sea-change. Even "Diaspora" died !

So yes Multisite may be not essential.

jdalsem commented 9 years ago

@ewinslow what costs are you talking about? I think with the current implementation of multisite in Elgg there is not a real benefit/profit in removing things like site guid. I think the effort of fully supporting multisite is less than the effort of removing all multisite related code. We at ColdTrick are willing to add the missing multisite features (over time) as there are just a few, relatively small, fixes to be done to have a "full" multisite support

jdalsem commented 9 years ago

i've added a multisite label to better track multisite related tickets

ewinslow commented 9 years ago

If we've got ColdTrick willing to support it, then I suppose that's fine. I still would like to see some assessment of the costs. The fact that people are coming up blank or can't figure out what I'm talking about worries me.

Does this complicate plugin code in any way (however insignificant it seems to you)? What do plugin debs have to take into account.

What does it mean for an install to be multi site? Are there access control or permissions concerns? How does administration work on multi site?

How does one set up a multi site installation in the first place?

If you ever wanted to move one sure in a multi site to it's own separate installation, is that possible?

Etc...

ewinslow commented 9 years ago

What is the relationship between sites in a single installation? Is it one network with multiple destination points, or multiple separate networks that just happen to be backed by the same database?

Are both configurations supported? Could there be a mix of both in the same database?

When a use registers, do they automatically register for all the sites? Why is the user name unique across sites otherwise?

Do the different sites have to be different domains or can they just be at different base paths?

Why might someone want to use multi site? What would be a bad reason for using multi site?

ewinslow commented 9 years ago

The fact that we have to all the above questions == complexity == cost. Cost for us and for admins and for plugin devs.

I'm glad ColdTrick is offering to support it, but if we think it's just a few issues here and there then we're going to end up committing to more than we can handle.

socialatm commented 9 years ago

What can I do with multisite that I can't do with a single site. Seems like unless they were all small sites performance would suffer rapidly. I'm sure there's more to it that I don't understand though.

jdalsem commented 8 years ago

I think i changed my mind regarding multisite implementation in Elgg. There is no real benefit in a shared database if there is no shared functionality between those sites. The current (partial) implementation of multisite in Elgg is limited to the concept of a Site entity where other Entities can exists on (site_guid in the tabels). There is no other feature in Elgg related to this concept. There is no management tool to create multiple sites. This has to come from other tools / plugins.

There is no documented way on how one should access another site, (other than the default) on an Elgg installation.

Besides the lack of features in core for a multisite implementation (where different sites use the same database), there is also the (performance) downside of having one big database for all data. I currently think it is easier and more future proof to have a seperated database for each website.

The downside of this approach is that you have to put in more effort if the sites share information (like accounts or notifications/messages) or features. But there are multiple solutions for these problems.

There are currently multiple flaws in the Elgg system related to multisite. And my current stance on this subject is to remove multisite completely from the system. I think it would be a good plan to remove this in Elgg 3.0. Does anyone have an opinion on this matter?

Removing it would mean

Benefits of removing multisite

mrclay commented 8 years ago

My favorite option: document prominently that MS isn't supported and site_guid should only be set to 1 and should not be read. Anywhere there's a site_guid argument, add a @link to those docs. Removal would be tons of work, would break a ton of plugins and core stuff (our test coverage is small) for little gain.

mrclay commented 8 years ago

...Though I think we could remove things like WHERE site_guid clauses without changing the API.

jdalsem commented 8 years ago

I am not happy with just documenting that it is not supported. We could leave site_guid function params intact in functions to not break all the code, but we should remove the code that uses the site_guid.

Currently we have traces of some kind of experimental support for multisite in the code... we should get rid of that. I think the amount of work to remove this is not that much.

Removing all traces or just documenting the fact that we are not supporting MultiSite, we at least should be much clearer about it. Therefore we first need to make the decision if we want it out or in. How do we organize a vote for this?

hypeJunction commented 8 years ago

Before voting, I would like to see at least one example of a site that uses multisite.

jdalsem commented 8 years ago

We created a multisite community on www.pleio.nl (still on Elgg 1.8) with over 600 sites.

Elgg core was customized to 'fully' support multisite. They share code, database and dataroot

hypeJunction commented 8 years ago

So, why drop rather than make it full support? On Mar 22, 2016 11:59 AM, "Jeroen Dalsem" notifications@github.com wrote:

We created a multisite community on www.pleio.nl (still on Elgg 1.8) with over 600 sites.

Elgg core was customized to 'fully' support multisite. They share code, database and dataroot

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Elgg/Elgg/issues/7372#issuecomment-199755053

jdalsem commented 8 years ago

As it will take a lot of discussion and work to make it fully supported and i do not think having multisite support in the database is a good approach on multisite installations

jdalsem commented 7 years ago

Multisite is gone