Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Drupal option from settings.php file '$db_prefix' is not honored when creating site_user_list table. This means this module is incompatible with multi-site installations.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | site_user_list_patch.txt | 1.55 KB | scafmac |
Comments
Comment #1
pukku commentedThis is very odd. the call to create the table is
db_query("CREATE TABLE {$name}.... Wrapping the table name in '{' and '}' is supposed to take care of this problem — it does everywhere else. Can you tell me what led you to suppose that this is a problem?Comment #2
scafmac commentedWell, I haven't dug down into the code, but I have a multi-site installation. I've installed the site_user_list module into one of the sub-sites module folder. I turned on the module only in that sub site. A new table is added to the DB named site_user_list_table. The way the base and sub sites are installed, tables are named as follows:
Site_user_list_table is the only table without a prefix. I tried turning off the module and uninstalling the module through the new Drupal 5.x module uninstall interface and the table was not removed. That bug might be related to the naming one. So to retest I manually dropped the table. I copied the module to a different sub-site module folder. Then I turned the module back on in the new sub site and the table returned sans any table prefix. Uninstalling didn't remove the table in the 2nd test either.
Mysql: 5.0.18
I didn't see any problem with a drop table statement, but your module is also logging lots of sql errors. Does it require any special privileges for the DB user?
Comment #3
pukku commentedHi! What are the errors? You might need to have 'create view', if that isn't already available.
Could you take a look in settings.php and see how things are setup? From the way you have it described, it can't be as simple as setting $db_prefix, because then you wouldn't have 'base_' and 'shared_' tables.
I'm also not sure how I would fix this; the database wrapper layer is supposed to handle this transparently.
Comment #4
scafmac commentedOk, with the 'Create View' privilege granted to the user, the sql errors have dried up. Perhaps that requirement should be noted in the docs if it isn't there already. I didn't notice any instruction to add that grant, but it is not one of the standard ones for Drupal.
However, that didn't solve the problem. The problem is in the module. I finally dug into the code. The problem is that the {}s enclosing the table variable are not being escaped. In php {} are evaluated before the double quotes; { followed by $ is used to evaluate complex syntax. I've attached a patch that escapes all occurrences and it has solved the issue.
Comment #5
pukku commentedThanks! I completely didn't know about this syntax — in perl you have to do something more complex, so I wasn't looking for this. I've applied these changes (both to 5.x and 4.7.x).
I will also add a note about 'create view' privilege being necessary.
Comment #6
pukku commented