Spawned from #281600: Database error: user not found in {subscriptions_user} table!.

Q: Is multi site support being considered for this module at all?

A: I don't know what multi-site support would require, so I'm neutral at this point.

Those knowledgeable about multi-site installation, please step forward...

CommentFileSizeAuthor
#5 subscriptions.351753.patch1.57 KBsalvis

Comments

dwarner’s picture

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

salvis’s picture

So, 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?

boris mann’s picture

Status: Active » Closed (works as designed)

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

Flying Drupalist’s picture

Status: Closed (works as designed) » Active

For 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. :)

salvis’s picture

Status: Active » Needs review
StatusFileSize
new1.57 KB

Ok, try this patch and let us know how it works.

Flying Drupalist’s picture

Works fine, I don't see the error any more and in testing subscriptions are sent correctly.

Thank you so much!

salvis’s picture

So, can you now create a user on one site and have Subscriptions serve the user on other sites, too?

Flying Drupalist’s picture

Yes, I created a new user to test this, and I haven't encountered any problems.

salvis’s picture

Status: Needs review » Fixed

Committed to both -dev versions.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.