Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Enhancement]: Modernize the built-in registered user My Account experience

Open
  • Is something wrong?
#7,489 5 comments 3 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@alex-pommier is already working on this.

Since Sep 1, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, css, html
Domain
backend, design, frontend

Research direction

Start by reading the existing global /ctl/Profile control and its ASCX files, then trace how DNN loads the synthetic module and handles profile, membership, files and messaging. The issue identifies a working prototype but leaves the architecture undecided: compare portal-level templates on the existing control with an optional proper module. Done means an agreed design that supports opt-in upgrades and different experiences per portal.

Written by the indexing model from the issue text.

Description

Status: New
Is there an existing issue for this?
  • I have searched the existing issues
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.

Image Image Image Image Image
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?
  • Yes
Would you be interested in sponsoring this enhancement?
  • Yes
Code of Conduct
  • I agree to follow this project's Code of Conduct
Dominant language
C#
Stars
1.1k
Forks
791
Avg merge
2d 12h
Merged PRs (30d)
28

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dnnsoftware/Dnn.Platform

All issues in dnnsoftware/Dnn.Platform

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.