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]>
----------------------------------------------------------------
