Invintus WordPress Plugin

WordPress plugin that integrates the Invintus video platform. Registers an invintus_video custom post type, a Gutenberg block for embedding events, an admin settings page for API credentials and player preferences, and webhook routes that keep videos in sync with the Invintus API.

Features

• invintus_video CPT with invintus_category / invintus_tag taxonomies
• Gutenberg block (taproot/invintus) with live editor preview
• Settings UI for API key, client ID, default player preference, and watch redirect path
• REST endpoints under invintus/v2/ for webhook upserts and player preferences
• invintus/... filters for extending almost everything (see Extension points below)

Installation

Most installs pull from the release dist (see Repository layout).

1. Download the latest ZIP from the dist repo releases page.
2. WP Admin > Plugins > Add New > Upload Plugin > choose the ZIP > Install + Activate.
3. Configure under Invintus Videos > Settings, or define the constants in wp-config.php:

   define( 'INVINTUS_API_KEY',   'your-api-key'   );
   define( 'INVINTUS_CLIENT_ID', 'your-client-id' );

Constants take precedence over the UI when defined.

Requirements

• WordPress 5.8+
• PHP 7.4+
• Node.js 16+ and Composer (development only)

Development

Two ways to run the plugin locally. Pick one.

Quickstart with wp-env (recommended)

Spins up a Dockerized WP at http://localhost:8888, mounts this repo as a plugin, and gives you wp / composer / phpcs inside the container. No host PHP needed.

npm install
npm run dist:build
npm run env:start

Then visit http://localhost:8888/wp-admin (login: admin / password).

To run the plugin the way it actually ships to users (compiled build/, vendored vendor/, no dev tooling), build a dist candidate and tell wp-env to mount that instead:

npm run dist:build   # writes .dist-candidate/invintus/

Then create .wp-env.override.json (gitignored) at the repo root:

{
  "plugins": ["./.dist-candidate/invintus"],
  "config": {
    "INVINTUS_API_KEY":   "your-key",
    "INVINTUS_CLIENT_ID": "your-client-id"
  }
}

npm run env:start again to pick up the override.

Other env scripts: env:stop, env:destroy, env:clean, env:logs, env:wp (wp-cli passthrough), env:composer, env:phpcs.

One-time bootstrap after a fresh env:start

After every env:destroy + env:start, WP boots with Plain permalinks and no .htaccess. Pretty REST URLs (/wp-json/...) return Apache 404s until both are fixed. The "Save Permalinks in wp-admin" trick reports success but doesn't actually write .htaccess -- /var/www/html is owned by root inside the wp-env container so the www-data PHP process can't write there. Do it from the host instead:

# 1. set a non-plain permalink structure
npx wp-env run cli -- wp rewrite structure '/%postname%' --hard

# 2. write the standard WP .htaccess (as root, via the cli container)
npx wp-env run cli -- bash -c 'cat > /var/www/html/.htaccess <<EOF
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\\.php\$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
EOF'

After this the Settings page can save, REST routes resolve, and the block editor works normally. The file persists for the life of the env -- only re-run after a destroy.

To do the whole "wipe everything and start over" cycle in one shot (destroy + rebuild dist + start + bootstrap):

npm run env:reset

That runs scripts/reset-env.sh. It destroys the wp-env database, rebuilds build/ and .dist-candidate/, brings the env back up, and applies the bootstrap above. Use it to verify the "fresh clone" recipe end-to-end or when env state is the suspected cause of a bug. Does not touch node_modules -- delete that manually first if you also want a fresh npm install.

Traditional setup

Clone into an existing WP install:

cd wp-content/plugins
git clone https://github.com/TVWIT/invintus-wp-plugin invintus
cd invintus
composer install
npm install
npm run start   # watch-mode dev build

Build, lint, format

Overriding the player URL

The player script source is filterable. Drop a must-use plugin at wp-content/mu-plugins/invintus-player.php to redirect it:

<?php
add_filter( 'invintus/player/script/url', function() {
    return 'https://player.beta.invintusmedia.com/app.js';
} );

mu-plugins load before regular plugins, can't be deactivated through the admin UI, and survive plugin updates -- ideal for "site policy" overrides that shouldn't ride with a release. Remove the file to revert.

The override is scoped to the screens that actually need the player (the Invintus settings page, the block editor, and front-end posts with the block). It does not load on unrelated wp-admin screens.

Cross-origin player builds

If the override URL points to a build that uses dynamic import() for its own chunks (some bundlers split runtime code this way), the browser will refuse to resolve the relative module specifiers unless the `