Invision Community 5's rich-text editor is TipTap, shipped as a compiled bundle. There is no source and no npm package, but there is a real third-party plugin API — and almost every way of getting it wrong fails silently. The editor loads perfectly, your button is simply absent, and there is nothing in any log to tell you why.

How an application ships editor JavaScript

Put plain .js files in applications/<app>/dev/editor/. Building the application writes them into data/editor.xml, and at runtime Invision concatenates every enabled application's plugins into one file.

Two things about that folder matter. Files must sit directly in dev/editor/ — a js/ subdirectory is skipped — and anything not ending .js is ignored.

Trap 1: the API is on ips.ui.editorv5

There is no ips.ui.editor at all. The whole editor is registered with ips.createModule( 'ips.ui.editorv5', … ).

/* WRONG — returns immediately, forever */
if ( !ips.ui.editor.registerExtension ) { return; }

Guarding on the wrong name means your file compiles, minifies, ships, installs and serves correctly while registering nothing. Invision wraps each plugin in a try/catch, but an early return is not a throw, so even that has nothing to report.

function editorApi() {
    if ( !window.ips || !ips.ui ) { return null; }

    var candidates = [ ips.ui.editorv5, ips.ui.editor ];

    for ( var i = 0; i < candidates.length; i++ ) {
        if ( candidates[ i ] && typeof candidates[ i ].registerExtension === 'function' ) {
            return candidates[ i ];
        }
    }

    return null;
}

Accept both names so a future rename cannot break it the same way, and retry briefly — createModule can define lazily.

Trap 2: the file is minified by a pre-ES6 minifier

Plugins are run through Garfix JsMinify, a JSMin descendant older than ES6. Template literals and regex literals do not survive it. Use string concatenation and new RegExp. Do not let a linter "modernise" the file.

Trap 3: locations is not a list of preferences

addButtons() {
    return {
        equation: {
            html:      '<span class="my-trigger"><i class="fa-solid fa-square-root-variable"></i></span>',
            command:   function ( props ) { /* … */ return true; },
            locations: [ null ]
        }
    };
}

A single null appends to the end of the toolbar. Naming an anchor — { after: 'link' } — is prettier, but the placement loop skips a button whose named anchor is absent. An administrator who hides that anchor makes your button vanish entirely, with no error. Unless the position genuinely matters, append.

Trap 4: your markup is sanitised, hard

What you return is injected inside Invision's own <button>, so the root element must not itself be a button. The tags script link style pre code iframe object embed noscript video are stripped, and every attribute except class style id src title rel alt is removed recursively. The element must have non-empty innerHTML or it throws.

The one that will actually cost you the afternoon

Before concluding your button is missing, check whether any toolbar exists:

document.querySelectorAll( '.ipsEditor__toolbar-item' ).length

A topic's reply box renders no toolbar at all until it is clicked. Load a topic, query for your button, and you get zero — not because registration failed, but because there is nothing there yet. Not one of Invision's own buttons is present either.

This looks identical to a broken plugin. It cost three rounds of debugging on an application whose button had been working the whole time; the tell was that the count above was 0 rather than 82. Open the editor first, then count.

When it really has failed

A broken plugin reports only to window.Debug?.error — no PHP error, no console error unless Debug is on. Two checks worth having:

• Is your code in the served bundle at all? Fetch applications/core/interface/editor/index.php and search it for your application key. If it is absent, the problem is the build or dev/editor/, not your JavaScript.
• Did your code run? Set a marker such as window.__myappDebug at the top of the file and again after registerExtension, then read it in the console. That distinguishes "never loaded" from "loaded and returned early" from "registered fine" — three failures that otherwise look the same.

The bundle is cached

Changes do not appear until Application::resetEditorPlugins() runs. It fires automatically on install, enable and upgrade, so during development reinstall the application rather than wondering why an edit had no effect.