Knowledge base

Things that cost me a day, so they cost you none

Working notes from building Invision Community and Flarum applications. Mostly the failures that give no error at all — the ones where everything installs cleanly and quietly does the wrong thing.

92 articles

Invision Community 5

86 articles

Extensions and contracts

What each extension point is for, what it must declare, and what happens when it is wrong — which is usually nothing visible.

Languages and text

The string table, translation, and the places where text does not appear where you expected it to.

Theming, templates and forms

Theme hooks, CSS that survives both colour schemes, and building forms that do not throw on render.

Background work and scheduled tasks

The queue system, work that has to happen after the response, and jobs that finish without doing anything.

Data, settings and storage

The database layer, settings, tags, file storage, and backing up a live site.

AI features and expectations

What these features do, what they cost, and what buyers reasonably but wrongly assume they do.

Application structure and releases

The JSON files an application is made of, versioning and upgrade steps, and testing from the command line.

Realtime, chat and calls

WebSocket gateways, relays and the server-side pieces live features depend on — where "it works when I test it" and "it works for your members" are different claims.

Your video calls work in testing and fail for a third of your membersNew

Flarum 2

6 articles

Nothing matches that.

Knowledge Base

Notes, gotchas and how-tos for Invision Community 5 and Flarum 2.

Show all categories

Flarum 2: notification Blueprints need getFromUser()

A notification Blueprint that omits getFromUser() fails at send time rather than at registration, so the extension installs and enables cleanly and only breaks when the notification actually fires.
The required surface
public function getFromUser(): ?User { return $this->actor; // may be null for system notifications } public function getSubject() { return $this->thing; } public function getAttributes() { return ['thingId' => $this->thing->id]; } public static function getType() { return 'myThing'; } public static function getSubjectModel() { return Thing::class; } Returning null is fine and is the right answer for a notification not attributable to a person. Omitting the method entirely is not.
Related: Flarum 2: frontend model relations must use the hasOne/hasMany call pattern, Flarum 2: json-api-server returns 403 for declared but unwritable fields

0 comments
29 views

Ernest Defoe

July 26Jul 26

Flarum 2: never redefine core CSS variables at :root

Redefining a core custom property at :root in an extension changes it for every other extension and for the theme, and whichever stylesheet loads last wins. The result is a conflict that only appears when a particular combination of extensions is installed, which makes it close to unreproducible from a bug report.
Wrong
:root { --primary-color: #34d399; /* now everyone has this */ } Right
Namespace your own variables, and scope any override to your own container:
.MyExtension { --myext-accent: #34d399; } .MyExtension-panel { background: var(--myext-accent); } If you genuinely need to react to the theme, read core variables rather than redefining them: color-mix(in srgb, var(--primary-color) 20%, transparent).
Related: Flarum 2: Laravel facades throw "facade root has not been set", Custom CSS that works in both colour schemes, and the var() name trap

0 comments
31 views

Ernest Defoe

July 26Jul 26

Flarum 2: frontend model relations must use the hasOne/hasMany call pattern

Frontend relations are declared as calls, not as property definitions. Getting this wrong produces undefined at render time with no console error, which reads as an API problem rather than a model problem.
Right
Thing.prototype.owner = Model.hasOne<User>('owner'); Thing.prototype.items = Model.hasMany<Item>('items'); Then thing.owner() — called, not read.
Eager loading is endpoint-level
eagerLoad is declared on the endpoint, not on the field. Putting it on the field silently loads nothing and you get an N+1 query pattern that only shows up under load:
Endpoint\Show::make() ->eagerLoad(['owner', 'items']), For relations resolved by a getter rather than a real Eloquent relationship, batch them yourself — there is nothing for eagerLoad to hook into.
Related: Flarum 2: notification Blueprints need getFromUser(), Flarum 2: json-api-server returns 403 for declared but unwritable fields, Flarum 2: AbstractModel mass assignment throws a 500

0 comments
26 views

Ernest Defoe

July 26Jul 26

Flarum 2: Laravel facades throw "facade root has not been set"

File, Cache, Storage and friends are Laravel facades. Flarum boots the Illuminate container without registering the facade root, so calling them throws:
RuntimeException: A facade root has not been set. The fix
Inject the contract instead of reaching for the facade. Flarum's container resolves them normally:
use Illuminate\Contracts\Filesystem\Factory; public function __construct(protected Factory $filesystem) {} // then $disk = $this->filesystem->disk('flarum-assets'); Same pattern for cache (Illuminate\Contracts\Cache\Repository) and the rest. Constructor injection also makes the dependency testable, which the facade never was.
Related: Flarum 2: AbstractModel mass assignment throws a 500, Flarum 2: never redefine core CSS variables at :root

0 comments
25 views

Ernest Defoe

July 26Jul 26

Flarum 2: json-api-server returns 403 for declared but unwritable fields

A field that appears in your API schema but is not explicitly marked writable produces a 403 Forbidden on write, not a validation error. The response says nothing about which field caused it.
The cause
json-api-server treats writability as opt-in. Declaring a field makes it readable; it does not make it settable. A create or update that includes it is rejected as a permissions failure.
The fix
Mark the field writable explicitly, and gate it with the same check your policy uses:
Schema\Str::make('myField') ->writable(fn($model, $context) => $context->getActor()->can('edit', $model)), Diagnosing it
Because the error is a bare 403, it looks like an authentication or policy problem and sends you to the wrong place. If the actor clearly has permission and you still get 403 on write, suspect an unwritable field before you suspect the policy.
Related: Flarum 2: AbstractModel mass assignment throws a 500, Flarum 2: frontend model relations must use the hasOne/hasMany call pattern, Flarum 2: notification Blueprints need getFromUser()

0 comments
22 views

Ernest Defoe

July 26Jul 26

Flarum 2: AbstractModel mass assignment throws a 500

Since Flarum 2, passing an array of attributes straight into a model constructor or fill() raises a 500 rather than silently ignoring unguarded attributes.
Wrong
$thing = new Thing($attributes); // or $thing->fill($request->getParsedBody()['data']['attributes']); Right
Assign properties explicitly. It is more code and it is also the only version that survives a schema change without quietly writing a column you did not intend:
$thing = new Thing(); $thing->title = $attributes['title']; $thing->body = $attributes['body']; $thing->save(); The same applies to relationships and to any helper that forwards an attribute array into a model.
Related: Flarum 2: json-api-server returns 403 for declared but unwritable fields, Flarum 2: frontend model relations must use the hasOne/hasMany call pattern, Flarum 2: Laravel facades throw "facade root has not been set"

0 comments
23 views

Ernest Defoe

July 26Jul 26

Content behaviours are TRAITS, so instanceof is always false

Hideable, Taggable, Lockable, FuturePublishing and the rest are traits, not interfaces. Testing for them with instanceof compiles, runs, throws nothing — and is false for every object on the site.
Wrong
if ( $item instanceof \IPS\Content\Taggable ) // always FALSE { $item->setTags( $tags ); } The feature simply never runs. Nothing in a log, nothing in a test that only asserts "no exception was thrown".
Right
if ( \IPS\IPS::classUsesTrait( $item, 'IPS\Content\Taggable' ) ) { $item->setTags( $tags ); } classUsesTrait() lives in init.php and accepts either an object or a class name. Core uses it everywhere for exactly this reason:
if ( IPS::classUsesTrait( $topic, 'IPS\Content\Hideable' ) and $topic->hidden() ) How to catch it
php -l cannot see this, and neither can a test that only checks a method returned without error. Assert the positive case explicitly: that a known-taggable class is detected as taggable.
Related: A content listener without $class takes down your whole community, Extension method signatures are fixed, and a mismatch is a fatal on install, One content listener for every content type, including Pages databases

0 comments
29 views

Ernest Defoe

July 26Jul 26

MemberFilter extensions are gated by a hardcoded area whitelist

Invision Community has a rich set of member filters behind the core/MemberFilter extension point: group, join date, last visit, content count, reputation, achievements, profile fields, and from Commerce, purchases, subscriptions, total spend and donations. Any application can reuse them instead of writing its own.
There is one trap, and it fails silently.
The trap
Every filter decides for itself which "areas" it is available in, and the list is hardcoded:
// core/MemberFilter/Lastvisit.php return in_array( $area, array( 'bulkmail', 'group_promotions', 'automatic_moderation', 'passwordreset' ) ); // nexus/MemberFilter/Purchases.php return in_array( $area, array( 'bulkmail' ) ); Invent an area name for your own application and every existing filter returns false. You get an empty filter list, with no error anywhere, and you lose exactly the Commerce filters most worth having.
The fix
Ask using 'bulkmail'. It is the only area that returns the full set, and third-party filters work automatically too.
foreach ( Application::allExtensions( 'core', 'MemberFilter', FALSE, 'core' ) as $key => $extension ) { if ( !$extension->availableIn( 'bulkmail' ) ) { continue; } if ( empty( $criteria[ $key ] ) ) { continue; } $clause = $extension->getQueryWhereClause( $criteria[ $key ] ); // documented as returning an array, but several return a bare string if ( is_string( $clause ) ) { $clause = array( $clause ); } $where[] = $clause; $extension->queryCallback( $criteria[ $key ], $query ); // joins } If you are sending email
core_members.allow_admin_mails is the opt-out flag, and the core bulk mailer hard-filters on it. Anything sending on an administrator's behalf must too. Unsubscribe already exists at app=core&module=system&controller=unsubscribe, with a key of md5( email . ':' . members_pass_hash ). Reuse it rather than inventing tokens — it invalidates itself on password change.
Related: The core/MemberRestrictions extension in Invision Community 5, Extension method signatures are fixed, and a mismatch is a fatal on install

0 comments
24 views

Ernest Defoe

July 26Jul 26

A core/Notifications extension needs a language key named after the CLASS

Register a notification extension without its language string and the entire ACP Notification Settings screen breaks for the whole site, including other applications' notifications.
The symptom
UnderflowException: lang_not_exists__notifications__myapp_Thing #0 /applications/core/modules/admin/membersettings/notifications.php(78): IPS\Lang->get(...) The cause
That screen loops every registered notification extension with no error handling:
foreach ( Application::allExtensions( 'core', 'Notifications' ) as $k => $extension ) { $types[ $k ] = array( 'title' => Member::loggedIn()->language()->get( 'notifications__' . $k ) ); } Lang::get() throws on a missing key, so one application without its string kills the page.
The trap
The key is built from <app>_<ExtensionClassName> — the class file name, not the notification type declared inside it. An extension in extensions/core/Notifications/Live.php needs:
'notifications__myapp_Live' => "Live topics", 'notifications__myapp_Live_desc' => "Notifications about live topics.", If the configuration group inside that class is called golive, you also need notifications__myapp_golive for the group itself. Both sets are required.
Core follows the same rule: Files.php in Downloads uses notifications__downloads_Files.
Related: A module shows as module__myapp_thing on the administrator restrictions screen, Why your app shows menutab__content or module__myapp_thing to customers, The core/Notifications extension in Invision Community 5

0 comments
24 views

Ernest Defoe

July 26Jul 26

A container query cannot style its own container

Container queries let a block lay itself out based on the space it was given rather than the size of the browser window — the only way to make one block correct in both a narrow sidebar and a wide content column. A media query cannot tell those apart, because the viewport is the same width in both.
The trap
An element that declares container-type cannot be styled by queries against that container. Only its descendants can.
/* BROKEN: the grid rule never applies */ .block { container-type: inline-size; container-name: blk; } @container blk (min-width: 520px) { .block { display: grid; } /* silently ignored */ .block__item { font-size: 1.6rem; } /* works */ } The cruel part is that rules targeting descendants do apply, so the block half-changes and looks broken rather than unchanged.
The fix
Use two elements: one defines the container, the other is laid out.
.blk__container { container-type: inline-size; container-name: blk; } @container blk (min-width: 520px) { .blk__body { display: grid; } } Testing it
Asserting that @container appears in the CSS proves nothing — it was there in the broken version too. This is only caught by rendering the block at two widths and looking at it.
Related specificity trap
Inside a container block, a bare .blk__value has the same specificity as .blk__value--name. Coming later in the stylesheet, it wins. Use .blk__value:not(.blk__value--name) when the modifier must survive.
Related: Custom CSS that works in both colour schemes, and the var() name trap, The Invision Community 4 CSS class that silently does nothing in 5, Widget conventions: two language keys, ipsWidget markup, and cached blanks

0 comments
25 views

Ernest Defoe

July 26Jul 26

Form\Editor needs an EditorLocations extension that actually exists

A form containing an editor throws the moment the page is opened, not on submit, if its app and key do not name a real extension.
The symptom
OutOfBoundsException: Admin #0 /applications/myapp/modules/admin/.../controller.php(340): IPS\Helpers\Form\Editor->__construct(...) The exception message is the key alone, with no mention of the app, which makes it read like a missing language string.
The cause
new Editor( 'body', '', TRUE, array( 'app' => 'myapp', 'key' => 'Admin' ) ) This resolves eagerly to applications/myapp/extensions/core/EditorLocations/Admin.php. If that file does not exist, the constructor throws.
The fix
Either register the extension, or point at an existing one. For an admin-authored email or announcement body, core/Admin is what core's own Bulk Mail uses:
new Editor( 'body', $value, TRUE, array( 'app' => 'core', 'key' => 'Admin', 'autoSaveKey' => 'myapp-thing-' . $id, 'tags' => array( '{member_name}' => 'Member name' ), ) ) The tags option adds an insert menu to the editor toolbar, which is a better home for placeholders than a help box above the field.
Testing it
This fails inside an ACP controller, which cannot be instantiated from the command line. A static check — reading the source for app/key pairs and confirming the file exists — catches it without a browser.
Related: "This theme may be out of date" usually means your form field, not the theme, The core/EditorMedia extension in Invision Community 5

0 comments
29 views

Ernest Defoe

July 26Jul 26

core/Loader js() and css() must return an array of arrays

An application that registers a core/Loader extension and returns a flat list of URLs will take down every front-end page on the site, not just its own.
The symptom
Every front page returns a 500. The log says:
TypeError: array_merge(): Argument #2 must be of type array, string given #0 /system/Dispatcher/Front.php(188): array_merge(Array, 'https://...') Note where the error comes from: the dispatcher, not your application. Nothing in the trace names the app responsible.
The cause
The front dispatcher merges each entry into its file list:
foreach ( $loader->js() as $js ) { $jsFiles = array_merge( $jsFiles, $js ); } Each element is expected to be an array. Returning array( $url ) passes a string into array_merge() and throws before any page renders.
The fix
public function js(): array { return array( array( $url ) ); // an array OF arrays } Why this is easy to miss
Calling js() yourself and seeing a non-empty array back is not a test. The failure only happens inside the dispatcher merge loop. Test by reproducing that loop across every installed Loader extension, or by actually requesting a page.
Recovering
If a site is already down, disabling the application restores it immediately: set app_enabled = 0 for that application and clear the datastore. No files need to be touched.
Related: Widget conventions: two language keys, ipsWidget markup, and cached blanks, The core/LiveSearch extension in Invision Community 5, The core/OutputPlugins extension: how a {tag} in a template is resolved

0 comments
25 views

Ernest Defoe

July 26Jul 26

Setting a theme custom_css and calling save() silently does nothing

Writing custom CSS to a theme in code appears to work. The setter runs, caches clear, save() reports success — and the column is never touched.
The cause
ActiveRecord::save() writes only fields recorded as changed:
$data = $this->_new ? $this->_data : $this->changed; But Theme::set_custom_css() assigns straight into _data and never marks the field:
public function set_custom_css( string $value ) : void { $value = str_replace( '</style>', '', $value ); $this->_data['custom_css'] = $value; // NOT $this->changed // ... clears an editor store key } The fix
Write the column directly and reproduce the side effects:
Db::i()->update( 'core_themes', array( 'set_custom_css' => $value, 'set_css_updated' => time(), // cache-buster on the served CSS URL ), array( 'set_id=?', $themeId ) ); $key = $themeId . '_theme_editor_custom_css'; unset( Store::i()->$key ); Theme::deleteCompiledTemplate( 'core', 'front', 'global', $themeId ); Theme::deleteCompiledCss( 'core', 'front', 'custom', 'custom.css', $themeId ); Store::i()->clearAll(); Two related notes
Custom CSS lives in core_themes.set_custom_css, not in core_theme_css — that table holds application stylesheets. It is served inside a <style id="themeCustomCSS"> block and is minified, so comments are stripped. Searching the served page for a marker comment will not find it; search for a selector instead. Related: Custom CSS that works in both colour schemes, and the var() name trap, Theme hook types are an enum of four, there is no "replace", and how to change the page title anyway

0 comments
27 views

Ernest Defoe

July 26Jul 26

Widget conventions: two language keys, ipsWidget markup, and cached blanks

Every widget needs TWO language keys
block_<key> and block_<key>_desc. Without them the AdminCP block picker lists raw key strings. Easy to ship without noticing, because the block itself renders fine.
Use ipsWidget markup, never your own ipsBox
The widget framework already supplies the box. Emitting ipsBox yourself nests a box inside a box and the header stops matching every other block on the page.
<div class="ipsWidget ipsWidget--vertical"> <h3 class="ipsWidget__header"> ... </h3> <div class="ipsWidget__content"> ... </div> </div> A widget that throws leaves a cached blank
The static cache writes an empty placeholder before rendering, deliberately. If rendering throws, that blank persists even after the fault is fixed. Always clear caches after fixing a widget, or you will conclude your fix did not work.
Configuration is an empty array in two different situations
Before a block has ever been configured, and after saving it with nothing selected. So $this->configuration['x'] ?? $defaults is wrong: ?? only catches a missing key, not an empty one, and you get a permanently blank block. Fall through to defaults when the value is empty, not merely absent.
Test through __toString(), not render()
__toString() runs init(), _render() and the caching layer. Calling render() directly bypasses all of that and proves far less.
Related: core/Loader js() and css() must return an array of arrays, A container query cannot style its own container, The core/Dashboard extension: ACP dashboard blocks in Invision Community 5

0 comments
26 views

Ernest Defoe

July 26Jul 26

Creating a Pages database and categories in code

The supported entry point is Databases::createDatabase(), which builds the records table, the default title and content fields, and a default category.
$db = new \IPS\cms\Databases; $db->key = 'kb'; $db->use_categories = 1; $db->save(); // createDatabase() READS these while building the fields, so write them first \IPS\Lang::saveCustom( 'cms', 'content_db_' . $db->id, 'Knowledge Base' ); \IPS\Lang::saveCustom( 'cms', 'content_db_lang_pu_' . $db->id, 'articles' ); \IPS\cms\Databases::createDatabase( $db ); Four traps
1. There are no database_template_* columns. Setting $db->template_listing throws Unknown column 'database_template_listing' in 'field list'. Templates moved out of the row entirely.
2. Categories<id> and Records<id> are generated on demand from a cached database list. In a fresh CLI process that cache is stale, so class_exists() returns false for a database that plainly exists. Clear the datastore and load the database first.
3. setPermissions() inserts your array verbatim. It does not fill in app, perm_type or perm_type_id. Omit them and every category collides on an empty key, surfacing as Duplicate entry '0' for key core_permission_index.perm_type, leaving categories with no permission row at all — invisible to everybody including an administrator.
$insert = array( 'app' => $catClass::$permApp, 'perm_type' => $catClass::$permType, 'perm_type_id' => $id, ); foreach ( $catClass::$permissionMap as $what => $column ) { $insert[ 'perm_' . $column ] = '*'; } $catClass::load( $id )->setPermissions( $insert ); 4. Categories::$permType is NULL on the base class. The generated per-database subclass sets it (categories_2 for database 2). Read it at runtime.
The page
A database is invisible until a page hosts it. The page body needs the database tag, the page needs a populated page_full_path and a permission row, and Page::buildPageUrlStore() must be rebuilt afterwards or it 404s despite every row being correct.
Note that a permission row existing is not the same as it being populated: save() writes an empty one, so checking only for presence will leave perm_view blank and the page will 403.
Naming the page
A page title is a language string keyed cms_page_<id>, not a column. Create a page in code and the key is never written, so breadcrumbs, the browser title and menus all display the raw key — cms_page_4.
\IPS\Lang::saveCustom( 'cms', 'cms_page_' . $pageId, 'Knowledge Base' ); \IPS\Lang::saveCustom( 'cms', 'cms_page_' . $pageId . '_desc', 'What it is for.' ); Setting page_name on the row is not a substitute — that is only the label shown in the AdminCP. Set both, or the two disagree.
Category paths, or every article redirects forever
Creating a category in code sets category_furl_name and leaves category_full_path NULL. Record URLs are assembled as <page>/<category_full_path>/<record>, so a NULL path produces a double slash:
https://example.com/kb//my-article-r7/ Invision Community then issues a 301 to what it considers canonical, computes the same double-slash URL, and the browser stops with ERR_TOO_MANY_REDIRECTS.
The category listing works perfectly throughout, so it presents as a problem with articles rather than with categories.
// top-level: the path is just the slug // nested: parent path . '/' . slug Db::i()->update( 'cms_database_categories', array( 'category_full_path' => $path ), array( 'category_id=?', $id ) ); Build them parent-first so a child can prepend its parent, then clear the datastore.
Related: A Pages category created in code sends every article into a redirect loop, Pages page content is not a template: why template syntax prints itself, and why removing an element does not stick

0 comments
27 views

Ernest Defoe

July 26Jul 26

S3 and R2 storage break in any CLI script without HTTPS=on

Anything run from the command line that touches S3-compatible storage fails with BAD_XML. That includes cron tasks and any maintenance script.
The symptom
RuntimeException: BAD_XML #0 /system/File/Amazon.php(823): IPS\Http\Response->decodeXml() #1 /system/File/Amazon.php(349): IPS\File\Amazon::makeRequest(..., 'put', ...) In the AdminCP it often shows up first as a Locked Task warning for s3Delete, with a climbing lock count that never clears.
The cause
IPS\File\Amazon::buildBaseUrl() picks http or https from Request::i()->isSecure() — the scheme of the current request — rather than from the storage endpoint. Under CLI there is no request, so it builds http://. Cloudflare R2 answers with a 301 to https; IPS then runs its S3-specific redirect handler, which expects the body to be S3 XML containing an Endpoint element. R2 returns an HTML page, so decodeXml() throws.
Real AWS S3 hides the bug by answering http directly instead of redirecting.
The fix
Put HTTPS=on in the environment. PHP CLI copies it into $_SERVER['HTTPS'], isSecure() returns true, and the URL is built correctly.
docker exec -e HTTPS=on my_container php /path/to/script.php Clearing a stuck task
Fixing the cause does not release an existing lock. Set running and lock_count back to zero for that task row in core_tasks.
This applies to any S3-compatible storage behind CLI: R2, Backblaze, MinIO, Wasabi.
Related: The core/FileStorage extension in Invision Community 5, Dumping an Invision Community database from PHP: ANSI_QUOTES, multi-member gzip, and the 0x trap, Your background task is running inside a visitor's page load
Related application: Backup & Restore — Backup & Restore runs its archiving from a scheduled task, so it is written to survive exactly this class of CLI-context difference rather than assuming a normal web request.

0 comments
29 views

Ernest Defoe

July 26Jul 26

Taggable::setTags() deletes every existing tag first

There is no "add a tag" operation in Invision Community. Anything that tags content programmatically must pass the complete final set, or it silently destroys work someone did by hand.
What setTags() actually does
Db::i()->delete( 'core_tags', array( 'tag_aai_lookup=?', $aaiLookup ) ); foreach ( $set as $key => $tag ) { try { Tag::load( $tag, 'tag_text' ); // must already exist // ... insert } catch( \OutOfRangeException ) {} // unknown tags are dropped in silence } Three consequences:
Every existing tag is deleted before anything is written. Unknown tags are discarded without error. Only tags already in the tag store can be applied. An array key of 'prefix' sets the item prefix rather than an ordinary tag. Merging safely
$existing = $item->tags(); // non-prefix tags only $prefix = $item->prefix(); // may be NULL $set = array_values( array_unique( array_merge( $existing, $new ) ) ); if ( $prefix !== NULL ) { // core runs array_unique() over the set; if the prefix text also appears as // an ordinary tag, the numerically-keyed copy wins and the prefix is LOST $set = array_values( array_filter( $set, function( $t ) use ( $prefix ) { return mb_strtolower( $t ) !== mb_strtolower( $prefix ); } ) ); $set['prefix'] = $prefix; } $item->setTags( $set ); Also worth knowing
The site setting tags_force_lower makes tags() return lower-cased text that no longer matches how the tag is stored. Database collation hides this on lookup, but re-saving repeatedly will slowly rewrite every tag on the site to lower case. Map tags back to the tag store's own spelling before saving.
Related: There is no event when a tag is created, and what that means for your app, Why a similarity threshold is never enough for automatic classification
Related application: Auto Tagging — Auto Tagging merges what it adds with the tags already on an item, maps them back to the tag store's own spelling, and can be limited to items nobody has tagged by hand.

0 comments
32 views

Ernest Defoe

July 26Jul 26

Extensions, themes & support for Flarum and Invision Community

Things that cost me a day, so they cost you none

Invision Community 5

Extensions and contracts

Languages and text

Theming, templates and forms

Background work and scheduled tasks

Data, settings and storage

AI features and expectations

Application structure and releases

Realtime, chat and calls

Flarum 2

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)