Showing the widget only where you need it
A common question: can the widget be limited to one section of the site, to the staging environment, or to the people who are testing it, instead of every visitor on every page?
Yes — but today it is decided on your side, not in the project settings. There are no page, domain or visitor rules in the app yet (they are on the roadmap). The widget starts as soon as its embed code runs, so the question is simply: when does your site print that code? Everything below is a way to answer it.
What Revisionme already checks
One rule works without any setup. A report is only accepted from the site the project was created for: the host from the project's Website URL, one level of its subdomains, and localhost for local development. You can see the list in Project settings → General → White-listed hosts.
So a project created for https://example.com also accepts reports from www.example.com and staging.example.com, but not from example.net — if the code ends up on a foreign domain, the form still opens there, but nothing reaches your inbox. A different site needs its own project.
Create the project for the bare domain (https://example.com) rather than for https://www.example.com: the subdomain rule is then in your favour, and www and staging both work.
Only on the staging environment
The usual case: you collect feedback while the new version is being reviewed, and the live site stays clean. Print the code only when your environment variable says it is not production:
<?php if (getenv('APP_ENV') !== 'production'): ?>
<script>
var __rm__config = {
projectId: 'YOUR_PROJECT_ID',
locale: 'auto'
};
</script>
<script src="https://widget.revisionme.com/app.js" defer id="rm_app_script"></script>
<?php endif; ?>
If the staging site is a subdomain of the same domain (staging.example.com), the project you already have covers it. If it lives on a separate domain or behind a password, create a second project for it.
Only on certain pages
The same idea with the path. Keep a list of the pages or sections you are reviewing and include the snippet only there:
<?php
$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$sections = ['/pricing', '/blog/', '/docs/'];
foreach ($sections as $prefix) {
if (strpos($path, $prefix) === 0) {
include __DIR__ . '/revisionme.php'; // the embed code
break;
}
}
In a template engine the check is the same, only the syntax differs; in a single-page application, render the snippet from the route your router already knows.
Only for certain IP addresses
Useful when the site is live and you want the widget visible to the office or to one reviewer, and to nobody else:
<?php
$allowed = ['203.0.113.10', '198.51.100.24'];
if (in_array($_SERVER['REMOTE_ADDR'], $allowed, true)) {
include __DIR__ . '/revisionme.php';
}
Two warnings. Behind a proxy, a load balancer or Cloudflare, REMOTE_ADDR is the proxy's address, and the visitor's one arrives in a header (CF-Connecting-IP, X-Forwarded-For) that you should only trust when the request really comes from your own proxy. And home and mobile addresses change, so an IP list is reliable for an office network and annoying for everyone else — for a person, the switch below is easier.
Only for logged-in users or a chosen group
If the people who leave feedback are signed in to your site anyway, use the check you already have — a role, a group, a flag on the account:
<?php if ($user && $user->hasRole('editor')): ?>
<?php include __DIR__ . '/revisionme.php'; ?>
<?php endif; ?>
A switch in the URL
The most convenient option for a client or a tester who has no account on your site: a secret parameter turns the widget on for that person and remembers it in a cookie, so it survives the next clicks.
<?php
if (isset($_GET['rm'])) {
// /any-page?rm=1 turns it on, ?rm=0 turns it off
setcookie('rm_feedback', $_GET['rm'] === '1' ? '1' : '0', time() + 86400 * 30, '/');
$_COOKIE['rm_feedback'] = $_GET['rm'];
}
if (($_COOKIE['rm_feedback'] ?? '') === '1') {
include __DIR__ . '/revisionme.php';
}
You send https://example.com/?rm=1 to the reviewer, they see the widget on every page for the next month, and the rest of your visitors never do.
WordPress
In WordPress the same conditions are already available as conditional tags. Add the snippet to the functions.php of your child theme (or to a small plugin) and hook it to the footer:
add_action('wp_footer', function () {
// Only for users who can edit posts; replace with your own condition,
// e.g. is_page(['pricing', 'about']) or is_singular('post')
if (!current_user_can('edit_posts')) {
return;
}
?>
<script>
var __rm__config = { projectId: 'YOUR_PROJECT_ID', locale: 'auto' };
</script>
<script src="https://widget.revisionme.com/app.js" defer id="rm_app_script"></script>
<?php
});
Useful tags: is_page(), is_singular(), is_category(), is_front_page(), is_user_logged_in(), current_user_can(), and wp_get_environment_type() !== 'production' for the staging case.
Without touching code, a snippet plugin does the same through its own interface: WPCode, Insert Headers and Footers, Header Footer Code Manager and similar ones all let you paste the embed code once and then choose where it is printed — everywhere, on selected pages or post types, only for logged-in users. Paste the code into the Footer / Body position so it runs before </body>.
Google Tag Manager
If your site is managed through GTM, make a Custom HTML tag with the whole embed code (both <script> tags, config first) and give it a trigger with conditions: Page Path contains /docs/, Page Hostname equals staging.example.com, a cookie variable equal to 1, and so on. That keeps the rules in one place and lets a marketer change them without a deploy.
A check in the browser is not a lock
Deciding in JavaScript (if (location.pathname.startsWith('/docs/'))) is perfectly fine for keeping the widget off a page. It is not a restriction, though: the code is already downloaded and anyone can start it by hand. When the widget must really be invisible to the public — before a launch, on a client's private staging — the condition has to be on the server, where the page is built, so that the embed code is simply not in the HTML.
Whatever you choose, it changes nothing for the reports you already collected: they stay in the app, and the ones that arrive later are from visitors who match the condition you set.
Planned
Page and visitor rules in the project settings, so this can be done without touching the site, are on the roadmap. If you need a particular rule, write to hello@revisionme.com — it helps decide what comes first.