Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Portal InheritancePortal Inheritance
Previous
 
Next
New Post
1/11/2008 2:38 PM
 

Actually, I am not talking about the look but the content and structure.  Our locations are in five states and some content will come from corporate, local locations and relevant RSS feeds (from associations in their respective state).  They want to add additional menu items and portlets to the "inherited" template, which comes from corporate.  If they are able to inherit then it will make our maintenance much easier.  Otherwise, we may have to support a possible 65 portal systems.  Realistically, it will probably be more like 30 but you never know.

We are looking for a system where it will make our job in IT a lot easier.  Some "approved" locations would be allowed to change the design but corporate wants primary control over their content.

 
New Post
2/4/2009 10:45 AM
 

Please reads Neil's requirements below.  Our company has the same requirements.  I've looked through the documentation and am still unsure DNN will satisfy our needs.  We also would like our subportals to have subportals.  What is the feasibility of this type of functionality in the current realease?  My apologies for not being more diligent in researching the questions but time is the issue here and our CEO is expecting quick answers.

Neil Fedin wrote
I'm very new to DNN and am trying to evaluate it to see if meets our business needs.  I've installed DNN and played around a bit, but I can't find some the big features I'm looking for.  I figure I should ask the experts before I dismiss the product.

The biggest feature I'm looking for is Portal Inheritance.  Our non-profit company has hundreds of local chapters nation wide.  We'd like to give them each their own website to faciliate communication.  I would like to create one portal and then have multiple sub-portals that inherit the style and content from its parent.  This way, if content was updated in the parent portal, it would also be updated on the child portal.  These sub-portals also need to have the ability to add/update their own custom content. 

The closest thing I've discovered in DNN to this is using the Templates when creating a new portal.  Unfortunately, the layout and content are only copied once to the new chapter.  If the template changes, the portal that was created with it does not also update.

Is there anyway I can accomplish what I'm looking for using DNN?

Thanks,

Neil

 
New Post
2/4/2009 11:46 AM
 

Cleverone wrote

Please reads Neil's requirements below.  Our company has the same requirements.  I've looked through the documentation and am still unsure DNN will satisfy our needs.  We also would like our subportals to have subportals.  What is the feasibility of this type of functionality in the current realease?  My apologies for not being more diligent in researching the questions but time is the issue here and our CEO is expecting quick answers.

 

As is hinted at in the discussion above, your answer is yes, and no.  DotNetNuke will support parts of what you're looking for out of the box, and third-party extensions will extend this coverage.  Specifically:

  1. Portals may be created at arbitrary addresses.  You are free to create http://mynonprofit.com, http://mynonprofit.com/chapter1, http://mynonprofit.com/chapter2, http://mynonprofit.com/chapter2/subgroup1, and so on.  These portals, though having hierarchical addresses, are not meaningfully associated in any other way.
  2. Accounts created at one portal (http://mynonprofit.com) may be used to authenticate with other portals (http://mynonprofit.com/chapter1) with distinct authorization per-portal.
  3. With proper templating and skin deployment, you may ensure that the same skins are deployed to all of your child portals.  Portal administrators are free to override these defaults, but hosts can to some extent limit these choices.
  4. Templating will allow you to create initial content on a child portal.  This content is not updated, or linked in any way, with other portals (see #6 below).
  5. Menu and page structure are portal-specific, and are not shared in any way between portals (see #7 below).
  6. Third-party modules and providers may, to some extent, remedy the issues outlined in #4 above.  For example, there exist modules that allow content to be shared between portals.  Mr. Hammond above indicated that the Engage:Publish module will in the future support this functionality to some extent.  I suggest contacting him (or Engage) for further details about if this might meet your needs.
  7. While I am not aware of any existing module that will satisfy menu synchronization referred to in #5 above, a menuing provider could, in theory, be written to coordinate page structure across portals.  If this doesn't yet exist as a module, it would certainly be a good opportunity for someone.  I would rank it as an moderately advanced development task for an experienced developer familiar with DotNetNuke.

Much of the equivocation you see in this thread is due to the fact that, as DotNetNuke is a very flexible platform, almost anything is possible (especially with the large ecosystem of third-party modules).  The exact relationship between precise fulfillment of your requirements, budget, and in-house development resources is the wildcard here.  One can accomplish almost anything, especially with some flexibility on the requirements end.  Regardless of your ultimate CMS choice, your outcome is likely to be a mix of the functionality offered by the platform and the policy that you develop for the people using it.  

Hope this gets you started!

Brandon


Brandon Haynes
BrandonHaynes.org
 
New Post
2/4/2009 3:11 PM
 

Thanks for detailed analysis of the requirements.  I saw in the demo that the sub portals (i.e. http://mydomain.com/chapter1, http://mydomain.com/chapter2, etc, ...) can have a separate domain mapped.  This is important for the users of our sub portals.  Can these sub portals have a subportal level?

We're obviously going to need to install and play around with the system.

 
New Post
2/4/2009 3:43 PM
 

Hi Cleverone,

DotNetnuke will support an arbitrary URI for a child portal (e.g. http://mydomain.com/a/b/c/d/e/f/g).  It accomplishes this by placing a Default.aspx file in the target directory which analyses the request and redirects accordingly.

Brandon


Brandon Haynes
BrandonHaynes.org
 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Portal InheritancePortal Inheritance


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out