| | 2 | |
| | 3 | --- |
| | 4 | |
| | 5 | summary courtesy of DD32: |
| | 6 | |
| | 7 | My points from what i know: |
| | 8 | |
| | 9 | * The current role system is rather complicated, But has a lot of flexibility |
| | 10 | * A lot of the flexibility isn't even used by most (ie. the ability to have a user with a Roll + a single capability) |
| | 11 | * The role system starts having trouble with a high number of users |
| | 12 | * To look up every user with a certain cap. it requires loading all the users, and then checking individually. |
| | 13 | |
| | 14 | The proposed changes are: |
| | 15 | |
| | 16 | * That we reduce the complex system to something much more simple: |
| | 17 | * Roles are retained, |
| | 18 | * However: |
| | 19 | * Limit users to 1 role (This would be on a per-blog basis, based off the permission prefix thinggi..) |
| | 20 | * Remove the ability for a user to be part of a Role, and have an extra capability added on top of that. |
| | 21 | * This has the ability to significantly increase performance, As now: |
| | 22 | * Looking up users with a specific cap is easy: |
| | 23 | * Filter the role list for roles with that cap |
| | 24 | * SQL the usermeta table for users in those roles |
| | 25 | * Select those users (if needed, else return the ID's) |
| | 26 | * An upgrade path is available which doesnt require extra tables, and reduces the ammount of serialization |
| | 27 | * The other option is a whole new set of tables.. which.. those who are sane (And there are some insane people in WP Dev..) realise that its not really needed. |
| | 28 | * Fine grain control has never been possible from WP without a plugin, Nothing would change here, If a user wants fine grained control over permissions, They'd still have to run a plugin, Its just that that plugin may have to do more heavy lifting now -- since wordpress's API/role system would be simpler and not support the extra fangledangles. |
