Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Here is a patch for the member.module to bring it up to 4.7 I need someone to look it over and see if it works for them. I have tested it on the 4.7 beta 4 release and it seems to work fine.
Comment | File | Size | Author |
---|---|---|---|
#19 | members6.patch | 7.49 KB | Junyor |
#18 | members5.patch | 7.09 KB | Junyor |
#17 | members4.patch | 7.65 KB | Junyor |
#15 | members3.patch | 6.95 KB | Junyor |
#14 | members2.patch | 5.49 KB | Junyor |
Comments
Comment #1
wiz-1 CreditAttribution: wiz-1 commentedWorks (for me at least).
Comment #2
walkah CreditAttribution: walkah commentedcommitted, thanks!
Comment #3
ryanrain CreditAttribution: ryanrain commentedi get a /members page that lists the fields i've specified in /admin/settings/members, but am not seeing any users listed.
also, before i created a role other than admin and authenticated user, the /members page was blank. consider replacing this with a page saying you ain't got no roles.
i'm running 4.7 beta 4 with php4.4, and am now thinking i'll just use profile and views.
peace,
-ryan
Comment #4
seanbfuller CreditAttribution: seanbfuller commentedSame here. I took a look at the data and it seems that authenticate users don't get an entry in the users_roles table. My test environment has five users, two of which are have roles in addition to authenticated user. The data set in users_roles has only two entries corresponding to these two roles. Does 4.7 maybe just assume a '2' (user = authenticated user)?
Seems to be the case since this is the sql that it is trying to execute when only have authenticate users selected under settings:
SELECT DISTINCT(u.uid) FROM {users} u INNER JOIN {users_roles} r ON u.uid=r.uid WHERE r.rid IN ('2') AND u.status=1 ORDER BY name ASC
Perhaps someone who knows more about the 4.7 user.module can comment here.
Comment #5
seanbfuller CreditAttribution: seanbfuller commentedI did some more searching and it looks like this is a result of Moshe's fix to "always grant the 'authenticated user' role to authenticated users:"
http://drupal.org/node/46323
So I guess the question is, does members.module need different sql for getting authenticated users, or should user.module be saving all those rids of 2? Is it safe to assume the former?
Comment #6
Patrick Nelson CreditAttribution: Patrick Nelson commentedAs Sean B Fuller has noted, this still isn't working in latest cvs of 4.7. Is anyone working on this? This is, I would have thought, quite a crucial module for most sites...
Comment #7
sanduhrsAny news?
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedthere is no point in writing a users_roles record of 2. all registered users are authenticated users. select * from users gives you all users with authenticated users role.
Comment #9
Jasmine@www.drupalitalia.org CreditAttribution: Jasmine@www.drupalitalia.org commentedHello to all
I've tryed different ways to add:
select * from users
in the query to mysql database, but I'm not a PHP nor mySQL expert, so, at the end I've tryed without inserting the "INNER JOIN" to the "user role" table, in practice this is my not expert "solution" to call all the users in the query:
$query = "SELECT (u.uid) FROM {users} u";
$sort = tablesort_get_order($header);
if ($sort['sql'] == 'p.value') {
$fieldid = db_result(db_query("SELECT fid FROM {profile_fields} WHERE name='%s'",drupal_substr(array_search($sort['name'], $fields), 8)));
$query.= " LEFT JOIN {profile_values} p ON u.uid=p.uid WHERE (p.fid = '". db_escape_string($fieldid). "' OR p.fid IS NULL) AND";
}
else {
$query.= " WHERE u.status=1" . tablesort_sql($header);
}
Of course I've understood the problem given by all of you, but the final comment of Moshe made me curiosity and I've understood that in 4.7.0 table users_roles dont have "role" 2 for authenticated users ... this is a pit!
On previous version of my Drupal sites into table users_role we had a field '2' for authenticated users, this is not anymore for version 4.7.0.
I know very little of PHP, but I understand that very near the query, we should di a IF related to "is the user in the table users" and if so go to read the table USERS_ROLES ...
I know I cannot post this suggestion without giving a solution, but as said before I'm not a PHP expert so to give a shure solution to other users.
Just hope this can help
Kiss
Jasmine
PS: With the members.module attached, when I select a role in the members list this will show all the members but show in the column "roles" just the selected role, this for me is enough, but I bet someone could make some hardcoding to avoid this.
Comment #10
binford2k CreditAttribution: binford2k commentedThe workaround is to create another role that serves the same purpose as the "authenticated user" role.
The real fix will be to figure out a way to choose the roles to list. It will have to select on the rid column for all the other roles and then special case for the authenticated user role.
Comment #11
LukeLast CreditAttribution: LukeLast commentedA quick fix that works for me is to add the line...
Right before the line...
Comment #12
wmostrey CreditAttribution: wmostrey commentedI made a clean solution for this. Code might need review. I would advice putting a 4.7 branch up so the members module comes up in the module list. It is by far the best user listing module.
http://mostrey.be/node/23
http://mostrey.be/files/mostrey/members-4.7.x.tar.gz
Comment #13
Junyor CreditAttribution: Junyor commentedHere's a diff for anyone that wants to take a look.
Comment #14
Junyor CreditAttribution: Junyor commentedHere's an updated patch with the following changes from Wim's patch:
1) Improved code consistency with regard to whitespace
2) Improved use of quotes and double-quotes
3) "javascript" -> "JavaScript"
4) There was a query in _members_fields() that was commented out and replaced with a separate query. I reverted to the query used in the 4.6 version.
5) Added missing "size" attribute to the multi-select form fields in members settings
Comment #15
Junyor CreditAttribution: Junyor commentedAnd here are a couple more changes that walkah made in HEAD (1.37 and 1.38). There were two new features added to 1.36 that weren't forward ported to HEAD, so I'm not sure if it makes more sense to forward port those or to just replace HEAD with 1.36.* after applying this patch.
Comment #16
Junyor CreditAttribution: Junyor commentedComment #17
Junyor CreditAttribution: Junyor commentedOnce more, with feeling:
1) Fixed http://drupal.org/node/66532
2) The name of the "changed" column in the users table in 4.6 changed to "access" in 4.7. I had to update a couple things to make sorting on the "Last Seen" column work.
Comment #18
Junyor CreditAttribution: Junyor commentedAnd, finally, here's a patch for HEAD (1.3.8) that brings it up to 4.7 and includes the new features in 4.6.
Comment #19
Junyor CreditAttribution: Junyor commentedFixing some whitespace problems in the patch for HEAD.
Comment #20
walkah CreditAttribution: walkah commentedfixed and branched. thanks a lot Junyor!
Comment #21
(not verified) CreditAttribution: commented