SignalPress bundles most dependencies locally and isolates PHP packages with namespace prefixing so they do not collide with WordPress or other plugins.
Overview: Extending SignalPress. Pro architecture: Free and Pro architecture.
Design goals
| Goal | Approach |
|---|---|
| Avoid version conflicts | PHP-Scoper prefix (SignalPressProVendor\...) in Pro |
| Work offline / without CDN | Admin UI assets bundled under assets/ |
| Minimize globals | Pro JS debug bundle compiles Consola privately — no window.consola |
| Load remote SDKs only when needed | PostHog browser SDK from configured host when tracking is enabled |
Bundled libraries (production)
| Library | SignalPress use | Where |
|---|---|---|
| [Tabulator](https://tabulator.info/) | Paginated delivery logs, Local records, System Logs tables | Free plugin assets/ |
| [Marked](https://marked.js.org/) | Render Markdown README in Help tabs | Free plugin assets/ |
| [Highlight.js](https://highlightjs.org/) | Syntax highlighting in Help code blocks | Free plugin assets/ |
| [Symfony VarDumper](https://symfony.com/doc/current/components/var_dumper.html) | Pro PHP sp() formatting | Pro vendor-prefixed/ |
| [Clockwork](https://underground.works/clockwork/) | Pro DevTools PHP metadata | Pro vendor-prefixed/ |
| [Consola](https://github.com/unjs/consola) | Pro JavaScript sp() console API | Compiled into Pro debug bundle |
License files ship alongside bundled assets where required.
Pro PHP dependencies
SignalPress Pro loads:
PHP
require_once SIGNALPRESS_PRO_PATH . 'vendor-prefixed/autoload.php';
Use SignalPressProVendor\ namespaces in Pro code — never assume unprefixed Symfony or Clockwork classes exist globally.
Example from Pro debugging:
PHP
use SignalPressProVendor\Symfony\Component\VarDumper\Cloner\VarCloner;
Pro JavaScript debug bundle
Pro debugging ships a private compiled bundle (signalpress-debug.js) built with esbuild in development. Production WordPress loads only the compiled file — not Consola as a separate script handle.
Basic tier uses signalpress-basic-debug.js in the free plugin (simple console output).
Remote / conditional loads
| Asset | When loaded |
|---|---|
| PostHog JS SDK | PostHog integration enabled with browser tracking — loaded from the configured PostHog host, not bundled |
| Clockwork Chrome extension | User installs extension; PHP sends discovery headers — Clockwork |
| Hub OAuth flows | Google / Microsoft OAuth for Sheets and Excel — credentials via Pro filters |
PostHog filters:
signalpress/posthog/load_browser_trackingsignalpress/posthog/load_web_analytics(legacy alias)
Build tooling (development only)
These tools are not loaded by WordPress in production:
| Tool | Purpose |
|---|---|
| [PHP-Scoper](https://github.com/humbug/php-scoper) | Prefix Pro PHP vendor code |
| [esbuild](https://esbuild.github.io/) | Bundle Pro JavaScript debug assets |
Contributors rebuild vendor and JS bundles when upgrading dependencies — end sites receive prebuilt artifacts in the plugin zip.
Admin asset cache busting
SignalPress versions mutable admin and browser scripts using file modification time (filemtime) rather than plugin version alone, so deployments pick up new behavior immediately.
Service-specific payload filters
Many integrations expose signalpress/{service-id}/payload filters (and service-specific variants such as signalpress/sentry/envelope). These are documented on each integration Help tab — not duplicated here.
See Developer hooks reference for the global hook list.
Extension guidance
When building custom integrations:
- Prefer
wp_remote_*and WordPress APIs over bundling HTTP clients when possible. - If you must ship a PHP library, namespace-prefix or isolate it in your plugin — do not modify SignalPress
vendor-prefixed/. - For browser SDKs, enqueue only when your service is enabled and configured — follow PostHog’s conditional load pattern.