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!
{ 1 comment }
Today, after thorough testing, we have enabled the wiki books extension on our UBC wiki server. In a nutshell, it compiles user-selected pages to user’s own collection that can be sorted, saved as a book, and printed to PDF.
It is by far the most complex extension we have enabled so far: it requires certain python, C++ and perl libraries in order to print to PDF and we have setup external server to handle resource-heavy PDF creation to keep main UBC wiki server fast and happy. It is based on Collection extension and you also need mwlib. Overview is here. Scott McMillan, that btw takes all the credit for installing this beast, will soon blog about important back-end steps that are left-out from this otherwise nice article.
For now, it is available only for logged-in users (you have to have CWL to see it and try it out). wikieducator.org and wikibooks.org both run it so in case you don’t have CWL, try it there.
Here is the case study:
Office of Learning Technology publishes annual Faculty Resource Guide (FRG), a nicely designed and printed handbook that is also available as a PDF.
Like with every printed publication, it takes time and effort (read money) to keep it current: we have annual design refreshing cycle, up-to date information edited and send back and forth to designer, the whole file sent to printer etc.
As a big step forward, we have established Faculty Resource Guide blog (http://blogs.ubc.ca/frg/) to make content authoring and keeping it up-to date a bit easier and available online to UBC faculty.
Faculty member could still not print the whole latest version of the book easily, as there is no easy way to send the content of the website to PDF or printer, one could do it only on page-by-page basis.
Wikibooks extension makes it easy:
Our FRG, just like every book should have a title page, so here it is in wiki flavour: it is nothing like a regular cover, we have instead: Short intro, links to contents (chapters), link to printable version (all pages manually aggregated – transcluded) of the whole book and link to PDF.
Very simple and still nothing special so far – now let’s see how wikibooks thingy kicks in: When you’re logged in with your CWL, you will see the link Create a book on the left hand side, just below navigation box. Once you click on it and start your new book, every wiki page will have an option on the top to add that page to your book collection. So, I might choose to compile a few pages from our Faculty Resource Guide (let’s say eLearning Tools and Distance Learning) but also add a few other pages from UBC wiki, let’s say WordPress FAQ and Online Teaching pages.
Now, I’ve got my own new book and I will save it as eLearning Tools and Distance Learning at UBC. I can also create my own chapters and drag and drop pages appropriately. Finally, in addition to saving a book under my own user’s space (User:Nrogic/Books/ eLearning Tools and Distance Learning at UBC), I could also make it part of the overall Books space: (UBC Wiki:Books/eLearning Tools and Distance Learning at UBC).
Very cool, this could work well for all sorts of support and training and lab manuals as well as for course content. Try it yourself!
{ 0 comments }
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:
{ 5 comments }
Constant Gardener, from Flickr.
Being the most flexible and open of all web spaces, wiki can quickly become a messy hotchpotch of various pages written in variety of tones, driven by different needs and intended for miscellaneous audiences. And that’s not almost ok. It is ok as long as it belongs to Namespace Notebook (or test or perhaps crap).
Growth of the wiki space, its usability and maintenance is often compared to gardening where wiki gardener or wiki gnome plays an important role in wiki’s overall health.
So what’s the deal with UBC wiki, who is it for and how is it going to be used?
New, MediaWiki-based, CWL-enabled (CWL is UBC’s single-sign-on implementation) UBC wiki has been up and running for almost a month, available to everyone with a valid CWL account (yes, we proudly display the CWL login link, meaning that this is NOT a pilot project). We are hoping that, as it is case with other successful large organization’s wikis (stretching this to a very larger organization called Earth, we could argue that its best information source is Wikipedia), this wiki will grow and become useful lexicon of UBC and a few things beyond that.
So far, we have recognized four major means of using UBC wiki (all four to be represented by corresponding Namespaces):
So where from here?
While it seems that we do have some valid ideas, technology seems pretty straight-forward, and it can only get better and easier to work with. On the other hand, we have yet to come with right strategies to get people interested in this, show potential and get the buy-in.
Only then we could really say that we have actually accomplished something.
{ 0 comments }
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!
{ 1 comment }
Finally, flickr video makes sense to me.
Great portrait that is accidentally an amazing video clip by Nikola T.:
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;
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!
{ 2 comments }
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:
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.
{ 4 comments }
We are planning the migration of our Movable-Type based websites to WordPress. While offering way nicer management interface and wealth of advanced controls, default WP installation still misses a few things that we took for granted in MT.
Here is the one: On our big websites that run on MT, such as Leap or OLT, we have multiple authors maintain number of posts and pages. Whenever there is a comment on any of these posts or pages, it should be directed to the author of the post for approval.
MT does this well, all the comments indeed go to the authors of the posts. WP however, redirects all the comments to the site admin (?!) with authors left in the dark about the new comments. Admin is usually the technical person who created the blog, without the clue what comments to approve. This makes management of the site very difficult as authors need to be able to respond to the comments in timely fashion.
Luckily we‘ve found Mark Ghosh’s extension that does exactly what we need: emails the comment to authors for approval. The extension is installed and working great at blogs.ubc.ca.
A month ago, Scott has enabled WP LaTeX plugin for all those UBC scientists who know how to use it.
One of those super creatures is my wife Sanja, who just happened to start using UBC blogs as her portfolio website. She was very happy to find out about the plugin and voila, her formulas were done in no-time!