I have selected another Manila site I host, www.londonpoolscampaign.com as a pre-testing test victim and found quite more than a few of member problems. in addition to the remnants of some sort of mass member creation fiasco (lots of consistently malformed member logins), it looks like there there were tons of members created with no record of a login. This is the result of Manila site owners enabling a poorly conceived commenting system called ‘Radio Hosting.’
This feature invited tons of abuse by comment spammers, and so I am inclined to leave these members and their comments behind, as a site that has been abuse can run in to tens of thousands of members like this. Please feel free to shout me down (okay don’t really shout, I’m a sensitive kinda guy) on this point.
Also I have opted to leave out members who have not logged in for two years or more. This may indeed be harsh – again please feel free to debate this with me. Any content posted by one of these expired users, will be the property of the admin on the new WordPress site.
So here are today’s changes to exporting members from a Manila site to a WordPress site:
1. You have a login, but have never logged in? Your out.
2. You have not logged in for the last two years? Your out. Your posts become property of the new admin.
Cecil re-enforced the point about not having a good Manila glossary to render new shortcuts from the new WordPress (WP) URLs for each story discussed earlier. He’s right, and this has brought about a major shift in the process here. This is important as this is the mechanism that will make sure your links in all your content that point to your own site sill still work after the conversion.
On one hand I want a table of old Manila URLs matched to new URLs, and the only way I can see to do this is to plow thru the Manila site in the exact order it was created – message one then message two then three etc. The trouble is that the glossary is not of a chronological nature. And he’s right, users go in and mess with it all the time.
So here’s the new plan – please hold your nose and remember, reshaping a large amount of complex, interrelated data in to a new schema never designed to house it is by nature a kludgey, messy operation – best to accept homely solutions (and refer to them as ‘novel approaches’) and just move on.
I’ll make one complete pass over all stories, home pages, images, GEMs and news items, accumulating new WordPress URLs for each resource as I go.
When that is complete, and I know the whole truth about every URL in the old glossary and have a new glossary against which I will re-render every Manila story and home page and then post the result as an update to each already existing WordPress page. Remember, this should only be necessary for Manila stories and home pages, possibly discussion posts as replies to home pages and stories since Manila ‘news posts’ do not render shortcuts or Manila macros.
Only a little easier said then done, and I know what your thinking but remember — this a ‘novel approach…’
I updated the flowchart to document this insanity – should have the code actually doing this shortly.
I have several good clients waiting patiently to get their Manila sites moved to Wordpress – don’t worry I’m smashing forward every night.
My latest progress includes getting images and now stories exported with the process. I am also seeing the URLs cross reference information being rendered correctly, for a Manila story for example there could be at least two, maybe more possible URLs:
www.manilaSite.com/stories/storyreader$551
www.manilaSite.com/myNewPuppy (custom path)
www.manilaSite.com/critters/MyNewPuppy (second custom path to same story – possible)
more custom paths…
At this point I am getting the first two – before I’m done I had better go back thru the Manila site’s custom site paths and clean up all the other references to each story.
Also i am building a shadow-glossary with new WordPress URLs for the export process as I go. This is a table of URLs matched to Manila ‘Shortcuts.’ I use this shadow glossary to resolve Manila Shortcut style links in content as I render it for export to the target WordPress site. In English this means that embedded Manila shortcuts will point to their new WordPress URLs after the conversion (this is needed because links like www.manilaSite.com/stories/storyreader$551 will look like www.manilaSite.com/?p=443 for example).
Since I am exporting each bit of content as it was input, and rebuilding the glossary in that same order, it opens the possibility that a user may have added an image or story after a post, then went back to the post to add the shortcut. This is a time travel issue I am going to have to address – no idea yet how to handle this with my chosen route but I’m sure I’ll come up with something…
I got a great note this morning from Cecil Coupe introducing himself and pointing me to a site he has set up to promote another means of converting Manila to WordPress – MvManila. This is yet another approach to getting Manila content unstuck. From what I have read on his site he has a good handle on the problem and has put forth an excellent solution.
This is good for Manila users – we now have three ways to go each with their own trade-offs to consider. My process won’t be perfect and Cecil or Jason’s solutions are good alternatives, each with their own challenges. The long and the short of this is that if you feel trapped with tons of posts in a Manila site and want out – there is help available!
One difference between out efforts is that I am not planning on releasing my code. In part because with total control over the Manila server and the WordPress install I have more flexibility, such as extending the WordPress API to allow for XML-RPC calls that otherwise don’t exist. I am not going to put in the time needed to take such code to a level that it could be released.
This will be a coin-operated service at Weblogger – I’m thinking maybe $79.95 to convert a Manila site with my process that includes a free year of WordPress hosting on our servers. A client would have to get me their Manila root file for me to do this, this can be done using a standard Manila backup feature. One caveat will be that the site’s GEMs must still be on-line from their old host for the move, as GEMs are not embedded in a Manila site’s database (the way Manila pictures, or images are).
I have chalked up a quick flowchart depicting the Manila to WordPress conversion process for the soon to be relaunched Weblogger WordPress Hosting service.
I have started up the debugging process on the Manila to WordPress conversion process.
So far we have all members from the Manila site being created remotely, complete with WordPress style logins – which can’t be e-mail addresses. My sollution has been to take the Manila e-mail login, take the ‘@’ sign and any other non-alphas like periods etc out – making John Doe’s Yahoo address into ‘johndoeyahoocom’ for John’s WordPress login. If John was a Managing Editors, or some other level of editor, hi role on the WordPress site is set at the same operational level.
We also have all Manila New Item Departments being created on the target site, so when we post all the Manila News Items they will have the same categories on the Wordpress site.
Manila Gems, if available from the Gems static server, are being uploaded to WordPress properly and their old URLs are stored with their new WordPress orient URLs so we can do some re-direction magic on the new server. This is nice, keeps old bookmarks, links and search engine referrals working, no breakage.
More to come in the next few days. I may be able to accept a few test users to get some feedback very soon. Stay tuned.
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.
