Some major changes were made to SFU Blogs this weekend. These changes have been planned for quite some time but were accelerated due to a critical security vulnerability in earlier versions of WordPress.
- Upgrade to WordPress 2.8.4
- More capabilities for Editors
- Better user management
Upgrade to WordPress 2.8.4
Previous versions of WordPress were subject to a critical security vulnerability in which an attacker could gain control of a WordPress install and inject spam and malware into posts. While it does not appear that any SFU Blogs installations were compromised, we felt it prudent to proceed with an immediate upgrade to the most current version of WordPress, 2.8.4.
In addition to patching the security flaw, WordPress 2.8.4 brings an exciting new feature to SFU Blogs: theme uploads. Prior to today, themes could only be installed by an IT Services administrator, manually. Now, any Editor-level user can either choose a theme from the WordPress gallery or upload a ZIP archive and activate the new theme. Please note that the default “sfu_theme” is still the only supported theme; you’re welcome to choose different themes or upload your own, but you do so at your own risk.
More capabilities for Editors
WordPress has several types of users, including Administrators and Editors. Administrators have full reign over a WordPress installation, while Editors can manage posts, pages, links, etc. but little else. For security and stability very rarely give out Administrator privilegs to non-IT Services staff; one wrong setting change by and Administrator can render a WordPress install inoperative. A common request has been for more powers for Editors, and we’ve come through. Editors now have most of the same capabilities as Administrators, including:
- changing themes, editing theme files, uploading new themes, modifying sidebar widgets, etc.
- changing the site title and description
- managing users (more on that below)
- much, much more
A side note: some sites had non-IT Services Administrators, either by previous arrangement or by Editors elevating themselves to Administrator. Now that Editors have virtually the same power as Administrators, any non-IT admins have been changed back to Editors. Additionally, security features that prevent users being elevated to Administrator have been put into place.
Better user management
Previously, adding, removing or modifying a user had to be done by IT Services staff. Additionally, options for user management was limited; we were limited to SFU users only, with no facility for adding external users or SFU maillists. Now, Editors can:
- Add SFU users with their SFU Computing ID
- Add external, non-SFU users (usernames must be greater than eight characters to avoid conflicts with SFU IDs)
- Specify up to four SFU maillists for each WordPress role (Editor, Author, Contributor, Subscriber). Maillist membership will be synchronized with your WordPress site daily at 0800.
The first two options are fairly simple; you can add either an SFU user by entering their SFU computing ID, or an external user by creating a username (greater than eight characters) and a password. External users will have their login information emailed to them.
The third is a bit more complicated. Assume the following situation: you manage the blog for the basketweaving club. You have two maillists full of blog Editors and Authors: basketweving-blogeditors and basketweving-blogauthors. You can now specify that the membership of these list be synchronized to your blog daily. When the synchronization happens, the following takes place:
- any user in the list who does not already exist in the blog is created and granted the appropriate user role
- any user who is no longer in the list is deleted from WordPress. Any posts or links created by that user are either:
- reassigned to the blog’s owner (or another user) — the default option
- any external, non-SFU users in the lists are skipped and not added to WordPress
- if a user exists in multiple role lists (e.g. they are in an Editor list AND an Author list), they will be given the lowest privileges (Author, in our example))
- users that exist today, as well as users created with the new SFU and external user tools will be unaffected by the maillist synchronization. For example: assume the user kipling was created as an Editor using the Add SFU User function AND that kipling also exists in a editor maillist. If kipling is removed from the list, he will NOT be deleted from the site as he was created with the single-user tools
Notice anything wrong?
These modifications and enhancements have been in the works for some time and have been throughly tested, but even the best laid plans may have unintended consequences. The critical security vulnerability in previous versions of WordPress made proceeding with the upgrade immediately a necessity. Please take the time to throughly check your site and make sure it functions normally – if you notice anything wrong please contact us at firstname.lastname@example.org.