I mentioned in this previous post that I'm working on a new variation of the Multi Sites hosting feature. This work is being sponsored as open source development by one of my customers. I'm not sure if I can mention who the customer is so for now I will leave them nameless.

For a long time it has been possible to host multiple sites using a single installation of mojoPortal with the secondary sites defined by different host names. The new feature provides an option to define the secondary sites by the first folder after the host name like http://somehostname/somefoldername.

The initial implementation of this has landed in svn/branches2.x for anyone interested in trying it out or providing testing. I'm sure there are still a few bugs here and there and am working to test all the features and fix any outstanding issues before making an official release.

I've also updated the documentation here:
http://www.mojoportal.com/muliplesites.aspx
and here:
http://www.mojoportal.com/multiplesitesbasedonfoldernames.aspx
with information about using this feature.

Some interesting changes have been committed to svn branches/2.x

One big change is that I have created dedicated physical pages for the admin features (SiteSettings, Role Manager, Content Manager, etc) which until now have just been modules that plug into the content sysem the same as the content modules. Now there is an Admin Menu page with links to all the admin features, and they no longer appear in the main menu. I did this for a number of reasons.

I'm planning to make it configurable which features are "installed" but the admin features should always be there. In the previous model because the admin features just exist on pages in the content system, it is possible to remove the admin features from the site using the content management features with no way to get them back easily without doing it directly in the db.  So separating the admin features into physical pages outside the content system seemed the way to go. This change also helps with multi site installations using one web and db because when new sites are created we don't need to create admin pages in the content system in the new site either.

There are now 2 new skins named treeview1 and treeview2 which are really coopies of the existing jwv1 and jwh1 skins but modified to use the TreeView control for the menu. One of the cool things about the TreeView is its ability to load nodes on demand from the SiteMap. In large sites with lots of pages and deep hierarchies this can be a performance benefit.

When using the normal Menu all the navigation links for the entire site are rendered as markup into the page, typically showing only the top level and using mouse over to reveal deeper nodes. If you view the source you see the Menu rendered as ul and li elements in the markup and every link is there for the whole navigation tree which can be a lot of markup in a large site. The more markup there is the bigger the page size and the slower the perfomance. Since the menu is on pretty much every page its part of the payload of most requests.

The TreeView control also renders as ul and li elements but with PopulateOnDemand it will not render the markup for invisible nodes. When you click a node it will expand and add just the nodes requested. You can see this when you view the source of the page. If you want to check it out, the treeview1 skin has the TreeView for the menu and the treeview2 skin has a regular horizontal menu for the main menu and a TreeView for sub pages beneath the top level. To see for yourself, create some deep hierarchies of pages and view the source of the page as you drill down from the top.

I also shortened the 3 column names on the mp_Users table and 2 column names on the mp_Sites table. Recently there has been some renewed activity by the Firebird data layer team. Firebird doesn't allow columns longer than 31 characters so this was a barrier in implementing the 2.x mojoPortal data layer. By renaming the columns this barrier is now removed so hopefully work will proceed for the Firebird data layer. Thanks to Gareth for all his hard work implementing Firebird for 1.x mojoPortal!

Some have noticed that the SQLite data layer for 2.x mojoPortal was broken a few versions ago and has not been shipped with the last few versions. Joseph Hill, who initially implemented the SQLite data layer has agreed to look into, so hopefully that data layer will come back to life sometime soon.

The National Recycling Coalition (NRC) recently revamped their web site using mojoPortal.

The project was managed by DDB Seattle, which is part of DDB Worldwide Communications Group.

I helped with the project as a consultant, providing some help with skinning and custom feature development.

"The NRC represents every sector of the waste reduction field including local recycling coordinators, corporate environmental managers, state and federal regulators, environmental educators and advocates, and waste management professionals. NRC's objective is to eliminate waste and promote sustainable economies through advancing sound management practices for raw materials in North America."

Its very exciting to know that mojoPortal can play a small part in such an important cause as Recycling. It was also a pleasure working with the good folks at DDB Seattle, I hope to have an opportunity to collaborate with them on other projects in the future. They are true professionals.

I know some users have been getting frequent svn updates directly from branches/joesandbox2

I've suggested using it in the past in some forum posts but I want to give a heads up to anyone working from svn code to use branches/2.x instead

Instructions for getting the source code from svn on Windows with TortoiseSVN can be found here:
http://www.mojoportal.com/tortoisesvn.aspx
and for those who want to experiment with mojoPortal on Linux, svn instructions are here:
http://www.mojoportal.com/gettingthecodewithsvn.aspx

You can rely on branches/2.x being relatively stable. I merge my changes from branches/joesandbox2 into branches/2.x when I believe them to be stable enough to share with other developers.
Use branches/joesandbox2 only at your own risk as I need to be able to commit changes there whether they are final/correct or not just to make sure I never lose work due to hard drive failure.

I mention this because I'm about to start working on some things that may make things bumpy in branches/joesandbox2 because I will be making changes in the core and will probably implement some things in MS SQL long before I get the other data layers implemented and therefore joesandbox2 will be broken for the other layers until I implement them.

I have a customer who is sponsoring a new feature, or really a variation on a current feature and this is what I'll be working on. The customer has been using mojoPortal for a few small projects and they want to use it on a larger planned project but to meet their needs they need the multiple sites feature to work differently than it currently does. Currently the site id is determined by the host name so mojoPortal can host multiple sites on a single web installation and db as long as each site has a different host name like this:
http://host1/
http://host2/

Note that on the internet the fully qualified host name is usually used so the pattern is:
http://hostname.domainname.topleveldomainname
like
http://www.somedomain.info
where www is the hostname, somedomain is the domain, and info is the top level domain

Of course you also often see the pattern:
http://domainname.topleveldomainname
like
http://somedomain.com
the reason this works without the host name is that the domain has a default host that is used when no specific host is specified

My customer needs the ability to create new sites in sub folders beneath the host name like:
http://hostname/site1
http://hostname/site2
or examples with fully qualified names would be:
http://www.somedomain.com/site1
http://www.somedomain.com/site2

So in these examples the hostname is the same and the site id will be determined by the first level folder.

I don't plan to eliminate the hostname driven feature but to add a config option to use the foldername instead.

The sites will be completely independent with their own users and content just as they currently are using hostnames.

Some of the challenges will be in making sure the friendly url re-writing adapts correctly and making sure sites aren't defined using folder names that clash with physical folders

This feature is being sponsored as open source development which means it will become part of mojoPortal and other users of mojoPortal who may desire this functionality will benefit.

I've just updated the documentation about localizing mojoPortal

http://www.mojoportal.com/localization.aspx
 
I'm renewing my push to improve documentation as I believe this is critical to improving the popularity of mojoPortal, which in turn is crucial for my business plan and trying to make a living working on mojoPortal.

Right now my top priorities are documentation and preparing for a new release with the recently completed extensible User Profile system.

The e-Commerce Solution project is temporarily on hold for now because the deadline has been pushed out by the one sponsor I have for this project and because the project is currently under funded and therefore not as high on my priority list.
 
Currently I have one sponsor pledging $1000 for this feature. I would really like to find some additional sponsors to make it worthwhile for me to work on the e-commerce feature so if you are interested in this feature and have any funds in your budget, please consider sponsoring this project. Please contact me if you are interested.