It was on this day 11 years ago that the domain ‘weblogger.com’ was registered by me and my little hosting experiment was off and running.
I am currently rebuilding all that is Weblogger and I hope we will see a revival and a fresh new face on the business soon!
Weblogger will soon be re-born as a WordPress/WPMU hosting company. Speaking of which - thats what I’m working on right now - better get back to it.
Okay, realizing there was not logical way to bring in old Manila threaded discussions was a bummer. Onward and upward. I working on mapping specific URLs from each Manila peice exported to WordPress. Stories, images etc. I am relying on the a part of the Manila database called the glossary (adrSite^.["#glossary"] just in case you do care).
Over the years managing Manila servers I can recall just enough cases of trouble with this index that I have a slight superstition about it, but we’re talking about a handful of cases years ago. Since this is a rare service request (haven’t heard about a problem in years) I think I’m gonna put my trust in this source as a reliable lookup for Manila stories and pictures.
WordPress returns enough information to calculate the new URL with each new post, story or image posted. So I just need to store the old URL and the new URL together so some future process can point traffic frm the old to the new.
Next I will need to devise the most efficient way for the WordPress site to recognize an incoming Manila link (which normally it would reject as a 404 not found) and forward the request to the the object’s new location. This way we can minimize (although not entirely eliminate) breakage for your content when you move.
We made this last year - this production stars my son Tucker, an un-named neighbor kid, yours truly and a special cameo appearance by Sid Kitty (aka Mr. Nootz). Tucker composed and played to background music. Very high production value for this narrow category of YouTube. Please take a look and give us a rating so we can make the top of the list (the current number #1 wood stacking video on YouTube sucks).
Another day another quagmire in my quest to convert Manila sites to WordPress… Manila users can, and often do post item in to the discussion group as top-level threads, and then subsequent replies. Pretty typical set up for a forum type program. Trouble is WordPress is not this type of animal.
I’m afraid there is no similar shape in WordPress land - content in WordPress are pages, blog posts, comments to pages or blog posts, attachments, tackbacks… but nothing I can see that resembles just a plain old discussion forum type top-level thread.
Possibly, I could simply create a custom news category on the target WordPress site titled something like ‘Manila Discussion Group Item’ and post top-level threads there. Trouble is with that approach that discussion group posts would sprinkle in among regular WordPress style home page published posts. This seems unnatural and confusing.
In the spirit of the k-i-m-c-s approach (keep-it-moderately-complex-stupid) that is my nature, I think I’m going to drop support for this type of content. If I get strong push-back then I’ll wander into this thicket again and scare something up to export this kind of content. I guess in the meantime I’ll make this fact plainly clear in the disclaimers on this process.
As I have developed the new Manila site export mechanism the have been a few little brick walls I needed to break thru to keep the process moving forward.
In my first pass over the requirements of this project I tried to do as many proof of concept runs to try to get a handle on what looked like the most difficult tasks in actually trying to export a Manila site entirely via XML-RPC to WordPress.
At the top of the list it a seemed was the fact that the call (getting techie here) ‘metaWeblog.newMediaObject’ did not seem to want to work at all with WordPress. So of course this became the very first task I undertook, since it appeared to be a show-stopper if I couldn’t lick it.
After a days or so of moderate hair pulling I finally pinpointed the problem within the Manila server.
Once I corrected the bad code it fired right up on the WordPress end and thus the chief obstacle as far as I could see at that time had been knocked off.
A move from Manila is long overdue for Weblogger. I’ve been working for some time on putting in to place everything I will need for a completely new Weblogger.com.
So many things will be better - lots of new billing automation to provide faster sales and configuration for our clients, new blogging platform, better support features - basically everything will be new from the ground up. We will still be supporting Manila hosting for as long as any of our currenty paying customers want it. I’ve been blogging about a conversion process to allow Manila users to move to WordPress, and I will offer the service for all Manila users packaged with annual WordPress hosting, so everyone wins.
The home page will soon have a new look and new marketing to reflect our transition. More on that soon.
In my previous post I described a one-brick-at-a-time approach for moving the content of a Manila site to a WordPress site. Just how am I planing on doing this you ask?
I’m going to use yet another Dave Winer invention, XML-RPC. This is a pretty heavy concept for non-programmers, so I’ll try to explain what this means in simple terms.
When you load your blog into your browser and log in to make a post - you are really just feeding some inputs (the title of the post, the post, links etc) in to a program, order ‘code’ that saves the post in to a database. When you view your post, it has been read from a database - fed thru some other part of your blogging program to display the post on your screen.
Most blogging platforms have a series of ‘hooks’ that activate some of the same code that you use through your browser. Programmers often refer to these ‘hooks’ as APIs (Application Program Interface). This means I can write a program and use it to post to my blog via it’s APIs - that is I don’t have to use a browser - I could script an automatic process to make a post to my blog every time my laptop wakes up, for example.
This is where XML-RPC comes in. WordPress has a set of APIs - which use a standard called XML-RPC to carry the inputs and return the results to my custom laptop opening program.
Now one more leap here - I can program a Frontier/Manila server to read a Manila post out of the Manila database - and post it to a WordPress blog automatically. If I set up the program to ratchet thru each Manila post - make some decisions about the nature of the post (a news post, a page, an image etc) - package it up according to XML-RPC and WordPress API standards and posting it to the WordPress blog I want to move to.
This is how I plan on moving a Manila site brick-by-brick to a new WordPress site.
Way back in the day… Dave Winer supposed people may one day want to move from one Manila host to another - so he pioneered a feature for Manila (an ancient but solid blogging platform) that allowed for a complete site export file. The file is useless unless you happen to have a copy of Frontier of Radio Userland hanging around, but it could be sent to a Manila host who could pop it right up for you on his or her server.
But alas this is of little help these days as the Manila hosting market never really took off and is a relatively quiet sector in terms of competition (disclosure - I am one of those hosts as the owner of Weblogger).
What Manila site masters really need is a way to change blogging platforms without the bruising pain of losing all of their posts and other content, images and editorial structures etc. In other words - is there way to savage the blood sweat and tears I’ve plowed into my Manila blog?
We have had Jason Levine’s script for exporting a Manila site in to an MT formatted file, which is compatible with the Wordpress importing process. This approach does leave a lot to be desired, mostly due to the fact that as each Manila item (post, page, image etc) seem to lose proper context when the site is exported in a single piece.
I liken this process to taking a brick house apart brick by brick and loading it on a flatbed truck to be re-assembled in another location. You do your best to document how the house was originally put together, you take pictures and make diagrams. Even with the best laid plans, in the end the re-assembled house is certainly recognizable but never really the same house. Plus you have an odd pile of left-over bricks!
A better approach would be to move the house one brick at a time. For the time that the house is partially located in two places, you have a perfect reference for where to put each brick, and you would probably wind up with a moved house that is pretty darn close to it’s original state. And no left-over bricks!
What I am talking about here is a new approach to moving a Manila site piece by piece - in such a way that the WordPress site you wind up with is much closer in all ways to your former Manila site.
I am currently working on this and I’ll try to blog a bit about my thinking as I build.
feh