Closed (fixed)
Project:
Subscriptions
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
28 Dec 2008 at 09:35 UTC
Updated:
2 Feb 2009 at 23:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
dwarner commentedI don't have experience maintaining a module for a multi-site install; just maintaining the install. Since any *tables* needed by the module should get created when the module is installed, the biggest problem is data that might be initialized at that time or later (such as user preferences). In the case we've been working with (issue #281600) it seems that the data isn't there for a user created in another site that shares the user table but not the subscriptions table (since the content tables aren't shared) so it would be best to initialize this data when it's detected that the info is missing.
Comment #2
salvisSo, typically, when you install a contrib module, you keep its tables unshared?
It wouldn't be hard to create {subscriptions_user} records as needed. What bothers me a bit is that we wouldn't be able to delete them when a user gets deleted, if they're spread out over multiple sites...
Do you run cron separately for each multi-site? If yes, you need a {subscriptions_queue} table per multi-site.
If no, you have to share the {subscriptions_queue} table (one cron, one table!). That can only work if you share the {node} table, because {subscriptions_queue} refers to nids.
Are we still in the green?
Comment #3
boris mann commentedModules themselves shouldn't have to do anything other than use the proper Drupal calls for files and databases to "support" multisite. There are specific multi-site modules such as Domain Access that need specific support.
Any sort of funky database sharing / prefixing / etc. is essentially unsupported and will be custom for your particular implementation.
If you want more support, a helper module that interacts with Subscriptions would be the right way to handle it.
Comment #4
Flying Drupalist commentedFor me, only the user_ table is shared. Everything else is separate, cron, modules, etc.
"Do you run cron separately for each multi-site? If yes, you need a {subscriptions_queue} table per multi-site."
Yes, of course. Each site has its own subscriptions tables, and it works dandily.
The only problem I've encountered is {subscriptions_user}. If creation as needed is easy, then please implement it. Drupal AFAIK doesn't reuse uids even after the user has been deleted, so there would be no conflicts with future users. It wouldn't be clean, but the only people affected would be multi-site users, and it's an easy choice between that or having subscriptions not working at all. Maybe do a cleanup of dangling records on cron run?
@Boris
Modules themselves shouldn't have to do anything other than use the proper Drupal calls for files and databases to "support" multisite.
That's not true. Some modules have unnecessarily twisted logic that make them multisite unfriendly. Subscriptions already mostly works. And if creation as needed will easily fix the problem, then why not?
I apologize for my presumption in reopening the issue, but I want to use this module very very much. :)
Comment #5
salvisOk, try this patch and let us know how it works.
Comment #6
Flying Drupalist commentedWorks fine, I don't see the error any more and in testing subscriptions are sent correctly.
Thank you so much!
Comment #7
salvisSo, can you now create a user on one site and have Subscriptions serve the user on other sites, too?
Comment #8
Flying Drupalist commentedYes, I created a new user to test this, and I haven't encountered any problems.
Comment #9
salvisCommitted to both -dev versions.