Migrate the admin theme from Bootstrap 3 to Bootstrap 5

[e107help]

Summary

Move the e107 admin area off Bootstrap 3 and onto a modern framework. The BS5 plumbing already exists in core (the 5.3.3 bundle is vendored under e107_web/lib/bootstrap/5/, registered in library_manager.php, and coreTemplatePath() already prefers e107_core/templates/bootstrap5/ when BOOTSTRAP > 3, see e107_class.php L3325-3336). What is missing is a BS5 admin theme face and the markup/compat work to render the admin UI under BS5.

Split out of #5686. Depends on the custom-admin-theme unblock landing first.

Framework decision happens here

This is the issue where the framework choice is settled. The two candidates:

• Plain vendored Bootstrap 5 (5.3.3) that is already in core. Lowest dependency footprint; nothing new to ship.
• tabler.io, a full admin UI framework built on Bootstrap 5. @Alex-e107nl and @Jimmi08 both favour it and hold licences for it; @Alex-e107nl's case is that every plugin developer gets documented components and examples, giving consistent admin integrations "so why reinvent the wheel." tabler is customisable via CSS variables, which feeds naturally into the admin theme preferences issue.

This decision was deliberately deferred out of the core unblock so the unblock is not held hostage to it. Please keep framework debate in this issue.

Scope of the migration work

• A Bootstrap 5 admin theme face (the bootstrap5 frontend theme currently has no admin half).
• Reworking admin markup that hardcodes BS3 classes (panels -> cards, BS3 grid/utility classes, button class shims, etc.).
• Compatibility handling for shared admin output so existing plugins keep rendering during the transition.
• FontAwesome 5/6 handling already exists version-aware in toGlyph() / toIcon(), so icon markup is largely covered.

Acceptance

• The admin area renders correctly under Bootstrap 5 end to end.
• The chosen framework (plain BS5 vs tabler.io) is decided and recorded in this issue.
• bootstrap3 admin theme continues to work for sites that have not switched.

---

Type: Feature. Triage Status: Backlog. Priority: Low. Split from #5686. Framework choice (plain BS5 vs tabler.io) to be decided here.

[Jimmi08]

Start point:
Get a list of all internal (core) classes that are mandatory for admin JavaScript (jquery, ajax...) - they should start with e_ prefix - with their functionality and conditions.
Check if all mandatory classes from JavaScript code use a custom prefix (so that they do not depend on Bootstrap class names)
Out of head - filtering, deleting, modal...

I mean - if I use class f.e. e_delete, then deleting functionality will be triggered out of box.

And bonus request - mark them if they can be used only in the admin area or the frontend too (yeah, I am pointing of using admin_ui / frontend_ui for members on frontend) (they should be separated by admin.jquery.js or front.jquery.js or something like that - some are in both, some not)

Thanks

[e107help]

Ahoj @Jimmi08, this is exactly the right place to start, and the good news is most of the groundwork you are describing already exists.

How the JS is split today

The behaviour files are loaded by context, so the admin-only vs frontend-too split you want is already encoded in which file a class lives in:

• all.jquery.js loads in both, admin (e107_admin/header.php#L63) and frontend (header_default.php#L63).
• admin.jquery.js loads in the admin area only (e107_admin/header.php#L62).
• front.jquery.js loads on the frontend only (header_default.php#L62).

The mandatory hook classes

They do already use the custom e- prefix you are hoping for, so the trigger selectors do not depend on Bootstrap class names. Your e_delete example is real: put the class on an element and the behaviour fires out of the box.

Both contexts (all.jquery.js), the framework-agnostic core:

Class	Does
.e-ajax	AJAX-driven form/page enhancement (L123-166)
.e-expandit (+-on/-off/-container)	show/hide toggles (L214-238)
.e-dialog-close	close a dialog (L304-310)
.e-hideme	hide on init (L340-343)
.e-modal	open content in a modal iframe
.e-confirm	browser confirm before submit (L867)
.e-tip	tooltip (L1130)
.e-tabs (+-add), .e-date/.e-datetime, .e-bb (bbcode), .e-rate, .e-nav, .e-password, .e-email, .e-multiselect	tabs, pickers, bbcode, rating, nav, etc.

Admin only (admin.jquery.js): .e-modal (admin iframe variant, L14), .e-tip, .e-confirm, .e-spinner, .e-count, .e-editable/.e-container, .e-sort (drag reorder), .e-toggle-sidebar, .e-sef-generate, .e-progress/.e-progress-cancel, .e-radio-multi, .e-typeahead, .e-alert, .e-shake, .e-noclick, the menu-manager .e-mm-selector, and the check-all/uncheck-all ids #e-check-all / #e-uncheck-all.

Frontend only (front.jquery.js): the comment behaviours .e-comment-submit / .e-comment-reply / .e-comment-edit / .e-comment-delete / .e-comment-approve, plus .e-rate-thumb, and shared .e-modal / .e-tip.

(I left the delete trigger named in admin-UI terms: there is no single .e-delete class. Row delete in admin_ui goes through the .e-confirm + standard etrigger submit path rather than a dedicated delete class.)

The catch for the BS5 work

The trigger classes are clean. What is not framework-independent yet is the JS body: several behaviours reach into hardcoded Bootstrap 3 structural classes when they manipulate the rendered widget, for example .modal-body / .modal-footer (admin.jquery.js#L48-L56), .dropdown-menu (L1115), .nav-tabs / .tab-pane, and the BS3-only .well. BS3 and BS5 share .modal-body and .tab-pane, but .well is gone in BS5 and a few wrappers change, so that is where the real porting effort lands, not in your e_ hooks.

So your instinct holds: keep tagging behaviour with the e- prefix and your themes stay framework-neutral. The migration work is the markup the JS expects to find inside those hooks.

The framework choice itself (plain BS5 vs tabler.io) is a separate call and the call there belongs to Deltik, so I will keep that thread above and not muddy this one.