Big Congratulations to the Mono Team for shipping Mono 2.2!

We've seen growing interest in our support for running mojoPortal on Linux with Mono judging by the increasing forum posts related to it. We try to be very careful as we improve mojoPortal, not to break compatibility with Mono. My testing is usually using the latest Mono built from their svn repository but when a release of Mono comes out I try to also test with the release version since this is what most people are using. Things are progressing rapidly in the Mono project which allowed us not long ago to change our target to the 3.5 version of .NET so that we can begin to dabble in Silverlight, and RESTful web services. Enough of the 3.5 stuff is there in Mono that we can compile and things mostly work but with a few bugs here and there including some bugs in the 3.5 version of Mono's implementation of MS Ajax aka System.Web.Extensions.

Historically I've used my physical openSuse machine to run VMWare server and then I could run the  Mono release virtual machines from there, but after upgrading to openSuse 11.1 I couldn't get my VMWare server to open any virtual machines. So I installed the VMWare Player on my Vista machine this time to test.

The Mono 2.2 virtual machine already had mojoPortal 2.2.6.8 installed and it works well and I noticed the ajax stuff worked fine there but in testing mojoPortal 2.2.8.2-b the UpdatePanels were not being updated in the UI and were logging some errors so I figured if I change the references and use the 2.0 .NET version of Ajax aka System.Web.Extensions 1.0 (since thats what mojoPortal 2.2.6.8 uses) maybe I could get the latest mojoPortal working as well as 2.2.6.8 does. And sure enough, after making this change, the latest mojoPortal seems to work very well ajax and all.

So I've packaged up a new mojoPortal 2.2.8.2-c release to work smoothly with the latest Mono 2.2 release. You can even download the source zip and build it an run it using Mono 2.2, the only thing you'll need to do for that is to copy the contents of Web.mono.config into Web.config so it will have the correct references to System.Wen.Extensions 1.0. The mojoportal-2-2-8-2-c-pgsql-for-mono.zip file is pre-compiled and the web.config is already configured for Mono. You can swap out the data layer dlls if you want to use a different db.

I think this is a major milestone for the Mono Project. mojoPortal is a complex application, and the fact that it runs well on Mono 2.2 shows that the Mono 2.0 ASP.NET stack is pretty solid. The 3.5 stuff is coming along but your mileage may vary.

The Visual studio solution and the Windows release packages are still targeting .NET 3.5. Its very handy that we use a separate mojoportal.mds for MonoDevelop even though it could open the Visual Studio solution, it allows us to do things differently on Mono as needed.

In our svn repository, will be changing our MonoDevelop projects back to reference the 3.5 version of System.Web.Extensions so we can keep moving forward and report bugs so they can get fixed in the next version of Mono. So 2.2 Mono users who want to play with the source code should use the .zip download instead of svn, unless you are also working with Mono built from svn as I am.

Other minor changes in 2.2.8.2-c include a new color picker that I mentioned in my previous post and we upgraded from jquery 1.2.6 to 1.3.

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

Blog Improvements

Thanks to the great work of Tom Opgenorth, Microsoft MVP, long time community member and all around cool guy, we now have support for using Windows Live Writer for posting to the blog feature. In fact I'm blogging this release announcement using it. Live Writer support has been a long requested feature so this should make a lot of people happy. I'm enjoying using it myself, its more rich than the web based editor and has spell checking. Its nice being able to save drafts locally and writing posts while offline. To learn how to configure Windows Live Writer for use with your mojoPortal blog see Using Windows Live Writer with Your Blog. There is also one other small improvement to the blog, its an option to show the post author name with each post for the use case where more than one person is posting in the same blog.

Forum Improvement

This was also an enhancement requested recently, previously forum notification email message only provided a link to the forum post, but now there is a setting to enable including the post body in the email notification.

IIS 7 Integrated Pipeline mode support

mojoPortal can now run in IIS 7 Integrated Pipeline mode, which is new in IIS 7. Previously you had to use "Classic" mode, but now it can run in either mode. The pipeline mode is something specified on the application pool and the default in IIS 7 is Integrated.

NeatUpload 1.3.4

This release we upgraded to NeatUpload 1.3.4. NeatUpload by Dean Brettle is the best upload control for .NET available. The new version among other things adds support for IIS 7 Integrated pipeline mode, which in turn made it possible for mojoPortal to support this mode.

Bug Fixes

This release also includes bug fixes for things reported in the forums since the last release.

Upgrade Notes

If you are running mojoPortal 2.2.7.9 or higher, you can skip uploading the ClientScript folder.

I have not yet created a release package for Mono this release because I ran into a hardware problem on my Mono build machine. I'm working on resolving that now and hope to upload a new package for Mono users tomorrow or the next day.

UPDATE 2009-01-07

I've uploaded the for Mono release package. I can say for sure it works using Mono from svn but I don't have an installation of Mono 2.0.1 so I can't be 100% sure if it works with that release.

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

Bug Fix

The main reason for this release is to fix a bug in the MS SQL version of the blog that was introduced in version 2.2.8.0. I'm surprised it took 5 days for anyone to report this bug, it was causing an error when adding new blog posts and this prevented the friendly url from being created to link to the post. Once it was reported I felt it needed an immediate fix and release. We are on a short release cycle anyway, typically we release every 2-8 weeks but any time a significant bug is confirmed we like to get a fixed release out as soon as possible.

If you are upgrading from 2.2.7.9 or higher, you don't have to upload the ClientScript or Data folders as nothing has changed there. Those are big folders so it should help not having to upload them.

New Stuff

YUI

Even though its only been a week since the last release there are some new things in this release worth mentioning. I've been gradually trying to eliminate the places where we were using ExtJs since they changed the license and we can no longer get upgrades, I'm focusing on YUI and jQuery and MS Ajax for UI enhancements. I previously removed all the use of ExtJs Tabs and implemented YUI tabs. In this release I implemented a YuiGridView, which is an ASP.NET GridView decorated with the YUI DataTable javascript. I had previously implemented a similar ExtJsGridView and was using it in quite a few places in mojoPortal, but now I have replaced all of those with the new YUI version.

Using the Google CDN

We've been shipping all the YUI and jQuery javascript with mojoPortal for a while. YUI is fairly large, its a lot of files and added a lot to the size of our package. Yahoo has had their own CDN (Content Delivery Network) that allowed you to just load the YUI files from the Yahoo servers, but they don't have support for SSL, so in the past it seemed better to include the files within the site, otherwise on secure pages IE users would get the pesky warning about the page having both secure and insecure content. Recently I saw this blog post in the YUI blog mentioning that google is now also hosting YUI on their CDN which does support SSL. So now we can leave out all of that YUI javascript from our package and load it from the google CDN. This is now enabled by default in mojoPortal, though there is a web.config setting that allows you to disable it if you have some reason why you want to host the files yourself, you still can do that, but its up to you to download the latest YUI and configure it in Web.config. We are also loading jQuery from the Google CDN. The only reason I can think of not to use the google CDN is if your site is on a private network and your users don't have internet access. To me that would be a very unusual use case, but in this case you would want to host all the javascript on the server.

WebStore Gets Its First Report

I implemented a Sales Overview report for the WebStore. I debated with myself whether to show you this screen shot, but I generally lean toward transparency so decided to show my own sales on this report. You can see that I'm clearly not making a living selling products yet.

For reference, the store opened on July 23, 2008 with only the Buy Me a Beer product. Event Calendar Pro went on sale August 20th, 2008, and Form Wizard Pro went on sale Sept 29, 2008. Sales are currently only a trickle and I have a long way to go to get to my goal of selling 50 units per month, which is the point where I would start to make a decent living. For now I am still living primarily on savings, but I am optimistic about reaching my goals before I run out of savings. I think I need to add iCal import and export to the Event Calendar Pro and I need to add support for multi page forms or surveys in Form Wizard Pro to make them more popular, and having a few more products would be good. However, I still think the main thing is to improve the popularity of mojoPortal since my products only target users of mojoPortal, and to that end I've outlined some things on my road map that I think will help get there. Anyway, the main idea of the screen shot is to show the new report. The tables are using the YUIGridView I mentioned, and the Chart is ZedGraph.

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

Blog Improvements

Refactored the core meta data system to make it easier for features to control the meta data for their own content. Now you have per post control of the meta data in the blog. Its now possible to use html in the excerpts. If you enable excerpts and don't enter an excerpt, we still generate a plain text one for you of the configured length, but you now have the flexibility to specify the content of the excerpt so you can use images and html, but in that case we don't truncate anything so as not to lose any closing tags, so its up to you to determine how much to include in the excerpt.

WebStore Improvements

Also added meta data support for products so you can optimise SEO for product pages. Also products are now indexed into the site search index and can be found using site search.

Site Search Improvements

I added paging to the results. Previously we just brought back up to 200 results and it was up to you to refine your search if you didn't find what you were looking for. Now you can page through all of the results no matter how many there are.

404 Page Not Found Handler

When a user clicks a broken link to your site or types an url incorrectly, they typically get what is known as a 404 page not found error. 404 s the status code that indicates to the browser (or crawler) that the page was not found. Web servers like IIS and apache have a page about the error that is shown to the user by default in that case but its not the most friendly thing. It is possible to customize the 404 page in IIS or apache, but typically we would rather control it from within our application. The prevailing technique for doing this in ASP.NET has been to declare a custom 404 page in Web.config like this:

<customErrors mode="RemoteOnly" defaultRedirect="yourcustomerrorpage.aspx">
<error statusCode="404" redirect="~/PageNotFound.aspx" />
</customErrors>

allowing you to customize the 404 page and make it a little more user friendly. The problem with this technique is that when it does the redirect it never delivers the 404 status code, it provides a friendly experience to the user by redirecting to a page that does exist so no 404 really occurs as far as the browser knows. This is bad for search engine crawlers because they don't see the broken links either and you don't find out about them as you should from google webmaster tools. Its better if you can get reports about the broken links in your site and fix them. So what you really want is a custom 404 page that provides friendly content but still delivers the 404 status code, but redirecting to this page is what will prevent the status. You could set a status code from within your custom 404 page but since you redirected it won't report the correct url because you are now at the error page url not the missing url. Redirecting is not the correct solution, its just easy.

So I implemented an HttpModule to trap exceptions that indicate 404 errors and instead of redirecting I keep the current url and set the response status code to 404 then I make a server side web request to the custom 404 page to get its content and then just write the content into the reponse. So in effect I deliver the content of the custom 404 page but stay on the incorrect url so the status code will indicate that this url was not found. You can see the status code in the screen shot below where I have firebug showing the status of the request.  I've also added the google 404 enhancement javscript to the cutom 404 page, so for example if a user typos the url for the download page (as shown below in the screen shot) as dwnload.aspx instead of download.aspx, google is smart enough to suggest the correct page.

This seems like an ideal solution as the user gets a friendly page with good suggestions and the crawlers get the correct story about broken urls.

Bug Fixes

There were a number of bugs reported in the forums since the last release which have been fixed. There were some problems with the setup scripts for MySql that affected some installations. There were a number of small bugs resulting from the re-organisation of the code. I think most of these are now shaken out and though the last release was a little bumpy the benefits of the new code structure were worth the trouble.

Upgrade Notes

People often complain about having to upload all the files again, but generally this is always the best thing to do to make sure you don't miss any of the new files. We are on short release cycles so it tends to amplify the problem for those who like to upgrade every release. For this release, if you are upgrading from 2.2.7.9, you can skip uploading the ClientScript folder and Data folder as nothing changed there since the last release. Those are 2 big folders, so it will save you some upload time. Be sure and upload all the rest of the files though, and if upgrading from older versions upload all the files.

Lots of other fun stuff going on. I've been prototyping some things in Silverlight that I will blog more on later.

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

New Related Sites Mode

mojoPortal has for a long time had the multiple sites feature which enables you to host multiple sites on a single installation using a single database. The feature was carefully designed to keep the sites and users completely independent so that each site is isolated from the others from a security perspective. But for some scenarios its desirable to host multiple sites but use the same users and roles in all of them. For example, maybe you want to have different versions of your site for different languages bu you want the same users in all of the sites. Or maybe a university wants to create separate sites for different departments but they want the students to have the same sign in credentials in all of them. This is now possible with simple configuration settings as indicated in the documentation. Multiple sites can be configured either based on host names or by folders beneath the root site. With the folder based sites, since they share a common cookie, once the user is signed into any of the sites he is signed into all of them.

New 301 Redirect Manager

When you create pages in mojoPortal, the page gets a friendly url based on its title, like /fun-stuff.aspx would be the url for a page named Fun Stuff. Now if you change the name of the page later it will get a different url, so for example if I change the name to Really Fun Stuff, its going to get a new url /really-fun-stuff.aspx.

Now from an SEO (Search Engine Optimisation) point of view, its not a good idea to be changing your urls willy nilly. If someone bookmarked your old url you don't want it to be broken, or if its already popular in search results, you don't want it to be a broken link. So ideally, you need to have the old page do a 301 redirect to the new page. The 301 status code tells the browser that the page moved permanently. Now mojoPortal will create the 301 redirect for you automatically when you re-name a page or blog post. However, its still not a great idea to be renaming your pages frequently, you should avoid it generally but if you need to its ok to do it. You can also see the 301 redirect mappings and manually manage them from Administration Menu > Advanced Tools > 301 Redirect Manager. You need to be very careful with this feature, you do not want to create circular redirects where 2 urls redirect to each other.

This is the last Release Targeting ASP.NET 2.0

This release as previous ones targets the 2.0 ASP.NET runtime. I requested feedback in my previous post about changing to target the 3.5 ASP.NET runtime and everyone who responded was in favor. I've already changed it in my svn sandbox and will change it in trunk soon. I find that on a machine with VS 2005 I am still able to build and run the solution as long as .NET 3.5 is installed. Using the Mono 2.0 release I could still get it working if I swaped out the Web.config so it used 2.0 version of System.Web.Extensions. Using the latest Mono built from svn I see that the Mono version of System.Web.Extensions has changed to 3.5, but I'm getting an error running it and will have to investigate further.

So the next release will target .NET 3.5. If someone needs a 2.0 build it will be possible for them to change the build target back to 2.0 (in Visual Studio 2008) and rebuild, because I'm not really planning to use 3.5 specific features in the core projects for a while yet. I just need to use the 3.5 version of ScriptManager to support features like Silverlight that I will use in external projects. Just like our other features, the external projects will copy the needed files up to the main Web project so it can work at runtime. This allows us to move forward and take advantage of new things in 3.5 while keeping general compatibility with Mono and 2.0 .NET. Changing the target to 3.5 NET on the core projects only changes the Web.config file and the .csproj file

I'm very excited to start working with Silverlight 2 and RESTful web services using the REST toolkit. I'm just beginning to do exploratory prototyping now but I'm seeing some very cool possibilities.