Page tree
Skip to end of metadata
Go to start of metadata


Current implementation of PUR doesn't provide a user's profile page. We could create such profile pages and then additionally provide integration with forum (commenting).

Profile page  MGNLPUR-118 - Getting issue details... STATUS

We can create simple dynamic profile page and then use links to these pages in forums and comments. Add possibility to disable profile-page feature.

We need to create:

New sample user profile class   MGNLPUR-119 - Getting issue details... STATUS

New forms  MGNLPUR-120 - Getting issue details... STATUS

Registration form 

Multistep registration form (or extend current single-step form) for entering more information about user.

  1. dynamic creation of forms 
    have to be integrated into Form Module if we want to use it (use reflection on UserProfile class to automatically create form registration/update form) 

  2. OR we could provide sample multiple registration form (have to be created for custom UserProfile class) for now
    • step1: same as current registration form
    • step2: personal information
    • step3: "About me" text
    • step4: photo(s)
    • ...

Profile update form 

Disable account form


Profile page template  MGNLPUR-21 - Getting issue details... STATUS

  • page takes parameter to identify user (?userId=roman)
  • suggested content components:
    • text&image (profile photo + about me)
    • image gallery
    • embedded Video

    • contact
    • ...

Possible integration

Forums and comments could provide links to profile pages.

  • forum
  • commenting




All configuration should be configurable trough module's config, see  MGNLPUR-16 - Getting issue details... STATUS .

Revise multisite configuration/registration, see  MGNLPUR-117 - Getting issue details... STATUS .

  • No labels


  1. Here a few comments on some of the proposed topics:

    • Status subapp: that's a good idea, but I don't think it's something we need at the moment. There are many more apps/modules that would benefit from stats in one form or another so I'd rather remove that topic rather than invent something specific to p.u.r

    • Profile page: this should be one page, not a generated page per user. Think that "public" users are maybe only on the public instance's repository. An author would create such a page, and publish it from the author instance. Having a per-user page on the public instance would mean they'll be outdated when the user changes their profiles, or that we'd somehow let public users modify website content. No good. One dynamic page with ?userId=roman; projects can configure some virtual uri magic to make those look nicer.
    • "Edit your profile" should be disable for non-public users
    • Photos: do we want this ? commenting already has some sort of integration with Gravatar. If there is a need for something else, that means we should somehow generalize this (i.e allow commenting to use these new pics somewhat configurably)
    • Use Form module: yes, but. For this to work in conjunction with a configurable/extendable UserRegistrar, we need changes in form module so that forms can be generate programatically. If you've thought about another way this could work, let me know of course !
    • Groups: nope. Public users should not select their own groups. And they should not be made aware of existing groups. (think security, you don't want to expose that). The module was made so that (does this feature still work ?) one could configure which groups/roles new users should be assigned to. In that regard, we could maybe think about a small tool that re-applies current config to all existing public users (if config changed after users have been created, they won't all have the same groups/roles)

    Additional proposed topic:

    • Review multi-site support. I know MGNLPUR-89 - Getting issue details... STATUS has been implemented, but I'm not sure how the following two sub-topics have been considered 1) have the possibility to have a per-site configuration (with defaults) - i think there's a "configuration resolver" ? While that's nice, I'd like to see if/how we could generalize this for other modules. 2) (optionally) store users in a subnode corresponding to the site they registered from. This second option needs some investigation though: does it mean one has to re-register for all sites ? What is the same user wants/needs to access several sites ? (do we automatically grant them the groups of the other site's config?) Do we even let someone registered for site X login on site Y ? (their registration for X may or may not give them enough permissions for Y, so they might be able to login and then get 403 return codes, which might not be the best UX)

    In general, this kind of page would benefit from

    • a better structure (look at the indentation of the table of contents (wink))
    • backing proposals with actual user needs or stories
  2. I always wanted to fix the appearance of the „Logout“ dialog popup that is shown when you click on a user’s name in the header. There are several things I don’t like about it currently. I guess this touches PUR only on a side lane, much like some of the improvements for user profiles that Roman suggests.

    I like the idea of having a photo per user and showing that photo as a thumb in various locations.

    I also like the idea of offering users to have their own profile page, though I think you should be allowed to disable such a feature altogether, one an admin level (not on a per-user level), as I would expect many sites to already manage their users and the associated profiles in external systems. I would suggest that we provide a template for such a profile so that it can be easily adapted and maybe even enriched with data slurped from external systems. I would not go for an auto-generated page here. A template-based page could also be easily designed to match the rest of a site implemented with Magnolia.

    Other than that, in this case, I think, I should come into play as soon as you’re thinking about concrete UIs. I certainly have my $0.02 to share on the topic of a well-structured registration form, for example, or of how a profile dialog should look like.