Requirements#
Use WordPress 6.3 or later, PHP 8.0 or later, an HTTPS public website and a single-site installation. Multisite is not supported. Your WordPress administrator must be allowed to manage plugins, and the Reesponder account must be an owner or admin of an active workspace with website capacity.
Public site and WordPress administrator must share the actual final hostname, including www where applicable. A subdirectory installation is supported when that host matches. The theme must call wp_footer(), because the plugin adds its script to the public footer. An administrator host on another domain or a theme omitting that hook requires attention before setup.
Install and approve the connection#
- Download the Reesponder ZIP from the website's Installation view.
- In WordPress, open Plugins → Add New Plugin → Upload Plugin, choose the ZIP, install and activate it.
- Open Reesponder in the sidebar and select Connect Reesponder.
- Sign in, review the hostname, choose the appropriate owner/admin workspace and approve.
- Return to the same WordPress administrator session and choose Enable widget.
Approval lasts ten minutes. Restart from your own dashboard if it expires or returns under another administrator. The plugin stays disabled immediately after connection; Workspace connected is not the final enablement step. Approve only a connection you initiated. A matching website is reused; a new host creates a website subject to capacity.
WordPress's plugin-upload instructions explain its ZIP install and activation screen.
Verify and clear caches#
Visit a signed-out public page after enabling and check its delivered HTML for one loader. An administrator view can bypass caches customers still receive. The plugin does not render on dashboard or feed pages. Check a page using the actual theme footer, then reload and open the launcher.
Return to WordPress and choose Check connection, or refresh the website status in Reesponder. This control reports connection and detection; it does not itself load a public page. Confirm fresh detection after the visit and ask a representative source-backed question. Purge relevant HTML caches after enablement or disablement; review optimizer behavior using the cache plan below.
What the plugin connects#
The flow sends the public website address for workspace approval, then stores management and installation settings in WordPress. Its private management token stays on that server. The visitor tag receives the public website identifier and domain-bound installation credential, not the management credential.
No WordPress administrator password is sent to Reesponder. The plugin does not request WooCommerce orders, payment data or arbitrary administrative operations. Connecting the public widget is separate from a merchant authorizing a WooCommerce read Action. Keep consumer secrets and other provider credentials out of the theme and connection URL.
Reconnect, pause or remove#
A reversible frontend pause uses Disable widget or plugin deactivation. To revoke the platform connection, use Disconnect Reesponder before deleting the plugin. A successful disconnect clears local settings; on a network error they remain so you can retry. Uninstall is only a best-effort remote revocation.
A domain move requires connection for the correct new public host because the plugin checks its saved hostname. Website removal in Reesponder is a broader operation than disconnecting WordPress. See the removal plan below for its effects, and the illustrated WordPress guide for setup screens.
Worked example: the plugin is enabled but visitors see no chat#
The administrator sees Enabled in WordPress, but a signed-out visitor still receives cached HTML created before the plugin was enabled. Compare the public page source with a fresh uncached request using your ordinary cache tools. If no reesponder.js tag is present, purge the appropriate page and CDN cache, then visit again. Generating a manual token does not repair an old cached page and conflicts with the platform-owned connection.
If the tag remains missing after the correct cache is purged, check the active theme’s footer hook and whether the affected page uses another document template. If the tag loads but verification fails, compare the final public hostname with the connected website. An administrator dashboard screen is not proof that the public footer was rendered correctly.
Acceptance checklist for WordPress and WooCommerce pages#
Check the plugin’s connected state, Enabled state, fresh public-page HTML and the remote Widget detected result. Test a normal article or policy page and a representative product page if WooCommerce is used. Open the chat on a phone and ask a safe question whose answer is present in reviewed Knowledge. Confirm that your site’s important controls remain usable.
Check a signed-out cached page after a theme or cache-plugin change. Record the hostname, plugin method, active theme, cache layer and time of the successful test. For private WooCommerce order access, run its separate authorized Action tests, including a mismatching customer email. A working product-page widget does not prove the order lookup was configured or that a return request refunds a payment.
Understand what approval changes#
The plugin opens Reesponder account approval from a connection initiated in your WordPress dashboard. Review the displayed public hostname and choose the appropriate workspace. Approve only when you intentionally started the flow. A connection link received unexpectedly from another person should not be accepted simply because it opens the correct Reesponder account.
When the workspace already contains a website with that hostname, the matching record is connected and its widget configuration is replaced by the plugin’s credential. If there is no matching website, the flow adds one and queues public-page Knowledge preparation, subject to the plan’s capacity. Core’s one-website limit therefore matters when connecting another domain.
Return to the same WordPress administrator session to finish the short-lived flow. The plugin verifies the return state and private verifier rather than trusting a success-looking URL alone. If you lose the tab or the process expires, start a new connection. Do not copy private connection values into your theme or a browser context object.
Handle page caches and optimizers deliberately#
WordPress can have several delivery layers: an application page cache, a hosting cache, a CDN and the browser’s own cached response. Identify which layer serves the public HTML for the route you are testing. Enabling or disabling the plugin changes new page rendering; a previously cached document may still contain the old script or omit the new one.
Purge the relevant HTML after changing the widget. If an optimizer combines JavaScript files, rewrites script tags or delays execution until another interaction, exclude the official loader when necessary. It reads its own data-site-id and data-installation-token through the currently executing script. Combining or moving it without those attributes can prevent correct initialization.
Do not disable your entire cache or browser security policy as a permanent workaround. Compare a fresh signed-out page with the intended script, isolate the exact failing layer and make the smallest needed exception. Repeat this check after theme updates or optimizer changes, because those releases can change how a previously working footer script is delivered.
Add WooCommerce order lookup as a separate task#
A WooCommerce site is still a WordPress website for widget installation. The plugin adds visitor support and prepares the public-domain connection; it does not request WooCommerce order permissions. If customers need private order status, configure the appropriate read-only Action separately in Reesponder.
For the native WooCommerce lookup, the merchant supplies a read-only REST API key through the Action’s protected credential field. The lookup uses an order number and verified customer email, then compares that identity with the order’s billing email before returning a small result. Keep the consumer secret out of the theme, page source and WordPress connection approval link.
Test a real controlled record owned by your test identity and a mismatching identity. The wrong customer must not receive order data. Widget detection, public Knowledge quality and private order authorization are three independent milestones. Built-in return requests are another separate feature: they record a request for review rather than automatically approving or refunding an order.
Pause, disconnect or remove with the intended result#
Use Disable widget when you want a reversible frontend pause while keeping the connection. Deactivating the plugin stops it adding scripts to new page renders but keeps settings for reactivation. In either case, purge cached HTML and inspect a new public visit; an already open browser may still contain a loaded widget.
Use Disconnect Reesponder when you want to revoke that platform credential and clear the local saved connection. It keeps the Reesponder website and conversations. Deleting the plugin afterward removes local code, but uninstall alone is only a best-effort remote revocation. Use the explicit disconnect before deletion when possible.
Use Remove website inside the website’s Settings view for the broader service operation. It removes site-scoped Knowledge and revokes installation, context and private-test credentials while retaining shared Knowledge, usage and billing and applying conversation retention rules. Do not describe a frontend pause as a data deletion or assume all external emails and records disappear.
Need help with this?
Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.