Jump to content
View in the app

A better way to browse. Learn more.

Invision Marketplace

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Everything you need for your community

Everything you need for your community

 Loading...
 Loading...
 Loading...
Version 1.3.0 Release Notes
Package Manager for Invision Community
Description
Package Manager is a powerful administrative tool for Invision Community that simplifies the process of managing, backing up, and transferring applications between different ICS instances. Designed with administrators and developers in mind, this application provides a comprehensive set of features for application management while maintaining security by preventing modifications to official IPS applications.
Key Features
Application Management
View All Installed Applications: See a complete list of all applications installed on your community with detailed information including version, author, and installation date.
Download Applications: Package and download third-party applications as TAR archives that can be installed on other Invision Community instances.
Security Protection: Built-in safeguards prevent downloading, backing up, or restoring official IPS applications to protect your license and community integrity.
Comprehensive Backup System
Application Backups: Create complete backups of application files, preserving the entire folder structure and all application assets.
Database Backups: Backup application-specific database tables to preserve user data and settings.
Language Backups: Extract and backup language strings for applications, making it easy to transfer translations between instances.
Pre-Restore Safeguards: Automatic creation of pre-restore backups ensures you can always recover if something goes wrong during a restore operation.
Backup Management
Organized Interface: View all backups for each application with details including version, creation date, file size, and backup type.
Multiple Backup Types: Distinguish between application, database, and language backups with color-coded indicators.
Bulk Operations: Delete all backups for an application with a single click when you need to free up space.
Restore Capabilities
Application Restoration: Restore application files from backups with proper validation and error handling.
Database Restoration: Restore application database tables from SQL backups with pre-restore safety measures.
Language Restoration: Restore language backups used for translating languages and share them with other communities.
Uninstall Guidance: Clear instructions for when applications need to be uninstalled before restoration.
Import/Export System
Upload Backups: Upload previously downloaded backups through a simple interface.
Validation: Thorough validation of uploaded files ensures only legitimate backups can be processed.
Format Preservation: Downloaded files maintain the exact format needed for re-uploading, ensuring seamless transfers between instances.
Developer-Friendly Features
Version Tracking: All backups include version information for easy identification.
Timestamp Naming: Automatic timestamping of backup files helps track when backups were created.
Organized Storage: All backups are stored in a dedicated directory for easy access and management.
Technical Details
Storage Location: All backups are stored in the
applications/applications_backups
directory.
File Formats: Application backups (.tar), Database backups (.sql), Language backups (.json).
Security: Built-in protection prevents unauthorized access to official IPS application files.
Error Handling: Comprehensive error handling with clear messages helps troubleshoot any issues.
Use Cases
Application Migration: Easily transfer third-party applications between development, staging, and production environments.
Version Control: Create backups before updating applications to ensure you can roll back if needed.
Disaster Recovery: Maintain regular backups of critical applications to protect against data loss.
Development Support: Simplify the development workflow by making it easy to package and distribute applications.
Important Notes
When downloading or backing up an application, please DO NOT click the button more than once. The process compiles the selected application's folder structure and files into a TAR archive, which can take time for larger applications.
This application WILL NOT allow downloading, backing up, or restoring official IPS applications due to licensing and security restrictions.
Database restoration will overwrite existing data for the application. Always ensure you have a current backup before restoring.
For security reasons, this application should only be accessible to trusted administrators.
Package Manager is the essential tool for Invision Community administrators who need reliable application management, backup, and restoration capabilities in a user-friendly interface.
IPS5.0.0+
Version 1.3.0 Release Notes
Package Manager for Invision Community
Description
Package Manager is a powerful administrative tool for Invision Community that simplifies the process of managing, backing up, and transferring applications between different ICS instances. Designed with administrators and developers in mind, this application provides a comprehensive set of features for application management while maintaining security by preventing modifications to official IPS applications.
Key Features
Application Management
View All Installed Applications: See a complete list of all applications installed on your community with detailed information including version, author, and installation date.
Download Applications: Package and download third-party applications as TAR archives that can be installed on other Invision Community instances.
Security Protection: Built-in safeguards prevent downloading, backing up, or restoring official IPS applications to protect your license and community integrity.
Comprehensive Backup System
Application Backups: Create complete backups of application files, preserving the entire folder structure and all application assets.
Database Backups: Backup application-specific database tables to preserve user data and settings.
Language Backups: Extract and backup language strings for applications, making it easy to transfer translations between instances.
Pre-Restore Safeguards: Automatic creation of pre-restore backups ensures you can always recover if something goes wrong during a restore operation.
Backup Management
Organized Interface: View all backups for each application with details including version, creation date, file size, and backup type.
Multiple Backup Types: Distinguish between application, database, and language backups with color-coded indicators.
Bulk Operations: Delete all backups for an application with a single click when you need to free up space.
Restore Capabilities
Application Restoration: Restore application files from backups with proper validation and error handling.
Database Restoration: Restore application database tables from SQL backups with pre-restore safety measures.
Language Restoration: Restore language backups used for translating languages and share them with other communities.
Uninstall Guidance: Clear instructions for when applications need to be uninstalled before restoration.
Import/Export System
Upload Backups: Upload previously downloaded backups through a simple interface.
Validation: Thorough validation of uploaded files ensures only legitimate backups can be processed.
Format Preservation: Downloaded files maintain the exact format needed for re-uploading, ensuring seamless transfers between instances.
Developer-Friendly Features
Version Tracking: All backups include version information for easy identification.
Timestamp Naming: Automatic timestamping of backup files helps track when backups were created.
Organized Storage: All backups are stored in a dedicated directory for easy access and management.
Technical Details
Storage Location: All backups are stored in the
applications/applications_backups
directory.
File Formats: Application backups (.tar), Database backups (.sql), Language backups (.json).
Security: Built-in protection prevents unauthorized access to official IPS application files.
Error Handling: Comprehensive error handling with clear messages helps troubleshoot any issues.
Use Cases
Application Migration: Easily transfer third-party applications between development, staging, and production environments.
Version Control: Create backups before updating applications to ensure you can roll back if needed.
Disaster Recovery: Maintain regular backups of critical applications to protect against data loss.
Development Support: Simplify the development workflow by making it easy to package and distribute applications.
Important Notes
When downloading or backing up an application, please DO NOT click the button more than once. The process compiles the selected application's folder structure and files into a TAR archive, which can take time for larger applications.
This application WILL NOT allow downloading, backing up, or restoring official IPS applications due to licensing and security restrictions.
Database restoration will overwrite existing data for the application. Always ensure you have a current backup before restoring.
For security reasons, this application should only be accessible to trusted administrators.
Package Manager is the essential tool for Invision Community administrators who need reliable application management, backup, and restoration capabilities in a user-friendly interface.
Cloudflare brings day-to-day Cloudflare zone management directly into the Invision Community 5 AdminCP. Instead of bouncing between your site and the Cloudflare dashboard, this app gives administrators a focused control panel for verification, DNS, cache behavior, SSL/TLS, firewall tooling, Zero Trust access, analytics, and related security features from one place.
The app is built for administrators who want practical Cloudflare controls inside IPS, with live zone reads, structured forms, Cloudflare-aware validation, documentation links, permission guidance, and visual summaries that help you understand what is configured before you change it.
What this app can manage
Connection and verification tools
Verify the saved API token, zone, account context, and managed hostname from inside the AdminCP so you can quickly confirm whether the app is talking to the correct Cloudflare resources.
DNS management
View, create, edit, and remove Cloudflare DNS records, review zone-level DNS settings, and handle common record types used by IPS communities and related services.
Cache controls
Manage zone cache settings, purge cache directly from the AdminCP, work with Cache Rules, and optionally trigger targeted Cloudflare content purges from IPS-side content events.
SSL/TLS controls
Manage core SSL/TLS and edge certificate behavior for the zone, including common encryption and visitor-facing TLS settings surfaced by Cloudflare.
Firewall and request protection
Work with IP Access Rules, Managed WAF rulesets, Custom Rules, Rate Limiting Rules, Zone Lockdown, IP Lists, Security.txt, and related security tooling using structured ACP workflows.
Zero Trust / Access Protection
Build and manage Cloudflare Access applications, policies, groups, and organization-level settings for protecting sensitive IPS areas such as the AdminCP.
API Shield and DDoS areas
Surface Cloudflare API Shield and DDoS-related management areas that can be controlled through the available API scopes and the plan features on your zone.
Analytics dashboards
Show Cloudflare traffic, cache, and security analytics directly inside the AdminCP using Cloudflare GraphQL-backed chart extensions and overview blocks where supported by your token, dataset, and plan.
Designed for real IPS administration
ACP-first layout that keeps related Cloudflare controls together.
Tab-based navigation across Cloudflare management areas.
Inline Cloudflare documentation links and permission notes to reduce token setup confusion.
Form helpers and presets for common IPS paths such as /admin, login routes, API endpoints, and cache-rule use cases.
Dialog-based creation and editing flows for major management actions.
Visual summaries and statistics blocks to make current zone state easier to review at a glance.
Important notes
This app manages your existing Cloudflare account and zones. A separate Cloudflare account is required.
Available controls depend on your Cloudflare plan, token permissions, and whether Cloudflare exposes the related settings or datasets for the selected zone.
Some Cloudflare features are read-only, unavailable, or product-specific depending on your plan or account entitlements. The app is designed to reflect those limits rather than masking them.
Analytics visibility can vary by GraphQL dataset availability, token scope, and plan support.
Ideal for
Community owners, IPS administrators, and developers who want a serious Cloudflare control surface inside Invision Community 5 without giving up Cloudflare-native concepts, terminology, or live API-backed management.
Developed by InvisionMarketplace.com - Professional Invision Community Applications
IPS5.0.0+
Cloudflare brings day-to-day Cloudflare zone management directly into the Invision Community 5 AdminCP. Instead of bouncing between your site and the Cloudflare dashboard, this app gives administrators a focused control panel for verification, DNS, cache behavior, SSL/TLS, firewall tooling, Zero Trust access, analytics, and related security features from one place.
The app is built for administrators who want practical Cloudflare controls inside IPS, with live zone reads, structured forms, Cloudflare-aware validation, documentation links, permission guidance, and visual summaries that help you understand what is configured before you change it.
What this app can manage
Connection and verification tools
Verify the saved API token, zone, account context, and managed hostname from inside the AdminCP so you can quickly confirm whether the app is talking to the correct Cloudflare resources.
DNS management
View, create, edit, and remove Cloudflare DNS records, review zone-level DNS settings, and handle common record types used by IPS communities and related services.
Cache controls
Manage zone cache settings, purge cache directly from the AdminCP, work with Cache Rules, and optionally trigger targeted Cloudflare content purges from IPS-side content events.
SSL/TLS controls
Manage core SSL/TLS and edge certificate behavior for the zone, including common encryption and visitor-facing TLS settings surfaced by Cloudflare.
Firewall and request protection
Work with IP Access Rules, Managed WAF rulesets, Custom Rules, Rate Limiting Rules, Zone Lockdown, IP Lists, Security.txt, and related security tooling using structured ACP workflows.
Zero Trust / Access Protection
Build and manage Cloudflare Access applications, policies, groups, and organization-level settings for protecting sensitive IPS areas such as the AdminCP.
API Shield and DDoS areas
Surface Cloudflare API Shield and DDoS-related management areas that can be controlled through the available API scopes and the plan features on your zone.
Analytics dashboards
Show Cloudflare traffic, cache, and security analytics directly inside the AdminCP using Cloudflare GraphQL-backed chart extensions and overview blocks where supported by your token, dataset, and plan.
Designed for real IPS administration
ACP-first layout that keeps related Cloudflare controls together.
Tab-based navigation across Cloudflare management areas.
Inline Cloudflare documentation links and permission notes to reduce token setup confusion.
Form helpers and presets for common IPS paths such as /admin, login routes, API endpoints, and cache-rule use cases.
Dialog-based creation and editing flows for major management actions.
Visual summaries and statistics blocks to make current zone state easier to review at a glance.
Important notes
This app manages your existing Cloudflare account and zones. A separate Cloudflare account is required.
Available controls depend on your Cloudflare plan, token permissions, and whether Cloudflare exposes the related settings or datasets for the selected zone.
Some Cloudflare features are read-only, unavailable, or product-specific depending on your plan or account entitlements. The app is designed to reflect those limits rather than masking them.
Analytics visibility can vary by GraphQL dataset availability, token scope, and plan support.
Ideal for
Community owners, IPS administrators, and developers who want a serious Cloudflare control surface inside Invision Community 5 without giving up Cloudflare-native concepts, terminology, or live API-backed management.
Developed by InvisionMarketplace.com - Professional Invision Community Applications
Member Map see where your community actually is
Most communities have no idea where their members are. You can guess from the timezone spread in your statistics, but you cannot see it, and neither can anyone else. A map turns a list of usernames into a group of people in places, and it is one of the few features that members genuinely enjoy adding themselves to.
Nobody appears without choosing to
There is no import, no bulk geocoding of profile fields, and no automatic placement of anyone. A member types a town on the map page and presses a button. That is the only way a pin ever appears. They can take themselves off again at any time, and doing so deletes the row rather than hiding it.
Nothing is ever read from a member's browser. No location prompt, no IP lookup, no GPS. Somebody types "Berlin" because they want you to know they are in Berlin.
It stores a town, never an address
This is the part that matters, and it is a design decision rather than a setting you have to get right. Coordinates are rounded before they are written, and the precise ones are never stored at all. At the default precision a pin describes roughly a kilometre enough to show someone is in Lisbon, not enough to show which street. A database that never held the exact point cannot leak it, and a member who removes themselves leaves nothing behind.
You can make it vaguer still. One decimal place is roughly ten kilometres, which suits a community that would rather show countries than cities.
No mapping account, no card on file
The map uses OpenStreetMap, and place names are looked up with OpenStreetMap's own geocoder. Neither needs an account, an API key, or a billing relationship, so this app costs nothing to run and there is no quota to blow through on a busy day.
Every lookup is cached, so a hundred members in Berlin cost one lookup between them. If you would rather use your own tile server or a commercial provider, both the tile URL and the geocoder URL are settings.
Guests do not see it by default
Your members agreed to be visible to a community, which is not the same as being visible to the internet. Guest access is off until you turn it on.
What you get
A map page listing everyone who has opted in, each pin linking to their profile
A single field for members to add or change where they are
Adjustable precision, so you decide how vague a pin is
Your choice of tile server and geocoder
A count of who is on the map, and a one-click purge in the AdminCP
Two honest limits. OpenStreetMap's tiles and geocoder are run by a volunteer project and their usage policy expects modest traffic — fine for a forum map, and the settings let a large community point at its own tile server instead. And the map draws in the browser using Leaflet, so a member browsing with JavaScript disabled sees the page but not the map.
IPS5.0.0+
Member Map see where your community actually is
Most communities have no idea where their members are. You can guess from the timezone spread in your statistics, but you cannot see it, and neither can anyone else. A map turns a list of usernames into a group of people in places, and it is one of the few features that members genuinely enjoy adding themselves to.
Nobody appears without choosing to
There is no import, no bulk geocoding of profile fields, and no automatic placement of anyone. A member types a town on the map page and presses a button. That is the only way a pin ever appears. They can take themselves off again at any time, and doing so deletes the row rather than hiding it.
Nothing is ever read from a member's browser. No location prompt, no IP lookup, no GPS. Somebody types "Berlin" because they want you to know they are in Berlin.
It stores a town, never an address
This is the part that matters, and it is a design decision rather than a setting you have to get right. Coordinates are rounded before they are written, and the precise ones are never stored at all. At the default precision a pin describes roughly a kilometre enough to show someone is in Lisbon, not enough to show which street. A database that never held the exact point cannot leak it, and a member who removes themselves leaves nothing behind.
You can make it vaguer still. One decimal place is roughly ten kilometres, which suits a community that would rather show countries than cities.
No mapping account, no card on file
The map uses OpenStreetMap, and place names are looked up with OpenStreetMap's own geocoder. Neither needs an account, an API key, or a billing relationship, so this app costs nothing to run and there is no quota to blow through on a busy day.
Every lookup is cached, so a hundred members in Berlin cost one lookup between them. If you would rather use your own tile server or a commercial provider, both the tile URL and the geocoder URL are settings.
Guests do not see it by default
Your members agreed to be visible to a community, which is not the same as being visible to the internet. Guest access is off until you turn it on.
What you get
A map page listing everyone who has opted in, each pin linking to their profile
A single field for members to add or change where they are
Adjustable precision, so you decide how vague a pin is
Your choice of tile server and geocoder
A count of who is on the map, and a one-click purge in the AdminCP
Two honest limits. OpenStreetMap's tiles and geocoder are run by a volunteer project and their usage policy expects modest traffic — fine for a forum map, and the settings let a large community point at its own tile server instead. And the map draws in the browser using Leaflet, so a member browsing with JavaScript disabled sees the page but not the map.
A two-way bridge between a forum and a Telegram group. Posts go out; replies come back and become real forum posts, written by the member who wrote them.
Why two-way
Sending forum posts to a Telegram channel is something you can already do with any webhook tool, including one you may already own. The half nobody offers is the return path: a message typed in the Telegram group becoming a post in the forum, attributed to the member who typed it, so the conversation is in one place instead of two.
How members are identified
A member links their own account from their forum settings. They are shown a one-time code, and they send that code to the bot in a direct message never in the group, because a code pasted into a group is a code everybody in it can use.
Until somebody links, their messages are ignored rather than guessed at. If you would rather nothing was lost, you can nominate an account for unlinked messages instead — but the strict setting always wins, so turning it on cannot be undone by a stray configuration elsewhere.
What it will not do
It will not post its own messages back to the forum, or forum posts that arrived from Telegram back to Telegram. The loop is closed in both directions.
It will not accept a call to its endpoint that cannot prove it came from Telegram, and it fails closed rather than open if the secret is missing.
It will not post the same message twice when Telegram retries a delivery.
Requirements
Invision Community 5
A Telegram bot token from @BotFather — free
Your community reachable over HTTPS, so Telegram can deliver to it
IPS5.0.0+
A two-way bridge between a forum and a Telegram group. Posts go out; replies come back and become real forum posts, written by the member who wrote them.
Why two-way
Sending forum posts to a Telegram channel is something you can already do with any webhook tool, including one you may already own. The half nobody offers is the return path: a message typed in the Telegram group becoming a post in the forum, attributed to the member who typed it, so the conversation is in one place instead of two.
How members are identified
A member links their own account from their forum settings. They are shown a one-time code, and they send that code to the bot in a direct message never in the group, because a code pasted into a group is a code everybody in it can use.
Until somebody links, their messages are ignored rather than guessed at. If you would rather nothing was lost, you can nominate an account for unlinked messages instead — but the strict setting always wins, so turning it on cannot be undone by a stray configuration elsewhere.
What it will not do
It will not post its own messages back to the forum, or forum posts that arrived from Telegram back to Telegram. The loop is closed in both directions.
It will not accept a call to its endpoint that cannot prove it came from Telegram, and it fails closed rather than open if the secret is missing.
It will not post the same message twice when Telegram retries a delivery.
Requirements
Invision Community 5
A Telegram bot token from @BotFather — free
Your community reachable over HTTPS, so Telegram can deliver to it
Developing IPS5 applications often requires navigating dozens of files to understand how classes, extensions, listeners, templates, language bits, settings, CSS, and database tables are connected. Framework Explorer is a developer productivity tool that provides a unified view of an IPS5 application directly from the AdminCP, making it easier to explore, navigate, and maintain your codebase.
Instead of manually searching through your application's files, you can quickly inspect its architecture, browse framework components, review inheritance, discover available methods, explore templates and stylesheets, inspect language bits and settings, and examine the application's database structure and data—all from a single interface.
Framework Explorer is designed for developers who are already familiar with the IPS framework and want to work more efficiently. Its goal is to simplify navigation and inspection of existing applications, not to teach IPS development or replace the official developer documentation.
- Ideal for:
IPS application developers
Marketplace authors
Maintaining existing applications
Exploring third-party applications
Understanding unfamiliar codebases
Developers already familiar with the IPS5 framework
- Features:
Class Explorer
Browse every PHP class in an application.
View inheritance, implemented interfaces, and used traits.
Inspect properties, constants, and methods.
Display namespaces, file locations, and PHPDoc information.
Optionally open files directly in your IDE.
Settings Explorer
Browse application settings.
View configuration keys, default values, and metadata.
Quickly identify available ACP settings.
Extension Explorer
Browse every IPS extension.
View extension types and implementations.
Inspect inheritance and available methods.
Quickly navigate extension classes.
Listener Explorer
Browse every event listener.
View listener types.
Inspect supported methods.
Identify the framework class associated with each listener.
Language Explorer
Browse every language bit.
Search by language key or translated value.
Quickly locate application translations.
Template Explorer
Browse all application templates.
View template groups and individual templates.
Display template source code.
Explore template relationships.
CSS Explorer
Browse all application CSS files.
View selectors, CSS variables, media queries, and imports.
Display the source code.
Search by filename, selector, or CSS content.
Filter results by application.
Optionally open files directly in your IDE.
Database Explorer
Browse application database tables.
View table structure, indexes, and records.
Filter tables by application.
Inspect column definitions and index information.
Browse table data with pagination.
Read-only database inspection for safe exploration.
IPS5.0.0+
Developing IPS5 applications often requires navigating dozens of files to understand how classes, extensions, listeners, templates, language bits, settings, CSS, and database tables are connected. Framework Explorer is a developer productivity tool that provides a unified view of an IPS5 application directly from the AdminCP, making it easier to explore, navigate, and maintain your codebase.
Instead of manually searching through your application's files, you can quickly inspect its architecture, browse framework components, review inheritance, discover available methods, explore templates and stylesheets, inspect language bits and settings, and examine the application's database structure and data—all from a single interface.
Framework Explorer is designed for developers who are already familiar with the IPS framework and want to work more efficiently. Its goal is to simplify navigation and inspection of existing applications, not to teach IPS development or replace the official developer documentation.
- Ideal for:
IPS application developers
Marketplace authors
Maintaining existing applications
Exploring third-party applications
Understanding unfamiliar codebases
Developers already familiar with the IPS5 framework
- Features:
Class Explorer
Browse every PHP class in an application.
View inheritance, implemented interfaces, and used traits.
Inspect properties, constants, and methods.
Display namespaces, file locations, and PHPDoc information.
Optionally open files directly in your IDE.
Settings Explorer
Browse application settings.
View configuration keys, default values, and metadata.
Quickly identify available ACP settings.
Extension Explorer
Browse every IPS extension.
View extension types and implementations.
Inspect inheritance and available methods.
Quickly navigate extension classes.
Listener Explorer
Browse every event listener.
View listener types.
Inspect supported methods.
Identify the framework class associated with each listener.
Language Explorer
Browse every language bit.
Search by language key or translated value.
Quickly locate application translations.
Template Explorer
Browse all application templates.
View template groups and individual templates.
Display template source code.
Explore template relationships.
CSS Explorer
Browse all application CSS files.
View selectors, CSS variables, media queries, and imports.
Display the source code.
Search by filename, selector, or CSS content.
Filter results by application.
Optionally open files directly in your IDE.
Database Explorer
Browse application database tables.
View table structure, indexes, and records.
Filter tables by application.
Inspect column definitions and index information.
Browse table data with pagination.
Read-only database inspection for safe exploration.
Invision Community already lets a member pick their language. What it cannot do is give you one to pick. A finished language pack is 22,363 strings, which is a translator's contract rather than a download so most communities run in English, and everyone who does not read English comfortably reads a little less, posts a little less, and eventually stops.
This translates both halves of that problem: the software itself, and what your members write in it.
The interface
Add a language in the AdminCP, press start, and the application works through all 22,363 strings with a language model. There is no pack to buy, no translator to commission and nothing to import. When it finishes, your members pick that language from the footer and the entire site is in it menus, buttons, error messages, notification text, everything.
You can stop and restart it at any point, and a half-finished language is a working site. Invision falls back to English for anything not yet translated, so there is never a broken state — just a site that is progressively more translated as the job runs.
It runs in the background through your existing task system. Nothing is translated twice, and adding a second or third language costs the same again not a multiple of a translator's fee.
Right-to-left languages
Arabic, Hebrew, Persian and Urdu are marked right-to-left and Invision mirrors its own layout for them. This sets that flag as part of creating the language, so an RTL community reads correctly rather than as left-to-right text in a left-to-right shell.
The posts
A translated interface does not help with a thread written in a language a member cannot read. Every post gets a translate control: one click and it is replaced, in place, in their own language, with a link back to the original.
Translations are stored the first time somebody asks, so the hundredth reader of that thread costs nothing. Editing a post invalidates its translation automatically, so nobody reads a translation of text that has changed.
It never damages what it translates
This is the part worth reading carefully, and it applies to both halves.

Interface strings are not prose. They carry substitution points like {1} and %s, HTML, and Invision's own plural syntax. A language model asked to translate them will occasionally return something that reads beautifully and is broken — a dropped placeholder throws an error on the page, and a flattened plural prints raw markup to your members.

So every translated string is checked before it is stored, and anything that fails the check stays in English. A missing translation is a missing translation; a broken placeholder is a support ticket. Plural forms are handled properly too — if the target language needs three or four forms where English has two, that is accepted rather than rejected.

Posts get the same treatment from the other direction: the model is never shown your markup at all. The post is taken apart, only the readable text is sent, and the translation is put back in the same places — so mentions keep linking to people, quotes keep their attribution and their link back, and code samples are never "corrected".
What it costs to run
You supply an API key for OpenAI or Anthropic, and you are billed by them for what you use. Translating a full interface is a few dollars of usage, once, per language. Posts are billed per post the first time each one is requested, with a length ceiling you control so a single enormous post cannot become a single enormous charge.
If you already run AI Assistant, this borrows its key and model so you keep one key and one bill.
What you need
Invision Community 5.0+, self-hosted
An API key for OpenAI or Anthropic — or AI Assistant already installed
A second language added in the AdminCP. This creates it; it does not need to contain anything.
Being straight about the limits. Machine translation is very good now and it is still not a human translator. For reading a forum comfortably in your own language it is more than enough. For anything legal, contractual or safety-critical, commission a person. And a translated interface is only as good as the model you point it at a small fast model is fine for most languages and noticeably weaker for a few.
IPS5.0.0+
Invision Community already lets a member pick their language. What it cannot do is give you one to pick. A finished language pack is 22,363 strings, which is a translator's contract rather than a download so most communities run in English, and everyone who does not read English comfortably reads a little less, posts a little less, and eventually stops.
This translates both halves of that problem: the software itself, and what your members write in it.
The interface
Add a language in the AdminCP, press start, and the application works through all 22,363 strings with a language model. There is no pack to buy, no translator to commission and nothing to import. When it finishes, your members pick that language from the footer and the entire site is in it menus, buttons, error messages, notification text, everything.
You can stop and restart it at any point, and a half-finished language is a working site. Invision falls back to English for anything not yet translated, so there is never a broken state — just a site that is progressively more translated as the job runs.
It runs in the background through your existing task system. Nothing is translated twice, and adding a second or third language costs the same again not a multiple of a translator's fee.
Right-to-left languages
Arabic, Hebrew, Persian and Urdu are marked right-to-left and Invision mirrors its own layout for them. This sets that flag as part of creating the language, so an RTL community reads correctly rather than as left-to-right text in a left-to-right shell.
The posts
A translated interface does not help with a thread written in a language a member cannot read. Every post gets a translate control: one click and it is replaced, in place, in their own language, with a link back to the original.
Translations are stored the first time somebody asks, so the hundredth reader of that thread costs nothing. Editing a post invalidates its translation automatically, so nobody reads a translation of text that has changed.
It never damages what it translates
This is the part worth reading carefully, and it applies to both halves.

Interface strings are not prose. They carry substitution points like {1} and %s, HTML, and Invision's own plural syntax. A language model asked to translate them will occasionally return something that reads beautifully and is broken — a dropped placeholder throws an error on the page, and a flattened plural prints raw markup to your members.

So every translated string is checked before it is stored, and anything that fails the check stays in English. A missing translation is a missing translation; a broken placeholder is a support ticket. Plural forms are handled properly too — if the target language needs three or four forms where English has two, that is accepted rather than rejected.

Posts get the same treatment from the other direction: the model is never shown your markup at all. The post is taken apart, only the readable text is sent, and the translation is put back in the same places — so mentions keep linking to people, quotes keep their attribution and their link back, and code samples are never "corrected".
What it costs to run
You supply an API key for OpenAI or Anthropic, and you are billed by them for what you use. Translating a full interface is a few dollars of usage, once, per language. Posts are billed per post the first time each one is requested, with a length ceiling you control so a single enormous post cannot become a single enormous charge.
If you already run AI Assistant, this borrows its key and model so you keep one key and one bill.
What you need
Invision Community 5.0+, self-hosted
An API key for OpenAI or Anthropic — or AI Assistant already installed
A second language added in the AdminCP. This creates it; it does not need to contain anything.
Being straight about the limits. Machine translation is very good now and it is still not a human translator. For reading a forum comfortably in your own language it is more than enough. For anything legal, contractual or safety-critical, commission a person. And a translated interface is only as good as the model you point it at a small fast model is fine for most languages and noticeably weaker for a few.
Federation
Somebody on Mastodon searches for @support@yoursite.com, presses follow, and from then on every new topic in that forum arrives in their timeline. They reply from where they already are. Nobody signs up for anything.
Federation makes your forums followable from the fediverse over ActivityPub — from your own domain, with no bridge and no third-party service in the middle.
How it works
Each forum is an address
Choose which forums federate and each becomes a followable account — @support@yoursite.com. Your community also has one of its own.
Topics go out
A new topic is delivered to everyone following that forum. Replies follow as replies, so the thread reads as a thread rather than a pile of unrelated posts.
People come back
Follows, likes and boosts arrive from anywhere that speaks ActivityPub — Mastodon, Lemmy, Misskey, Pixelfed and the rest.
Your domain, your posts
Nothing is relayed through anybody else's server. The addresses are yours and the content is served from your site.
No server configuration. Most ActivityPub implementations hand you an nginx rewrite rule and wish you luck. This one is an application: install the tar, pick your forums, done. It serves its own WebFinger, NodeInfo and actor documents through Invision Community's own routing.
Built to be safe with a stranger's instructions
An inbox is the only endpoint on a forum that acts on requests from people you have never heard of, so the checking matters more than the feature list.
Every incoming request is verified with HTTP Signatures — and not only that the signature passes, but what it covers. A signature that omits the request target can otherwise be replayed against a different endpoint, turning a harmless activity into a destructive one.
The body digest is checked against the body. A valid signature over a swapped payload is refused.
Replays are rejected, so a repeated delivery cannot become a duplicate post.
A delete for one of your posts from a remote server is refused outright. Only the original author's server may withdraw their own content.
Stale requests are refused, with enough tolerance for a server whose clock has drifted.
Delivery that tells you the truth
Queued, not inline
Nobody waits on a remote server to finish posting. Delivery runs in the background.
Retries that widen
A server being restarted is retried gently; a server that has gone for good is given up on within about a day and marked, rather than retried forever.
One copy per server
Where a remote offers a shared inbox it gets a single delivery for all its followers, instead of one request each.
Failures kept
The queue shows what went where, how many attempts, and the last error — so "why did that server stop receiving posts" has an answer.
Publishing is one-way and permanent. Anything federated leaves your server and is stored on other people's. It cannot be recalled — a delete is a request that well-behaved servers honour, not a guarantee. Choose the forums deliberately, and do not federate anything you would not put on a public timeline. Federation ships switched off with no forums selected, and stays that way until you choose.
Check it actually works
The AdminCP fetches your own discovery endpoints from the outside and tells you what came back. If a firewall, a CDN rule or an nginx block on dot-directories is swallowing them, you are invisible to the fediverse and there is no other symptom — you simply never appear in anyone's search. This turns that into a line of text you can read.
Requirements
Invision Community 5.0 or newer (self-hosted)
A public hostname over HTTPS, and PHP with OpenSSL
The task scheduler running, since delivery is queued
No account with me, no external service, no per-post fee
Set your community's URL before you federate. Every address this creates is built from it, and other servers remember them. Changing the board URL afterwards orphans every actor, follower and published post on every server that has seen them.
IPS5.0.0+
Federation
Somebody on Mastodon searches for @support@yoursite.com, presses follow, and from then on every new topic in that forum arrives in their timeline. They reply from where they already are. Nobody signs up for anything.
Federation makes your forums followable from the fediverse over ActivityPub — from your own domain, with no bridge and no third-party service in the middle.
How it works
Each forum is an address
Choose which forums federate and each becomes a followable account — @support@yoursite.com. Your community also has one of its own.
Topics go out
A new topic is delivered to everyone following that forum. Replies follow as replies, so the thread reads as a thread rather than a pile of unrelated posts.
People come back
Follows, likes and boosts arrive from anywhere that speaks ActivityPub — Mastodon, Lemmy, Misskey, Pixelfed and the rest.
Your domain, your posts
Nothing is relayed through anybody else's server. The addresses are yours and the content is served from your site.
No server configuration. Most ActivityPub implementations hand you an nginx rewrite rule and wish you luck. This one is an application: install the tar, pick your forums, done. It serves its own WebFinger, NodeInfo and actor documents through Invision Community's own routing.
Built to be safe with a stranger's instructions
An inbox is the only endpoint on a forum that acts on requests from people you have never heard of, so the checking matters more than the feature list.
Every incoming request is verified with HTTP Signatures — and not only that the signature passes, but what it covers. A signature that omits the request target can otherwise be replayed against a different endpoint, turning a harmless activity into a destructive one.
The body digest is checked against the body. A valid signature over a swapped payload is refused.
Replays are rejected, so a repeated delivery cannot become a duplicate post.
A delete for one of your posts from a remote server is refused outright. Only the original author's server may withdraw their own content.
Stale requests are refused, with enough tolerance for a server whose clock has drifted.
Delivery that tells you the truth
Queued, not inline
Nobody waits on a remote server to finish posting. Delivery runs in the background.
Retries that widen
A server being restarted is retried gently; a server that has gone for good is given up on within about a day and marked, rather than retried forever.
One copy per server
Where a remote offers a shared inbox it gets a single delivery for all its followers, instead of one request each.
Failures kept
The queue shows what went where, how many attempts, and the last error — so "why did that server stop receiving posts" has an answer.
Publishing is one-way and permanent. Anything federated leaves your server and is stored on other people's. It cannot be recalled — a delete is a request that well-behaved servers honour, not a guarantee. Choose the forums deliberately, and do not federate anything you would not put on a public timeline. Federation ships switched off with no forums selected, and stays that way until you choose.
Check it actually works
The AdminCP fetches your own discovery endpoints from the outside and tells you what came back. If a firewall, a CDN rule or an nginx block on dot-directories is swallowing them, you are invisible to the fediverse and there is no other symptom — you simply never appear in anyone's search. This turns that into a line of text you can read.
Requirements
Invision Community 5.0 or newer (self-hosted)
A public hostname over HTTPS, and PHP with OpenSSL
The task scheduler running, since delivery is queued
No account with me, no external service, no per-post fee
Set your community's URL before you federate. Every address this creates is built from it, and other servers remember them. Changing the board URL afterwards orphans every actor, follower and published post on every server that has seen them.
Writing Assistant
Plenty of people have something worth saying and stall before they say it. The support question that arrives as "it's broken, help". The reply that reads angrier than it was meant to. The topic somebody starts three times and abandons.
Writing Assistant puts a button in the post editor, next to bold and italic. It fixes what is already written, and it drafts from a sentence when there is nothing written at all.
Seven ways to improve what is there
Fix spelling & grammar
Corrections only. It will not quietly rewrite somebody's voice while it is in there.
Improve writing
Clarity and flow, keeping their vocabulary and register. If they write plainly, it stays plain.
Make it shorter
Cuts padding and repetition without dropping a point, a question or a caveat.
Add detail
Develops what is already there. It cannot introduce facts that were not.
Friendlier tone
Removes the sarcasm and keeps the disagreement. It will not water down what somebody is actually saying.
More professional
Raises the register without turning it into a press release.
Summarise
A long post down to its key points.
And two for the blank page
The member writes a sentence about what they want to say, and gets a draft to edit. Ask a better question is the same idea pointed at your support forum: it turns a vague complaint into something your community can actually answer.
It marks what it does not know instead of inventing it. Every assistant of this kind fills gaps with plausible specifics — a version number, a price, an error message nobody ever supplied. On a forum that means members posting confident details that are false, and your staff correcting them. This one writes [your IPS version], [paste the error here], [what you have already tried], and tells the member the draft has gaps to fill. A draft with three placeholders is useful. A draft with three fabrications is a trap.
It cannot damage a post
Quoted text, code blocks and mentions are removed before the request and put back afterwards. The model never sees them, so it cannot alter them. If one does go missing, the member is warned before they can replace anything.
Nothing is applied without the member pressing Replace. They see the result first, can compare it against the original, and can retry.
Every change goes through the editor's normal undo.
You decide what it costs
Monthly cap
A hard stop in dollars. When the month's estimated spend reaches it, the assistant pauses until the month rolls over. This is the setting that means one member cannot hand you a bill.
Daily limits
Per member and across the whole site, measured over a rolling 24 hours rather than a calendar day — so somebody who runs out at 11pm is not handed a fresh allowance an hour later.
Length limits
Nothing is spent rewriting four words, and nobody pastes a novel in.
Per group
Set globally, and again per action. Let everybody fix their grammar; keep drafting for members who have earned it.
Spend is an estimate, not a bill. It is calculated from published token prices for models it recognises. A self-hosted model shows as zero, which is accurate — but so does an unrecognised commercial one, and for that the cap cannot protect you. Set a budget limit with your provider as well.
The instructions are yours to change
A support forum and a fiction workshop want opposite things from "improve writing". Every instruction is editable in the AdminCP, including the shipped ones, and your edits survive upgrades. You can add your own actions too, with their own icon and group restrictions.
Shared safety rules — never invent facts, return only the text, preserve quotes and code — are applied automatically and cannot be removed by editing an action.
Reporting that tells you something
Calls and spend, broken down by action and by member. The number worth watching is how often members keep the result rather than cancelling. Call counts only prove the button is being pressed; a low kept-percentage on one action means its instruction needs retuning, and you can go and retune it.
Your key, your data
Works with Anthropic, or anything speaking the OpenAI chat-completions shape — including self-hosted gateways such as Ollama, vLLM, LiteLLM and OpenRouter. Set the base URL and nothing leaves your network.
Members' drafts are not stored. The log records which action ran, when, by whom, and the token counts — not the text. There is a setting to keep it temporarily while you tune a prompt; it is off by default.
Already running AI Assistant or Guardian? It will reuse that key rather than making you paste a second copy.
Requirements
Invision Community 5.0 or newer (self-hosted)
An API key from your chosen provider, or a self-hosted endpoint
Outbound HTTPS from your server
No account with me, no service of mine in the middle, no per-request fee. You pay your provider directly for what your members use.
IPS5.0.0+
Writing Assistant
Plenty of people have something worth saying and stall before they say it. The support question that arrives as "it's broken, help". The reply that reads angrier than it was meant to. The topic somebody starts three times and abandons.
Writing Assistant puts a button in the post editor, next to bold and italic. It fixes what is already written, and it drafts from a sentence when there is nothing written at all.
Seven ways to improve what is there
Fix spelling & grammar
Corrections only. It will not quietly rewrite somebody's voice while it is in there.
Improve writing
Clarity and flow, keeping their vocabulary and register. If they write plainly, it stays plain.
Make it shorter
Cuts padding and repetition without dropping a point, a question or a caveat.
Add detail
Develops what is already there. It cannot introduce facts that were not.
Friendlier tone
Removes the sarcasm and keeps the disagreement. It will not water down what somebody is actually saying.
More professional
Raises the register without turning it into a press release.
Summarise
A long post down to its key points.
And two for the blank page
The member writes a sentence about what they want to say, and gets a draft to edit. Ask a better question is the same idea pointed at your support forum: it turns a vague complaint into something your community can actually answer.
It marks what it does not know instead of inventing it. Every assistant of this kind fills gaps with plausible specifics — a version number, a price, an error message nobody ever supplied. On a forum that means members posting confident details that are false, and your staff correcting them. This one writes [your IPS version], [paste the error here], [what you have already tried], and tells the member the draft has gaps to fill. A draft with three placeholders is useful. A draft with three fabrications is a trap.
It cannot damage a post
Quoted text, code blocks and mentions are removed before the request and put back afterwards. The model never sees them, so it cannot alter them. If one does go missing, the member is warned before they can replace anything.
Nothing is applied without the member pressing Replace. They see the result first, can compare it against the original, and can retry.
Every change goes through the editor's normal undo.
You decide what it costs
Monthly cap
A hard stop in dollars. When the month's estimated spend reaches it, the assistant pauses until the month rolls over. This is the setting that means one member cannot hand you a bill.
Daily limits
Per member and across the whole site, measured over a rolling 24 hours rather than a calendar day — so somebody who runs out at 11pm is not handed a fresh allowance an hour later.
Length limits
Nothing is spent rewriting four words, and nobody pastes a novel in.
Per group
Set globally, and again per action. Let everybody fix their grammar; keep drafting for members who have earned it.
Spend is an estimate, not a bill. It is calculated from published token prices for models it recognises. A self-hosted model shows as zero, which is accurate — but so does an unrecognised commercial one, and for that the cap cannot protect you. Set a budget limit with your provider as well.
The instructions are yours to change
A support forum and a fiction workshop want opposite things from "improve writing". Every instruction is editable in the AdminCP, including the shipped ones, and your edits survive upgrades. You can add your own actions too, with their own icon and group restrictions.
Shared safety rules — never invent facts, return only the text, preserve quotes and code — are applied automatically and cannot be removed by editing an action.
Reporting that tells you something
Calls and spend, broken down by action and by member. The number worth watching is how often members keep the result rather than cancelling. Call counts only prove the button is being pressed; a low kept-percentage on one action means its instruction needs retuning, and you can go and retune it.
Your key, your data
Works with Anthropic, or anything speaking the OpenAI chat-completions shape — including self-hosted gateways such as Ollama, vLLM, LiteLLM and OpenRouter. Set the base URL and nothing leaves your network.
Members' drafts are not stored. The log records which action ran, when, by whom, and the token counts — not the text. There is a setting to keep it temporarily while you tune a prompt; it is off by default.
Already running AI Assistant or Guardian? It will reuse that key rather than making you paste a second copy.
Requirements
Invision Community 5.0 or newer (self-hosted)
An API key from your chosen provider, or a self-hosted endpoint
Outbound HTTPS from your server
No account with me, no service of mine in the middle, no per-request fee. You pay your provider directly for what your members use.
Backup & Restore
Invision Community ships with no backup of any kind. The only thing it does is ask you to tick a box confirming you have made one — immediately before an upgrade, which is the single most dangerous thing the software does.
The usual advice is "just run mysqldump". On a correctly configured server you cannot. Invision Community's own Configuration Error notification tells administrators to disable exec, shell_exec, passthru, popen and proc_open. Take that advice, as you should, and every shell-based backup tool stops working.
This is pure PHP. No shell, no mysqldump, no external binary. It works on shared hosting, in a container, and on a hardened server where nothing can be executed.
It reads every backup back
A backup nobody has ever opened is not a backup — it is a file you are hoping about. After writing an archive this one reads it again, from the beginning, and checks:
the compressed stream decompresses whole, without truncation;
the end-of-file marker is present, which is what proves it was not cut short;
the SHA-256 checksum matches what was written;
every table is present, and every table's row count matches.
Only then is it marked verified. A backup that fails any of those is marked failed and — importantly — never counts towards your retention limit, so a good archive is never deleted to make room for a broken one.
It tells you when a backup is not a snapshot
Where the database is small enough to finish in one request, the dump runs inside a single transaction with a consistent snapshot: every table as it was at the same instant. Where it is too large, the work is queued across requests — which means the first table is read minutes before the last, while people are still posting.
Both kinds are labelled, on every row. A staged backup can contain a reply whose topic is missing. That is a real limitation of any backup taken this way, including mysqldump without --single-transaction, and you are told which kind you have rather than left to assume.
Somewhere other than the server it is protecting
A backup on the same disk as the community does not survive losing that disk. Archives are written above the web root where possible, so they cannot be requested over the internet at all — and can be sent to any storage you have already configured: Amazon S3, Cloudflare R2, Backblaze or FTP.
If the parent directory is not writable and archives have to live under the web root, the application says so plainly on the screen rather than quietly hoping the filename is enough.
Restoring
One table
The case that actually happens: somebody deleted a forum. Restore that one table and nothing else — the rest of the community, including everything posted since, is untouched. The screen shows which tables have lost rows since the backup, so you can see what is missing before you touch anything.
Everything
Runs from a generated standalone script, not from a button. A full restore replaces the very tables the running request depends on — sessions, caches, the job queue — and doing that from inside the suite is how a community ends up unable to start. The script boots nothing, reads your configuration directly and survives its own work.
The restore script is key-protected, refuses to run without an explicit confirmation, and refuses outright if the archive does not match the database it is pointed at — for example if it came from a different install, or before an application was added — unless you override it deliberately.
Details that matter when it counts
Binary data is hex-encoded, so blobs, attachments and anything with a NUL byte come back byte for byte rather than quietly corrupted.
A legitimate zero stays zero in an auto-increment column, instead of being silently reassigned and breaking every row that pointed at it.
Archives are portable. The dump is written as ordinary SQL that restores in any MySQL session, not only inside Invision Community.
The schedule is measured from the last successful backup, not the last attempt — so a job that fails every night cannot keep satisfying the schedule while producing nothing.
It survives its own restore. Restoring replaces this application's own records too; it rebuilds them by reading the archives back off disk, rather than reporting that you have no backups.
Requirements
Invision Community 5.0 or newer (self-hosted)
PHP with zlib, which every install already has
A running task scheduler, for scheduled backups
No shell access. No mysqldump. No external service.
IPS5.0.0+
Backup & Restore
Invision Community ships with no backup of any kind. The only thing it does is ask you to tick a box confirming you have made one — immediately before an upgrade, which is the single most dangerous thing the software does.
The usual advice is "just run mysqldump". On a correctly configured server you cannot. Invision Community's own Configuration Error notification tells administrators to disable exec, shell_exec, passthru, popen and proc_open. Take that advice, as you should, and every shell-based backup tool stops working.
This is pure PHP. No shell, no mysqldump, no external binary. It works on shared hosting, in a container, and on a hardened server where nothing can be executed.
It reads every backup back
A backup nobody has ever opened is not a backup — it is a file you are hoping about. After writing an archive this one reads it again, from the beginning, and checks:
the compressed stream decompresses whole, without truncation;
the end-of-file marker is present, which is what proves it was not cut short;
the SHA-256 checksum matches what was written;
every table is present, and every table's row count matches.
Only then is it marked verified. A backup that fails any of those is marked failed and — importantly — never counts towards your retention limit, so a good archive is never deleted to make room for a broken one.
It tells you when a backup is not a snapshot
Where the database is small enough to finish in one request, the dump runs inside a single transaction with a consistent snapshot: every table as it was at the same instant. Where it is too large, the work is queued across requests — which means the first table is read minutes before the last, while people are still posting.
Both kinds are labelled, on every row. A staged backup can contain a reply whose topic is missing. That is a real limitation of any backup taken this way, including mysqldump without --single-transaction, and you are told which kind you have rather than left to assume.
Somewhere other than the server it is protecting
A backup on the same disk as the community does not survive losing that disk. Archives are written above the web root where possible, so they cannot be requested over the internet at all — and can be sent to any storage you have already configured: Amazon S3, Cloudflare R2, Backblaze or FTP.
If the parent directory is not writable and archives have to live under the web root, the application says so plainly on the screen rather than quietly hoping the filename is enough.
Restoring
One table
The case that actually happens: somebody deleted a forum. Restore that one table and nothing else — the rest of the community, including everything posted since, is untouched. The screen shows which tables have lost rows since the backup, so you can see what is missing before you touch anything.
Everything
Runs from a generated standalone script, not from a button. A full restore replaces the very tables the running request depends on — sessions, caches, the job queue — and doing that from inside the suite is how a community ends up unable to start. The script boots nothing, reads your configuration directly and survives its own work.
The restore script is key-protected, refuses to run without an explicit confirmation, and refuses outright if the archive does not match the database it is pointed at — for example if it came from a different install, or before an application was added — unless you override it deliberately.
Details that matter when it counts
Binary data is hex-encoded, so blobs, attachments and anything with a NUL byte come back byte for byte rather than quietly corrupted.
A legitimate zero stays zero in an auto-increment column, instead of being silently reassigned and breaking every row that pointed at it.
Archives are portable. The dump is written as ordinary SQL that restores in any MySQL session, not only inside Invision Community.
The schedule is measured from the last successful backup, not the last attempt — so a job that fails every night cannot keep satisfying the schedule while producing nothing.
It survives its own restore. Restoring replaces this application's own records too; it rebuilds them by reading the archives back off disk, rather than reporting that you have no backups.
Requirements
Invision Community 5.0 or newer (self-hosted)
PHP with zlib, which every install already has
A running task scheduler, for scheduled backups
No shell access. No mysqldump. No external service.
Most of the people reading your community are not members of it. They arrive from a search result, read the answer they came for, and leave — and nothing about that visit is recorded, so you never find out which of your topics were the ones worth joining for.
Convert does two things: it asks them to join at the moment they are most likely to say yes, and it tells you which pages actually worked.
Ask at the right moment
Invision Community's guest sign-up block is a static panel in the sidebar. It says the same thing to somebody who has just landed as to somebody who has read six topics and is scrolling to the bottom of a seventh.
Convert puts the prompt where the visitor already is, and only when it makes sense:
The reply box
Where a signed-out visitor is told they need an account to reply. They have read to the bottom of a discussion and want to say something — the strongest moment the software has.
Under the discussion
At the end of the posts on a topic.
Every page
The foot of any page, including Downloads, Pages and Gallery.
And only to the right people. Show it after somebody has read two pages, not one. Show it only to visitors who arrived from a search engine. Show it only in the forums where it makes sense. Show it at most twice a visit, so it never becomes wallpaper.
"No thanks" is remembered. When a visitor dismisses a prompt it stays dismissed, for as long as you choose. Nothing is more likely to lose a reader than asking them the same question on every page after they have already said no.
Then find out what actually worked
Every prompt is measured the whole way down: shown, clicked, joined, posted. Not just the click — the click is easy. The number that matters is at the bottom.
What brings people in
The pages people were reading when they decided to join, ranked. Usually a surprise, and usually the most useful screen here — it tells you what your community is actually good at before you write another word of copy.
Where they came from
Search, social, another site, or direct — recorded from the first page of the visit, so it survives them clicking around.
Compare two versions
Give two prompts the same test name and each visitor sees one of them, consistently, for their whole visit. Then read the two rows side by side.
It counts the people who joined without being asked, too. That is the number every prompt is competing against, and leaving it out is how conversion reporting ends up permanently flattering. If forty people joined unprompted last month and three came through a prompt, you have learned something real.
Honest about what it shows
A rate with nothing behind it is shown as blank, not as 0%. "Never shown" and "shown a thousand times and ignored" are opposite findings, and printing zero for both hides the difference exactly when you need it.
Impressions are counted on the server, as the page is built. Counting them with a script means an ad blocker can delete them, which quietly inflates every click rate you look at.
Posting is tracked separately from joining. A prompt that produces accounts which never post has produced nothing, and the report is built so it can say so.
What it collects
Daily totals per prompt — shown, clicked, dismissed. No row is ever written per visitor. The only per-person record is one row for each member who registers, so that the report can say which page brought them in; it is created at registration and belongs to a member you already have.
The only cookie it sets exists to remember that somebody pressed "No thanks". Everything else rides the session Invision Community already keeps.
Requirements
Invision Community 5.0 or newer (self-hosted)
Registration open to guests, which is what there is to convert them to
Nothing else. No account, no key, no external service.
IPS5.0.0+
Most of the people reading your community are not members of it. They arrive from a search result, read the answer they came for, and leave — and nothing about that visit is recorded, so you never find out which of your topics were the ones worth joining for.
Convert does two things: it asks them to join at the moment they are most likely to say yes, and it tells you which pages actually worked.
Ask at the right moment
Invision Community's guest sign-up block is a static panel in the sidebar. It says the same thing to somebody who has just landed as to somebody who has read six topics and is scrolling to the bottom of a seventh.
Convert puts the prompt where the visitor already is, and only when it makes sense:
The reply box
Where a signed-out visitor is told they need an account to reply. They have read to the bottom of a discussion and want to say something — the strongest moment the software has.
Under the discussion
At the end of the posts on a topic.
Every page
The foot of any page, including Downloads, Pages and Gallery.
And only to the right people. Show it after somebody has read two pages, not one. Show it only to visitors who arrived from a search engine. Show it only in the forums where it makes sense. Show it at most twice a visit, so it never becomes wallpaper.
"No thanks" is remembered. When a visitor dismisses a prompt it stays dismissed, for as long as you choose. Nothing is more likely to lose a reader than asking them the same question on every page after they have already said no.
Then find out what actually worked
Every prompt is measured the whole way down: shown, clicked, joined, posted. Not just the click — the click is easy. The number that matters is at the bottom.
What brings people in
The pages people were reading when they decided to join, ranked. Usually a surprise, and usually the most useful screen here — it tells you what your community is actually good at before you write another word of copy.
Where they came from
Search, social, another site, or direct — recorded from the first page of the visit, so it survives them clicking around.
Compare two versions
Give two prompts the same test name and each visitor sees one of them, consistently, for their whole visit. Then read the two rows side by side.
It counts the people who joined without being asked, too. That is the number every prompt is competing against, and leaving it out is how conversion reporting ends up permanently flattering. If forty people joined unprompted last month and three came through a prompt, you have learned something real.
Honest about what it shows
A rate with nothing behind it is shown as blank, not as 0%. "Never shown" and "shown a thousand times and ignored" are opposite findings, and printing zero for both hides the difference exactly when you need it.
Impressions are counted on the server, as the page is built. Counting them with a script means an ad blocker can delete them, which quietly inflates every click rate you look at.
Posting is tracked separately from joining. A prompt that produces accounts which never post has produced nothing, and the report is built so it can say so.
What it collects
Daily totals per prompt — shown, clicked, dismissed. No row is ever written per visitor. The only per-person record is one row for each member who registers, so that the report can say which page brought them in; it is created at registration and belongs to a member you already have.
The only cookie it sets exists to remember that somebody pressed "No thanks". Everything else rides the session Invision Community already keeps.
Requirements
Invision Community 5.0 or newer (self-hosted)
Registration open to guests, which is what there is to convert them to
Nothing else. No account, no key, no external service.
Pulse — traffic analytics that never leave your database
Invision Community tells you a great deal about your content. Registrations, posts, reactions, badges, points, solved rate — there are forty statistics screens in the AdminCP and they are genuinely good.
None of them tell you about your traffic. Not pageviews. Not visitors. Not where anybody came from. Guests, who are most of the people reading your community, appear nowhere at all — they exist only in the sessions table, which is wiped continuously.
The official answer is Google Analytics
Invision Community ships an integration whose entire job is injecting Google's tracking script into your pages. That is the supported route, and for a lot of communities it is not a route at all: a cookie banner, a data-protection question you would rather not answer, and your members' browsing habits handed to an advertising company.
Pulse is the third option. Every figure below is measured on your own server, stored in your own database, and shown in your own AdminCP. Nothing is sent anywhere.
What it measures
Headline
Pageviews · visitors · sessions · bounce rate · average visit length
Where they went
Top pages, with the whole path — not just content items
Where they came from
Referring sites, with your own domain excluded
Who
Members against guests, and desktop against mobile and tablet
Countries
A world map you can hover, country by country
Every headline figure carries a trend line, and the whole dashboard can be read over seven, thirty or ninety days.
No JavaScript. No cookies. No IP addresses.
This matters enough to be specific about, because "privacy-friendly" is easy to claim.
No script is loaded. Not one byte of JavaScript, not even for the charts — the graphs and the world map are inline SVG. Nothing is fetched from anywhere.
No cookie is set, so Pulse adds nothing to a consent banner.
No IP address is ever written to the database. One is read to compute a hash and immediately discarded. There is no column to store it in.
The visitor identifier is salted with a secret that changes every day. It cannot be reversed, and it cannot be matched from one day to the next — so it counts visitors without following anybody.
A pageview records whether somebody was signed in, never which account. There is no member column.
Raw events last hours, not for ever. They are rolled into daily totals and deleted. After that a day exists only as a handful of numbers.
The settings screen lists all of this in the interface, with live counts, so you can answer a data-protection question by pointing at it.
It cannot slow your forum down
The recording happens after the page has already been delivered. Invision Community closes the connection to the browser before running its shutdown work, and Pulse writes its single row at that point. The visitor has their page before the database is touched. There is no query on the way in, no join, and nothing that can fail in a way that affects the page.
Honest about the limits
Some things cannot be measured without JavaScript, and it is better to say so than to invent them:
A one-page visit has no measurable length. There is no exit signal, so bounces contribute nothing to the average visit time rather than a made-up figure. The average is over visits that can actually be measured.
Visitors are counted per day and added up. Somebody who comes on Monday and Tuesday counts twice over a week. Counting them once would mean keeping the raw records for the whole period, which is exactly what this app is designed not to do.
Countries need a header from in front of your site. If you run Cloudflare or a load balancer that provides one, the map fills in. If nothing supplies it, the map is hidden rather than shown empty. Pulse does no geolocation lookups of its own — that would mean either an external request or shipping a database of IP ranges.
Also
Crawlers are separated out, using Invision Community's own spider detection. Search engines can be most of your raw traffic and none of your audience.
You can exclude your own staff, so your browsing does not become the story.
Retention is yours to set — hours of raw events, days of history.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
A running task scheduler — the hourly rollup is what produces every figure
Nothing else. No API key, no account, no external service.
IPS5.0.0+
Pulse — traffic analytics that never leave your database
Invision Community tells you a great deal about your content. Registrations, posts, reactions, badges, points, solved rate — there are forty statistics screens in the AdminCP and they are genuinely good.
None of them tell you about your traffic. Not pageviews. Not visitors. Not where anybody came from. Guests, who are most of the people reading your community, appear nowhere at all — they exist only in the sessions table, which is wiped continuously.
The official answer is Google Analytics
Invision Community ships an integration whose entire job is injecting Google's tracking script into your pages. That is the supported route, and for a lot of communities it is not a route at all: a cookie banner, a data-protection question you would rather not answer, and your members' browsing habits handed to an advertising company.
Pulse is the third option. Every figure below is measured on your own server, stored in your own database, and shown in your own AdminCP. Nothing is sent anywhere.
What it measures
Headline
Pageviews · visitors · sessions · bounce rate · average visit length
Where they went
Top pages, with the whole path — not just content items
Where they came from
Referring sites, with your own domain excluded
Who
Members against guests, and desktop against mobile and tablet
Countries
A world map you can hover, country by country
Every headline figure carries a trend line, and the whole dashboard can be read over seven, thirty or ninety days.
No JavaScript. No cookies. No IP addresses.
This matters enough to be specific about, because "privacy-friendly" is easy to claim.
No script is loaded. Not one byte of JavaScript, not even for the charts — the graphs and the world map are inline SVG. Nothing is fetched from anywhere.
No cookie is set, so Pulse adds nothing to a consent banner.
No IP address is ever written to the database. One is read to compute a hash and immediately discarded. There is no column to store it in.
The visitor identifier is salted with a secret that changes every day. It cannot be reversed, and it cannot be matched from one day to the next — so it counts visitors without following anybody.
A pageview records whether somebody was signed in, never which account. There is no member column.
Raw events last hours, not for ever. They are rolled into daily totals and deleted. After that a day exists only as a handful of numbers.
The settings screen lists all of this in the interface, with live counts, so you can answer a data-protection question by pointing at it.
It cannot slow your forum down
The recording happens after the page has already been delivered. Invision Community closes the connection to the browser before running its shutdown work, and Pulse writes its single row at that point. The visitor has their page before the database is touched. There is no query on the way in, no join, and nothing that can fail in a way that affects the page.
Honest about the limits
Some things cannot be measured without JavaScript, and it is better to say so than to invent them:
A one-page visit has no measurable length. There is no exit signal, so bounces contribute nothing to the average visit time rather than a made-up figure. The average is over visits that can actually be measured.
Visitors are counted per day and added up. Somebody who comes on Monday and Tuesday counts twice over a week. Counting them once would mean keeping the raw records for the whole period, which is exactly what this app is designed not to do.
Countries need a header from in front of your site. If you run Cloudflare or a load balancer that provides one, the map fills in. If nothing supplies it, the map is hidden rather than shown empty. Pulse does no geolocation lookups of its own — that would mean either an external request or shipping a database of IP ranges.
Also
Crawlers are separated out, using Invision Community's own spider detection. Search engines can be most of your raw traffic and none of your audience.
You can exclude your own staff, so your browsing does not become the story.
Retention is yours to set — hours of raw events, days of history.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
A running task scheduler — the hourly rollup is what produces every figure
Nothing else. No API key, no account, no external service.
Drip Campaigns — email sequences that run themselves
Somebody registers at three in the morning on a Saturday. A week later they have posted nothing and you have not spoken to them, because nobody was awake to. Multiply that by every member who ever joined and you have the reason most communities lose people in their first fortnight.
A drip campaign is a sequence of emails that starts when a member does something and then unfolds on their clock — a welcome straight away, a nudge two days later, an invitation to introduce themselves after a week. Everyone gets the same thoughtful onboarding regardless of when they arrived.
Invision Community has this. On Cloud. On some plans.
Email Drip Campaigns arrived in Invision Community 5.1 for Cloud customers, on selected packages. Self-hosted communities do not get them at all.
This app brings sequences to self-hosted — and adds the two triggers the Cloud version does not have. Both were the most-requested things in the comments under the announcement, and neither made it in.
The trigger nobody else offers: they stopped showing up
Every other trigger is an event — somebody did a thing, so something happens. Absence raises no event. Nobody fires a notification when a member quietly stops visiting, which is exactly why re-engagement is the hardest email to send and the one worth the most.
This app goes looking instead. Set a number of days, and members who cross that line are enrolled by a scheduled scan. A "we miss you" series that actually reaches the people it is about.
And renewals, which are not first purchases
Invision's Cloud version fires on "purchases a subscription". This one also fires on renewals, on an upcoming expiry — the moment worth acting on while there is still something to save — and on cancellations. Thanking a three-year customer for joining reads badly; these deserve different emails and now they can have them.
Every trigger
Joining
Registers · confirms their email · updates their profile
Taking part
Joins a club · responds to an event · completes a course
Money
Buys · renews · is about to expire · cancels
Absence
Has not visited for a set number of days
Chaining
Another campaign finishes
Event responses can be narrowed to one answer, so you are not telling somebody who declined that you will see them there. Triggers for applications you do not run are never shown, and never listened for.
Audiences built from filters you already have
This app invents no filters of its own. It uses Invision Community's own member filters, which means you can target by group, join date, last visit, content count, reputation, achievements and profile fields — and, if you run Commerce, by purchases, subscriptions, total spend and donations.
Anything a third-party application adds to that list works here too, automatically.
It checks again before every email
This is the part that stops a campaign embarrassing you. Someone qualifies for "we miss you" on Monday, comes back on Tuesday, and on Wednesday the second email arrives telling them how much you miss them. Audiences are re-checked before every send, not just at enrolment, so a member who stops matching stops receiving. It can be switched off; it is on by default for a reason.
Care taken where it matters
Opting out is honoured absolutely. A member who has turned off administrator emails is never enrolled, never sent to, and is removed from a campaign if they opt out mid-sequence.
Unsubscribing uses Invision Community's own mechanism — the same link, the same page, and a key derived from the account so it stops working when the password changes.
Nobody is enrolled twice. A trigger that fires more than once for the same person does nothing the second time.
Disabling an email does not strand anyone. Members waiting on that step move to the next one rather than sitting there for ever.
Posting and paying never wait on email. Enrolment happens in the background; sending happens on a schedule.
No core files are edited. Upgrading Invision Community will not break it.
Check a member
"Why didn't they get it?" has a dozen possible answers. There is a screen that gives you the actual one: whether they can be emailed at all, whether they match each campaign, whether they are enrolled, which step they are on, and when the next email is due.
Requirements
Invision Community 5.0 or newer (self-hosted)
Working outgoing email and a running task scheduler
Commerce, Calendar, Clubs are all optional — their triggers appear only if you run them
IPS5.0.0+
Drip Campaigns — email sequences that run themselves
Somebody registers at three in the morning on a Saturday. A week later they have posted nothing and you have not spoken to them, because nobody was awake to. Multiply that by every member who ever joined and you have the reason most communities lose people in their first fortnight.
A drip campaign is a sequence of emails that starts when a member does something and then unfolds on their clock — a welcome straight away, a nudge two days later, an invitation to introduce themselves after a week. Everyone gets the same thoughtful onboarding regardless of when they arrived.
Invision Community has this. On Cloud. On some plans.
Email Drip Campaigns arrived in Invision Community 5.1 for Cloud customers, on selected packages. Self-hosted communities do not get them at all.
This app brings sequences to self-hosted — and adds the two triggers the Cloud version does not have. Both were the most-requested things in the comments under the announcement, and neither made it in.
The trigger nobody else offers: they stopped showing up
Every other trigger is an event — somebody did a thing, so something happens. Absence raises no event. Nobody fires a notification when a member quietly stops visiting, which is exactly why re-engagement is the hardest email to send and the one worth the most.
This app goes looking instead. Set a number of days, and members who cross that line are enrolled by a scheduled scan. A "we miss you" series that actually reaches the people it is about.
And renewals, which are not first purchases
Invision's Cloud version fires on "purchases a subscription". This one also fires on renewals, on an upcoming expiry — the moment worth acting on while there is still something to save — and on cancellations. Thanking a three-year customer for joining reads badly; these deserve different emails and now they can have them.
Every trigger
Joining
Registers · confirms their email · updates their profile
Taking part
Joins a club · responds to an event · completes a course
Money
Buys · renews · is about to expire · cancels
Absence
Has not visited for a set number of days
Chaining
Another campaign finishes
Event responses can be narrowed to one answer, so you are not telling somebody who declined that you will see them there. Triggers for applications you do not run are never shown, and never listened for.
Audiences built from filters you already have
This app invents no filters of its own. It uses Invision Community's own member filters, which means you can target by group, join date, last visit, content count, reputation, achievements and profile fields — and, if you run Commerce, by purchases, subscriptions, total spend and donations.
Anything a third-party application adds to that list works here too, automatically.
It checks again before every email
This is the part that stops a campaign embarrassing you. Someone qualifies for "we miss you" on Monday, comes back on Tuesday, and on Wednesday the second email arrives telling them how much you miss them. Audiences are re-checked before every send, not just at enrolment, so a member who stops matching stops receiving. It can be switched off; it is on by default for a reason.
Care taken where it matters
Opting out is honoured absolutely. A member who has turned off administrator emails is never enrolled, never sent to, and is removed from a campaign if they opt out mid-sequence.
Unsubscribing uses Invision Community's own mechanism — the same link, the same page, and a key derived from the account so it stops working when the password changes.
Nobody is enrolled twice. A trigger that fires more than once for the same person does nothing the second time.
Disabling an email does not strand anyone. Members waiting on that step move to the next one rather than sitting there for ever.
Posting and paying never wait on email. Enrolment happens in the background; sending happens on a schedule.
No core files are edited. Upgrading Invision Community will not break it.
Check a member
"Why didn't they get it?" has a dozen possible answers. There is a screen that gives you the actual one: whether they can be emailed at all, whether they match each campaign, whether they are enrolled, which step they are on, and when the next email is due.
Requirements
Invision Community 5.0 or newer (self-hosted)
Working outgoing email and a running task scheduler
Commerce, Calendar, Clubs are all optional — their triggers appear only if you run them
Auto Tagging — tags every topic by what it is about
Tagging only works if people do it, and people do not do it. Your tag list gets built with care, gets used properly for a fortnight, and then quietly stops being used at all. Everything posted after that is untagged, so tag pages go stale, filtering misses things, and the vocabulary you designed is doing nothing.
This reads each new topic and applies the tags that actually fit it.
It matches meaning, not words
A topic titled "my card keeps getting declined and I was charged twice" gets tagged billing — a word that appears nowhere in it. Invision's own tag box offers autocomplete over text the author has already typed, which cannot do this. Matching here is done on meaning, so a topic reaches the right tag even when it shares no vocabulary with it at all.
It uses your tags. Only your tags.
Nothing is invented and nothing new appears in your tag list. The app reads the tags you have already defined and chooses between them, so the vocabulary stays exactly as you designed it. Disable a tag and it stops being applied.
It also learns what each tag means in your community, not in general. A tag is understood partly from the topics that already carry it, so build on a woodworking forum and build on a gaming forum end up meaning quite different things — as they should.
It will not touch work someone did by hand
This is the part worth reading carefully. Adding a tag in Invision Community is not actually an operation the platform offers — saving tags replaces every tag on the item. A tagging tool that gets that wrong will silently delete tags your moderators set, and nobody will connect the loss to the app that caused it.

Auto Tagging always writes the complete set: existing tags, the new ones, and the item's prefix. By default it leaves anything already tagged completely alone.
Honest about confidence
Every match carries a score, and there is a threshold below which nothing is applied. The defaults are set to tag less rather than tag wrongly — a wrong tag is worse than a missing one, because someone has to find it and undo it.
There is a Preview screen that scores real topics from your own community and shows you the numbers, so you can pick a threshold from evidence rather than from a guess. It tags nothing while you do it.
Fits around the site rather than into it
Posting never waits. Tagging happens in the background after the topic is saved. Nobody sits watching a spinner while an API is called.
Backfill on demand. Tag the topics you already have, batched so a large community does not arrive as one enormous bill.
Scope it. Restrict it to certain forums, and list any tags it must never apply — solved and staff pick mean something procedural that only a person should decide.
Respects your limits. It will not push an item past your site-wide maximum tags per item.
One key, one bill. If you run Related Topics or AI Assistant, it can borrow their embeddings key instead of asking for another.
No core files are edited. Upgrading Invision Community will not break it.
What it costs to run
Auto Tagging needs an embeddings API key — Voyage AI or OpenAI. This is not a subscription to me; you hold the account and pay the provider directly.
Embeddings are among the cheapest things either provider sells. Your tag list is processed once and then only when it changes, and each new topic is a single small request. For an ordinary community this runs to a trivial amount per month, and there is no charge at all while nothing is being posted.
Requirements
Invision Community 5.0 or newer (self-hosted)
Forums
Tags enabled, with at least a few tags defined
An embeddings API key from Voyage AI or OpenAI — or Related Topics / AI Assistant already installed, in which case it can share theirs
IPS5.0.0+
Auto Tagging — tags every topic by what it is about
Tagging only works if people do it, and people do not do it. Your tag list gets built with care, gets used properly for a fortnight, and then quietly stops being used at all. Everything posted after that is untagged, so tag pages go stale, filtering misses things, and the vocabulary you designed is doing nothing.
This reads each new topic and applies the tags that actually fit it.
It matches meaning, not words
A topic titled "my card keeps getting declined and I was charged twice" gets tagged billing — a word that appears nowhere in it. Invision's own tag box offers autocomplete over text the author has already typed, which cannot do this. Matching here is done on meaning, so a topic reaches the right tag even when it shares no vocabulary with it at all.
It uses your tags. Only your tags.
Nothing is invented and nothing new appears in your tag list. The app reads the tags you have already defined and chooses between them, so the vocabulary stays exactly as you designed it. Disable a tag and it stops being applied.
It also learns what each tag means in your community, not in general. A tag is understood partly from the topics that already carry it, so build on a woodworking forum and build on a gaming forum end up meaning quite different things — as they should.
It will not touch work someone did by hand
This is the part worth reading carefully. Adding a tag in Invision Community is not actually an operation the platform offers — saving tags replaces every tag on the item. A tagging tool that gets that wrong will silently delete tags your moderators set, and nobody will connect the loss to the app that caused it.

Auto Tagging always writes the complete set: existing tags, the new ones, and the item's prefix. By default it leaves anything already tagged completely alone.
Honest about confidence
Every match carries a score, and there is a threshold below which nothing is applied. The defaults are set to tag less rather than tag wrongly — a wrong tag is worse than a missing one, because someone has to find it and undo it.
There is a Preview screen that scores real topics from your own community and shows you the numbers, so you can pick a threshold from evidence rather than from a guess. It tags nothing while you do it.
Fits around the site rather than into it
Posting never waits. Tagging happens in the background after the topic is saved. Nobody sits watching a spinner while an API is called.
Backfill on demand. Tag the topics you already have, batched so a large community does not arrive as one enormous bill.
Scope it. Restrict it to certain forums, and list any tags it must never apply — solved and staff pick mean something procedural that only a person should decide.
Respects your limits. It will not push an item past your site-wide maximum tags per item.
One key, one bill. If you run Related Topics or AI Assistant, it can borrow their embeddings key instead of asking for another.
No core files are edited. Upgrading Invision Community will not break it.
What it costs to run
Auto Tagging needs an embeddings API key — Voyage AI or OpenAI. This is not a subscription to me; you hold the account and pay the provider directly.
Embeddings are among the cheapest things either provider sells. Your tag list is processed once and then only when it changes, and each new topic is a single small request. For an ordinary community this runs to a trivial amount per month, and there is no charge at all while nothing is being posted.
Requirements
Invision Community 5.0 or newer (self-hosted)
Forums
Tags enabled, with at least a few tags defined
An embeddings API key from Voyage AI or OpenAI — or Related Topics / AI Assistant already installed, in which case it can share theirs
Passkeys — sign in with a face, a fingerprint or a security key
A passkey replaces the password entirely. Your members tap their phone, look at their laptop, or touch a security key, and they are in. Nothing to remember, nothing to type, nothing to leak.
This is a real login method, not a second factor. Invision Community has no WebAuthn support of any kind — this registers through core's own login-handler system, so the passkey button sits alongside your existing sign-in options and behaves like one of them.
Why passkeys and not another password policy
They cannot be phished. A passkey is bound to your domain by the browser. A convincing copy of your login page on another domain simply will not work — the credential refuses to sign for it.
They cannot be reused. Every site gets a different key, so a breach somewhere else cannot reach your community.
There is nothing on your server worth stealing. You store a public key. It verifies signatures and can create none.
Nothing to reset. No "forgot password" flow, no reset emails, no support tickets about them.
What members see
Adding one
A page in their account settings. One button, their device prompts, they name the key. Several devices, several keys.
Signing in
A "Sign in with a passkey" button on the normal login form.
Managing them
Rename or remove any key, with the date added and last used, so an old laptop is easy to spot and revoke.
Works with what people already have
Face ID and Touch ID, Windows Hello, Android biometrics, iCloud Keychain, Google Password Manager, 1Password, Bitwarden, and hardware keys such as YubiKey. Nothing to install — every current browser has this built in.
Built carefully, because this is authentication
Every check the WebAuthn specification asks for is performed, and the reason each one exists is that skipping it breaks the model. The challenge is single-use, purpose-bound and expiring, so a captured ceremony cannot be replayed. The origin is compared exactly — not "starts with" — so a lookalike domain cannot relay it. Registrations cannot be replayed as logins. A signature is verified over exactly the bytes the authenticator signed.
Cloned-device detection. WebAuthn gives one signal that a credential may have been copied: a signature counter that goes backwards. If that happens the passkey is disabled and the member is told why. Authenticators that don't count at all report zero forever — that is normal, and is never mistaken for an attack.
No third-party code. No composer packages, no bundled cryptography library, nothing fetched at runtime. Verification uses PHP's own OpenSSL functions.
Hidden when it cannot work. Browsers refuse passkeys outside a secure context, so on a site without HTTPS the button does not appear rather than failing when pressed.
No core files are edited. Upgrading Invision Community will not break it.
What you control
How many passkeys each member may register
Whether to require user verification — a fingerprint, face or PIN, rather than mere presence
Whether a backwards counter disables the credential
The name members see on their device when it asks them to confirm
Requirements
Invision Community 5.0 or newer (self-hosted)
HTTPS. Browsers will not create or use a passkey without it.
PHP with OpenSSL — standard on every install
IPS5.0.0+
Passkeys — sign in with a face, a fingerprint or a security key
A passkey replaces the password entirely. Your members tap their phone, look at their laptop, or touch a security key, and they are in. Nothing to remember, nothing to type, nothing to leak.
This is a real login method, not a second factor. Invision Community has no WebAuthn support of any kind — this registers through core's own login-handler system, so the passkey button sits alongside your existing sign-in options and behaves like one of them.
Why passkeys and not another password policy
They cannot be phished. A passkey is bound to your domain by the browser. A convincing copy of your login page on another domain simply will not work — the credential refuses to sign for it.
They cannot be reused. Every site gets a different key, so a breach somewhere else cannot reach your community.
There is nothing on your server worth stealing. You store a public key. It verifies signatures and can create none.
Nothing to reset. No "forgot password" flow, no reset emails, no support tickets about them.
What members see
Adding one
A page in their account settings. One button, their device prompts, they name the key. Several devices, several keys.
Signing in
A "Sign in with a passkey" button on the normal login form.
Managing them
Rename or remove any key, with the date added and last used, so an old laptop is easy to spot and revoke.
Works with what people already have
Face ID and Touch ID, Windows Hello, Android biometrics, iCloud Keychain, Google Password Manager, 1Password, Bitwarden, and hardware keys such as YubiKey. Nothing to install — every current browser has this built in.
Built carefully, because this is authentication
Every check the WebAuthn specification asks for is performed, and the reason each one exists is that skipping it breaks the model. The challenge is single-use, purpose-bound and expiring, so a captured ceremony cannot be replayed. The origin is compared exactly — not "starts with" — so a lookalike domain cannot relay it. Registrations cannot be replayed as logins. A signature is verified over exactly the bytes the authenticator signed.
Cloned-device detection. WebAuthn gives one signal that a credential may have been copied: a signature counter that goes backwards. If that happens the passkey is disabled and the member is told why. Authenticators that don't count at all report zero forever — that is normal, and is never mistaken for an attack.
No third-party code. No composer packages, no bundled cryptography library, nothing fetched at runtime. Verification uses PHP's own OpenSSL functions.
Hidden when it cannot work. Browsers refuse passkeys outside a secure context, so on a site without HTTPS the button does not appear rather than failing when pressed.
No core files are edited. Upgrading Invision Community will not break it.
What you control
How many passkeys each member may register
Whether to require user verification — a fingerprint, face or PIN, rather than mere presence
Whether a backwards counter disables the credential
The name members see on their device when it asks them to confirm
Requirements
Invision Community 5.0 or newer (self-hosted)
HTTPS. Browsers will not create or use a passkey without it.
PHP with OpenSSL — standard on every install
Community Stats — one block that fits wherever you put it
Invision's built-in stats block shows three things: total members, most ever online, and the newest member. No posts, no topics, no sense of whether any of it is growing.
This shows what a visitor actually wants to know, with the trend behind it — and it reflows to whatever space you give it.
The same block, both orientations
It measures its own container, not the browser window. Drop it in a 260px sidebar and it renders as a neat stacked list. Drop it across a content column and the same block becomes a row of tiles. Nothing to configure and no second block to maintain — a normal responsive block cannot do this, because a viewport media query cannot tell a narrow sidebar from a wide page.
If you would rather decide yourself, you can force it to always stack or always tile.
Who's online, with faces
A row of avatars linking to profiles, with an overflow count when there are more than will fit.
Anonymous browsing is respected, properly. A member who has chosen to browse anonymously is never shown and never counted — and neither are guests or search engine spiders. The number beside the avatars is derived from the same list that draws them, so the count and the faces can never disagree with each other.
Figures that mean something
Counts
Members, topics, posts, online now, newest member
And, if you run them
Files, images, blog entries, events
Trend
A rise or fall over a period you choose
Sparkline
A 30-day line beside each figure
Only the figures your community can actually produce are offered — install Gallery and an image count appears in the list by itself. Nothing runs a query for something you are not showing.
Trends work on the first day
Members, topics and posts can be rebuilt from their own timestamps, so one click gives you a month of history immediately rather than asking you to wait a month for the block to look finished. Everything else starts recording from now.
And until there is real history, no trend is shown at all. A "+0" on a fresh install would be a lie dressed up as data.
Built to sit on a busy page
Cached. Counting every row on a large community is not free, so figures are shared between visitors for an interval you set.
No JavaScript. The sparklines are drawn inline as SVG — no charting library is loaded, on any page the block appears on.
Big numbers stay readable. 12,300 becomes 12.3k rather than breaking the layout of a sidebar.
Follows your theme, or takes an accent colour of your choosing.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
Forums, Downloads, Gallery, Blog and Calendar are all optional — the block simply offers whatever you have
IPS5.0.0+
Community Stats — one block that fits wherever you put it
Invision's built-in stats block shows three things: total members, most ever online, and the newest member. No posts, no topics, no sense of whether any of it is growing.
This shows what a visitor actually wants to know, with the trend behind it — and it reflows to whatever space you give it.
The same block, both orientations
It measures its own container, not the browser window. Drop it in a 260px sidebar and it renders as a neat stacked list. Drop it across a content column and the same block becomes a row of tiles. Nothing to configure and no second block to maintain — a normal responsive block cannot do this, because a viewport media query cannot tell a narrow sidebar from a wide page.
If you would rather decide yourself, you can force it to always stack or always tile.
Who's online, with faces
A row of avatars linking to profiles, with an overflow count when there are more than will fit.
Anonymous browsing is respected, properly. A member who has chosen to browse anonymously is never shown and never counted — and neither are guests or search engine spiders. The number beside the avatars is derived from the same list that draws them, so the count and the faces can never disagree with each other.
Figures that mean something
Counts
Members, topics, posts, online now, newest member
And, if you run them
Files, images, blog entries, events
Trend
A rise or fall over a period you choose
Sparkline
A 30-day line beside each figure
Only the figures your community can actually produce are offered — install Gallery and an image count appears in the list by itself. Nothing runs a query for something you are not showing.
Trends work on the first day
Members, topics and posts can be rebuilt from their own timestamps, so one click gives you a month of history immediately rather than asking you to wait a month for the block to look finished. Everything else starts recording from now.
And until there is real history, no trend is shown at all. A "+0" on a fresh install would be a lie dressed up as data.
Built to sit on a busy page
Cached. Counting every row on a large community is not free, so figures are shared between visitors for an interval you set.
No JavaScript. The sparklines are drawn inline as SVG — no charting library is loaded, on any page the block appears on.
Big numbers stay readable. 12,300 becomes 12.3k rather than breaking the layout of a sidebar.
Follows your theme, or takes an accent colour of your choosing.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
Forums, Downloads, Gallery, Blog and Calendar are all optional — the block simply offers whatever you have

Top Developers

Last reviews

Applications Directory

A complete and convenient directory of applications for Invision Community, with categorization and sorting options.

Ratings and feedback

Only verified and trusted reviews!

Add new Application

Any developer can add their application to this directory.

You need to create account

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.