Hi,

thanks a lot for your work on this module!

I installed the latest dev version (2009-Mar-23) and could not get to the administration page, where it's possible to add access restrictions on lists based on roles. I'm not the user with the number 1 id so I had some access restriction problems. It turns out, there's a typo here:

in line 90, inside phplist_menu() {

this:

'access arguments' => array('aadminister phplist'),

should be, I think, like this:

'access arguments' => array('administer phpList'),

don't forget the capital "L" in "phpList" (that took me another while).

I had the same error about the connection ("Password is set - no connection") people have already described. But I tried with all kinds of prefixes ("phplist_user_" etc) and nothing seemed to work. I echoed the rendered table name in the phplist module and it was the same as in my db. Other functions of the module did already work so I was a quite confused. Then I changed the following lines:

line 160:

if (db_table_exists($prefix['user'] .'user')) {

to

if (true) {

and everything worked, also synchronization. Then I realized the "db_table_exists" function was not working with any table of my phplist installation. I'm no drupal expert at all (just started), so I cannot get to the root of this problem at the moment.

I hope this helps a little bit.

bests,

rodrigo

CommentFileSizeAuthor
#3 phplist-414206.patch440 bytespinolo

Comments

paulbeaney’s picture

paulbeaney commented

Hi,

I have fixed the error in line 90 - thanks for pointing it out.

You are not the first to have had the "NO CONNECTION" error, but alas noone has ever reported back exactly what the problem was. In theory, in MySQL 5.1 at least, you only need SELECT permission on a database to do SHOW TABLES so there's no reason why line 160 fails for you (unless any MySQL gurus following this can perhaps enlighten us?)

Given that the majority of people do not have a problem, I intend leaving this line of code as-is for now.

Regards,

- Paul

rodrigoderteano’s picture

rodrigoderteano commented

Hi Paul,

thanks for your reply.

I do have select permissions (and so on) and mysql version 5.1.30 for the db user, so I don't have a clue about the "connection" error. Maybe I can help you with this at some later point, when I know a little bit more about drupal mysql api.

I found another bug, though. I had problems with the list access configuration based on roles. I got an access error whenever I wanted to subscribe to a mailing list, although I had the right lists attached to my user role in the configuration. Seemes like there's a problem with the configuration form and the "lid" value that is attached to each checkbox. The "lid" (list id) value is not the same as in phplist.

The problem, at least with my version of php (5.2.8), is that the "array_merge" call in function "phplist_list_roles" around line 305 wipes out the original array_keys, which carry the "lid" information. So I changed:

$options = array_merge(array("". t('All'). ""), $options);

into:

$options = array("". t('All'). "") + $options;

Now subscriptions work smoothly.

Hope this helps.

cheers,

rodrigo

pinolo’s picture

pinolo
he/him
commented
Assigned: Unassigned » pinolo
Status: Active » Needs review
StatusFileSize
new phplist-414206.patch440 bytes

Confirming the behaviour described by rodrigo.

stanley78’s picture

stanley78 commented

oops...

that may be the case. I'm also far from mysql guru but could suppose something. If SHOW TABLES implicitly executes SELECT FROM INFORMATION_SCHEMA, the module's user must have at least privilege to select from TABLES table. Whether that privilege is given or not depends on the way phplist was installed. Of course, if someone has root access that's not a problem to create/alter such a user. But if phplist is installed by script at the remote host? Nobody knows what default rights are assigned.
That's why I suppose some people have problems and some don't.

paulbeaney’s picture

paulbeaney commented
Status: Needs review » Fixed

$options = array("". t('All'). "") + $options;

This change is now in D6-DEV. I checked both this way and the array_merge() way, and they both give the same results for me, so since the only reports of errors have been with array_merge(), it seems sensible to go this route (although personally I find doing a string concatenation on an array a bit strange semantically !!)

Thanks for your input.

Regards,

- Paul

paulbeaney’s picture

paulbeaney commented

If SHOW TABLES implicitly executes SELECT FROM INFORMATION_SCHEMA, the module's user must have at least privilege to select from TABLES table. Whether that privilege is given or not depends on the way phplist was installed.

SELECT is such a basic permission that I can't imagine any user (except for replication purposes) not having it. It would extremely surpising if any hosting service didn't provide it by default to all new database users.

SHOW TABLES is actually a red-herring. I have checked the Drupal code and it does a SELECT within the function drupal_db_table_exists().

Regards,

- Paul

stanley78’s picture

stanley78 commented

hi paul

i can see this:

function db_table_exists($table) {
return (bool) db_fetch_object(db_query("SHOW TABLES LIKE '{". db_escape_table($table) ."}'"));
}

which when called from module transformed to query (in my case)

SHOW TABLES LIKE 'drupal_phplist_user_user'

that's ok to add a prefix if it's right one. however I have separate db for phplist without drupal_ prefixes... maybe db_query uses some global prefix variable to extract {}, or gets from context, I don't know - I'm not a programmer.

paulbeaney’s picture

paulbeaney commented

Hi Stanley78,

Thanks for the update. It's the PGSQL db_table_exists() which uses a SELECT - my mistake. I think you have hit the nail on the head about Drupal adding its own prefix when looking in the PHPlist database. I don't have a prefix for my Drupal tables, which would explain why I have never been able to reproduce the problem.

Which leads to the next question - how to reliably check that the PHPlist database is accessible? Doing a 'SELECT * FROM' *could* work, but surely Drupal will error if the table doesn't exist. Not very friendly. Or how about hard-coding a 'SHOW TABLES' , but then the module will only work for MySQL...

Any suggestions/opinions?

- Paul

stanley78’s picture

stanley78 commented

hi paul

thank you for improving my english with a handful of idioms :)

about prefixes.

maybe you should look at function db_prefix_tables($sql) in drupal code. probably it's possible to create elements in $db_prefix array for phplist during module installation/configuration, add var 'phplistprefix' and set user tables without prefixes...

just as a rash proposal :)

Status: Fixed » Closed (fixed)

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