Yesterday I implemented a feature to generate a dynamic Google Site Map from the ASP.NET SiteMapProvider used in mojoPortal. My implementation is pretty basic right now, I'm using the defaults for the optional attributes changefreq and priority and leaving out lastmod for now, but I intend to add database fields to capture and manage those properties for each page in the content management system, hopefully before the next release.

You can see the sitemap for this site at http://www.mojoportal.com/SiteMap.ashx

I checked the initial implementation into svn/trunk yesterday and am merging a few improvements now so anyone working with the source code from svn can get it now.

You submit your sitemap to google in the Webmaster tools. Doing so is supposed to help google (and perhaps other search engines) crawl your site and index your content, you know all the SEO stuff to give you more ROI on your web content, blah blah ;-)

Anyway this feature will make it easy to submit your site map and it will stay up to date automatically.

I'm happy to announce the release of mojoPortal 2.2.3.3, its available now on the download page.

New this release:

Added a search feature to the member list

Repaired the broken SQLite data layer, it is now working better than ever using the new Mono.Data.Sqlite library.

Added support for Firebird Sql

Updated to the newest versions of NeatUpload, Lucene.NET, and log4net

Miscellaneous bug fixes as reported in the forums.

If you run into any difficulties please post in the forums.

Don't forget to nominate mojoPortal for the Open Source CMS Award!

I bet there aren't too many other projects out there supporting 5 different databases.

UPDATE 2007-07-26:

I discovered a significant bug today, file uploads are not working in the Gallery, Shared Files and File Manager due to some issues with NeatUpload. Its my own fault really because I upgraded to the latest svn version of NeatUpload instead of the stable release. I did test after the upgrade but not thoroughly, I saw the progress bar and it looked like it uploaded but it did not and in my haste I failed to notice. In any case I have it fixed here by switching to the stable release, just doing some final testing now on Mono and then will be packaging up a new set of files. If you already installed the release files I think the only 2 files that you will need to replace will be Brettle.Web.NeatUpload.dll and Web/NeatUpload/Progress.aspx. I'll post another update later after I have uploaded the new files. Sorry for any inconvenience.

UPDATE 2007-07-26 Part 2:

I've updated the files on the download server with the fix for the above noted bug. As I mentioned, if you already installed the release version from the previos download, the only files to replace are Web/bin/Brettle.Web.NeatUpload.dll and Web/NeatUpload/Progress.aspx

Buoyed by my success in reviving the SQLite data layer I decided to try and get Firebird Sql working. After only 4 days I have it all working pretty well. Its available now in svn trunk and I will be packaging precompiled deployment files for Firebird in the coming release which will ship very soon.

Gareth Goslett had implemented Firebird in the 1.x version of mojoPortal but it has been sitting unused and un-usable for the 2.x version of mojoPortal for a good while. My motivation for taking interest in Firebird was because back when I blogged a little about Gareth's work before I noticed a pretty good uptick in web traffic due to links from sites in the Firebird community. It seems to me they have a pretty thriving community and yet not much out there in the portal/web framework space that does support Firebird so it just seemed like it would be worthwhile to get this working in mojoPortal.

Rather than try to update the old version, I started from scratch figuring that if I'm going to maintain this data layer I want it to be as similar as possible to the other ones. I wrote some Codesmith templates to generate Fiebird tables from MS SQL tables and to generate stored procedures and data access code for standard crud operations. These will allow me to maintain this data layer going forward fairly easily. Then I implemented a FBSqlHelper based on the one we have for PostgreSql. Then I copied the dbPortal.cs from the MySql data layer and with some quick find and replace I was able to compile it against the new FBSqlHelper.  I chose the MySql data layer because its has embedded sql statements rather than stored procedures and I figured that was the shortest path to a working implementation, I would just have to make adjustments here and there for differences in sql syntax. As it turned out I did have to implement stored procedures for all methods where we do an insert to an autogenerated integer id column. This is implemented using sequences (aka generators) in Firebird but the only way I could return the new id to the calling code was using stored procedures so I went through and found those methods where this was needed, generated the procedures and data access code for those methods with a few adjustments as needed and voila thigns were starting to work. Next it was just a matter of finding the bugs where the sql syntax wasn't right. For example where MySql and PostgreSql use syntax like LIMIT 10 OFFSET 10 , Firebird uses SELECT FIRST 10 SKIP 10 * FROM TABLENAME. The most difficult challenge was due to the lack of support for temporary tables but with some creativity I found a way not to need them.

My efforts were guided by the Firebird book, online documentation and Gareth's previous implementation code, so Gareth deserves some credit too. I hope the Firebird community will find mojoPortal useful.

Several versions ago the SQLite data layer stopped working so I stopped making releases with this data layer. When I first implemented WebParts in the MyPage feature I never could get the SQLite version to work correctly because I was having trouble getting the blob data in and out of the db due to some issue in the Mono.Data.SqlitClient library which we were using for data access with SQLite.

Not long ago the Mono team revamped a new library, Mono.Data.SQLite, to support 2.0 .NET data access with SQLite and the old library is no longer recommended for use. Yesterday I was able to repair the mojoPortal SQLite data layer by switching to the newer library and doing just a little re-working of code in a few places. The best part is that blobs work well using the new library so I was even able to get WebParts working with SQLite.

The fix is in svn trunk now for anyone interested and next release we will include a package for SQLite. The interesting thing about SQLite is that it only requires a tiny dll and file acess to work. So for instance it should be possible for me to distribute a db already populated with default data with no need for any database setup. Pretty cool! Of course for a real web site I would still recommend to use one of the more robust platforms to get best performance.

Hey mojoPortal community, please nominate mojoPortal for the PackT Publishing 2007 Open Source CMS Award.

Nominations begin July 16, 2007