seeing if the rss e-mailer works
a test of custom css
So, I’ve allowed the class attribute for the h2 tag only. Is it a good idea to allow the class attribute so that people can override the default CSS with custom classes? Is it a bad idea?
So, I managed to get the add_existing_user code to add a user based on either their netid or their e-mail address. It’s not a lovely hack, but it does the job and I’m sure makes someone happy.
In Users.php:
case 'addexistinguser':
...
if ( !empty($new_user_email) ) {
//UT Arlington Modification - if this is a netid, treat appropriately
if (username_exists($new_user_email))
{
//$username should equal the input from the form
$username = $new_user_email;
//we need to get the id of the user in order to use the array_key_exists() function
$user_id = $wpdb->get_var("SELECT ID FROM {$wpdb->users} WHERE user_login='$username'");
//the rest of this is the same as if using the e-mail address
if( ($username != null && is_site_admin( $username ) == false ) && ( array_key_exists($blog_id, get_blogs_of_user($user_id)) ) ) {
$location = 'users.php?update=add_existing';
}else {
add_user_to_blog('', $user_id, $_POST[ 'new_role' ]);
do_action( "added_existing_user", $user_id );
$location = 'users.php?update=add';
}
header("Location: $location");
die();
}
//then comes the block for an e-mail address
So, pptpconfig is kind of stupid in that you can’t use a # in your password. That might have been a tip to my password, if I hadn’t already changed it. 
I’ve finished a couple of the To-Do items from yesterday:
Finished:
- removed hard-coding of uid in code and modified ldap authorization plugin to simply use an attribute value rather than hard-coded uid or samaccountname
- added setting of users to exclude from ldap authentication (this is actually work on the ldap authentication plugin) rather than every site admin being excluded so that LDAP users can be site admins
Remaining:
- user front-end display of permissions
- user front-end for adding permissions
- fix wp-admin header so all responsible blogs show
I have made some terrific progress on a plugin for LDAP group authorization. Here’s what’s going on:
Accomplished:
- added database table to store group information
- added plugin pages that control the front-end for both the user and site-admin (this is actually two plugins)
- added code to the pluggable.php file that searches LDAP and the database and adds the permissions for matching groups
- added code to ldap_core.php that allows it to return data from multiple result sets
To Do:
- add user front-end code that will search LDAP and allow the user to add a group with a selected set of permissions
- add user front-end code that will display the user’s given groups and allow them to remove selected permissions
- remove hard-coding of uid in code, possible modify ldap authorization plugin to simply use an attribute value rather than hard-coded uid or samaccountname
- possibly add setting of users to exclude from ldap authentication (this is actually work on the ldap authentication plugin) rather than every site admin being excluded so that LDAP users can be site admins
- fix so that wp-admin header displays drop-down of all sites with privs
Testing to see if I can post as pcrandal when I really am using my other user account.