QDN: Of Manila and Portability

Dec 20, 1999 | Q

Today, I moved my EditThisPage site off of Userland’s server, and onto my own. All in all, it was a phenomenally easy thing to do; that being said, there are a lot of things that I had to think about and do beforehand in order to make it that much easier. This is a quick missive about the process of moving a Manila or EditThisPage site — things to think about while designing the site in the first place, all the way through things that you need to do once the site is on its new foundation.

A few weeks ago, Userland released Frontier 6.1, with a remarkable technology built into it called Manila. (If you don’t know about Manila, I recommend clicking on that last link and reading a little about it.) Very quickly thereafter, they set up EditThisPage, a place where anyone could get a Manila website of their own, and have it hosted for free for 60 days. I had been hearing about Manila from Dave Winer (via Scripting News) and others for a while, so I decided to give it a try — I set up my own site, Q.

Within about three or four hours of playing with my ETP site, I was wowed — effortlessly, I had created what I thought was a nice-looking site, and just as effortlessly, I could edit the contents of that site and build up a remarkably complex hierarchy of content. Seeing that Edit This Page button all over the place made be happy. Using my web browser to edit the look and feel of my website made me even happier. Over the next two weeks, I continued to use my site, updating it regularly, tweaking the look and feel, and remaining shocked at how easy it all was.

I have been running various versions of Frontier since 1.0, and Manila sold me on setting up a server with Frontier 6.1 on it. I wanted to move Q to that site, and thankfully, I was able to do that — on my very first day of playing with Manila, I had asked what would happen if I wanted to take my root file and put it on my own server, and Dave had committed to making that possible. Out of this came the downloadMySite feature of Manila, which lets you download your own site’s entire root file and move it to any Manila server you want.

This was painfully simple — I just typed the URL to the downloadMySite feature of my ETP site into my browser’s address bar, http://queso.editthispage.com/downloadMySite/MySite.root, and (so long as I was logged in as a managing editor of the site) along came my site’s root file.

Next, I made sure that my copies of manila.root and mainresponder.root were up-to-date, and I threw my new root file into the Guest Databases\www directory of my new server. (I also renamed the file from MySite.root to q.root.) In Frontier, I opened the root file and then, with it as the selected window, I chose Install Site from the Server menu. When asked for the new URL of the site, I typed q.queso.com; Frontier then did its thing and my site was done. Very cool.

I found that there are some small things that needed to be changed after installing a site that has been downloaded via downloadMySite.

User Passwords: when you download your site via downloadMySite, none of your users have passwords anymore (this is by design). Unfortunately, this means that none of your users can log in, including the managing editors. So, you have to go into the #membershipGroup table in your root file, open up the users subtable, and then open each of your users and give them a password. Of course, you next have to post a note on your site telling your users to email you for their new password; they can then change the password by logging in and going back to the Join function. (This is a step that I would love to see Userland eliminate, either by creating these password entries for you or just passing the real passwords along in the root file — after all, only managing editors can download the site.)
Incorrect URLs: there are a few small places where your old URL probably will show up, all of which are in the administrative preferences sections. In the Membership panel, the email bulletins probably contain a URL for the unsubscribe page; in my site, it still was the old URL. Likewise, the master page template on the Advanced panel had my old URL as the link for the page title, and I had to change it. Since I currently don’t have a search engine set up, I don’t know if URL for the home page in the Searching panel would have been updated; you’ll want to look at this as well. And last, in the Advanced panel, any links to your own site in the Navigation section will probably have to be changed, especially if you’re going from a site that was down a path folder from the website’s root level to a site that is at the website’s root level.
Incorrect addresses: So far, I’ve found at least one place where the address to my website was incorrect after moving it. In the website root, check out the #discussionGroup/prefs/adrMsgReader entry; this address probably needs to be updated to reflect the new root file.
Shortcuts: your old Manila provider probably had a big glossary of shortcuts, and you probably utilized them once or twice. Now that you’re on your own, those shortcuts may not go anywhere. Your options are twofold: recreate them (easy if you only used one or two of their shortcuts), or ask your provider if they would be willing to give you their glossary. Userland’s glossary, which is what runs behind ETP, can be grabbed here (and they religiously keep it up to date).
Syndication and Monitor Memberships: Of course, if you are currently a content provider for My.Userland, a member of Weblog Monitor, or subscribed to any similar services, you’ll want to go to them and update your information. For My.Userland, you want to go to the Change URL page (you’ll need to know your channel number); for Weblog Monitor, you go to your prefs page.
Redirection: Lastly, you will want to ask your prior Manila provider to provide you with a redirection from your old site to your new one (unless you have worked out something else, or the terms of your agreement with them excluded this option). This is actually a very easy thing for them to do; there’s an (undocumented) feature of MainResponder (the web server framework on which Frontier and Manila are built) that lets the person running the server just put a #redirect entry at the root of the site’s table. This entry is the base URL of the new site, and according to Brent Simmons, this method of redirecting means that all requests to the old URL will be totally rewritten to the new one. (Thus, http://a.site.com/discuss will be rewritten to http://b.site.com/discuss, rather than just being thrown at the root http://b.site.com/. Very nice.)

Once you make these minor changes, you’re done — your site is set up, and you’re ready to rock.

There is a step that makes your life significantly easier when you’re moving your website, and it’s something that you have to implement from the very first day of using Manila, even at the old site’s location: use relative, not absolute, URLs in all of your self-referential links.

What do I mean by this? When you’re linking to some other day’s discussion group message list, you can write the link two ways:

<a href=”http://my.site.com/discuss/1999/12/20”>
<a href=”/discuss/1999/12/20”>

The first one uses an absolute URL — the URL specifies everything, the http protocol, the hostname, the path, and the document. The second one uses a relative URL — by omitting the http protocol and the hostname, the browser just tacks on the current ones to the given link path.

Why does this matter? Because when you move sites, your hostname generally changes. By using relative URLs throughout your site, you won’t have to go in and change all of those links; they will point to the right place, since the browser will just use the hostname from the home page of the site to fill in the rest of the link location.

Note that you should use this practice everywhere — in your master page template (I even use <a href=”/”> as the link for my page title), in your daily entries and stories, in your image SRC tags (if you’re using images uploaded into the pictures section of your Manila site), in your handmade shortcuts, and everywhere else you can think of.

Have fun with Manila. It can do amazing things, and it can make your life easier while doing those amazing things. You aren’t limited to weblog-type sites, or to discussion group sites; I have now written image processing and photo browsing sites, database maintenance sites, and simple redirection sites, all with the exact same basic tool.

Also, play with it, get comfortable on the server side, and spend time tracing through scripts. You learn a lot, find features you never knew about, and have plenty of “Aha!” moments. You will write better scripts in the end, and you will definitely be worth more as a site designer and suite designer than before.

Lastly, continue to work with the community to find features, solve problems, and suggest solutions. There’s plenty of room to grow, both in the community and in Manila.