Recent Comments

Godfrey's  section widget!

When we were designing the first version, I knew this is too good to be true.

And then Godfrey took it to the yet another level!

Congratulations to Godfrey and others from OLT who worked on this fantastic plug-in!

Just during last week, two well-known edublog spaces, Jim Groom's UMW blogs and Alan Levine's CodDogBlog (both WP-based) experienced serious hiccups and in case of UMW blogs serious downtime. There are many to blame, from mindless spammers to the mighty Google, but in the nutshell, problem seems to be the nature of how we use WP in general: our small pieces became one giant does-it-all piece with many loose holes that all the bad guys (viagra/casino/porn) and good guys (google and similar bots) so vigorously exploit.

Can we hold it together?

In the next couple of posts, I will try to go through our experiences with running WordPress in larger institution; here is the preview:

• scope (what we offer):
  Delete and forget about WP themes and base your offer on templates: blog, course, website, community portal, project management space, resource repository, rss aggregate, event calendar, research space, photo gallery...
• signups and user management:
  Implement campus’ single-sign-on authentication, and write plugins to connect to campus student information system to download students to course blogs. One of the biggest time-consuming tasks with large user base systems is the user management and account creation and you want to automate this as much as possible.
• development  framework and system maintenance:
  VMs, SVNs and Backups – your university IT department is your friend. Hang out with these guys and revisit your statements on cheap and dirty if you want to last. Development, Verification and Production server – you gotta have all three. In sync. Often looks like mission impossible but it is actually doable.
• typical development tasks
  Based on our experience, these are the typical tasks in WP development that require framework mentioned in the previous bullet – you don’t want to try any of these on your production server:
  • Major Content/Architectural changes – your client will ask you to shift few hundred pages around. This is the case primarily with WP-based websites mostly
  • Look and Feel work – you have to change all your typography, headers and footers and rewrite all your CSS files because campus decided to update their look and feel.
  • Plug-ins development  - Make sure that your development environment is exactly the same as your production one or you are up for nasty surprises.
  • Back-end upgrades – Your LAMP, your WP core needs to stay upto date.
  • Migrations - We did migrate few hundred MovableType blogs to WP and survived.
• buy-in, support and training
  Don’t count on your edupunk coolness. You are here to provide good service and support.
• searching and reporting
  It is often pain in the butt and slows down the servers but it also gives a lot in return. Any WP coding that stores content in custom fields will not be indexed by WP itself so just use Google search instead. And after using Google analytics you can’t use any other tool. Also make sure to be able to report on number of blogs (and their types) and users at any time.
• new requests
  Say no. They are typically unreasonable, otherwise plugins would be already written. If you hear it 1000 times than you might want to consider it. Clients are usually wrong.

It is not often that I feel completely pleased about the work that team I work with or myself have finished. There is always a bit of "well, this could be done better", or "we should have...".

But after our final testing and publishing of Section Widget to WordPress Plugin Directory, my heart is full.

Yes, some of "well, this could be done better", and "we should have..." still exist, but I am absolutely pleased and I see enormous potential on how this widget can continue to grow and change the way we think of the WordPress as the Content Management System (hint: next version will enable custom fields management). Special credit goes to our fantastic co-op student Godfrey Chan, for making things happen in hours rather than weeks, while maintaining out-of-this-world quality of code.

Please learn about it, download it and enjoy it!

Enej Bajgorić created the plugin for republishing MediaWiki (or any HTML) pages within WP.

For those who liked the idea, here are some good news: we are continuing development of this plugin for our culturepedia project.

Here is the functionality in the nutshell;

• seamlessly integrate wiki pages, categories or searches into WP blogs.
• works as both shortcode (more here and here) and widget.
• content can be constantly refreshed (as wiki pages changes) or one-time brought in.
• the wiki content will be searchable by google (not the case with WikiInc).
• the wiki pages could be further shared by using embed functionality.

For example, if I want to publish all the pages from ubc wiki that are stored in both culturepedia AND idioms category, I should shortcode something like this:

[gimmiewiki -category URL:http://wiki.ubc.ca category:culturepedia,idioms refresh:yes popups:yes|embed|link]

Or if we end up developing a visual component, it could look like this:

Will get back with more!

We have been running Movable Type for over three years and for number of reasons (far better platform, CWL integration, the support overhead and availability of plugins, to name a few) decided to move to WordPress.

Since last summer we have pretty smooth, CWL-enabled, pilot WPMU installation available to selected UBC faculty, staff and students; so far, things look pretty good!

Now that we are at ease with our ability to run the new system, we are planning to migrate more than a thousand MT users  and blogs to WP.  We are expecting that only the small number of people will actually want to move their blog - for the rest... well, we are thinking about it as the great autumn-cleaning opportunity. Anyways, EVERY blog will be backed up and saved in case users come in the future to restate their blogs.
Here is the process with its requirements and challenges along with the ideas on how to go around them:

Setup: There are three environments in which the migration takes place:

• Original MT (Source)
• Verification WP (Check-point)
• Production WP (Target)

The process:

1.       Notifying the Users and Project Tracking.
We will send the email to users describing the migration process and inviting them to create an account and a blog on the Production WP, which is the new location for their blog. We have classified all the users on the scale of 1 to 5, based on the importance of the blog (we have tons of abandoned blogs) and we also have special VIP list - those blogs get extra attention!
Here are the fields of our migration tracking database:
blog_id, blog_name, entries_count, blog_site_url, author_id, author_name, author_email, other_blog_owners, blog_description(tags), priority_rating, migration_notes,  vip, new_author_name, other_authors_translation, new_url.
You can sense the complexity of this operation by just looking at these fields!

2.       User reports back
Upon creating the account, blog user gets back to us with the account and blog info (details instructions on how to do this were sent in an email). We then proceed with the next step of migration:

3.       The Import to Verification WP
MT blogs and users' info are exported from MT to Verification WP by using WeblogsMigrator plugin that Michael Ha and Seth Tee have specifically developed for this purpose. This WP plugin actually queries the MT database and retrieves all the information on the given blog and user and then stores them in the Verification WP. So, we end up with blogs, authors and comments, all properly imported within WP Verification. Users from MT keep the same username in WP Verification. It is worth mentioning that in this process, all the links that point to the other posts within same blog are being re-written to point to the new URLs. It is even cooler that we are grabbing all the media files (images, movies) and storing them automatically in WP Verification.

4.       Finalizing the Look and Feel and dealing with blogs' extras.
Here, we apply theme that look close to one in MT, for look and feel consistency. For VIPs, this may involve additional tweaking or creation of the new theme. If needed, we consult with users on how to proceed with extra content (if there is any) of their MT blogs. Usually, this means dealing with side bar content and advising on how to recreate these in WP (through using widgets).

5.       From WP Verification to Production
After examining the blog and round of QA, we do another round of export/import; this time using slightly changed WeblogMigrator. Things get hairy with blogs that have multiple authors; for this reason, we made sure that this plugin, which looks very much like standard WP to WP import, also provides username matching. With this, we make sure that the original users keep ownership of their posts after the blog is migrated. It is expected that many users will have different usernames from those on MT, that's why we cannot automate this process. This is only important for multi user blogs.

6.       Redirecting old URLs
One of the major requirements of this process is to make sure that every post will automatically redirect to the new post's URL.  In the process of importing (step 3), we record the old and the new URL for each post and store it in the database. This table is now queried to produce the  .htaccess file that will, for every post, redirect to the new post URL.

7.       User takes control
At this point user has the complete control over their blog. We are expecting that owners of more complex blogs will require additional support that we can provide through pointing to various WP support websites and examples online, or via direct support.