I am a little confused about the portal/site architecture for my new site.

I have decided upon one installation, serviced by two databases (DNN data and business-specific data).

There are four classes of users:

• The web-surfing public – site needs to be brochure-like, glossy and attractive.
• Registered users – regular clients (about 100 in no.) who need an      industrial-strength site to read and write their own specific/filtered data, as well as access a whole lot of reference material (prices, timetables etc)
• Office staff –will need access to DNN admin functions as well as other information (procedures manuals etc); an intranet.
• On the-road staff – will need a subset of the office-staff information.

A large amount of the information will be common to all users.  However, the look and feel of the relevant pages will be different, especially between the public-access areas and the registered-users areas.

I think I have two approaches:
A.    Three portals, each a parent,

• one (for the registered-users) associated with the main domain; and
• the other two (general-public and the office/on-the-road) using sub-domains. The split between office and on-the road would be done by roles and permissions.

This approach seems to have advantages: one installation, all portals share the common data sources, redundancy through portal independence, and different ‘look and feel’ can be readily achieved across the different portals.
The only downside I can envision concerns the maintenance effort. I can’t find any information about sharing pages across portals (‘modules’ yes, but nothing about actual pages).  For instance, I will have timetable information that the four user-classes need.  Can I make up one page and reproduce it across all portals, and update in it only one place? Or does a page have to be built for each portal and then, in due course, be individually updated (ie in terms of the presentation – not the data, that will be dB fed)? 
OR….
 
B.    Just have one portal and control access by use of roles and permissions.
The upside would be that everything would be consolidated, so less administration (except it ‘it’ went down).  There would only be one page for the likes of Our Timetable; not the multiple update situation of option A.  
However,

• the ‘look and feel’ would have to be a compromise across the user streams    

• Registered users would be presented with all the Unauthenticated/All Users information – perhaps too cluttered
• The menu bar could be big and clumsy.

Which way to turn? I am tending to think A, or have I missed something and there is another standout option? 

Since my post a moment ago I have had another thought.

Perhaps my Option A is the way to go and the update workload can,
indeed, be handled by sharing modules. 

I'm new to DNN so am not yet into building my own modules, but I have seen that (in Issue 17) Lee shows how to assign modules such as 'Events' to a number of portals.  

My assumption was that the modules that could be assigned were the off-the-shelf/unconfigured modules.  

However, is it the case that configured modules can be shared in the way Lee described?

For example, can the standard 'Events' module be configured in terms of presentation and data into 'Easter Events', 'Christmas Events' etc  and then be made available to all portals?

If that's the case, then my problem is solved.  Isn't it???

That is: use whatever number of portals is necessary (each with their own overarching look and feel), and then plug in the required modules with the relevant nuts-and-bolts data.

I think that multiple portals within an installation is likely the way to go.

But, I think that you may have misinterpreted Issue 17. I believe that the tutorial shows how to create page "templates" so that similar pages can be created in other portals. You can also have portal templates.

There are third-party modules that are designed to share data across portals. I don't have any experience with them, so can't make any knowledgeable recommendations. But, look at Snowcovered, and feel free to come back here to ask questions.

With multiple portals, you'll also probably want to share users or subsets or users across portals and you'll probably want to make it so that people only have to login once. There are also third-party solutions.

And, you could have everything in one site, and use different skins for different parts of the site to get the different looks that you want. You could have a "main" home page, but use subsidiary "home" pages for the other parts.

Now, as you said that you are a newcomer to DotNetNuke, you'll probably want to get familiar with the product first. I'd recommend that you start with a "sandbox" site, in which you can experiment. Then maybe you want to start building only one of the sites you've mention. Once that is done, you can get on with multiple portals or multiple portals within an installation.

In any event, please come back often and ask questions. We're here to help!

In addition to the info Joe has provided, I would also implement RSS feeds. - so, for instance you could use an articles module which creates RSS feeds, add the content you require into the articles module, and then display the content of those articles using an RSS feed in the other portals, it maybe worth having a look at Issue no 3 as this looks at RSS feeds in detail.

Where does time go!? We first discussed this topic back in 2008. And, of course, I'm still a keen DNNCreative subscriber. Great work from you guys.

My DNN 4.8 site (www.exemplaronline.com.au) has been running well from the start but my conscience has kicked in and I am about to do a complete, start-from-scratch rebuild using 6.2.

I thought it prudent to check to see if our early conclusions still hold true. A dominant aim is to have an architecture that gives SEO the greatest chance of success.

Background
Physically, I am hosting the site (and it’s related booking-program databases) on my premises. I use a one-site approach that caters for all roles. Logged in as admin/host, you see 23 tabs on a horizontal menu bar (using Flex 2 skin by DrNuke). I have broken the pages/tabs into three ‘sites’ by using roles and page permissions and no more than a few tabs appear on each ‘site’. The ‘sites’ are for Unregistered users (eg brochure style pages, booking form), Registered users (eg filtered, user-specific booking information (using Indoogrid as the data access layer - great product, but in death throws, aagh!)), and our Staff (eg global views of all users and their data, day-to-day management tasks). There are pages common to both (eg Our Services, Our Fleet etc), and there are others that only administrators see (eg Admin, Host , PayPal Management)

Conclusions
DNS, URL, Aliases, IIS configuration/maintenance is easy. Everything is pointing in the one direction.

Logging In. Not ideal. With the standard DNN login you get to only have one destination/landing page. My staff have to put up with an error message and then go to their correct home page. I haven’t dug deeply but I understand new login modules can redirect logins based on specific roles. Correct? Any recommendations?

Privacy/Commercial Sensitivity. All registered (ie contracted) users have to access their corporate site via the home page of the public site. I therefore dare not display ‘specials’ that they are not part of.

General Configuration/maintenance. A bit messy because I am working across 23 tabs, constantly scrolling left and right. It was even very difficult to find a skin that would span so many tabs. DrNuke were terrific and modified theirs to suit my purpose (they build a ‘wide’ view). Flex 2 is excellent but I am a bit uneasy about being limited in the skin(s) that I may be able to use. (PS a blinding flash! I could go vertical! Or a combination of the two.)

Page Maintenance. Very easy. Many pages are accessed by more than one role but, since there is only one instance of these common pages, maintenance is minimised. (However, I believe it is now much easier to develop and maintain dispersed data by using portal and module templates, and by sharing data and users across portals.)

Search Engine Optimisation. A large percentage of the use of the site is by registered users. I have a feeling that the back-end of the site is increasing the popularity of the front end (via number of visits etc); where I need it.

New Considerations
Mobile Site Redirection. I haven’t researched this yet, but I know I have to! Is it a factor here? For instance, if redirections have to go to other portals (rather than to other pages within the portal), that will be a clear architectural consideration.

Social Media. Again there may be similar, governing considerations.

Way Ahead - Options
One. Status Quo. It would be much easier for me to stick with the current architecture, and use the latest modules to streamline a number of areas (eg login). However .... probably still limited by skin choice. SEO: is it hindered/clouded by having such a diverse set of pages? ... and with the back-end not actually requiring any SEO. Or is it improved by, as I mentioned above, the back-end assisting the front-end??

Two. Or should I build each of my ‘sites’ as a Portal (probably all parents)? (With either separate URLs or as sub-domains?) I would use templates, and data and user sharing across portals. No more messy 23-wide menu. I would have unlimited access to skins (eg the public site could be fancy, the office site could be plain). Perhaps, if the public site were to be small and specific, then SEO may be more concentrated and effective. Is that how it works?
(PS it’s probably worth mentioning here that we have an SEO challenge in that we have a diverse product range that doesn’t sit neatly under a few key words (ie airport transfers, weddings, conferences, charters, tours, etc ... across five geographic regions). People are searching for ‘airport transfers Cairns’, or ‘weddings Port Douglas’ etc etc etc PPS Should I have one portal for each product grouping, say by region? ... and still sharing pages etc across the portals. Decisions!? ))


However ....... DNS configuration etc would be more involved, but certainly not complicated. Even with modern modules, maintenance of data across portals would be increased. (again, no problems). My understanding is that I would have to hand out more than one URL: one for the public site and then others for the other ‘sites’. That’s not ideal; it would be cleaner to talk/advertise in terms of one URL. But then again, users would each come in via their own dedicated home page and be presented with a skin that best fits.

Three. Any other/better ways??

Conclusion
I am tending to think Option 2. But, then again, I sure ain’t no expert!

As you can see, I am confused by the possibilities! I know that it is a big ask but I would certainly welcome any advice that anyone could give me, and no doubt others with a similar headache.

Regards, Gordon

I also like option 2. I would put all three portals in a single install.

The good news is that you really do understand the options.

I believe that V7 of DotNetNuke will have some features that permit sharing users and content across portals better.

Was there any updated on this? I am interested in this use case and its implementation, as the thing we are trying to do is very similar and so far, I liked the approach(es) discussed.