Welcome, Guest. Please login or register.

Author Topic: (RFD) Lessons learned in the Amiga.org migration process.  (Read 1503 times)

Description:

0 Members and 1 Guest are viewing this topic.

  • Guest
(RFD) Lessons learned in the Amiga.org migration process.
« on: May 10, 2009, 03:10:32 AM »
Learned a bit more than I wanted to know in the last couple of weeks.

Pulled the trigger Friday and spent $180 out of pocket on a copy of vBulletin for the site, after getting news that PHP4 would be dead soon.

After reading two entire books on Drupal and spending countless hours, vBulletin seems like the most appropriate way to move forward without losing all of our old forum posts or user accounts.

Indeed, the import went pretty well, except that there are about 75,000 dead posts on the site -- mostly from around the 2001/2002 time frame which are corrupt and cannot be imported.

Why are they corrupt?  Well, between the initial hack and our attempted recovery, along with the data corruption which happened in -- as I recall -- 2002, (when we all had to start over), either the thread is an orphan with no topic, the topic has no threads, or the user account attributed to the thread no longer exists.

For those of you who take pride in your post counts and are still here 7 years later, you might be affected.  Please understand -- nothing I can do about it, as your post counts are really invalid anyway.

I'm *not* saying people will have zero posts, but for example, where I have 3200+ now, under the new site, that number seems to be about 1900 or so.

If it really matters to you, I can let you know how to find it under the new system.

Which brings me to the more interesting news....

It seems that vBulletin, while allowing you to create themes and styles, does not operate in a "template" fashion the same way other sites do.  In other words, it pretty much requires CSS to function now.

What does this mean?  This means that if we end up going to vBulletin because PHP4 dies (*and it is*) then the only way to get the antiquated Amiga browsers to work is if they support CSS.

I know that will more than likely piss off the purists, but again, CSS is a 12+ year old technology and it's almost inexcusable that it hasn't been added to -- at a minimum -- later versions of iBrowse.

Then again, with everyone threatening to crack iBrowse because the author disappeared, I can't say that I blame him for not wanting to continue.

I'm not saying the site can never be HTML 3.x compatible for the old Amigas, I'm just saying that the amount of core code upkeep -- which would have to be reinvented for every new version -- for so few users is simply not practical.

Sorry.  I'll keep it Amiga compatible where I can, but at this point, whether we went with vB or Drupal, I can't make promises.

The new theme will look as close to the current theme as I can possibly make it, but it just won't look good on a 15 year old unsupported Amiga browser.  Again, sorry.

Why don't I do xyz?  Because it's not the right way to go.

Why don't I just run xyz?  Because moving to yet another nuke/xoops/etc clone doesn't get us anywhere if I have to keep hacking the code to make it Amiga compatible.

I really am at a loss here, because like most applications which once ruled the world from an Amiga keyboard, the Internet has just moved to where it's time to move up, even if that means having to resort to using a PC or mac to read the site.

Feel free to chime in, but unless you have the one in a million idea that I haven't thought of, not sure what I'll have to say in return.
 

Offline djbase

Re: (RFD) Lessons learned in the Amiga.org migration process.
« Reply #1 on: May 10, 2009, 03:26:08 AM »
I don't see a real problem about CSS. For example all NG-Amiga systems have CSS-capable browsers and most people have a modern PC or Mac so there might be only a little few people left which could feel pissed if there are any at all. There are many other amiga-related sites around which uses CSS and nobody seems to have a real problem with.
AMIGA 1200 | Vampire 1200 II | 128 MB RAM | Indivision AGA Mk3 | 256 GB SD | AmigaOS 3.2.2
AMIGA 600 | Vampire 600 II | 128 MB RAM | Indivision ECS Mk3 | 256 GB SD | AmigaOS 3.2.2
 

Offline GadgetMaster

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2177
    • Show only replies by GadgetMaster
Re: (RFD) Lessons learned in the Amiga.org migration process.
« Reply #2 on: May 10, 2009, 05:57:02 AM »
Hi Wayne, I guess you feel a bit like this poor guy under the seesaw: :ponder:

Just a message of support for your decision to migrate and I hope others can be positive too.

Change is inevitable which is sometimes a good thing as it helps us appreciate what we take for granted.

Keep up the great work. If there's any way I can help (maybe with testing and stuff) just give me a shout.
 

Offline benJamin

  • Full Member
  • ***
  • Join Date: Mar 2003
  • Posts: 226
    • Show only replies by benJamin
    • http://cms.jaminjay.com/
Re: (RFD) Lessons learned in the Amiga.org migration process.
« Reply #3 on: May 10, 2009, 06:30:29 AM »
I haven't been able to find anything useful in vBulletin yet, but Drupal has some useful API stuff for the possibility of having the die-hard non-CSS browser users to build their own front-end and let the core team get on with the job of servicing the rest.

Keep up the good work.


jJ
Amiga.org - The site for MiniMig support and news.
blakemilesmusic.com
 

Offline Colani1200

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 707
    • Show only replies by Colani1200
Re: (RFD) Lessons learned in the Amiga.org migration process.
« Reply #4 on: May 10, 2009, 08:13:52 AM »
Sounds like a good route. Good luck in the further migration process Wayne.

Quote

DJBase wrote:
I don't see a real problem about CSS. For example all NG-Amiga systems have CSS-capable browsers


Exactly.
 

  • Guest
Re: (RFD) Lessons learned in the Amiga.org migration process.
« Reply #5 on: May 10, 2009, 03:36:40 PM »
Quote

benJamin wrote:
I haven't been able to find anything useful in vBulletin yet, but Drupal has some useful API stuff for the possibility of having the die-hard non-CSS browser users to build their own front-end and let the core team get on with the job of servicing the rest.


The reason behind my decision was actually a logic progression.

- vB allows us to save the forum and user information which is by far the most important.

- vB has an image gallery that we could use to save the images from the old site, albeit we will need to do it manually.

- vB can be expanded indefinitely via a "blank page mod" meaning if we want a news module, I can write one.  

- vB has great and useful features such as social groups (which for example, I can set up a "Amiga.org steering committee" and others like SACC could easily set up an "Amiwest 2009 planning" group.

- vB has blogs, which not everyone will find useful, some will.

- vB can be expanded with project management tools which would allow programmers to set up "projects" on the site and manage bugs, suggestions, to do lists, etc.  Just for myself -- again, another example -- it will be nice to use to track bugs, lists, and feature requests for the site itself.

I fully admit that Drupal will more than likely be able to do all those things and more, but again as others have pointed out, Drupal is not a CMS (ready to go out of the box like xoops or other CMS engine) but a framework around which you have to completely build up a site from scratch.

Besides, even with expansion, since Drupal is not focused on being a forum software, the forums and forum management for Drupal seem to completely suck, no matter how hard they try.

Since the PHP4 server switch will happen before 5/31, I frankly don't have the time to go to Drupal and make it usable for this community, and history has taught me how absolutely impatient this community can be.  Especially with change.

Besides, since the forum and user data is already salvageable by vB, there is NOTHING stopping us from embracing it, then developing a Drupal system up around vB and tying the two together.

The big step, and reason for my choice was to be able to save the forum and user data, which will then have it in a modern format that can later be transferred into any other program we decide to embrace.

Wayne
 

Offline Hattig

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 901
    • Show only replies by Hattig
Re: (RFD) Lessons learned in the Amiga.org migration process.
« Reply #6 on: May 10, 2009, 11:04:54 PM »
Good luck with the move. It's a big one, but you are correct in realising that it is important to keep the existing posts and data, and that the world moves on.

Short of creating a web service front end to vBulletin and writing a custom Amiga application to access data and present it externally to a web browser, I can't think of a way to get a non-CSS supporting browser to work nicely. And if you create such a web service, you might as well create a non-CSS version of the site, it's such a large project.