The Feedback Magic plugin is live on WordPress.org. It cleared manual review and is in the directory, which means installing the widget on a WordPress site is now: Plugins → Add New → search "Feedback Magic" → Install → paste your key. No script tag, no theme file, no FTP. (The plugin page has the install steps, the requirements and what each widget type does.)
That last part is the reason it mattered enough to do. Pasting a <script> into
a theme is easy right up until the theme updates and eats it, and "add this to
your header" is a sentence that ends a lot of trials.
What the plugin actually does
Very little, deliberately. It is a loader.
You paste a publishable key per widget type under Settings → Feedback Magic, and it enqueues the matching hosted bundle with your key, position and (if you want it) the signed-in user's email attached. It does not re-implement the widget, store your feedback in WordPress, or add a database table. The widget it loads is byte-for-byte the one a hand-written script tag loads, so anything we fix in the widget is fixed on your WordPress site without you updating anything.
That is a real design choice with a real trade-off, so here is the other side of it. Because the plugin is a loader, it needs our service to be up and reachable from your visitors' browsers, exactly like the script tag does. If what you want is feedback stored inside your own WordPress database with no third party involved, this is the wrong tool and one of the self-hosted form plugins is the right one.
A note on version numbers, since they do not line up and that tends to look like neglect: the WordPress plugin, the npm package and the product itself are separate artifacts on separate release schedules. The plugin being on 1.3.x says nothing about the product being on 1.0.0. We keep one release stream for all of them rather than four changelogs, because three of four changelogs always go stale and a stale one reads as abandonment.
What we integrate with, and what is next
Feedback Magic currently pushes submissions out to GitHub Issues, Jira, Zendesk, Freshdesk, Freshservice, Twilio and any webhook you like. The webhook covers everything in principle, which is a thing people say when they have not built the integration you actually wanted.
So the honest position: the next one is not decided, and we would rather be told than guess. Slack is the one we hear about most and the one we do not have. Vote:
That poll is not a screenshot and not a form we bolted on for the occasion. It is our own survey widget, embedded on this page the same way you would embed it on yours, submitting through the same gateway your visitors' submissions go through. If it is broken here, it is broken for you — which is the most reliable way we have found to notice.
A few notes on it, since a public write-in box on a public page is exactly the sort of thing that gets abused:
- Every submission passes a Cloudflare challenge before it reaches the database, plus a hidden-field trap, a minimum fill time, and a per-IP rate limit. That is the standard path for every widget we serve, not something special for this page.
- The tally can only ever show the options we listed. A choice that is not on the menu is dropped server-side rather than stored, so the bar chart cannot be turned into a billboard by anyone with a terminal. We shipped that fix alongside this post — it was a real gap, and adding a write-in is what made us look for it.
- What you type in "Other" is private. It goes to our dashboard, not onto this page. The public bars show a single "Other" bucket and nothing more.
- Slurs and abuse get a polite ask to rephrase. Note the word polite — strong language in feedback is often the most useful part of it, so that screening is off by default on every widget we sell, and turned on here because strangers can reach this one.
One thing it is not: a ballot. Results are indicative, not audited — we are trying to find out what people want, not run an election.
If you are installing it today
Two things worth knowing:
- A key is per widget, not per site. Each widget type you enable has its own publishable key, and they are safe to expose — a key only permits submitting to that one widget. Take each from that widget's Install tab.
- Try it on a staging site first if your theme is unusual. The plugin
enqueues through the standard
script_loader_tagfilter, which is well-behaved, but themes that aggressively concatenate or defer scripts can still surprise everyone involved.