Site front end

The same file manager, published to logged-in site users through a Joomla menu item — no admin access required.

Why put it on the front end

Giving a client, contributor or contractor a file manager normally means giving them a Joomla admin login. That is a broader grant than the job needs, and on many sites it is one you would rather not make at all.

The site component removes that trade. A user logs into the front end as they already do, follows a menu item, and gets the file manager scoped to exactly the folders their profile grants — with no route into the administrator at all.

Publishing it

The package installs the site component, but nothing is public until you create a menu item.

1. Menus → (your menu) → Add New Menu Item
2. Menu Item Type → Next File Manager → File Manager
3. Access → a level that requires login. Not Public — guests have no profile and get nothing, so a public item is an empty page with a login prompt behind it
4. Set the title and menu position as usual
5. Save

Users whose profile grants at least one root now see the file manager at that URL.

What is identical to the admin

Everything that matters:

• The same app. The identical single-page application, with the same browser, tree, context menu, editor, lightbox, upload queue and search.
• The same profiles. Front-end access resolves through exactly the profile mechanism described in Profiles & access control — the same roots, the same sixteen commands, the same limits, the same direct-beats-group precedence. There is no separate front-end permission model to keep in step.
• The same protection. Protected paths, secret files and per-path locks apply unchanged. See Protection.
• The same command allowlist. The front-end dispatcher accepts the same named operations as the admin and refuses everything else.
• The same logging. Front-end operations appear in the Activity log like any other.

There is deliberately no "front-end mode" that relaxes anything. A weaker enforcement path reachable without an admin login would be the obvious thing to attack.

What differs

• The Configuration tab is not there. Storage, places, profiles and settings are admin-only. A front-end user manages files, never the component.
• The Activity Log tab is not there. It is Super-User-only, and a Super User is in the admin.
• The chrome is the site's. The app renders inside your site template rather than the admin one, and follows the template's width.

Session expiry

Long file work outlives short sessions, and an upload queue that dies on an expired session with no explanation is a bad afternoon.

When a request comes back unauthenticated, the app raises an in-place re-login dialog instead of navigating away. Enter your password, and the interrupted request is replayed — you carry on where you were, with your place, path and selection intact.

This needs System - Next File Manager Session enabled under System → Manage → Plugins. It ships with the package and is enabled on install.

Access checklist

If a user reports an empty page or a permission error:

1. Is the menu item's access level login-required, and does the user meet it?
2. Do they have a profile? Front-end users need one exactly as admin users do — see Profiles & access control.
3. Does that profile grant at least one root? Commands without roots grant operations on nothing.
4. Is the place published? An unpublished place is invisible even to a profile that grants it.
5. Is the session plugin enabled?

Security notes

• Use HTTPS. File contents and credentials transit every request. This matters more on the front end, where users are likelier to be on untrusted networks.
• Scope tightly. A front-end grant is reachable by anyone who obtains that user's site password. Grant the narrowest root that does the job, and leave write off where reading is enough.
• Prefer a dedicated profile. Do not reuse an admin-facing profile for front-end users just because the folders overlap — separate profiles let you tighten one without disturbing the other.