Member Profile extendable area

[Tony Air]

I think it will be great to include a frontend extendable area which will be extended by the other silverstripe modules.

Some websites may have member management areas for an instance silvershop has it.

It maybe also be extended by the other modules to manage the other things.

I suggest to make a controller to extend it in common way like Model Admin, but without any scripting or styling cuz websites maybe really different on frontend side.

Here's a concept: https://github.com/a2nt/silverstripe-member-profiles

[Sam Minnée]

There's this module that might be a better starting point than a new module?

http://addons.silverstripe.org/add-ons/silverstripe-australia/memberprofiles

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Sam Minnée

CEO

SilverStripe Limited

[Tony Air]

Well I suggest a basic controller like ModelAdmin that will have some basic functionality like profile editor form and menu generated by child classes.

This controller shall be included to the CMS so every module developer will use it to have a common way to extend profile areas.

Cuz now every module use their own way to work on profile areas and for an instance memberprofiles not integrated with silvershop.

So if some module needs a profile area it just extends it and will be automatically added to the menu as a subpage for an instance:

/profile - profile editor page

/profile/orders - silvershop orders page

/profile/address - silvershop address management page 

/profile/myownclass - ...

etc 

[Tony Air]

So basic functionality of this controller as I see it's a list of child classes with URLs to make a menu in templates, URLs handler, security checks and profile editing form

[kPodo]

Hm I did something like that in a project not too long ago. I ended up creating an AccountController with multiple actions and templates. An extension of such a controller would allow to add url's, plus create any getters to display in the custom functions. It's a bit all over the place but we could start working on a module?

A side note - one thing I've heard about 75% of time is that "Member" is really often confusing - especially when we have multiple user types (admin etc.). Shouldn't the base user model be called "User" for SS4?

[Tony Air]

Yes, that's the same. Just now we have a mess of modules for user profiles area which can't be included into the same interface without hooks.

As for side note I will vote for it.

[off...@netwerkstatt.at]

You think of some generic frontend CRUD? +1 from me.

[Sam Minnée]

If your goal is to create more of a common member profile system that other modules can integrate with, contributing to the existing module would likely be more effective than creating another module.

I'm sure if there are missing features from the existing module you could raise a PR for them?

[Tony Air]

It's duplication of code cuz every module that works with profile area needs user profile editing form.

More than that if u have 2 modules: event management system and silvershop what module will draw profile area with profile areas menu?

In most cases u will have 2 profile areas placed independently.

silevershop: /accounts with profile editing form, order management system

and event management module accessible by the other URL with the other areas, but with profile editing form too

So if u need to integrate few modules into one place u need to make one more module to integrate specific modules into one area and some code of this modules will be duplicated.

My goal is to integrate parent class to silverstripe for profile area which will be extended by the other profile modules.

Like we have ModelAdmin, SiteTree and the other parent classes to extend.

Maybe there's the other solution to make very basic profile module and the other profile modules will extend it and add it to requirements like reports module.

[Tony Air]

I think that profile CRUD functionality shall be extension of basic profile module. So u will have a basic profile page controller with template, profile menu, profile area url handler and member object form.

Extension of this controller will add extended module to menu, extended module template as sub-template and extended module will be accessible by sub-URL of profile page.

CRUD needs to be one more extension cuz some profile extensions may need only to display some information a graph for an instance.

[Martine bloem]

Would definitely be great to have a nice basic frontend login/register option that isn't connected to any other module, that is nicely integrated with the default theme, and that can be switched on or off, with well thought out general hooks for other modules to hook on to. It might even get some attention in the docs. Kinda like in Laravel...

But it would still be a module. And probably not a permanent part of a SilverStripe distribution as SilverStripe has been busy decoupling anything that looks like a module from core.. Besides, contrary to ModelAdmin, this is mostly a frontend thing...

Question is: could this in any way be a nr 1 SilverStripe maintained module? With that extra attention in the docs? That would probably stimulate other apps to use it, ánd give SilverStripe a nice out of the box experience!

Otherwise one could just start building and make it a great little module - or even base it on the existing one :)

Martine

[Nicolaas Thiemen Francken - Sunny Side Up]

+1 Tony ... great idea.

[kPodo]

So I'm starting to work on something because it'll be needed by a project.

I'm imagining this:

- a UserAccountPage (I wanted a page because that would allow the choice of the endpoint URL in a simple manner)

- a FrontendUserForm that will wrap frontendfields around the Member object and it's already a custom form that'd be easy to tweak. At it's basis, one would need to override the frontend fields - and with the crappy SS .middleColumn and things it usually takes a bit of messing with the markup of fields that combine with a bower library. Ultimately, the #1 use/challenge with this is a user friendly drag and drop file upload -- Uncle Cheese's dropzone seems pretty good. There are a ton of other UX libraries that would be amazing if we could integrate them (such as drag and drop etc), or, coming from another perspective, let's say we wanted to use the amazing UIKit UX components (field, drag&drop organization etc) and have it fit seamlessly with a profile edit form. Hence -- the isolation of this form - and right now I don't know the details of how this would work.

- If one didn't want to use the page, the UserAccountController should be self sufficient with some config and the route being set manually.

- For actions, I am imagining a base class of UserAccountAction - the package would come with an UserAccountAction_Overview, UserAccountAction_EditProfile, UserAccountAction_Register (frankly, MemberProfiles feels super clunky to me and half the stuff I don't need and half the stuff I do need isn't there lol), UserAccountAction_EditPassword, UserAccountAction_ResetPassword (I guess this would be just a way to improve this and bring them under the url structure). I guess the class actually has to be a controller since we want each area to have its own template and getters/setters/forms/logic.

- The UserAccountController would have logic that would get all subclasses of UserAccountAction and generate the UserAccountMenu (side nav for the account area, done in simple ul li a structure, and taking the classes as parameters

- I'd maybe have a smaller version for the nav menu that'd spit out the register / login and then a user name with submenu of all account sections

- One would extend a UserAccountAction and create a new action - throw in any getters / setters / forms into that action (action controller) and 

- Root page template for the account, and layouts for each specific action

- Extras: configuring icons for for the frontend account menu, simply configuring URL's, internationalization

(By the way is there no slack channel for SS devs to chat between each other and pow-wow about stuff like this more in realtime? :)

On Wednesday, November 2, 2016 at 2:01:08 PM UTC-7, nicolaas wrote:

+1 Tony ... great idea.

[kPodo]

One more thing - possibly separately or possibly with this - I've always missed an invite-based / token-based registration system in SS. This could be a good endpoint to develop on top of this.

Basically, a person generates an invite or a partially filled user account, the user is e-mailed an invite link, and the user then clicks the link. I see two (possibly different use cases). 1. the user completes the profile, including entering their password - or 2. the user only goes in and updates the temp password (so #2 just feels like a subset of #1 without the surrounding profile fields). Really simple, slick, easy to use. I've had about 4, 5 projects like this where this was asked for but we worked around it in the end.

[Sam Minnée]

Have you had a look at the existing module to see how close to what it is that you need? Perhaps a few PRs to that module would be easier?

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Tony Air]

I have upgraded and refactored code so now CRUD and Menu icons are supported.

Will make new documentation latter.

If someone wants to take a part in working on this module u're welcome.

Here's an example of CRUD module:

class ProfileListings
    extends ProfileCRUD
    implements PermissionProvider
{

     private static $menu_icon = '<i class="fa fa-pencil-square-o"></i>';

     private static $menu_title = 'Your Listings';

     private static $managed_models = [
        'ListingItem'
     ];

     public function providePermissions()
     {
        return [
            'VIEW_ListingItem' => 'View Listings',
            'CREATE_ListingItem' => 'Create Listings',
        ];
     }
     public static function canView()
     {
        return Permission::check('CREATE_ListingItem');
     }

     public static function canCreate()
     {
        return Permission::check('CREATE_ListingItem');
     }

}

And example of Profile Area extension:

class ProfileAnalytic extends ProfileController
{

     private static $menu_icon = '<i class="fa fa-pencil-square-o"></i>';

     private static $menu_title = 'Analytics';

     
     public static function canView()
     {
        return Permission::check('VIEW_ANALYTICS');
     }
}

Both of this modules will be automatically added to profile menu with titles and icons or ClassName will became Class Name title, all of them may have extra actions the same way as u extend the other controllers.

On Thursday, October 27, 2016 at 9:42:56 AM UTC+3, Werner Krauss wrote:

[Tony Air]

> - a UserAccountPage

Right now u can use ProfileController.ss as basic template placed into Page.ss Layout area which will have menu generated in ul>li manner by ProfileMenu.ss using child classes of ProfileController

> - FrontendUserForm

it's extendable MemberEditProfileForm I extend it to use Uncle Cheese's dropzone in my project, but it isn't required by default in case u want to use ur own UI solutions for an instance I block dropzone js and css cuz I build profile area js+css using gulp into one file.

>  I'd maybe have a smaller version for the nav menu that'd spit out the register / login and then a user name with submenu of all account sections

it is done u can use MemberRegistrationPage and extend it. You can put LoginForm and Registration Form into this page or u can split it into 2 areas.

Menu is generated at ProfileController.

> One would extend a UserAccountAction and create a new action

It's supported by extending ProfileController or ProfileCRUD

> - Extras: configuring icons for for the frontend account menu, simply configuring URL's, internationalization

Icons supported, internationalization supported. As for URL's right now u can easily configure main profile area url by:

ProfileController:

  url_segment: 'profile'

I will add more URL's customizations latter.