ReviseFlow WordPress Plugin: Install Guide and What It Captures

For most WordPress teams the bottleneck of feedback collection is not the actual reporting — it is the friction of getting a feedback widget on the site in the first place. Pasting script tags into header.php every release, training a content team on which file to edit, dealing with cache plugins clobbering the snippet. The ReviseFlow WordPress plugin replaces that ritual with a one-click install and four checkboxes.

This post walks through the plugin end to end: install, settings, the WordPress context that gets attached to every report, the WooCommerce and multilang behaviours, and the developer hooks for theme authors who want to tweak it.

What the plugin does in one sentence

It loads the ReviseFlow widget bundle on your front-end with defer, decorates the script tag with your widget token and the visitor's language, and emits a small inline window.ReviseFlowContext block so every feedback submission carries WordPress-specific metadata.

That is the whole story. There is no proxy server, no PHP-side feedback storage, no admin page that talks to your database. The widget submits directly to the ReviseFlow API the same way any other embed does — the plugin only orchestrates where and when it loads.

1. Install

In a WordPress admin:

1. Go to Plugins → Add New and search for ReviseFlow.
2. Click Install Now, then Activate.

The plugin shows a dismissible admin notice nudging you toward the settings page until you save a widget token.

2. Get a widget token

Sign up at reviseflow.io (free plan is unlimited on one project). Open the project settings and copy the widget token — that is the only credential the plugin needs.

3. Configure settings

Under Settings → ReviseFlow the form is intentionally short:

Right next to the token field there is a Test connection button. It calls a private health endpoint on the ReviseFlow API and reports back the workspace, project name and plan tier — so you immediately know the token is valid before saving.

4. Hide the widget on a single page

In any post or page editor look for the ReviseFlow Widget meta box in the sidebar. Tick "Hide ReviseFlow widget on this page" and update — the widget never loads on that URL. Common uses: legal pages, login screens, internal landing pages that have their own feedback form.

What the plugin attaches to every report

This is the part that makes the WordPress plugin different from a raw script tag. Before the widget bundle loads, the plugin emits a small <script id="reviseflow-context"> block that defines window.ReviseFlowContext. The widget reads it and forwards the metadata to every feedback submission.

For a logged-in editor browsing a blog post, the metadata looks like this:

{
  "platform": "wordpress",
  "wpVersion": "6.6",
  "phpVersion": "8.1.10",
  "siteUrl": "https://shop.example.com",
  "theme": { "name": "Astra", "version": "4.5.0" },
  "user": { "id": 42, "roles": ["editor"] },
  "isMultisite": false,
  "post": {
    "id": 1207,
    "type": "post",
    "permalink": "https://shop.example.com/blog/hero-redesign",
    "template": "default"
  }
}

In the ReviseFlow dashboard this shows up as a "Platform context" panel inside the feedback detail view. Triage stops being "this looks broken on a page somewhere" and becomes "this looks broken on /blog/hero-redesign, theme is Astra 4.5.0, the reporter is an editor". You can reproduce the bug in the right environment without a back-and-forth.

WooCommerce reports include cart context

If WooCommerce is active, the plugin automatically appends a woocommerce block:

"woocommerce": {
  "isWooPage": true,
  "pageType": "checkout",
  "cart": { "itemCount": 3, "total": "129.00", "currency": "EUR" },
  "checkout": {
    "paymentGateways": ["stripe", "paypal"]
  }
}

That makes checkout regressions trivially debuggable. A bug report from a checkout page now arrives with the cart total, currency, and the list of available payment gateways at the moment of failure — the kinds of facts that normally take three Slack messages to extract from a reporter.

Language detection for WPML and Polylang

Translation plugins are a frequent source of "it works on the English version but not on the Italian one" tickets. The plugin detects WPML and Polylang and adds a language block:

"language": { "code": "it", "name": "Italiano", "plugin": "polylang" }

So you can filter feedback by locale on the dashboard side and stop chasing ghosts.

Page builders are handled

Elementor preview, Divi front-end builder, WPBakery inline editor and Beaver Builder all run the front-end with their own UI overlaid on the page. A floating feedback button in that context is a usability disaster. The plugin detects all four edit/preview modes and bails on widget injection automatically. Open the live URL in a normal tab and the widget reappears.

Developer hooks

For theme and plugin authors who want to integrate more tightly, four filters are available:

// Hide the widget on specific URLs without changing settings.
add_filter( 'reviseflow_should_load_widget', function ( $should_load ) {
    if ( is_page( 'private-area' ) ) {
        return false;
    }
    return $should_load;
} );

// Show the visibility meta box on custom post types.
add_filter( 'reviseflow_visibility_post_types', function ( $types ) {
    $types[] = 'product';
    return $types;
} );

// Enrich every feedback submission with extra context.
add_filter( 'reviseflow_context', function ( $context ) {
    $context['app_release'] = get_option( 'app_release_tag' );
    return $context;
} );

// Override the bundle URL (e.g. to serve from your own CDN).
add_filter( 'reviseflow_bundle_url', function ( $url ) {
    return 'https://cdn.example.com/reviseflow/bundle.js';
} );

The reviseflow_context filter is especially powerful for staging environments — append the deploy SHA, environment name or feature flag state and every report tells you which build it was filed against.

Privacy posture

The widget itself does not set tracking cookies. When a visitor submits feedback their browser metadata (user agent, viewport size) and the WordPress context block above are sent to ReviseFlow. Disclose this in your privacy policy. ReviseFlow stores feedback data on ReviseFlow infrastructure and cloud storage; full data processing details are on reviseflow.io/privacy.

The plugin does not call home from PHP. The only outbound request the WordPress server makes is the optional Test connection button on the settings page, which hits the ReviseFlow health endpoint. No telemetry, no usage pings.

When you should not use the plugin

A few situations where the plugin is not the right tool:

• Headless WordPress where the front-end is not served by WordPress. The plugin only injects on pages WordPress renders. For a Next.js / Gatsby / Astro front-end, embed the widget directly in your front-end app.
• Multi-tenant SaaS on a single WP install. The plugin is single-tenant — one widget token per site. If you need per-account branding and routing, the SaaS-side ReviseFlow project model is the better fit.
• Pages served from object cache only. Make sure the plugin's small inline script makes it through your full-page-cache layer. Most WP cache plugins handle this fine, but it is worth a smoke test after enabling.

Get started

The plugin lives in the official WordPress plugin directory. Install, paste your token, save — the feedback button is on your front-end before the next deploy. The full settings reference and developer hooks list lives on the WordPress install docs page.