This is extremely interesting. I've been looking for something considerably more ambitious than a conventional XenForo media gallery, and Prizma appears to be heading in a direction that could potentially fit a fairly large project I'm building.
Since this is brand new, I have a number of questions about the architecture and longer-term plans. Some of these may simply be things you haven't implemented yet, which is completely understandable.
1. External/object storage
Is there currently, or will there be, support for S3-compatible object storage such as Amazon S3 or Cloudflare R2?
I'm particularly interested in installations where the media library could eventually become very large. Ideally, uploaded media should not have to live permanently on the XenForo application's local filesystem.
If external storage is supported/planned, will the implementation remain reasonably provider-independent rather than tightly coupled to one storage company?
2. Data portability / export
This is very important to me.
If a site eventually contains hundreds of thousands or millions of media items, what is the exit/migration story?
Would it be possible to export or otherwise reliably migrate:
- media ownership
- albums/categories
- comments
- reactions
- titles/descriptions
- tags
- metadata
- permissions
- relationships between media and members/content
- original file/object locations
I don't expect a one-click migration tool for every competing product, but I would want to know that the underlying data is accessible and documented rather than effectively locked into the add-on.
3. API / developer integration
Is there an API, service layer, repository layer, event/listener system, or other supported way for another XenForo add-on to interact with Prizma?
For example, could another add-on safely:
- retrieve a member's media
- retrieve media belonging to a particular category/area
- create links between media and another site feature
- search/filter media
- react to media creation/deletion
- apply additional permission rules
- obtain media metadata
A documented API would be a major advantage.
4. Permissions
How granular are the permissions?
Can access be controlled by user group and category/album/section?
More importantly, can another add-on safely determine or influence access? I am eventually going to have private/semi-private member groups that may need their own permission-controlled areas inside one central gallery.
I would strongly prefer one gallery with permission-controlled branches rather than installing separate gallery systems.
5. Upload moderation / safety hooks
Is there a clean point in the upload process where another add-on can inspect or quarantine a file BEFORE it becomes publicly visible?
I am planning centralized upload-safety processing for images/video and would need to be able to perform things such as file validation, malware/safety checks, metadata processing, adult/gore detection, etc., before an upload is published.
I would not want to hack this into Prizma templates or modify Prizma source code.
6. Video processing
- For uploaded video, how is transcoding handled?
- Does Prizma use FFmpeg?
- Are multiple resolutions/codecs generated, and is that configurable?
- Can the original be discarded after successful processing if the administrator chooses?
- Can generated video files be moved directly to external object storage/CDN storage?
7. Images
- Does Prizma create optimized display versions of uploaded images?
- For example, resizing very large originals and generating WebP/AVIF or other optimized formats?
- Can administrators decide whether original full-resolution uploads are retained?
8. Live streaming
I'm very curious about this feature.
- What actually provides the streaming infrastructure?
- Is Prizma itself acting as the streaming system, or does it integrate with an external streaming server/service?
- What protocols/services are supported or planned?
- How do recording, retention, moderation and bandwidth work?
- Can live streaming be completely disabled while retaining the rest of Prizma?
9. Feature modularity
Can the major media types/features be independently disabled?
For example, could a site enable:
- images
- video
- panoramas
- Shorts
while completely disabling:
- e-books
- music
- live streaming
I would definitely prefer that these function as optional parts of the same platform rather than every installation having to expose every type of media.
10. Search and discovery
- How searchable is Prizma content?
- Are titles, descriptions, tags, member names, categories, etc. indexed?
- Is there any planned integration with XenForo Enhanced Search?
- Could another add-on eventually include Prizma media in a site-wide search/discovery interface while respecting Prizma permissions?
11. Tags and people mentions
What tagging system is available?
I'm particularly interested in a very simple modern member-facing tagging experience rather than something that feels like administrative metadata.
Can members tag/mention other members in media, and if so, does that generate the appropriate XenForo alerts?
12. Relationship with XenForo conversations
Can Prizma media be easily embedded/shared into normal XenForo threads and posts?
Conversely, is there any mechanism or planned mechanism for media uploaded into conversations to be associated with Prizma rather than creating completely separate media silos?
13. Moderation
Do XenForo moderators have centralized moderation tools for Prizma?
Things I'm thinking about include reports, approval queues, deletion/restoration, member restrictions, batch moderation, media ownership changes, and auditability.
14. Graceful disable/uninstall
- What happens if Prizma is disabled?
- Will the rest of XenForo continue operating normally?
- And if somebody eventually removes Prizma, is there a documented uninstall/export process that avoids leaving a large amount of unexplained data behind?
For a substantial site, this is nearly as important as installation.
15. Scale
Have you designed Prizma with very large galleries in mind?
Obviously nobody can promise a specific number without knowing the server and workload, but I'm interested in whether the architecture has been designed for installations that could eventually contain millions of media records and a very large amount of off-site media storage.
Things such as pagination, database indexing, thumbnail generation, background jobs/queues, CDN delivery and avoiding filesystem bottlenecks become pretty important at that point.
16. XenForo compatibility and long-term maintenance
Which XenForo 2.3 versions are you developing/testing against?
And since the add-on is brand new, what are your plans regarding:
- update frequency
- XenForo point-release compatibility
- future XenForo major-version support
- bug/security fixes
- backwards-compatible upgrades
I realize this is quite a list. I'm not asking because I expect all of it to already exist in the first release.
I'm asking because what you've built is interesting enough that I'm seriously considering whether Prizma could become the foundation of the media/gallery system for a much larger community project.
The front-end direction is considerably closer to what I've been looking for than a traditional forum gallery, so I'm particularly interested in understanding the architecture underneath it and where you intend to take it.
Very interesting project. I'll definitely be following the development.
Thank you for taking the time to write this out properly
this is exactly the kind of question list I would want to see before committing to an add-on for a large project, so I will answer all sixteen honestly, including the parts that do not exist yet.
Where something is missing I have said so plainly and given the release it is planned for.
1. External / object storage
This works today
Prizma does not write media to disk itself. Everything goes through
XenForo's own abstracted filesystem — uploads through the standard attachment system, covers and generated assets through the public data path. There is exactly one direct file write in the entire add-on and it is a local key file, not media.
The practical consequence is that if you point XenForo's filesystem at S3 or R2, Prizma's media follows automatically. It is provider-independent because it is XenForo's storage layer doing the work, not a storage integration of my own.
2. Data portability / export
Partly today, and I want to be straight about the gap.
What is already true: all Prizma data lives in ordinary MySQL tables and in XenForo's own attachment system. Nothing is serialised into a proprietary blob, nothing is encrypted, and files are stored under XenForo's normal storage handling. Ownership, categories, albums, comments, ratings, tags, metadata and permissions are all in readable relational tables.
What does not exist yet: an exporter. Today there is an importer that brings XenForo Media Gallery content into Prizma, but not the reverse.
This is planned for 1.4, and it is the item I take most seriously on your list — including an "export to XenForo Media Gallery" path so that leaving is a supported operation rather than a data-recovery project. A documented schema will go with it.
3. API / developer integration
Partly today.
Prizma is built on XenForo's own patterns — entities, repositories, finders and services — so another add-on can already query media through the normal framework, for example with a finder on the media entity, and go through the same permission checks the gallery uses.
What is missing is my own documented event layer. Planned for 1.2: published events for creation, deletion and publishing, plus developer documentation for the service and repository layer, so integration does not depend on reading my source.
4. Permissions
This works today and is one of the parts I am most confident about.
Permissions are XenForo's native content permission system, not a parallel model. On top of the usual user-group permissions there are per-category overrides for viewing, adding, editing own, editing any, deleting own and deleting any. Album privacy is a separate axis controlled by the member.
Another add-on can read access with a standard content permission check against the category content type, so your private and semi-private group areas can be branches inside one gallery rather than separate installations. That is exactly the model the add-on was designed around.
5. Upload moderation / safety hooks
Not today.
Planned for 1.2: an event fired before an upload becomes visible, so another add-on can inspect, reject or quarantine the file. Your requirement of not editing templates or add-on source is the right requirement, and it is how it will be built.
6. Video processing
No transcoding today. Uploaded video is served as-is, with byte-range support so seeking works without downloading the whole file. There is no FFmpeg dependency at the moment.
Planned for 1.3: FFmpeg-based transcoding, multiple renditions, an option to discard the original after successful processing, and writing the output through the same storage layer so object storage is included.
7. Images
Partly today. XenForo's thumbnailing is used, and there is an optional maximum-dimension setting that downscales very large originals at upload time. There is no WebP or AVIF derivative generation yet.
Planned for 1.3: optimised display derivatives and an administrator setting for whether full-resolution originals are retained.
8. Live streaming — an important clarification
Prizma is not a streaming server, and I would rather say that clearly than let it be assumed.
What it does: embeds Twitch, Kick and YouTube streams, and plays direct HLS (.m3u8) sources in the bundled player. The LIVE badge is refreshed in the background by cron — from the provider APIs for Twitch and YouTube, or by reading the HLS manifest for direct sources. It never makes an external request while a page is being rendered.
Recording, retention and bandwidth therefore belong to whatever streaming service or origin you use. Prizma is the presentation and permission layer, not the infrastructure.
And yes, it can be disabled — see the next answer.
9. Feature modularity
Partly today: you already control which gallery layouts are available and which types appear in the sidebar.
Full per-type enable and disable is in the next update (1.1.5), so a site can run images, video, panoramas and Shorts with e-books, music and live streaming switched off entirely. I agree with the principle — every installation should not have to expose every media type.
10. Search and discovery
This works today. Media and comments are indexed through XenForo's own search system, covering titles, descriptions and tags, and results respect Prizma's permissions. Because it uses XenForo's search abstraction rather than a private index, Enhanced Search works too, and another add-on can include Prizma results through the normal search API.
One honest note: there is currently a bug where the type-specific search tab is missing its form template. It is the first item in 1.1.5.
11. Tags and people mentions
Tags today are XenForo's native tags — the same interface members already know, not a separate administrative metadata system.
Tagging other members in media does not exist yet. Planned for 1.2, including the appropriate alerts.
12. Relationship with threads and posts
Not today, and I consider this a real gap.
Planned for 1.1.5: BB code for embedding a media item into posts and threads. Deeper editor integration depends on where XenForo 2.4 lands, so I would rather ship the useful half now than wait.
Media uploaded inside conversations being adopted into Prizma is a larger design question; I have noted it but have not committed it to a release yet.
13. Moderation
Partly today. Media carries a state field and everything is permission-controlled, but there is no report handler and no approval queue.
Planned for 1.2: reports, approval queue, batch moderation, ownership changes and deletion or restoration through the tools moderators already use.
14. Graceful disable / uninstall
Today: uninstall routines exist and remove Prizma's own tables and columns; disabling the add-on leaves the rest of XenForo working normally.
What is missing is the documentation — exactly what is removed, what remains, and what to export first. That documentation is in 1.1.5, and the export path that should precede it is the 1.4 item in answer 2.
15. Scale
Designed for it, not yet proven at millions, and I will not claim otherwise.
What is in place: indexes on the access paths that actually get used, including composite indexes for category-plus-date and state-plus-date listings; pagination throughout; and background job queues for the expensive work such as cover fetching, duration extraction and metadata processing, so uploads do not block on it.
Planned for 1.4: a scale-hardening pass with published measurements rather than assurances.
16. XenForo compatibility and maintenance
XenForo 2.3.0 and newer, developed and tested against 2.3.12. PHP 8.0+.
Commitments: point-release compatibility, security and bug fixes, and backwards-compatible upgrades within the 2.x line. Support for a future major XenForo version is intended but I will not put a date on something that has not been released.
In short
Working today: object storage, granular per-category permissions, native search including Enhanced Search, native tags, and the indexing and job structure underneath.
Next update (1.1.5): per-type enable and disable, BB code embedding, the search form fix, uninstall documentation.
1.2: moderation tools, pre-publish hooks and a documented API, member tagging.
1.3: video transcoding, image derivatives.
1.4: export and portability, scale hardening.
Thank you again for the depth of the questions. If any of these matter enough to change your order, tell me which — the roadmap above is a plan, not a contract, and the items real projects need get pulled forward.
