Clean up default.settings.php

You want to remove the *EXTREMELY* *USEFUL* shared tables functionality when the real problem you danced around is that the user profile image should be a field and not something hardcoded in the users table? Really? Can I mark this "Closed (won't fix)"?

Duplicate of #1292470: Convert user pictures to Image Field.

You want to remove a core feature because of complications implementing with specific use cases? Seems kinda cutting your foot off because you can't find a shoe that fits. I've been building sites with table sharing since 2009 on both D6 and D7, I know how it works and the problems involved with it.

• Table prefixing is a somewhat advanced feature that you shouldn't be using if you don't understand the implications. Buyer beware.
• Moving the user images into fields (#1292470: Convert user pictures to Image Field) would finally get rid of that core limitation that multisite systems run into, and then leave room for a contrib module for syncing the user profile images across multiple sites.
• Other shared configuration data? If you're doing a multisite setup with shared users then you should also ensure the same architecture is implemented, e.g. text formats, fields, etc - exportables helps with this. Again, buyer beware.
• The roles gets complicated, but workable. Again, sharing the roles table can work, but as role_permissions is dependent upon the specific modules in use and sharing the system table (a prerequisite for sharing role_permissions to avoid running into #1063204: Adding a new permission causes integrity constraint violation) opens up a huge can of worms.
• Perhaps the documentation should be updated with more detail for specific use cases, or at least a disclaimer of "This has many implications, tread carefully"?

Again, removing this feature from Drupal the wrong way of approaching this problem.

I would agree that we should just remove all of this help text. Sharing tables between installations is an advanced (and mostly unsupported) use-case. It should not be documented in defaults.settings.php.

I agree with both sides here. I've used shared tables on multiple projects (including my own latest site for Webform: http://webform.com), so I would definitely prefer it stay intact. That said, settings.php is a disaster of end-user documentation. Removing the database sharing information gets my full support. Another related issue to cleaning up settings.php is #1055862: Require sites.php to opt-in for multi-site support/functionality, which would nix the first 45 lines of irrelevant documentation (multi-site support) for 95% of sites.

IMO, there's cleaner ways to share user accounts across sites. For instance, http://drupal.org/project/services_sso_client - it will even handle user profile pictures with media_internet.

Sharing a database table between installations seems like you're asking for trouble, because you're essentially joining the sites at the hip. If something happens, then *both* of your sites are completely hosed, whereas with a more decoupled approach, that might not be the case. I would much rather see the shared table functionality totally removed, but I can live with deprecating it. I guess.

How about rewording the example to focus on loading additional data from other sources, e.g. for use with entity API? So, rather than focusing on shared user data it could say:

 * @code
 *   'prefix' => array(
 *     // Load all Drupal tables from the normal database.
 *     'default'   => '',
 *     // Load this data from the legacy database.
 *     'hammers'   => 'legacy.',
 *     'spanners'  => 'legacy.',
 *   ),
 * @endcode

Stop promoting is ok. But not removing is no way. I know too much sites with shared tables so loosing this functionality will cause a this sites to move another CMS

@sun: How about providing a link to a docs page on d.o for full documentation on how to configure it?

I agree this shouldn't be removed it is a very very useful tool in a dev environment where the size of the db makes it impossible for each dev to have there own copy of it - but not making it common knowledge works in my book. (and Drupal has lots of those undocumented settings!)

I won't vote for removing the shared tables. this is a killer feature and removing this will kill many usage scenarions. User's picture can easily be shared by overriding the user_picture theme. see http://www.drupalfx.com/content/sharing-user-picture-across-multiple-dru...

i agree with #10 and #14.
either reword it, or place a link to docs

"For advanced mult-site functionality, please read the article at http:/xxxxxxxxxx"

Proposed patch looks fine to me. I don't think we need to discuss table loading from an external DB either. Thats what the array of database connections is for (usually).

Despite #1055862: Require sites.php to opt-in for multi-site support/functionality is in, we still carry the multisite baggage in defaults.settings.php

6: drupal8.settings-prefixes.6.patch queued for re-testing.

It looks like that was overtaken by [#551549], and further work is being done in #3106531: Notify in Status Report that per-table database prefixes are no longer supported, and will throw errors in Drupal 10.0. Closing this a duplicate.

If that is incorrect, set the status to Active and explain what needs to be done here. Thx