| | 7 | |
| | 8 | I just noticed that my lengthy response didn't make it.... |
| | 9 | |
| | 10 | I don't understand why adding capabilities on a per user basis is a bad idea. I understand that managing capabilities capability solely by capability would be burdensome but roles would serve as a shorthand and would probably be adequate for 98% of the users. In my case, I have about 4,700 users and only about 25 of are better than subscriber status. It is only those 25 that I may need to tweak. |
| | 11 | |
| | 12 | I also understand that adding capabilities as separate lines in a table-- usermeta or other-- could possibly lead to performance problems but I think that that problem is overstated. A million users is a the far extreme, for one. As ryan_b wrote, "How many blogs do you know that have a million users?" And adding capabilities one per line does not add ten lines per user as it would have to to get 10 million lines from 1 million users. It adds about 3 lines per user, since most users are going to be subscribers and have few capabilities. I've tested this. |
| | 13 | |
| | 14 | I added a line for role and a line for each capability for a database of about 4700 users. It added a little better than 14,000 lines. In total the usermeta table has ~44,000 lines. Without an index I can pull up all users of x cap or x role in 0.1 seconds, and with an index it drops to 0.002 seconds. It looks like you would need a lot of users to see a performance hit. Even so, separating the roles and capabilities into separate table should help, and you could eliminate a lot of those lines by only storing the user specific role changes using keys like 'add_cap' and 'del_cap' for example. |