Tue 21 Feb 2006
Over the weekend we had some suspicious activity involving the wiki module in our abandoned PostNuke project. This prompted a major cleanup in the oceaninfo-dev to remove all unused CMS’s that were used or tested by various projects.
The CMS’s included: PostNuke, Xoops, Mambo, Drupal, WordPress, OpenDocMan, and Plone
The projects included: Ocean Informatics, Interoperability, CCE LTER, and Palmer LTER
For some of these projects, I downright deleted the code-base and corresponding database. I only did this for projects/cms’s I was sure have never (and will never) be used:
- Interoperability/WordPress - we had installed a blog for interoperability, but it was never used
- Interoperability/OpenDocMan - an open source document manager, never used
- Palmer LTER/WordPress - I played with this last month, but have since migrated to a file structure so this is no longer needed
- CCE LTER/WordPress - Same as Palmer LTER
- Plone - Open-source CMS we are not using, nor are capable of running at this time since it requires a ZOPE environment? We’ve had the installation package sitting on our server taking up space. I deleted this (we can always dl it again if we want).
- Additionally, I removed some backed-up code like ‘interop2′ and ‘interop3′ which I once saved mainly as snapshots.
Don’t worry, I didn’t delete everything. For the more significant sites (for historical purposes, etc.), I created tar archives of the code-base and the sql dump so that they can be easily recreated should we want to play with them again. These tar files are stored in project/oceaninformatics/web_archives:
- ccemambo.tar - CCE LTER site in Mambo
- ccepn.tar - CCE LTER in PostNuke
- ccev1.tar - First version of the CCE LTER site. We originally entertained building the CCE LTER in a static file structure and also in a couple CMS’s (above)
- interop_xoops.tar - The interoperability site in Xoops. It ran in Xoops for about a year. Eventually we migrated it out of Xoops, and the entire site got a complete overhaul just last month.
- oi_drupal.tar - Ocean Informatics in Drupal. Not much there, but we can archive it anyway.
- oi_mambo.tar - Ocean Informatics in Mambo. Same deal as Drupal.
Ironically enough, the one Project/CMS I left intact for now is our Ocean Informatics/PostNuke site. Because we have some referential content in there, I would like to make sure I find the best way to archive/migrate the content. I have since disabled the wiki module (since that’s what gave us the warning emails).
The referential content I am referring to is our old News blog: OI Core and OI Dev. My original plan was to save a couple web pages spanning all entries. However, I realized that this approach wouldn’t save comments for any posts.
What would be the best way to archive an array of threads? Should we import the old posts into WordPress? Or should we recreate a structure of nested web pages, where each sub-page shows the entire thread for one post?
2 Responses to “oceaninfo-dev cleanup”
Leave a Reply
You must be logged in to post a comment.


February 21st, 2006 at 4:45 pm
And would the answer as to archiving for the past Ocean Informatics PostNuke site be the same if the question were asked about the current website?
-karen
February 22nd, 2006 at 12:29 pm
That’s something we should worry about if we ever decide to move on from WordPress.
I feel I should rephrase my question: It’s not a matter of how, but a matter of why. We could easily import the old PostNuke posts into WordPress, but why would we want to?
Aside from being a bit time-consuming, are these posts valuable enough to be archived within WordPress, or are they just noise that would clutter our archives?
I feel comfortable letting them stay in PostNuke, unless there are security concerns for leaving it up. Likewise for WordPress, should we ever move on, I would just keep the posts here.
Generally, starting a new blog is a chance to refresh. Why initially clutter it up with old content that is mostly no longer relevant?