JMP Delete My Account - Joomla Extension

Guide to Configuring and Safely Using JMP Delete My Account

JMP Delete My Account is useful when a Joomla site needs to give registered users a clear way to delete or temporarily block their own account without going through manual back-and-forth with an administrator. This guide focuses not on the extension listing itself, but on a working implementation: what to check before installation, how to enable the feature, where to place the delete action, which notifications to configure, how to run a test, and what to do if the form or confirmation step does not work.

There are several details you should understand before you start. According to the Joomla Extensions Directory, the extension lets you choose between permanent deletion and temporary blocking, uses an email verification code, sends notifications to both the user and the administrator, and does not allow deletion for administrative accounts. These details affect more than just setup - they shape your site policy as well: the user needs to understand the consequences, the administrator needs visibility into the event, and the site owner needs to remember that some data may still be stored in third-party extensions.

This article is intended for community owners, webmasters, Joomla administrators, and developers who need to integrate an account deletion button cleanly into a user dashboard, user menu, or a dedicated page. We will cover safe testing with a test account, access permissions, text localization, Joomla core compatibility, and common symptoms such as "the menu item is visible to guests," "the confirmation code never arrives," or "the user was deleted, but their content is still on the site."

What Problem This Extension Solves on a Joomla Site

On a standard site, a user can usually register, sign in, update part of their profile, and reset a password, but deleting an account typically remains an administrator task or part of a privacy workflow. On a small site, that may seem acceptable: the user submits a request through a contact form, the administrator opens the user list, and handles it manually. On a real community site, member area, private club, training portal, or directory, that approach quickly becomes inconvenient. Requests get lost, users do not know the status of their request, and administrators spend time on repetitive work.

JMP Delete My Account addresses exactly this part of the user journey. The extension adds a controlled action that allows a registered user to initiate deletion or blocking of their own account from the public side of the site. At the same time, the administrator does not have to expose that action to everyone: access to the menu item, module, or page should be restricted to the Registered level or another appropriate Joomla access level.

The real value of the product is not that it "deletes a user," but that it makes the process controlled and predictable. The visitor gets a clear exit point for their account, the administrator gets a notification about the event, and the site needs less manual support. For sites that store personal information, this also helps create a more transparent user workflow, although the extension itself does not replace your legal data-handling policy and does not automatically erase all data from third-party components if they are not part of the deletion process.

What Happens from the User's Perspective

The user sees an action such as "Delete Account" or "Close Profile" in their personal area of the site. After starting the process, they must confirm their intent. In the current JED description, email code verification is mentioned explicitly: a code is sent to the user, and the action can continue only after the correct code is entered. That reduces the risk of accidental deletion, especially if the user left an active session open on someone else's device.

After confirmation, the site performs the action chosen by the administrator: permanent deletion or temporary blocking. That choice matters because not every project should immediately destroy the account. For a forum or private club, it may be enough to block sign-in, preserve the activity history, and review the data manually later. For a simple site with a minimal profile, deletion may be more appropriate, as long as it does not conflict with the project's internal rules.

What Remains on the Administrator's Side

The administrator is responsible for where the action appears, who can access it, which text the user sees, and who receives notifications. They also need to verify that deletion or blocking does not break related processes: content authorship, orders, subscriptions, integrations with a membership component, custom fields, comments, or profiles stored in a third-party extension. Account deletion is not just a button in the interface - it changes the user's state across the entire site ecosystem.

That is why proper setup begins not with publishing a menu item, but with a short inventory: which user groups exist on the site, which extensions store user data, who should receive notifications, and what the warning message should say before confirmation.

Who JMP Delete My Account Is a Good Fit For, and When Another Approach Is Better

The extension is especially useful on projects where user registration is not just decorative, but actually part of how the site works. That includes private sections, member dashboards, communities, event sites, educational portals, expert directories, comment-enabled sites, or any project where users actively manage their own profile. In those cases, manual account deletion feels outdated: people expect to see a clear way to close a profile in the interface, and administrators do not want support to turn into a queue of repetitive requests.

JMP Delete My Account fits well when you need a self-service user workflow with confirmation, not mass database cleanup. It does not replace tools for deleting thousands of inactive accounts, it is not a full GDPR consent management center, and it should not be treated as an emergency utility for cleaning spam registrations. Its role is narrower and more practical: to give a regular registered user a safe way to close their own account.

Good-Fit Scenarios

The most natural use cases look like this:

• A private community wants to reduce support workload and let members delete their own accounts.
• A site with a member dashboard wants to show a "Delete Account" option only to logged-in users.
• A project owner wants to temporarily block an account instead of deleting it permanently, so there is time for manual review.
• An administrator wants to receive a notification whenever a user initiates deletion or blocking.
• The project needs an extra safeguard against accidental actions through an email code.

In all of these cases, the extension creates a clear user path. It is especially important that the action should not be available to guests. If a guest can see a delete-account link, it is not only pointless, but confusing: there is no active account in that session to act on.

When the Extension May Not Be Enough

If the site stores large amounts of user-generated content, handles orders, subscriptions, payments, communities, forums, or complex profiles, deleting a Joomla account alone may not be enough. Joomla's official privacy workflow documentation emphasizes that data deletion in the core depends on privacy-system support from extensions, and related data may require separate manual review. That is not a weakness of this specific product, but a property of the whole system: third-party components may keep their own records, and those records do not disappear automatically just because the user can no longer sign in.

For projects like that, it is better to treat JMP Delete My Account as a convenient user entry point into the process, not as the only privacy tool. If you need profile export, consent logs, manual moderation of requests, integration with consent forms, and deletion across many components, you should also evaluate dedicated privacy extensions.

What to Check Before Installation and Publishing the Feature

Before installing the extension, it is important to define what a successful outcome actually means for your site. On one site, that may be full deletion of a regular non-admin user. On another, it may be account blocking plus a notification to the site owner. On a third, it may be a dedicated item in a private menu that opens a confirmation flow only after login. If you do not define the goal up front, it is easy to end up with a feature that is technically enabled but poorly aligned with the site's real policies.

Start with a staging environment or at least a backup. Account deletion changes data, and reversing it from the admin panel is not always possible. If the site has orders, subscriptions, user content, or a related profile in a third-party component, create a separate test user with no important data attached. Do not test the workflow with your own administrator account: according to the JED description, deletion of administrative accounts is unavailable, and that is the right behavior from a security standpoint.

A Quick Pre-Launch Checklist

Before publishing the action in a menu, go through this short list:

• Check which user groups should be able to see the delete action.
• Decide whether the account should be deleted permanently or temporarily blocked.
• Verify that Joomla mail is configured correctly, because the email code and notifications depend on mail delivery.
• Create a test registered user with no administrative privileges.
• Review which third-party extensions store user data: profile, comments, orders, subscriptions, messages, files.
• Prepare a clear warning message so the user understands what changes after confirmation.
• Decide who receives notifications: one main address, a group of administrators, or a support mailbox.

This preparation may seem simple, but it prevents most errors. For example, if Joomla mail is not working, the user will never receive the verification code. If the menu item is published with the Public level, guests will see it. If third-party components were not checked, the administrator may assume the data was fully removed even though some records are still sitting in a separate table.

Access Permissions and Visibility of the Delete Option

Joomla uses viewing access levels to control who can see content, modules, and menu items. The Joomla documentation explains that the Access field ties a site object to a viewing level, and the viewing level itself contains user groups. For account deletion, that is critical: the item should be visible only to users who actually have an account in the current session.

In the standard case, use the Registered level. If the site has a dedicated member group, such as a club, course, or private section, you can create a custom access level and assign it only to the relevant group. Do not use Public for the delete item. A guest visitor should not see an action that belongs in the user dashboard.

Practical check: open the site in a private browser window. If the account deletion item is visible without logging in, the access settings are wrong. Fix the visibility first, then test the deletion flow itself.

Installing the Extension and Running the First Admin-Panel Check

JMP Delete My Account installs like a standard Joomla extension. The exact path depends on your interface version, but the logic is familiar: the administrator uploads the ZIP package through the extension installer, waits for the success message, and then looks for a new component, settings page, or related plugin. Joomla Extensions Directory reminds us that after installation, components appear in the Components menu, plugins in Plugin Manager, and modules in Module Manager. So after installation, do not guess - confirm which type of package appeared in your system.

In the JED listing for JMP Delete My Account, the product is shown as a Joomla extension by JoomHelper and appears in the user management category. In the current JED data, the Includes field points to a component-type package, and user reviews mention a separate menu. That is a useful clue, but on a live installation you should still verify exactly what shows up in your site's admin panel. If the package includes additional plugins, they may need to be published separately.

Basic Installation Sequence

1. Create a site backup or prepare a staging copy.
2. Open the Joomla admin panel and go to the extension installation section.
3. Upload the extension ZIP package using Upload Package File or the equivalent UI option.
4. After installation, open the lists of components, plugins, and menus to find the items added by the extension.
5. If the package added a plugin, make sure it is published.
6. Open the extension settings, but do not publish the delete action in the main site menu yet.
7. Create or select a test user with standard permissions.

The short version after installation: the extension should be visible in the admin panel, its settings should open without errors, and the site should not yet expose a public link for account deletion. Publishing the action is the next stage, and it is best done only after the mode, text, and notifications are configured.

Initial Test Without Risk to a Real User

For the first test, create a separate user, sign in with that account in another browser, and make sure the user does not belong to the Manager, Administrator, or Super Users groups. That matters not only because the extension blocks admin-account deletion, but because the deletion workflow should be tested against the behavior of a regular site member.

Then verify that Joomla mail works. You can use the standard mail-configuration test tools or trigger a safe action that sends a message to the user. If the site is not delivering mail, do not move on to testing the email deletion code: you will end up diagnosing the extension for a failure that is really caused by mail configuration, SPF/DKIM, SMTP, or incoming mail filtering.

Detailed Configuration After Installation

The most useful part of configuration is not a checklist of every setting, but an understanding of which decisions the administrator is making. JMP Delete My Account has several key branches: delete or temporarily block, how to confirm the action, who receives notifications, what message the user sees, and where the entry point should appear. Do not enable everything just because it is available. The configuration should match the actual risk profile of your site.

Action Mode: Delete or Temporarily Block

JED describes an option where the user is not permanently deleted, but temporarily blocked instead. For most working sites, that is a sensible starting point. Blocking gives the user the practical effect of losing access, while giving the administrator time to inspect related data: orders, comments, profile records, subscriptions, files, and content. If testing shows that full deletion does not break your site's business logic, you can consider the stricter mode later.

For a typical community site, start with temporary blocking. For a simple site where the user profile is barely connected to any content, deletion may be fine. For a store, paid membership site, site with order history, or site with authored content, it is better not to enable permanent deletion without a separate internal procedure. First test the consequences on a test account, then make the decision for real users.

How to Verify the Selected Mode

After saving the mode, run a test as a regular user. If blocking mode is selected, the user should no longer be able to log in after confirmation, but the record should still be visible to the administrator in the user list as blocked or in an equivalent state. If deletion mode is selected, the user record should disappear from the list or no longer be available as an active account. Do not rely on the on-screen message alone: confirm the state in the admin panel.

Email Confirmation Code

Email code verification protects against accidental clicks and actions taken in a session that was left open. The user starts the deletion process, receives a code at the email address tied to the account, and enters it to continue. The article should not promise absolute security: if the user's email account is compromised, the code will not save the situation. But for a normal user workflow, it is a strong extra safeguard.

Check three things: the message arrives quickly, the email text is clear, and the code cannot be guessed from the interface. If messages are going to spam, fix SMTP and domain records instead of disabling confirmation for convenience. In an account deletion flow, convenience should not win over proof of intent.

Notifications to the User and Administrator

According to the JED description, email is sent to both the user and the administrator when deletion or temporary blocking happens. That is useful for two reasons at once. The user gets confirmation that the action was completed, and the administrator sees the event and can review related data. On a site with support staff, it is better to use a shared operational address monitored by the right people, not one administrator's personal inbox.

Do not make legally risky promises in the notification text such as "all your data has been completely deleted." A safer and more accurate wording is that the account was deleted or blocked in the Joomla system, and that if the user needs related materials removed, they can contact you through the specified channel. This matters especially on sites with comments, orders, publications, or profiles stored in third-party extensions.

Interface Text and Localization

The user-facing text shown before deletion should be brief, but not cold or overly formal. It should explain the action, the consequence, and how to cancel or get help if that is possible. If the extension uses Joomla language strings, change them through the standard language overrides system. The Joomla documentation explicitly recommends not editing core files or third-party extension files, because those changes may be lost during updates. To replace individual strings, use System -> Language Overrides or the equivalent path in your Joomla version.

A good warning message answers three questions:

• What exactly will happen after confirmation.
• Whether the user will be able to sign in again or the account will be closed.
• Where to get help if the action was triggered by mistake.

If the site is multilingual, test every language version. You should not leave an English warning on the Russian version of the site if the rest of the user area is translated. That kind of mismatch reduces trust and can lead to user mistakes.

Where to Place the Account Deletion Action

Account deletion should not be buried so deeply that users have to contact support to find it, but it also should not become an intrusive button on every page. The best location is a logical area within the user's account space: a user menu, profile page, private account-actions module, or a dedicated "Account Settings" page. The important point is that the action should be visible only after login and should not conflict with ordinary links such as "Edit Profile" or "Logout."

In current JED reviews, users mention that the extension includes a separate menu and does not require complicated steps after installation. If your version creates its own menu-item type, use it: that makes it easier to keep Joomla routing, access, and behavior correct. If your installed documentation describes a different output method, follow it, but validate access and results with the same level of care.

Option 1: Add It to a User Menu

For most sites, a separate item in a menu shown only to registered users is the best fit. The logic looks like this:

1. Create a separate menu or use the existing user-account menu.
2. Add a menu item linked to the account deletion function from the installed component, if that item type is available.
3. Set Access to Registered or to a custom access level.
4. Check the Link Type tab if you want to add a class for visual styling.
5. Publish the menu module only in the private area of the site.
6. Test the item as a guest, as a regular user, and as an administrator.

Joomla's menu item documentation shows that menu items include a Link Type tab and a Link Class field. That is helpful for styling a button-like link, but it does not replace the actual access setting. A class changes the appearance of the link, not who is allowed to see it.

Option 2: The Older Trigger-Link Approach

In older materials about the Delete My Account extension by Function90, you can find a method where the action is triggered by a link with the class f90-delete-my-account. That is useful background if you maintain an older installation or if the documentation for your package explicitly requires that class. For the current JMP Delete My Account by JoomHelper, first look for the standard component menu item or the developer's instructions, and use the trigger-link approach only if it is confirmed for your version.

An older implementation looked like this:

<a href="#" class="f90-delete-my-account">Delete my account</a>

If that is the version you have, do not place the link in public-facing content without restrictions. Put it in an article, module, or menu available only to authenticated users. Also, do not rename the class arbitrarily: if the extension script listens for a specific CSS class, changing it will break the modal trigger.

How to Keep a Risky Action from Becoming an Accidental Click

Place the action separately from normal navigation items. Do not put it right next to Logout if the items look visually identical. A good pattern is a calm but noticeable label plus a warning on the next step, not a huge red button in the menu. Red can make sense in the confirmation step, when the user already understands the context, but in the menu it can feel overly aggressive.

If you want to highlight the item slightly with CSS, use a menu class and a custom template file such as user.css in your template. That is safer than editing extension files.

.account-delete-link > a,
a.account-delete-link {
  color: #9f1d1d;
  font-weight: 600;
}

.account-delete-link > a:hover,
a.account-delete-link:hover {
  color: #6f1111;
  text-decoration: underline;
}

This snippet does not interfere with the deletion logic. It only makes the link easier to recognize visually. To roll it back, remove the class from the menu item or remove the CSS from the template file. After the change, test the item on a mobile screen, because some templates handle classes differently in standard menus and collapsed mobile menus.

How the Confirmation Flow Works and Why It Matters

The account deletion flow should be built as a sequence where each step reduces the chance of error. The user clicks the action, sees an explanation, confirms their intent, completes email verification, and only then does the site perform the action selected by the administrator and send notifications. If you remove any of those stages, the process becomes faster, but riskier.

For the administrator, the button itself is only part of the story - the result must also be verified. After a successful run, you need to make sure the user can no longer sign in, that their status matches the selected mode, that emails were sent, and that related components did not behave unexpectedly. This matters especially on sites where the user authored content or belonged to a group.

The "Request -> Code -> Action -> Notification" Chain

You can think of the working chain like this:

1. The user opens a protected menu item or an account page.
2. They start the deletion or blocking action.
3. The site shows a warning and sends a code by email, if that verification step is enabled in your configuration.
4. The user enters the code and confirms the action.
5. The extension deletes or temporarily blocks the regular account depending on the settings.
6. The user and the administrator receive notifications.
7. The administrator reviews related data if the site stores it in third-party components.

This model works well because the user does not depend on a manual support response, but the action remains deliberate. The email code turns deletion into a two-step process. The administrator notification creates a record for follow-up review.

Why Administrative Accounts Should Not Be Deleted from the Public Side

The JED description explicitly says that the deletion feature is unavailable for admin accounts. That limitation is expected. An administrative user is tied to site management, settings, extensions, access permissions, and often content authorship. Letting that kind of account delete itself from the public side would be far too risky. If you need to remove an administrator from a project, use the standard user-management tools, permission transfer, and backup access procedures.

Do not try to work around that restriction by changing the user's group memberships just for testing. The extension should be tested with a regular user. Administrative account handling requires a separate internal process: at minimum two super user accounts in case access is lost, up-to-date contact addresses, and a valid backup.

User Data, the Privacy Process, and Responsibility Boundaries

Deleting a Joomla account and deleting all personal data are not always the same thing. Joomla core can work with users, permissions, and privacy requests, but third-party extensions may store their own records. Joomla's privacy workflow documentation states this clearly: a deletion action can process data only from extensions that support privacy integration, and the administrator may still need to review and delete data manually from other extensions.

That is why a guide for JMP Delete My Account needs to be honest: the extension helps the user initiate account deletion or blocking, but the administrator is still responsible for the site's data-retention rules. If the user posted comments, placed orders, uploaded files, wrote articles, or participated in a third-party community, verify what happens to those records after deletion or blocking.

The Difference Between Deletion, Blocking, and Anonymization

In practice, these are three similar but distinct outcomes:

• Account deletion - the user record is no longer available as a normal Joomla account.
• Account blocking - the user can no longer sign in, but the record remains available for review or manual handling.
• Anonymization - personal fields are cleared or replaced, while technical records may remain for data continuity.

JMP Delete My Account, according to its description, lets you choose between deletion and temporary blocking. Joomla's privacy component follows its own workflow: a request is confirmed, a super user processes export or data deletion, and for a registered user the name, username, and email may be anonymized, the account blocked, and the user logged out of the session. These workflows can be combined in your internal policy, but they should not be blended together in the user-facing warning text.

What to Review in Third-Party Extensions

Make a list of the components where the user may have left data. For each one, ask a single question: what happens to those records after the Joomla user is deleted or blocked? Comments may still retain an author ID. A store may keep order history. A community extension may keep a separate profile. A file component may retain uploaded assets. A form may still contain a submission with the user's email address.

If the answer is unknown, do not tell the user that "all data is deleted." A more accurate message is that the account is closed and related data is handled according to the site's policy. In the notes.txt for this article, it is recorded that detailed public documentation from JoomHelper about internal handling of third-party data was not available, so any confident promise about complete removal of every trace was intentionally excluded from the article.

Practical Example: A Private Menu for Member Account Deletion

Here is a concrete scenario: a Joomla site runs a private community with user registration. The owner wants regular members to be able to close their own accounts, while guests should not see that option, administrators should not use it accidentally, and the support team should receive notifications. For the initial rollout, we choose temporary blocking instead of permanent deletion, because related data still needs to be reviewed.

Goal

The goal is to create a menu item in the user menu that is visible only to authenticated members. After clicking it, the user confirms the action through an email code, the account is blocked or deleted according to the chosen setting, and the administrator receives a notification. After verification, the item can remain in the live user dashboard.

Preparation

Before the steps below, the following conditions should already be true:

• The extension is installed and opens correctly in the admin panel.
• Joomla mail delivery works.
• A regular test user exists with no administrative privileges.
• A user menu or account module exists and is visible only to the Registered access level.
• Temporary blocking is selected as the mode for the first test.

Setup Steps

1. Open the extension settings and choose the action mode: for the first test, use blocking or the safest available option.
2. Enable email-code confirmation if that option exists in your version.
3. Specify the administrator address or service mailbox that should receive notifications.
4. Review the warning text. It should explain account closure and the consequences, but it should not promise deletion of all data from third-party components.
5. Create a menu item in the private user menu. If the extension added its own menu-item type, use it. If your documentation requires a trigger link, use the documented class exactly as confirmed.
6. Set Access to Registered or the required custom user level.
7. Save the item and test it on the public side of the site while logged in as the test user.

Expected Result

Guests do not see the delete option. A normal registered user sees it in their personal area. After clicking it, a confirmation appears, then the user receives a code by email and enters it. After successful confirmation, the account changes state according to the selected mode, and the administrator receives an email about the event.

A Common Detail That Gets in the Way

If the user clicks the item and nothing happens, do not start with the user database. Start with the interface path instead: is the required plugin published, is the template JavaScript working, is an old cached version of the page still being served, is the menu-item type correct, or is the trigger class set properly? Account deletion is the final step. Before it can happen, the menu item display, confirmation script, email delivery, and code entry all need to work correctly.

How to Verify the Result After Configuration

Result verification should be its own stage, not just a quick click after installation. Account deletion affects login, mail, access permissions, and related data. If you test only whether the menu item is visible, you can miss the main problem: the user saw the link, but the email never arrived, the form did not accept the code, or the account remained active.

Test as a Guest

Open the site in a private window and do not sign in. Confirm that the delete option, the account module, and the direct action page are not available to guests. If the menu item is hidden but the direct URL still opens, check the access level of the menu item itself, the related content item, or the component. In Joomla, you need to restrict not just link visibility, but access to the page itself.

Test as a Regular User

Sign in as the test user, open the user menu, and run the workflow. Confirm that the warning is readable, the email code arrives at the correct address, the form accepts the code, and after confirmation the user can no longer keep using the account as if nothing happened. If blocking is enabled, another login attempt should be denied. If deletion is enabled, the account should not remain active.

Check the Admin Panel

After the user-side test, open the user list. Check the status of the test account. Then check the administrator mailbox. If the site keeps activity logs or uses privacy workflows, verify that the event did not create unexpected errors. If the test user was the author of content, a comment, or a record in a third-party component, check how that record appears after deletion or blocking.

Quick summary of verification: success is not just a polished confirmation form. Success means the whole chain works: correct visibility, working email delivery, code acceptance, account state change, administrator notification, and no unexpected errors in related data.

Safe Adjustments to Text, Appearance, and User Support

Even a well-configured account deletion feature can make users uneasy. That is why the interface should feel calm, clear, and predictable. The action should not be hidden, but it also should not look like just another routine navigation item. The user needs to understand that it is a serious action, and the administrator needs a clear channel for questions.

Warning Text

A good warning does not scare the user or overpromise. It explains that the account will be closed, access to the personal area will be lost, and support is available if the user has questions. If temporary blocking is enabled, say that explicitly and note that manual processing may still be required. If deletion is enabled, do not claim full removal of all data unless third-party components have been reviewed and confirmed.

Localization Through Language Overrides

If the extension displays text through language strings, use language overrides. This is Joomla's standard method for replacing individual phrases without editing extension files. In the admin panel, choose the correct language and site area, find the string by text or key, and save your custom wording. After the extension is updated, that override should remain in place, while a manual edit inside the extension files may be lost.

Support After Deletion

It is helpful to include a single support contact channel in the notification sent to the user. Do not put a long legal statement directly into the modal window. A short warning plus a link to the site's policy or support page is usually better. If a user deletes the account by mistake, support needs to know which mode is enabled: recovery may be easier if the account was blocked, and it may be impossible without a backup if the deletion was permanent.

Why Account Deletion May Not Work and How to Diagnose It

Problems with JMP Delete My Account usually do not come from one "magic" error, but from a break somewhere in the chain: the menu item is visible to the wrong users, the confirmation script does not load, the email never arrives, the user enters the code too late, the selected mode does not match expectations, or a third-party component stores data separately. The best way to diagnose the issue is by symptoms.

The Delete Option Is Visible to Guests

Symptom: the account deletion link or menu item is displayed without signing in.

Possible cause: the menu item, module, or article was left at the Public access level. Sometimes the administrator restricts only the menu module, but forgets about the page itself.

What to check: the Access field on the menu item, module access, access on the related content item, and the direct URL in a private browser window.

How to fix it: set Registered or a custom access level, clear the Joomla and template cache, then retest the page as a guest and as a regular user.

Nothing Happens When the User Clicks

Symptom: the user clicks the link but sees no modal, form, or page transition.

Possible cause: the required plugin is not published, the wrong menu-item type was selected, an old trigger class is being used for the wrong version, the template breaks the JavaScript, or the cache is serving an outdated page.

What to check: whether the component opens in the admin panel, whether related plugins are published, whether the browser shows JavaScript errors, whether the menu item was created correctly, and whether an optimization plugin disabled the required scripts.

How to fix it: start with the extension's standard menu item if one exists. If your version's documentation requires a CSS class, check the exact spelling. Temporarily disable aggressive JavaScript optimization and repeat the test.

The Email Code Never Arrives

Symptom: the user starts deletion but never receives the confirmation code.

Possible cause: Joomla mail is not working, the message is landing in spam, SMTP is misconfigured, the user's email address is invalid, or the mail server is rejecting the sender.

What to check: Joomla test mail, the spam folder, SMTP logs, the user's address, SPF/DKIM records, and the email content.

How to fix it: configure SMTP correctly, use a sender address on the site's domain, and test delivery across multiple mail services. Do not disable confirmation until you have ruled out the mail problem.

The User Is Deleted, but Their Content Remains

Symptom: the account is closed, but comments, articles, orders, files, or a profile in a third-party component are still visible.

Possible cause: the third-party component stores its own data, and deleting the Joomla user does not automatically clean up every related record. Joomla User API documentation also warns that user references in some records may remain.

What to check: comments components, store components, community tools, file components, subscriptions, forms, and custom user fields.

How to fix it: prepare a manual checklist for handling related data. For sites with privacy requirements, use the Joomla Privacy workflow or a specialized component that supports the integrations you need.

An Administrator Account Cannot Be Deleted

Symptom: deletion does not work for a user with administrative privileges.

Possible cause: this is an expected limitation. JED states that the deletion feature is unavailable for admin accounts.

What to check: the user's group memberships and assigned permissions. Sometimes a test user is accidentally placed in an elevated group.

How to fix it: test only with a regular registered user. For administrative accounts, use standard user management and a separate access-transfer procedure.

The Layout Broke After Enabling the Menu Item

Symptom: the delete item looks like a normal link, stands out too aggressively, or displays incorrectly in the mobile menu.

Possible cause: the template applies menu classes differently, the CSS was added too broadly, or the item was placed in the wrong module.

What to check: the HTML class on the menu item, the mobile menu, hover states, text contrast, and visibility for keyboard navigation.

How to fix it: use a dedicated menu-item class and minimal CSS in the template file. If the styling hurts accessibility, roll back the CSS and keep the default appearance.

Product Demo Video

The Joomla Extensions Directory listing for JMP Delete My Account includes a YouTube demo video. It is useful as a visual reference for the user workflow: where to find the extension demo, what the account deletion logic looks like, and which interface elements are worth checking after installation. The video does not replace testing on your own site, because the menu structure, template, mail delivery, and access permissions depend on your specific Joomla configuration.

After watching it, do not copy the settings mechanically. Use the video as a reference point, then repeat your own validation workflow: the guest does not see the item, the user receives the code, the administrator receives the notification, the account changes state, and related data is reviewed separately.

When JMP Delete My Account Is the Right Choice

JMP Delete My Account is worth using if your Joomla site has real registered users and you want to give them a clear, controlled way to close their account. The extension is especially appropriate for communities, member dashboards, and private sections where manual request handling is already creating support overhead. Its main strengths are user self-service, the choice between deletion and temporary blocking, email confirmation, and administrator notifications.

Before launch, verify three things: the menu item is accessible only to registered users, email-code delivery is reliable, and the consequences for related data are understood. If the site stores orders, comments, publications, or profile data in third-party extensions, do not promise users that one click will wipe every piece of data. Define the process first, then enable the feature on the live site.

If the workflow behaves correctly after testing, you can download JMP Delete My Account and roll it out step by step: first with a test user, then in a private menu, then with notification checks, and only after that for all appropriate user groups.

The main criterion is simple: the user understands what will happen, the administrator sees the event, the site does not expose a risky action to guests, and related data does not go unmanaged. If those conditions are met, the extension turns account deletion from a manual support request into a normal part of the Joomla user dashboard.