It's really interesting to read everyone's comments on this. Glad to see other people out there feel there's a need for a clear direction for UGC.
Wish I could be at the conference :( It's too far away for us Aussies! If this is discussed on the day I'd be keen to hear the direction the conversation goes. Cheers, Brent -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ruben Reusser Sent: Friday, 4 September 2009 9:43 AM To: Magnolia User-List Subject: Re: [magnolia-user] What's Magnolia's UGC Story? This would be a great topic for the magnolia conference community day :-) I'd love to compare notes on this one. My 2c: We run a larger site with user generated content and the PUR module. We use your 'just stay on public' version and then allow users from the editor group to actually manage the content the way the users can manage their own content. We use a more sophisticated form module to do a kind of inline content editing. my reasons why I love this: - a common user does not understand the popups and editing his/her content. They want it to be simple (say like the form module or the way one manages content on facebook) - administrators get to do drive-by editing on content they don't like - activating/deactivating content or promoting content is just another button that only admins see - they are browsing the site, see an event they'd like to feature on the main page, they just click and it's done. They see something explicit, they can just remove it. No need for a separate admin console. We use a couple of editor group only pages to list the new/edited content for them to review. - search works over the whole site. A global search can return any page, anywhere. Weather it contains a name or whatever - it's found - you can use a hierarchical storage for a member's data - it's easier to grow that way since all the data for that user is in one place and not spread out over a lot of tables. my lessens learned from it: - make sure you store content that you don't want to be found somewhere else (if you hide an email address on the page in a node but then allow a global search, the user is found anyway - also, make sure a search for 'superuser' or any other user that edits a lot or inserts all your default nodes does not kill your application - there are a lot of nodes labeled by that user and it can kill the search result performance - make sure you don't have too many subnodes in one node (limit to max of 50, create a hierarchical tree such as year/month/day/node or something else that helps you do this) - magnolia (and jackrabbit) does not like nodes with a lot of subnodes. - creating new nodes is slow - make sure your backup/restore process works (bootstrapping with a lot of data in the repositories can be VERY slow) - don't use the file storage in jackrabbit - your data will explode 10 fold because of the small files it creates. Ruben [email protected] Danilo Ghirardelli wrote: > >> I've been exploring a little bit recently with the PUR and Forum >> modules + commenting. I get the impression these modules are >> relatively young is that right? > > I'm really really interested in the topic, because managing user > generated content is something we've been asked quite often. Maybe > it's simply the "web 2.0 feeling" it gives... A good question I heard > is: "Magnolia is a good content management system, so why it can't > manage that content?" > > But my question is: which is the Magnolia standard way to handle user > generated content? I don't know if there is already one, from the docs > I read seems there isn't. Modules that handles UGC are not young, but > they gave (to me at least) a strong impression that each one was just > tailored to do its little part in its own way, without a bigger plan. > > So far, I've seen implemented (or thought) these solutions about UGC: > - Separate database, with out-of-Magnolia handling of the contents (in > a relational database, usually with hibernate or similar). This seems > a good solution but may leave some integration problem in Magnolia, > and it seems unlikely that this will be accepted as a "Magnolia > standard", because it's more a last resort for worst cases. > - "Just stay on public", content generated is stored on public server > and authors have no way to access or handle it. May require to have a > few "unpublishable" nodes in the author instance to avoid overwriting > all the public data (and if the repo is not separated from the > published one it may be unsafe). It's really easy to implement for > simple cases, but it's also limited. > - Single instance. With a few hacks, it seems possible to have a > single instance for both public and authoring (or better using the > public one as authoring), in which contents are only "published" or > "unpublished" (only logged authors can view them), killing the concept > of "modified and not yet published". This way you can use the existing > repo to store also pubilc content and have authors edit/moderate it. > Seems to be a good compromise but it's still not good to be a standard > solution. > - Backpublishing, with the public instance that automatically publish > its user generated content to the author one, so it can be published > back correctly when the author edits something. This feels really > unsafe (public instance must see and have access to the author one) > and may lead to concurrency problems. > - Author pulling (only thought about it as possible solution): the > author instance has no copy of UGC but whenever it needs to edit it, > it calls a servlet/webservice on public instance to retrieve the > content and another one to save it. Or stores the copy locally and > then publish it the standard way, but even this may lead to > concurrency problem. Seems quite complex and not very performing. > > In the end I didn't like any of these solutions. There is still > something that I'd like to try, if I don't find anything better: > separate UGC repo clustered between public and author. Leaving the > current repos configured as they are, I'd like to add another (almost) > full set of the same repos, but configured to be clustered between > author and public, so the data is automatically shared. The UGC-user > will contain the public users and the others all kind of user > generated data (not only content stored in pages/paragraphs but maybe > also files stored in data modules if any client would ever ask for > something so strange). Obviously there would be many tweakings > involved, but it shouldn't be totally impossible. Just my two cents, > but I'd like to share your ideas about the topic. > > Regards, Danilo. > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
