feat: Improve plugin DX: multi-file structure support and better handling of embedded HTML/JS

Before Submitting

• I searched open and closed issues and discussions for an existing request.
• I checked whether this already exists on the dev branch or latest source.
• I understand that maintainers want a well-written issue or discussion before any code pull request.
• This request is not a security vulnerability.

Problem

ProblemThe current Open WebUI plugin model (Tools, Functions/Pipes/Filters/Actions/Events) is based on a single Python file. This design is excellent for simple plugins and one-click import, but it becomes a significant developer-experience problem as soon as a plugin grows beyond a basic script.Common issues observed in the community:Very large single files (hundreds or thousands of lines).
HTML, CSS and JavaScript for Rich UI embeds are stored as long string literals inside the Python file. This destroys syntax highlighting, makes code navigation painful, and turns reviews into a chore (especially on GitHub).
No official convention or support for a structured folder layout (e.g. separating the entry-point Python module, helper modules, static HTML/JS/CSS assets, and documentation).
Harder to maintain, version, collaborate on, and audit non-trivial plugins.

A typical example can be seen in community repositories where a single .py file mixes business logic with large embedded front-end assets.

Desired Behavior

Proposed solution : Keep full backward compatibility with the current single-file model (it remains ideal for simple plugins), while adding optional multi-file / structured plugin support.Suggested direction:Optional multi-file plugin formatAllow a plugin to be distributed as a folder (or zip/archive) with a clear convention, for example:

my-plugin/
├── main.py # Entry point (Tools / Pipe / Filter / Action / Event class)
├── lib/ # Optional helper Python modules
├── static/ or assets/ # HTML, JS, CSS for Rich UI
├── templates/ # Optional
└── README.md

The loader would resolve relative imports and serve static assets associated with the plugin.

Better handling of Rich UI assetsAllow referencing external HTML/JS/CSS files instead of embedding everything as Python strings.
Or provide a clean way to register and load front-end assets belonging to the plugin.

Editor & developer experience improvementsProper syntax highlighting and navigation even for larger plugins.
Support for viewing/editing multi-file plugins in the admin UI (tabs or file tree) when the structured format is used.

Documentation & community conventionsOfficial template for “simple” (single-file) vs “structured” plugins.
Clear guidelines on when to use each approach.
Recommendations that improve readability, maintainability and auditability (important because plugins run server-side).

Why This Matters

Benefits : Significantly better readability and maintainability for complex plugins.
Easier code review and collaboration.
Cleaner separation of Python logic and front-end assets.
Lower barrier for higher-quality community plugins.
Preserves the simplicity of the current single-file workflow for lightweight use cases.

Additional context : This would be an incremental, opt-in improvement rather than a breaking change. The single-file import path should remain fully supported.Happy to help refine the folder convention, migration path, or loader design if this direction is of interest to the maintainers and the community.Thank you for the excellent extensibility system — this proposal aims only to make it scale more gracefully for richer plugins.

Examples or References

No response

Alternatives or Workarounds

No response

No repository files or tests are named. Start by locating the current single-file plugin loader and the admin UI used to view or edit plugins, then review how embedded Rich UI assets are handled. Done requires an agreed structured folder or archive convention, preserved single-file compatibility, external asset support, and documented simple versus structured plugin usage.