Description: A meta-extension that moves Flarum from a "Fixed Template" to a "Component-Based" layout, allowing admins to unhook any Mithril component (from Core or Extensions) and relocate it into custom-defined layout slots.
Key Modules:
The Porter: A GUI to map components to slots (e.g., StartDiscussionButton -> BottomRow-Left).
The Nuke: A master list of "Kill-switches" for default CSS/JS behaviors (Drawer, Toolbar, Hero).
The Asset Morphing Engine: A "CSS Reset" panel for Branding (Circular Logos, Button padding, Row heights) that uses all: unset logic to prevent "Style Leaks."
The Hook Engine: Automatically adds state-based classes (.is-guest, .is-mobile, .is-admin) to the body for zero-JS CSS styling.
Executive Summary:
Flarum’s strength lies in it's minimalist, component-based Mithril.js architecture. However, for the average administrator—particularly those on hosted platforms like FreeFlarum—modifying the core layout (e.g., creating a double-row responsive header, relocating the Search component, or disabling the mobile drawer) currently requires either fragile DOM manipulation via Custom JS or a high-entry-barrier extension development cycle.
I am proposing Flarum Architect: a "Meta-Extension" designed to act as a bridge between Flarum’s rigid default templates and a fully modular, component-agnostic UI.
The Technical Concept: "Component Teleportation"
Instead of using standard CSS display: none or jQuery-style appendChild()—which often break Mithril’s virtual DOM reconciliation—Flarum Architect would utilize Mithril Portals.
This allows the extension to "unhook" a native component (e.g., IndexPage-newDiscussion or HeaderSecondary) from its default parent and "re-hook" it into custom-defined HTML slots created in the Admin Area.
Key Functional Modules:
- The Component Mapper (The Porter)
A GUI in the ACP that lists registered Mithril components (Core & popular Extensions).
Users can map these components to "Layout Slots" (e.g., Top-Row-Right, Action-Bar-Left, Sidebar-Bottom).
Result: Components retain their full state, event listeners, and logic, but appear in entirely new locations.
- The Structural "Nuke" List (Logic Toggles)
A master list of boolean switches to disable hard-coded legacy behaviors that frequently conflict with custom designs:
[Toggle] Disable Mobile Drawer & Bottom-Sheet logic.
[Toggle] Force Desktop-style Dropdowns on mobile viewports.
[Toggle] Suppress Default Navigation Row (Desktop) or Toolbar (Mobile).
- The Asset Morphing Engine (Logo/Avatar Tools)
A surgical CSS panel that applies all: unset logic to branding elements.
Enables "one-click" transformations like Circular Logos or custom sizing without "Style Leaks" from Flarum’s core LESS files.
- Global State Hooks (Semantic Body Classes)
Automatically injects state-driven classes into the <body> tag:
.is-guest / .is-logged-in
.is-mobile / .is-desktop
.is-admin / .is-mod
Purpose: Empowers admins to write clean, targeted CSS without needing to write utility JavaScript.
Why the Ecosystem Needs This:
Reduced Fragmentation: Instead of dozens of "micro-extensions" that each move one small element, Architect provides a unified framework for layout management.
Stability for Non-Devs: By moving components at the Mithril level, we avoid the "Frankenstein effect" where custom scripts and core logic fight for control of the DOM.
Creative Freedom: It moves Flarum from a "Forum Software" to a "Community UI Framework," allowing for diverse designs that don't all follow the default skeleton.
For Self-Hosted Admins (The "Speed" Factor)
Self-hosted admins have access to extend.php, but writing PHP and Mithril for every minor layout change is time-consuming.
Rapid Prototyping: They can use Architect to test a new "Double-Row" layout or sidebar position in seconds via the ACP. If they like it, they can leave it running or use it as a blueprint to hard-code it later.
Lower Maintenance: Every time they update Flarum, they don't have to manually refactor their extend.php logic. Architect handles the "translation" between the new Flarum version and their custom layout.
For Developers (The "Boilerplate" Factor)
Experienced devs often get bored writing the same "Move the Search Bar" or "Hide the Hero" code for every client.
A Standardized Framework: Instead of reinventing the wheel, a dev can install Architect on a client's site and use the GUI to handle the "grunt work" of layout positioning.
Focus on Custom Logic: This frees the developer to spend their billable hours on unique features (like custom APIs or new functional extensions) rather than fighting CSS alignments in the header.
For Extension Authors (The "Compatibility" Factor)
If Architect becomes a standard, other extension authors can "register" their components with it.
Example: A developer makes a "Live Chat" extension. Instead of guessing where the user wants the chat toggle, they simply register the component with Architect, and the admin "Teleports" it to whichever row or corner they prefer.
The Universal Value
While Architect would be a game-changer for relatively restricted environments like FreeFlarum, its value is universal. For the self-hosted admin, it is a Rapid UI Prototyper. For the professional developer, it is a Layout Framework that eliminates the repetitive 'boilerplate' of UI relocation, allowing them to focus on high-level feature development.
Q: Won't "teleporting" components break Mithril’s Virtual DOM or event listeners?
A: No. By using Mithril Portals (or the m.mount / vnode redirection pattern), the component’s internal state, lifecycle hooks, and event listeners remain intact. It isn't "moving" an element after it renders; it is telling Flarum to render that component into a different container from the start.
Q: How does this impact performance or "page bloat"?
A: Paradoxically, this is often more performant than the current alternative. Many admins currently use 200+ lines of "MutationObserver" JavaScript and heavy CSS overrides to "hack" the UI. Architect replaces those expensive DOM-manipulation scripts with native internal routing, reducing layout shift (CLS) and CPU overhead.
Q: Will this break whenever Flarum Core updates?
A: By targeting standard Mithril components (like HeaderSecondary or Search) rather than specific CSS class names, the extension remains more resilient to minor version updates. As long as the component exists in Core, Architect can relocate it.
Q: Is this just for the Header?
A: While the Header is the most requested area for modification, the Architect framework is designed to be "Component-Agnostic." The goal is to allow the relocation of any registered UI element—from the Sidebar and Hero to Post-Stream widgets.
Q: How does this handle Mobile Responsiveness?
A: Architect provides the "Mechanical" move (e.g., placing a component in Row 2). The "Visual" styling remains CSS-driven. However, by providing global body classes like .is-mobile and .is-desktop natively, Architect makes it significantly easier for admins to write clean, responsive media queries that don't conflict with core logic.
Q: Does this replace existing extensions?
A: It complements them. While it might replace small "utility" extensions that only move one specific button, it empowers larger extensions (like Blog or Chat) by allowing admins to place those extension widgets exactly where they fit best in a custom layout.
Q: Isn't this too complex to build?
A: It's certainly a high-level engineering task, but it shifts the burden of layout stability from the amateur admin's CSS to a robust, developer-maintained framework. That is a net win for Flarum's reputation for stability.
Q: How does "Architect" specifically benefit hosted environments like FreeFlarum?
A: Hosted users are often the most restricted because they lack access to extend.php or the ability to upload custom extension folders. Currently, their only path to a unique UI is "Brute Force" CSS/JS injection via the Admin Dashboard, which is notoriously fragile. Architect provides these users with a "Virtual extend.php"—a high-level, stable GUI to orchestrate components and styles without needing server-level access. It turns a "locked" environment into a creative playground.
Conclusion: This is not a request for a specific layout. It is a request for a toolset that empowers the community to build their own layouts responsibly. By moving the logic from "Hacking the DOM" to "Orchestrating Components," we improve the stability and professional standard of Flarum customisation.
