Is there an existing issue for this?
Description of problem
I’ve been working on rebuilding DNN’s built-in My Account/Profile experience. This is where registered users edit their profile, change their password, manage profile visibility, update their photo and manage communications.
The existing functionality works, but the interface looks and feels dated compared with newer parts of DNN and the Aperture theme. I often replace it with a custom module on client projects, but I think improving the built-in experience would be more useful to the community.
One complication is that this is not a normal module. DNN loads it using the older slave/admin-control mechanism:
/ctl/Profile → global Profile control → synthetic module → ContentPane
It looks like a module inside the page, but there is no real module instance, ModuleId, TabModuleId, or normal module settings.
We also need to be careful with existing sites. Some installations may already have custom themes, CSS, providers or code that depends on the existing interface.
Description of solution
I have a working prototype that reorganizes the experience into Account, Profile, Security and Communications sections.
It continues to use DNN’s existing user, profile, membership, file and messaging functionality. Custom profile properties created in DNN are also supported. The goal is to rebuild the interface without creating a separate user or profile system.
The styling uses DNN CSS variables with fallbacks so it can work with Aperture and third-party themes.
I would also like the modern experience to be customizable without requiring someone to modify the core ASCX files.
DNN already has examples of templated components that provide:
- Templates included with the component
- Portal-level template overrides
- A template selected for each module instance
The first two parts could potentially work here. DNN could provide default account templates and look for portal-specific overrides under Portals/{PortalId}.
The per-instance part does not apply to the current account editor because the synthetic module has no real module instance or settings. Supporting that part would require changing this into a proper module or introducing some other portal-level selection mechanism.
The template itself could control the layout, ordering, wrappers and styling of areas such as:
- Account summary
- Navigation
- Account details
- Profile
- Security
- Communications
DNN would continue to create and process the actual fields, custom profile properties, validation, permissions, visibility controls, password changes, photo uploads and saving.
The modern experience should be opt-in for upgraded installations so existing customized sites are not unexpectedly changed. It must also support multi-portal installations where different portals may use different experiences or templates.
Description of alternatives considered
The current prototype directly rebuilds the existing ASCX controls. This is the simplest approach, but replacing the old markup unconditionally could affect installations that have customized it.
A proper optional module would provide normal module settings and make per-instance template selection straightforward. It would also be deployable and easier to place on different pages. However, that would be a larger change from DNN’s current global ctl/Profile mechanism.
Configuration could be added to the Persona Bar, but I’m not convinced template and presentation settings justify adding more Persona Bar UI.
A web.config setting would be simple, but it would apply to the entire installation and would not work well for multi-portal installations requiring different choices.
Razor could be considered if this becomes a proper MVC module. If it remains a Web Forms global control, a token-based HTML template may work better with the existing server-control lifecycle.
Anything else?
I have the prototype running locally and can contribute the code once there is some agreement on the architecture.
The prototype currently includes:
- Account, Profile, Security and Communications sections
- Custom DNN profile properties
- Profile-property visibility controls
- Profile-photo uploading
- Password management
- Communications and subscriptions
- Responsive styling based on DNN CSS variables
The main question is whether the modern experience should remain part of the existing global control with core and portal-level templates, or whether it should become an optional proper module with normal instance settings.
Do you plan to contribute code for this enhancement?
Would you be interested in sponsoring this enhancement?
Code of Conduct
Is there an existing issue for this?
Description of problem
I’ve been working on rebuilding DNN’s built-in My Account/Profile experience. This is where registered users edit their profile, change their password, manage profile visibility, update their photo and manage communications.
The existing functionality works, but the interface looks and feels dated compared with newer parts of DNN and the Aperture theme. I often replace it with a custom module on client projects, but I think improving the built-in experience would be more useful to the community.
One complication is that this is not a normal module. DNN loads it using the older slave/admin-control mechanism:
/ctl/Profile→ globalProfilecontrol → synthetic module →ContentPaneIt looks like a module inside the page, but there is no real module instance,
ModuleId,TabModuleId, or normal module settings.We also need to be careful with existing sites. Some installations may already have custom themes, CSS, providers or code that depends on the existing interface.
Description of solution
I have a working prototype that reorganizes the experience into Account, Profile, Security and Communications sections.
It continues to use DNN’s existing user, profile, membership, file and messaging functionality. Custom profile properties created in DNN are also supported. The goal is to rebuild the interface without creating a separate user or profile system.
The styling uses DNN CSS variables with fallbacks so it can work with Aperture and third-party themes.
I would also like the modern experience to be customizable without requiring someone to modify the core ASCX files.
DNN already has examples of templated components that provide:
The first two parts could potentially work here. DNN could provide default account templates and look for portal-specific overrides under
Portals/{PortalId}.The per-instance part does not apply to the current account editor because the synthetic module has no real module instance or settings. Supporting that part would require changing this into a proper module or introducing some other portal-level selection mechanism.
The template itself could control the layout, ordering, wrappers and styling of areas such as:
DNN would continue to create and process the actual fields, custom profile properties, validation, permissions, visibility controls, password changes, photo uploads and saving.
The modern experience should be opt-in for upgraded installations so existing customized sites are not unexpectedly changed. It must also support multi-portal installations where different portals may use different experiences or templates.
Description of alternatives considered
The current prototype directly rebuilds the existing ASCX controls. This is the simplest approach, but replacing the old markup unconditionally could affect installations that have customized it.
A proper optional module would provide normal module settings and make per-instance template selection straightforward. It would also be deployable and easier to place on different pages. However, that would be a larger change from DNN’s current global
ctl/Profilemechanism.Configuration could be added to the Persona Bar, but I’m not convinced template and presentation settings justify adding more Persona Bar UI.
A web.config setting would be simple, but it would apply to the entire installation and would not work well for multi-portal installations requiring different choices.
Razor could be considered if this becomes a proper MVC module. If it remains a Web Forms global control, a token-based HTML template may work better with the existing server-control lifecycle.
Anything else?
I have the prototype running locally and can contribute the code once there is some agreement on the architecture.
The prototype currently includes:
The main question is whether the modern experience should remain part of the existing global control with core and portal-level templates, or whether it should become an optional proper module with normal instance settings.
Do you plan to contribute code for this enhancement?
Would you be interested in sponsoring this enhancement?
Code of Conduct