There have been a bunch of changes, hopefully improvements, over the last few days.

1. The BuddyPress “social networking layer” was turned off. It didn’t look like anyone was actually using it, and it was causing confusion (2 separate places to set avatar images, multiple locations to post new content, confusion around privacy, and complicating site maintenance and support). So, for now, I made the executive decision to turn it off. It may come back in the future, but not until BuddyPress has had some more time to stew.
2. A new theme. I’ve switched the “home” theme and am working on building some more useful functionality into it – a handy dashboard to access all of your sites, for starters. I’ll be tweaking the “home” site over the next couple of weeks.
3. A better “admin bar” – that grey bar that runs along the top of the page. When logged in, it now provides much better functionality, making it easier to get to the good bits of your site, and to create and manage content quickly.

I’ve got a bunch of other things I’m (slowly) working on, and will try to roll out some more improvements over the holiday break.

If you have any questions, please contact me.

The planned database code migration took a LOT longer than planned, and didn’t work out in the end. I wound up having to back out the planned code changes, so we’re back where we started. In addition, the campus database server became unhappy as part of the process, and blocked connection attempts from the server that runs UCalgaryBlogs (and a bunch of other stuff) – so I had to migrate all data to a Teaching & Learning Centre database server so we could use UCalgaryBlogs again.

I’d done testing of the new database code, and it worked fine prior to attempting to roll it out on the production server. I’ll do some more testing (and am talking to the developer of the new database code to help debug the situation). I won’t try to do any further rollouts of the code without some extensive testing – and all data will be safe, regardless.

I need to convert some of the database configuration for UCalgaryBlogs to new library that will offer us higher performance and more scalable database connections.

I’ve tested the new configuration, and it should work just fine. If there are no snags, there should be no more than a few seconds of downtime. If the gremlins decide to come out and play, that may be extended to a few minutes as I revert to the previous configuration.

I’m planning to do the configuration change at 10am on Wednesday, November 11. Hopefully, it being a holiday, and the beginning of reading week, there should be little activity on the site (you DO have other things to do, right?). It should only take a few seconds, but in the worst case scenario, the service will be back up and running normally no later than 11am that day.

If you have any concerns, please let me know. I’ll post an update after the database configuration has been changed.

I think I’ve tracked down the cause of the problem that was preventing access to the Dashboard on all sites. If you’re still having trouble accessing your Dashboard, or with publishing new blog posts, please let me know ASAP.

I apologize for the inconvenience this problem caused. I know it’s difficult when the software doesn’t work when expected – especially under the pressure of writing as part of a course. Thanks to everyone who reported the problem – that really helped me track down the cause and (hopefully) fix it as quickly as possible.

- D’Arcy

There is currently an issue preventing users from accessing their Dashboards for their sites – meaning you can’t write new blog posts, or edit existing posts (among other things).

I’m working on tracking down the cause of this right now. Hopefully it won’t take long to debug this.

I apologize for the inconvenience. Thanks for bearing with the difficulties here on UCalgaryBlogs.ca!

I just rolled out a mobile interface for UCalgaryBlogs.ca – if you’re accessing the site from a mobile device such as iPhone, iPod Touch, Blackberry, or Android, you should now see a sleeker, optimized interface. It’s not perfect, but it’ll load a LOT faster, and should display a LOT better on the small screen, as opposed to the scaled version of the “normal” interface. Here’s a screenshot of the front page of ucalgaryblogs.ca under the new mobile interface:

There are a few options to tweak, if you really want to, to customize how the mobile version of your site works – check out your Dashboard, in the Settings section, for an item called “WPTouch” and click the shiny checkboxes to your heart’s content…

Looks like we’re back to normal operations here – IT is looking at adding some additional resources to the server to make sure it keeps on chugging along, and I’ll try to monitor it as closely as possible. If you notice anything misbehaving (taking for EVER to load, borking, etc…) please let me know ASAP.

It looks like UCalgaryBlogs is running a little slower than it should be lately – I’m trying to track down causes of this, and apologize for any problems the slowness may be causing. I’ll post an update once I’ve figured out what’s slowing us down. Hopefully we haven’t outgrown the server already…

The BuddyPress social networking layer for UCalgaryBlogs was just updated, but something imploded during the update. The data is all still safe, and I’m tracking down causes and fixes. Hopefully everything will be back up and running normally as expected soon.

All blogs should be working normally – the only thing affected is the social networking layer, which was running the front page of UCalgaryBlogs.ca (so, in the meantime, it has reverted to a previous design)

The evil spammers just keep on hitting our little blogging platform. I apologize to those of you who have had the nasty spam comments published on your blogs. The spammers are truly the filth of the internet, and we’re locked in an arms race against them.

They use automated scripts for the most part to publish comments containing links to their various casino/viagra/porn websites, trying to boost traffic to their sites and trick Google into listing them higher in search results.

I’ve been trying different antispam techniques – using the distributed Akismet spam system, the standalone WP-SpamFree system, and a few others, but nothing has been 100% effective at keeping the spamroaches at bay.

So now I’m rolling out a “captcha” system on a trial basis. Only anonymous (i.e., not logged in) people should see it at all. When it is displayed, the person (or spam script) will have to decode 2 images and type them as text before a comment will be accepted. For example:

In this case, a person wanting to publish a comment would have to enter the words “hearted Russians” before the comment would be accepted. If a person can’t read the words, they can click the arrow link to get a new set of images to decode. If a person just can’t read captchas at all, there is an audio alternative, which is available by clicking the speaker icon.

The reCAPTCHA project is interesting. From the reCAPTCHA website:

reCAPTCHA is a free CAPTCHA service that helps to digitize books, newspapers and old time radio shows.

reCAPTCHA improves the process of digitizing books by sending words that cannot be read by computers to the Web in the form of CAPTCHAs for humans to decipher. More specifically, each word that cannot be read correctly by OCR is placed on an image and used as a CAPTCHA. This is possible because most OCR programs alert you when a word cannot be read correctly.

But if a computer can’t read such a CAPTCHA, how does the system know the correct answer to the puzzle? Here’s how: Each new word that cannot be read correctly by OCR is given to a user in conjunction with another word for which the answer is already known. The user is then asked to read both words. If they solve the one for which the answer is known, the system assumes their answer is correct for the new one. The system then gives the new image to a number of other people to determine, with higher confidence, whether the original answer was correct.

I’m philosophically opposed to captchas – they penalize everyone in an attempt to stop the spammers. I’m hoping that this plugin will strike a proper balance – only being displayed to people that aren’t logged in is a very good start.

Also, when creating an account on the site, people will have to decode the captcha. This is to prevent the automated “splog” scripts from creating spam blog sites to publish links – we currently get up to a dozen of these automatically created each and every day.