Posted by yngens on July 11, 2008 at 10:02pm
Jump to:
| Project: | Subscriptions |
| Version: | 5.x-2.4 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
When I go to any new users subscriptions page, for instance http://www.mysite.com/user/411/subscriptions it gives error:
Database error: user 411 not found in {subscriptions_user} table!
The module should not give such error, even f a new user has no subscriptions.
Comments
#1
Is this a fresh install or an upgrade from a previous version? What database and what version do you run? There is a
db_query("INSERT INTO {subscriptions_user} (uid) SELECT uid FROM {users} WHERE uid > 0");query run both on install and on update and hook_user op insert runsdb_query("INSERT INTO {subscriptions_user} (uid) VALUES(%d)", $account->uid);so I really wonder how could that happen. How was this user created? Regular register form, or something custom?#2
Please reopen if you can add something.
#3
False alert, since this was happening on a subdomain site of multisite installation. The module's tables has to be installed separately for each site.
Thanks!
#4
Thanks for letting us know.
BTW, I've added a comment to the code to indicate that the message really is intentional.
Even if it still took a while to figure out what was wrong, the message did serve its purpose.
#5
Automatically closed -- issue fixed for two weeks with no activity.
#6
I'm also seeing this error. I've read the comment about the users being created w/o the correct hooks being called, but this isn't the case.
In multisite setups that share the users table a user can get registered properly in one site and then have this error pop up in one of the other sites.
#7
Yes, I can imagine that this would happen. If you share the {users} table, you should probably also share the {subscriptions_user} table.
I have no idea whether this can work at all though, and I don't think sharing some tables between sites is within the Drupal specs, especially not sharing others.
#8
Sharing a table like the users table between sites isn't a problem and Drupal is designed with this in mind.
What information does the subscription_users table include? Does it include subscription information, or only their preferences? We don't share role or content types so I wouldn't want to share a table that includes site-specific information.
Otherwise would it be possible to populate the table when it's detected that the information is missing?
#9
{subscriptions_user} has only user configuration information. The one field that might cause some minor trouble is the last_sent field, which would be shared among the multisites.
The record in {subscriptions_user} is created when a user is created and removed when the user is deleted. That way we have a clear lifecycle. I'm not very fond of creating records on the basis that they're missing.
I'm not aware of anyone having tested Subscriptions in such a multi-site setup, and I have no idea whether any of it works in such an environment. You will probably find more issues and will have to come up with patches on your own. Please open a new issue for each of them...
#10
I'm getting this too on 6.x dev. Can {subscriptions_user} be created when a user is added to the user table rather than with one site's hooks? Otherwise I support "Otherwise would it be possible to populate the table when it's detected that the information is missing?". Though it's not a clear life cycle, it'll enable support for subsites, and I don't really see a drawback. I've been using subscriptions for a year, on 5.x and now 6.x too and had no problems until this far.
#11
I don't understand what you're saying — please rephrase...
#12
Sorry I'm not sure myself, I think I said something impossible and silly. Is multi site support being considered for this module at all?
#13
Let's branch multi-site support to #351753: Multi-site support? and continue there...
#14
There's a patch in #351753: Multi-site support?. If you're interested in this, then test the patch and provide feedback, otherwise it won't go in.
I let myself be convinced that it's worth the small effort to support multi-site installations, and that patch fixes this issue as well.
#15
Committed to both -dev versions.
#16
Automatically closed -- issue fixed for 2 weeks with no activity.
#17
I found a problem w/ the implementation of the patch; the user_load() call is invalid;
On my installation on line 517, I have:
$account = user_load($uid);This should be:
$account = user_load(array('uid' => $uid));-Doug
#18
It's valid for D6, but not for D5. Committed to 5.x-2.x-dev.
Thanks!
#19
Please keep the official release updated too.. I just spent 2 hours trying to wonder why on earth I'm getting thousands of PHP errors each time nodes are saved by some users. "Normal" user downloads the latest official release and when it contains critical mistakes like these.. ouch :(
#20
Sorry to hear you got bitten badly by this bug.
It has taken a month to be reported — I don't think this warrants creating a new release immediately.
#21
It was actually the minor but critical bug stated in comment #17 that caused the horde of PHP errors whenever a subscription triggering node was saved :)
#22
Automatically closed -- issue fixed for 2 weeks with no activity.