So I’ve finally got round to getting down and dirty with HTML5 and CSS3 by revamping the blog theme. I initially started by having a look at the Bones theme but it was too complicated to work out how it integrated with WordPress. So next stop was HTML5 and CSS3 from pragprog and the WordPress site design guide and after a few hours I had the bones wired together and along with some font help from the Bones styles the blog is now HTML5 and very minimal. Just how I like it. I’ll be porting the CSS to SASS next and then adding more nice stuff and making it look slightly less minimal but not much. I particularly like the way I have full control over the posts themselves now and the style plays nice with gists. Luvvly jubbly!
What a mess. This is a real mess. I normally upgrade to the latest release as WP is normally very good. This time it’s a complete and utter mess. I get the impression 2.8 wasn’t tested. At all. Get 2.8.1 out the door please!
seems something has changed to break plugins which then break wordpress. For me, it’s the podPress plugin. Disabling it brings back the tag functionality.
Since I changed the LDAP to be a plugin and integrated it with the REST installer, I now have a template 1.5.2 WordPress that can be installed via a simple REST web service call.
When you make the call with the new user’s details, the modified installer will create a new blog for them, add them as a level 9 user with LDAP authentication and an admin user whose password they don’t know. It also automatically activates the LDAP plugin.
This means though that they could deactivate the LDAP plugin and cause the helpdesk to overheat when they can’t login any more, so I hacked a few files to provide user level restriction for plugins:
Plugin Name: LDAP
Plugin URI: http://codebrane.com/blog
Description: LDAP authentication
Author: Alistair Young
Author URI: http://codebrane.com/blog
The LDAP plugin, as you can see, now requires a user level of 10 to view it.
These are the files I hacked to provide the user level restriction for plugins:
- wp-admin/plugins.php – now compares Level: in the plugin file with the user’s level. If they’re below the Level: required to view the plugin, the plugin isn’t displayed
- wp-admin/admin-functions.php – now extracts the Level: attribute from plugin files
Must keep an eye on this plugin from Bill Gray. Bill has taken my code and wrapped a really nice GUI round it for a WordPress 1.5.2 plugin.
I got so fed up with WP’s feeble anti spamming system that I just went ahead and implemented a Yahoo style anti spam number. It’s a stop gap fix just now until I’ve got time to make it more robust. The comment form just displays a number in a JPG and if you don’t enter that number when submitting a comment you get nowhere!
So, all you twats in p*k*r land. I hope you rot!
This example is for moving http://www.weblogs.uhi.ac.uk/lis to http://weblogs.uhi.ac.uk/vle
First thing is move the directory on the server, from [WEBLOGS_HOME]/lis to [WEBLOGS_HOME]/vle
Then update the weblog’s database.
update wp_lis_posts set guid=REPLACE(guid, “lis”, “vle”);
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’siteurl’;
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’fileupload_realpath’;
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’fileupload_url’;
update wp_lis_options set option_value=REPLACE(option_value, “lis”, “vle”) where option_name=’home’;
I’ve now upgraded my instance of WordPress to 1.5. Very easy too, if you follow the instructions at:
Install/Upgrade to 1.5
How to copy your database
Following on from adding LDAP to WordPress 1.2.1, I’ve ported it to 1.5.
The basic mechanism is the same, i.e. after successful authentication, the cookie is modified to store a hash of the username and the LDAP marker, instead of the password. LDAP accounts are quite often used institution-wide for single sign on (SSO), so I think it’s a bad idea to store that password anywhere outside the LDAP server, even if it’s double hashed. On Novell NDS you can’t even get the password, you can only compare it.
The modified files for 1.5 are:
- ldap/* – Contains all the LDAP functionality
- wp-config.php – Contains some LDAP definitions
- wp-includes/functions.php:wp_login() – modified to do LDAP authentication and check for the LDAP marker in the cookie
- wp-includes/fuinctions.php:wp_setcookie() – modified to set the LDAP marker instead of the password in the cookie
As before, you can enable LDAP authentication in wp-config.php:
setting “LDAP_ENABLED” to “true” will turn on LDAP authentication. Setting it to “false” will turn it off and WordPress will revert to normal database authentication and cookie setting.
A change from 1.2.1 LDAP is the “admin” user is not authenticated via LDAP. So, if your LDAP server goes down, you can still get in to your blog.
One thing to note, is if you turn on LDAP authentication, all users of your instance of WordPress must have local accounts as before but they also must have LDAP accounts or they won’t get in.
To address security concerns, I’ve trimmed the distributed files and changed all .h files to .php. I’ve also bundled a .htaccess in the /ldap directory to deny all access.
You can follow a discussion on LDAP authentication here
The link below includes all the modifications to improve security.
Download the LDAP modifications for WordPress 1.5
Auricle article on WordPresMU
Seems other people are thinking the same thing. How to manage thousands of users and their blogs?
Interesting developments at WordPress…