Auto Update Approval Guard - Joomla Extension

How to Configure Auto Update Approval Guard for Controlled Joomla Updates

Auto Update Approval Guard is most useful not when you simply want to turn on another Joomla feature, but when automatic core updates need to become a controlled workflow. The extension adds a required decision point before an automatic update: a new version cannot be installed until an authorized recipient either approves it through the link in the email or blocks it.

Below, we will cover site preparation, installation of the system plugin, recipient selection, status flow, a practical approval workflow, and how to verify the outcome. We will also look at cases where it makes sense to temporarily disable automation, how not to confuse approval with immediate installation, and why version history matters more than it may seem at first launch.

This guide is intended for site owners, administrators, agencies, and developers who already maintain Joomla 6 sites and want to preserve the speed of automatic patching without allowing core changes to happen unless a responsible person has made a clear decision.

What Problem Pre-Update Approval Actually Solves

In Joomla, automatic core updates are designed to help a site receive available fixes more quickly. On its own, that is convenient: you do not have to keep logging into the admin panel, watching every notification, and running standard updates manually. But on a live site, a core update almost always affects more than just CMS files. It can expose an extension compatibility issue, an outdated template override, a bug in custom code, a changed integration behavior, or a problem that only end users will notice.

Auto Update Approval Guard does not replace Joomla's built-in update subsystem, and it does not update third-party extensions. It works specifically before an automatic core update. When Joomla detects a new target version and attempts to run an automatic update, the plugin checks the status of that version. If no decision has been made yet, the current attempt is stopped, a record is created for that version, and an email is sent with two actions: approve or block.

This approach is especially valuable where technical responsibility is shared. For example, the site owner may have access to the site, the agency may handle support, and a developer may be the one who must approve the update. Instead of sharing passwords or asking someone to urgently log into the admin panel, the stakeholder gets an action link. At the same time, that link does not turn the email into a mechanism for instantly deploying a new version: it changes the decision for that specific version, while the next installation attempt remains the job of Joomla's standard service.

What Happens Before Any Files Change

According to the developer, the plugin intercepts the onBeforeJoomlaAutoupdate event. This is an important detail: the check runs before the automatic mechanism starts replacing core files. For each new version, a separate state and a protected token are created, tied to both the version and the site. A user from the recipient list chooses one action, and the plugin records the outcome in its history.

The practical point of this interception is straightforward. The team gets a review window: time to read the release notes, make sure a backup exists, remember any nonstandard overrides, and decide whether the next automatic run should be allowed. The plugin does not promise that updates become risk-free; it makes the decision point visible, repeatable, and documented.

Why This Is More Than a Standard Email Notification

A standard notification simply tells you that an update is available. AUAG follows a stricter sequence: version detected, notification sent, approved or blocked, successfully installed, and finally recorded. Each version has its own lifecycle, rather than being just another email that can get buried among other alerts. That helps distinguish "we received the message" from "we approved this exact version."

Another difference is protection against repeated emails. For a single new version, the extension sends the initial request only once, and later automatic attempts use the saved state. So turning on approval control should not turn every new Joomla attempt into a flood of identical messages. If a version has been explicitly blocked, no new tokens or emails are generated for it.

Who This Workflow Fits and When Another Approach May Be Better

The extension fits well on sites where core updates cannot be left completely unattended, but manually managing every release is still too slow. This could be a corporate website with integrations, an online storefront with custom modules, a portal with multiple editors, a client site maintained by an agency, or a group of similar sites where one responsible person needs to confirm the decision.

AUAG is especially useful in a "one site, multiple roles" setup. A technical specialist can prepare the validation, the project owner can decide on the timing, and the support mailbox can receive the notification. The plugin can pull recipients from Joomla user IDs, user groups whose members are allowed to receive system emails, and direct email addresses. These sources are merged with duplicates removed.

• A good fit for a public Joomla 6 site where automatic core updates are already needed, but each change must be approved.
• A good fit for an agency that wants the client or the on-call engineer to make the decision without giving them admin panel access just for a single action.
• A good fit for a project with an internal procedure: backup, quick review, approval, and post-update verification.
• May not be a good fit for a staging environment where updates are intentionally applied without approval and the team is ready to restore the environment quickly.
• May not be a good fit for a local or private site if Joomla's built-in automatic update mechanism is unavailable because the site is not publicly accessible.
• Does not replace update management for third-party extensions, templates, or custom code. Those require a separate review process.

There is little reason to enable the plugin just for a nice-looking status history if the site does not use Joomla automatic updates at all. The developer explicitly notes that if automation is disabled in the Joomla update component, the extension remains passive. First decide whether the site truly needs an "automatic, but only after approval" model rather than fully manual or fully autonomous maintenance.

What to Check Before Installing It on a Live Site

Preparation matters because AUAG controls the approval point for an update, not the consequences of a failed update. If it is unclear before installation who makes the decision, where the emails go, and how quickly the site gets checked after a core change, the plugin will simply make a disorganized process more visible.

Compatibility and Update Availability

The product page states that this is a system plugin for Joomla 6 and requires PHP 8.3 or later. Do not assume that applies to an older Joomla installation: if the site does not meet the stated CMS and PHP requirements, first create a separate platform upgrade plan. Also make sure the site is publicly accessible for Joomla's built-in automatic update mechanism. The official Joomla documentation notes that automatic updates are intended for publicly accessible sites; for a private staging environment behind a firewall, a manual workflow is usually required.

Backup and Restore Readiness

Before changing the update workflow, verify not just that a backup exists, but that restoration is actually possible. You need copies of both the files and the database, a clearly defined storage location, access for the responsible staff member, and a brief record of how to bring the site back online. Joomla's built-in backup reminder does not replace this check. Do not approve the first update through the new workflow until it is clear who will restore the site and how if something goes wrong.

A practical minimum is to restore the backup on a test environment, confirm that it opens correctly, and document the latest changes to the template, integrations, and custom additions. If the site includes payment forms, a user account area, an external system sync, or custom scheduled jobs, add them to a short post-update validation list.

Email and Recipients

Because the decision arrives by email, system email reliability is critical. Check the sender address, delivery to external domains, the spam folder, and whether a real owner is responsible for any shared mailbox. Do not use the address of someone who no longer works on the site just because they are still a super user. It is better to define at least two responsible contacts: the primary recipient makes the decision, and a backup receives the same notification and can step in if the primary person is unavailable.

If you plan to use a Joomla group, make sure the right users are actually in it and that they have the setting enabled to receive system emails. Otherwise, the group may exist in the permission structure while some people never enter the actual notification chain. After enabling the plugin, run a safe delivery check using a test address or during the first controlled release.

Decision Procedure

Agree in advance on what each action means. Approval should mean: the team has seen the notification, knows which backup is current, understands when Joomla will make the next attempt, and is ready to verify the site. Blocking should mean something different: this specific version must not be installed automatically on this site, and any further action will be handled manually in the admin panel. Do not use blocking as a "remind me later" button unless you have a record of why the version was stopped and who will revisit it.

Practical tip: add four lines to your internal procedure: who receives the email, who approves it, which pages are checked after the update, and where the working backup is stored. That is enough to make AUAG part of a real process rather than just another plugin with an unclear purpose.

Installing the System Plugin and Running the First Controlled Check

Installation is done through Joomla's standard installer component. After installation, the developer points to the system plugin path: System - Plugins - System - Auto Update Approval Guard Pro - AUAG. Open it, review the recipient settings, save the configuration, and enable the plugin. Then open the Joomla Update component and make sure automatic core updates are enabled: without that, AUAG never receives the automatic attempt it is supposed to control.

Do not treat the plugin's enabled status as proof that the whole chain works. On the first run, you need to confirm three separate things: Joomla can perform automatic checks, the plugin is active, and email delivery works. At the same time, do not try to force an update on a live site just to demonstrate the process. It is safer to use the next real update or rehearse the workflow first on a comparable copy of the site.

A Low-Risk Sequence

1. Save a backup and record the current Joomla version in the team's maintenance log.
2. Install the extension archive through the Joomla admin panel using the standard process.
3. Open the AUAG system plugin, define the recipients, and enable it.
4. Review the automatic update settings in the Joomla Update component, without changing the update channel unless you have a separate reason to do so.
5. Confirm that the responsible people have access to the working mailbox and understand the approval or blocking process.
6. Document who will review the plugin history and which site pages will be checked after a version is installed successfully.

After saving, do not expect a new table to appear on the front end of the site. AUAG is part of the administrator-side system workflow. Its visible output appears when a new automatic attempt happens: an email, a history entry, and a status change for a specific version.

Why You Should Not Change the Update Channel at the Same Time

The Joomla update channel determines which versions the site considers in the first place. AUAG controls whether a version is allowed through, not which release source gets used. If you switch channels, change automation settings, update extensions, and enable a new plugin all on the same day, it becomes difficult to tell what caused any outcome. First stabilize the baseline Joomla configuration, then enable the approval layer, and only after one successful cycle change other parameters one at a time.

Configuring Recipients: Who Gets the Right to Decide

The most important AUAG setting is not cosmetic, but organizational. The developer confirms three recipient sources: Joomla user IDs, user groups with the ability to receive system emails enabled, and direct email addresses. The extension merges recipients and removes duplicates. That means you do not have to build a separate structure for every site, but it does require careful role selection.

For a small site, it is convenient to specify one responsible Joomla user and one backup email address. For a team, it makes more sense to combine a group containing the technically responsible staff with a shared support address. An external address is useful if the decision should go to an agency or a project manager who does not need normal access to the admin panel.

Do not add a broad "all administrators" group unless you truly need it. The more recipients you add, the greater the chance that different people will make conflicting decisions or assume someone else will handle it. The plugin uses protected links, but token security does not remove the need to limit decision-making to the right people.

A Typical Configuration for a Live Site

For a client site, you might use one shared support mailbox as the primary channel and two Joomla users as backups. One person is responsible for the decision, and the second confirms that the email does not go unanswered. If the client needs to approve the maintenance window, they can receive a direct copy of the notification, but the team should agree in advance on who actually clicks the link. This matters especially when updates are allowed overnight and several people read the same mailbox.

Also verify that the corporate mail system does not rewrite long links, require a second sign-in to another account, or hold messages for moderation. If company policy makes those links hard to use, do not try to work around it with technical tricks. It is better to approve the sender address, use a dedicated mailbox, or stay with manual updates until the email path becomes reliable.

The Version Lifecycle: From Pending to Final Recorded Outcome

It is most useful to think of AUAG not as a toggle, but as a state log for a specific Joomla version. When the automatic update service detects a new version, the extension creates a record for it. The history can then include markers for creation, notification sent, approval, blocking, and final recording after a successful installation.

Waiting for a Decision

A new version begins in a pending state. At this step, the plugin generates a token tied to the version and the site, then sends the initial email. The automatic attempt that triggered this step does not continue with the update. This matters for troubleshooting: if the version was not installed after the email, that is usually not an error. That is exactly how the protective layer is supposed to behave.

Approval Without Immediate Installation

After someone clicks the approval link, AUAG changes the state of that version. However, approval does not launch the installation that same second. The developer explains that Joomla's central service tries again later, usually after a noticeable delay and with a limited number of attempts for that version. So there is no need to click the link multiple times, reinstall the plugin, or start troubleshooting just because the Joomla version number did not change immediately after the email.

Your internal procedure should account for that delay. If the update must happen within a strict maintenance window, check whether Joomla's automatic cycle is the right fit for that task. If it is not, it is more reliable to run a manual update in the admin panel after approval rather than expecting the email approval to act like an instant deployment button.

Blocking a Specific Version

The blocking action applies to one specific version. According to the AUAG description, that version will no longer be installed automatically on that site, no new tokens or repeat emails will be generated for it, and the confirmation email indicates that installation must be done manually through the admin panel. This is useful if the team already knows about a problem with a custom template, integration, or critical extension and wants to stop that particular release without disabling automation permanently.

Blocking comes with a cost: it does not solve the compatibility problem, it only postpones the change. So record a short reason, a link to the task, and a re-evaluation date in your internal log. Otherwise, a few weeks later you will see the status but have no idea why an important update still has not been installed.

Final Recording After a Successful Installation

When a previously approved version is successfully installed through Joomla's standard automatic mechanism, AUAG moves it to a final state that is no longer open to changes and sends a success email showing the old and new Joomla versions. This final record is useful for auditing: it lets you separate "approved" from "actually installed." The history in the plugin settings becomes a compact chronology rather than a set of guesses based on the mailbox.

How to verify the outcome: after the cycle is complete, find the version entry in AUAG history, match its status to the success email, and then verify the version in the standard Joomla Update component. Only when all of those indicators line up can you confirm that the change was not just approved, but actually applied.

Practical Example: Updating an Agency-Managed Site with Required Approval

Consider a live client site with custom template changes, a contact form, and an integration with an external service. The client does not want admin panel access, and the agency does not want the core update installed until the release notes and backup have been checked. Joomla automatic updates are enabled, AUAG is installed, and the recipients are the shared support mailbox, the lead developer, and a backup address for the project manager.

Goal and Preparation

The goal is to keep allowed fixes flowing automatically while stopping installation until the team decides. Before a new version appears, the team verifies the backup, defines the validation route, and agrees on roles: the developer evaluates technical risk, the project manager chooses the timing, and the on-call specialist watches the outcome. The route includes the home page, the form, the admin login, a page with a critical user action, and the hosting error log if it is available.

Step 1. Joomla Detects a New Version

Joomla's built-in service starts an automatic attempt. AUAG receives the event before any files change and sees that the target version does not yet have a decision. It creates a record, generates a protected token, and sends the initial email to the recipients. At this step, the site stays on the previous version, which is the expected outcome.

The on-call person should not treat the lack of an update as a failure. Their job is to confirm that the email arrived and that the version appears in the history with a pending status. If the email is missing, first check delivery, recipient sources, and whether the plugin is enabled rather than clicking random buttons in Joomla Update settings.

Step 2. The Team Makes a Decision

The developer reads the official Joomla release notes and compares them with the site's specifics. If nothing points to a risk, they confirm that the backup is current and the validation route is ready. The authorized recipient clicks the approval link. If the team already knows about a compatibility issue, they choose blocking instead and record the reason and the manual update plan in the working task.

It helps to separate the decision from the test. Approval does not prove compatibility. It only allows the next automatic attempt. Testing happens either in advance on a site copy or immediately after a successful update, once the system confirms that installation has actually happened.

Step 3. Wait for the Next Scheduled Run

After approval, do not try to speed things up by clicking the link repeatedly. The plugin saves the decision, and the next installation depends on Joomla's built-in schedule. In the team log, record the approval time and the period during which the on-call person will monitor the outcome. If the update is critical and must happen immediately, switch to Joomla's normal manual update procedure after a separate evaluation instead of breaking the AUAG workflow.

Step 4. Confirm the Update and Check the Site

Once installation succeeds, a success email arrives. The on-call specialist opens Joomla Update, verifies the current version, and runs the prepared validation route. They open the public home page without signing in, test the important form with a sample submission, sign into the admin panel, open the page with the custom template, and check for critical errors in the available log.

If every item passes, the team records a successful outcome and keeps the backup reference until the next review period. If only one element breaks, do not assume AUAG is at fault: the plugin controls approval, but the root cause may be in the template, an extension, or custom code. In that case, follow your normal restore and troubleshooting plan.

How to Verify That the Approval Layer Is Actually Working

AUAG validation should be based on signals, not on a single screen. You cannot treat the process as configured just because the plugin is enabled. You need confirmation of correct behavior before a decision, after a decision, and after installation.

Check not only AUAG history, but also Joomla's standard information. The plugin history shows what decision was made for a specific version. The Joomla Update component shows the platform's update state. The email confirms that the notification reached the selected channel. Together, these three sources give you a far more reliable picture than a single screenshot.

Checking the Front End After Success

The exact page set depends on the project, but the minimum route should be short and repeatable. Open the home page in a new window, check the contact page, submit a test form, sign in with a normal user account if one exists, and review a critical workflow such as search, cart, service booking, or lead submission. Do not try to manually test the entire site after every update. It is better to choose five to ten functions whose failure would actually matter to the business.

If caching is in use, clearing the cache may be necessary only after you have recorded the symptom and understand that the cause is tied to stale markup or assets. Do not clear everything before checking: otherwise, you may erase a useful troubleshooting trail. First compare the page in a private window, confirm that the problem is reproducible, and only then proceed according to the site's maintenance plan.

Workflows That Should Stay Separate: Core Auto Updates, Manual Installs, and Extension Updates

One common mistake is assuming that AUAG controls every update on the site. According to the developer's description, it stands in front of automatic Joomla core updates. Joomla's built-in automatic update feature also applies to the CMS core. Third-party components, modules, plugins, and templates use their own update channels and may require a different workflow.

This limitation does not make the plugin weak. On the contrary, it gives it a clear boundary of responsibility. AUAG answers the question, "Should this Joomla version be allowed to install automatically on this site?" It does not answer, "Are all add-ons compatible?" and it does not perform bulk maintenance for a collection of extensions. For that second question, you need testing, a list of critical add-ons, and, when necessary, a separate tool for managing multiple sites.

When to Keep Automatic Mode Enabled

Keep automatic updates enabled if the site is public, the team is prepared for a brief review, and the delay until the next built-in attempt is acceptable. AUAG is especially useful when you want to keep patch automation but add a human decision point. It is a compromise between fully manual maintenance and having no review checkpoint at all.

When to Temporarily Switch to Manual Mode

Temporarily disable automatic mode in Joomla Update settings if the site is going through a major redesign, a template migration, a critical extension replacement, or a period when no one can confirm recovery. In that situation, the plugin should not become an excuse for risky automation. It remains passive, and the team performs the update manually in a scheduled window after testing.

How to Combine AUAG with a Staging Copy

This safe practical pairing is not a special official integration. It is simply a standard Joomla maintenance workflow: first validate the new version on a copy of the site, then approve it for the live site through AUAG. On the copy, disable real notifications or use isolated addresses so the team does not get confused. On the live site, keep only the recipient list that should actually make the decision.

Verifying this setup is straightforward: the critical validation route is repeated on the copy, and then the live site confirms that a current backup exists before approval. If testing reveals a problem, the version is blocked for automatic installation and tracked in a separate task. The rollback is not removing AUAG, but refusing approval for the problematic version and switching to manual mode until compatibility is understood.

Limits You Should Not Hide Behind the Word "Protection"

Auto Update Approval Guard adds a review barrier, but it is not a backup system, availability monitor, antivirus tool, testing platform, or extension update manager. Its tokens and history help confirm the decision, but they cannot guarantee that a specific release will not cause a conflict. So do not promise a client "complete safety" after installing the plugin.

It is also important to account for the email dependency. If a message lands in spam, no one actually owns the shared mailbox, or the recipient does not understand what the links mean, the process will stall in a waiting state. That is safer than a silent installation, but it can delay an update you do need. Review the recipient list regularly after staffing changes and verify that the site's email infrastructure is functioning.

A blocked version does not automatically disappear as a risk. It simply will not be installed automatically by this plugin on that site. The team still has to decide how to apply the update manually after compatibility has been reviewed. If blocking becomes a permanent state without an assigned task and owner, it turns into a quiet accumulated problem.

A Safe Improvement That Does Not Require Code Changes

AUAG does not require a custom PHP snippet or edits to the plugin files. The available sources do not confirm a precise public extension point for that kind of code, and changes to a system plugin will be lost during updates. Instead of code, use Joomla's built-in tools: user groups, system email settings, a dedicated support mailbox, a backup, and a decision log.

If you need to change the wording of the team's companion message, do it at the level of your internal email template or written procedure rather than interfering with token logic. For example, you can create a standard task with fields for the target version, release notes link, backup, test results, approver name, and verification time. That approach is reversible, does not depend on the extension's internal code, and makes audits easier to follow.

When Auto Update Approval Guard Is the Right Choice

AUAG is worth using when a site is already ready to receive automatic Joomla core updates, but the team wants a clear decision point before installation, a well-defined recipient list, and per-version history. Its strength is not a promise of trouble-free updates, but operational discipline: a new version is visible, the action is assigned, the decision is recorded, and success can be distinguished from simple approval.

If you have confirmed Joomla 6 and PHP compatibility, configured reliable email, prepared a backup, and agreed on a site review process, you can download Auto Update Approval Guard and start with one controlled cycle. After the first successful update, keep your short procedure next to the plugin history so the extension becomes not a one-time safeguard, but a clear part of regular site maintenance.