Support & FAQ

That's the supply-chain guard doing its job. On the first install of a GitHub-mapped add-on, Addon Expert pins the repo's stable numeric identity (owner ID, repo ID, created date). If those change later, it blocks the install — that pattern matches an ownership transfer or a deleted-and-recreated repo (RepoJacking).

If you know the change is legitimate (the maintainer transferred the repo, or you intentionally moved to a fork), use Reconfirm trust on the Releases screen to pin the new identity, then install. The reconfirm is itself written to the Audit Log. A username rename alone does not trip this — the numeric owner ID is stable across renames.

The add-on's addon.setup.php declares a higher PHP/EE requirement than your server runs, and EE itself would refuse it too. Addon Expert surfaces this before extracting. The right fix is to upgrade PHP/EE to meet the requirement.

If you believe the author over-declared (the code doesn't actually use the newer version), tick Override version requirements — Addon Expert holds the upload, scans the code, and tells you whether anything newer than your version is actually used. Forcing patches the declared requirement so EE accepts it, and flags the add-on with an override badge. The scan is best-effort: it can't see dynamic calls, so verify before relying on it.

No — that's what auto-finalize is for, and it's on by default. After Addon Expert swaps the files, the next time you load one of its screens it runs EE's update step (the add-on's upd.php + the version-row bump) automatically. If you've just installed and the banner is still there, load the Packages or Releases screen once. If it persists, check Settings → "Auto-finalize" is enabled, and look at the Audit Log for an auto_finalize_failed entry with the error.

PHP opcache can briefly serve the old addon.setup.php after a swap; Addon Expert invalidates it, but a very aggressive opcache config (or validate_timestamps=0) can still delay things. Reload the screen once. The Audit Log records the install either way, and the auto-finalize banner shows the from→to versions or a "nothing to do" note so you always know what happened.

No. Addon Expert uses a new short name (addon_expert), so EE treats it as a separate add-on — but on install it copies your existing config from the old addon_installer (GitHub mappings, trust anchors, settings, requirement overrides, and the release cache) to the new names. The originals are left untouched, so the old add-on keeps working until you uninstall it and a rollback loses nothing. After confirming everything carried over, uninstall the old "Addon Manager +" and re-add the CP custom-menu entry (it points at the new short name).

Addon Expert can't force itself into the Custom menu — EE keeps that admin-controlled. Add it once via Settings → Menu Manager (a CP page, not the add-on's own Settings). Then Addon Expert's hook renders the label with a pending-update count, e.g. Addons (3). You can change the label and toggle the count under Addon Expert → Settings.

One-click GitHub updates keep a backup of the previous version under system/user/cache/addon_expert/backups/<short_name>/<timestamp>/ (outside the add-ons directory). To roll back, replace system/user/addons/<short_name>/ with the backed-up copy and load a CP page so EE re-reads the version. You can also just install any previous release from that add-on's GitHub releases tab.

Yes — Addon Expert is MIT licensed and the full source is public at github.com/calimonk/ee-addon-expert. Every release is free, with no license keys or per-site limits. Fork it, read it, send a pull request. It's a maintained fork of Addon Manager + by Javid Fazaeli.

The only outbound calls are to the public GitHub API — to check /releases/latest and verify repo identity for add-ons you've mapped — and to download a release when you click install. Calls are unauthenticated (public repos only). Nothing about your site is sent anywhere; the audit log and caches stay on your server.