We're looking at building a community section as an add-on for Umbraco. This will consist of members with profile pages, inboxes, galleries, friends, favourite articles, etc. This shouldn't be too much problem I don't think - some new document types, some custom controls, some new tables + XSLT extenders. At the very least, though, each member will have a profile page (which will be a document) under the URL format /members/X which means potentially thousands of nodes under the members node - my question is how much will this negatively affect performance? I read elsewhere on the forums about someone with 5,000 child nodes and this produced noticable performance degredation (this may have just been in the backend, though, I don't rightly remember). I know there is a global property in Umbraco for alternate URL's for content items, I guess I could place the /members/X URL into this property and have the nodes stored in a date seperated folder structure? What would the best way be?
I'd probably look to have just 1 member page, and use URL rewriting to pass in the name of the user who's details you want to display, that way you also don't need to maintain pages for every user, but I guess that really depends on what you want the profile page to do.
Passing the username is via a querystring is against requirements, I can't use the built-in alternate URL parameters of a document with a querystring can I? And I don't want to go writing a new ISAPI DLL to handle the usernames so I think I'll just have to create each profile page as a new Document.
The SocialFront project looks interesting, a trimmed down version of our requirements but potentially a good building block. I'll be sure to make the project available once complete, whichever route we take.
Community Section
Hey hey,
We're looking at building a community section as an add-on for Umbraco. This will consist of members with profile pages, inboxes, galleries, friends, favourite articles, etc. This shouldn't be too much problem I don't think - some new document types, some custom controls, some new tables + XSLT extenders. At the very least, though, each member will have a profile page (which will be a document) under the URL format /members/X which means potentially thousands of nodes under the members node - my question is how much will this negatively affect performance? I read elsewhere on the forums about someone with 5,000 child nodes and this produced noticable performance degredation (this may have just been in the backend, though, I don't rightly remember). I know there is a global property in Umbraco for alternate URL's for content items, I guess I could place the /members/X URL into this property and have the nodes stored in a date seperated folder structure? What would the best way be?
Hey John,
I'd probably look to have just 1 member page, and use URL rewriting to pass in the name of the user who's details you want to display, that way you also don't need to maintain pages for every user, but I guess that really depends on what you want the profile page to do.
You may also want to take a look at SocialFront http://our.umbraco.org/projects/collaboration/socialfront-for-umbraco which is a community package for Umbraco (though I'm not sure what state it is currently in, it may give you some good ideas).
Matt
Passing the username is via a querystring is against requirements, I can't use the built-in alternate URL parameters of a document with a querystring can I? And I don't want to go writing a new ISAPI DLL to handle the usernames so I think I'll just have to create each profile page as a new Document.
The SocialFront project looks interesting, a trimmed down version of our requirements but potentially a good building block. I'll be sure to make the project available once complete, whichever route we take.
Thanks Matt.
is working on a reply...