Eyesite Monitor

Your site can look fine and still lose money: the checkout fails after a plugin update, the contact form stops sending e-mails, a payment gateway silently drops orders, or the site goes down at night. Usually the owner finds out days later, from an unhappy customer.

Eyesite Monitor checks your WordPress site and WooCommerce store for exactly these problems and tells you in plain language what broke and what to do about it. It works on its own inside WordPress. If you connect it to the free EyeSite service (eyesite.pl), your site is also checked from outside every minute and you get an e-mail as soon as something stops working.

What it catches

• The store stops selling: failed payments, a broken cart or checkout, missing shipping methods and unusual silence when no orders come in.
• The contact form stops sending: failed submissions, e-mails that never leave the server and messages that would otherwise be lost.
• The site goes down: availability checked every minute (when connected), plus disk space, memory and WP-Cron on the server.
• Google or AI assistants cannot see the site: indexing blocks, sitemap, structured data, and whether ChatGPT, Claude and Perplexity may read it.
• Security gaps: WordPress versions with known vulnerabilities, SSL certificate expiry, changed core files, missing two-factor authentication.
• Errors visitors see: JavaScript and PHP errors, including errors on contact forms.

External services

This plugin connects to the EyeSite service (https://eyesite.pl) to provide external uptime monitoring and e-mail alerts. The connection is entirely optional and only happens after you click the “Connect” button in the plugin panel. Without connecting, the plugin still works locally (the monitoring dashboard is available offline).

What data is sent, and when:

• When connecting (after you click “Connect”): your site URL, your site name, the monitoring endpoint URL (which contains the API token used to read status) and your administrator e-mail address (pre-filled on the connect page, editable) used for alert notifications. This data is sent to the connect page at https://eyesite.pl/connect.
• Periodically: the EyeSite monitoring backend requests your site’s public status endpoint (/?eyesite-api=check) to read health status (UP/DOWN and check results) and e-mails you on failure.
• Once a day: the plugin verifies the connection token by sending it to the EyeSite automation backend at https://n8n.bielecki.cloud/webhook/eyesite-verify.
• On disconnect: the plugin sends the token to https://n8n.bielecki.cloud/webhook/eyesite-disconnect.
• Uptime data (only when connected, fetched in the background): the plugin reads your site’s public uptime history from the EyeSite status page at https://status.eyesite.pl (the status page is identified by a slug made from your site’s address, e.g. example-com). This includes the day-by-day availability file https://status.eyesite.pl/eyesite-dni/.json used in the monthly report. Only the slug is sent; nothing else.
• Feedback form (only when you submit it): the message, feedback type, your site URL, site name and administrator e-mail are e-mailed to the plugin author and also posted to https://n8n.bielecki.cloud/webhook/eyesite-feedback for logging. Nothing is sent unless you click “Send”.
• Page-speed check (opt-in, off by default): only after you enable “Pomiar szybkości strony” in the settings or click “Włącz pomiar prędkości” on the dashboard, the plugin sends your site’s public URL to the EyeSite automation backend at https://n8n.bielecki.cloud/webhook/eyesite-lighthouse, which queries the Google PageSpeed Insights API (https://developers.google.com/speed/docs/insights/v5/about) server-side and returns the performance score. It then repeats at most every 6 hours while you open the plugin dashboard. Only the public site URL is sent; no personal data. You can switch it off at any time in the settings. Google’s terms: https://developers.google.com/terms ; privacy: https://policies.google.com/privacy
• Audit and repair requests (only when you click “Zleć naprawę” or a free-audit button): your site URL, site name, administrator e-mail, the type of request, the problem description shown next to the button and the detected consent-mode status / names of tracking tags found on your home page are e-mailed to the plugin author (kontakt@eyesite.pl) using your site’s own mailer and also posted to https://n8n.bielecki.cloud/webhook/eyesite-audit-lead so that we can contact you about the request. Nothing is sent unless you click the button.
• Connection notice (only when you click “Connect”): the plugin author (kontakt@eyesite.pl) receives an e-mail with your site name, site URL and administrator e-mail, sent by your site’s own mailer, so that the service can be set up.
• E-mail delivery test (only when the site is connected to EyeSite): the plugin sends a short test e-mail from your site’s own mailer to probe@eyesite.pl. The message contains only a random token (no site data, no personal data). The plugin then asks https://n8n.bielecki.cloud/webhook/eyesite-mailprobe for the verdict (SPF/DKIM/DMARC result, blacklist status), sending only that token. The test runs when you click the test button on the e-mail card and automatically at most once a day while the site is connected; disconnecting stops it.
• WordPress security status (once a day): the plugin downloads the public list of WordPress releases from WordPress.org at https://api.wordpress.org/core/stable-check/1.0/ and compares it locally with the installed version, to warn you when your WordPress version has publicly known security holes. The request sends nothing about your site (no version, URL or token). This is the same WordPress.org API that WordPress itself uses; terms: https://wordpress.org/about/privacy/
• Known vulnerabilities in plugins and themes (opt-in, off by default): only after you enable “Sprawdzanie znanych luk we wtyczkach i motywach” in the settings, the plugin sends the list of installed plugin and theme slugs with their version numbers to the EyeSite automation backend at https://n8n.bielecki.cloud/webhook/eyesite-vulns once a day (and shortly after an update). The backend matches the list against a copy of the Wordfence Intelligence vulnerability database (https://www.wordfence.com/threat-intel/) and returns the matching records. No site URL, e-mail address, token or personal data is sent, and the list is not stored. Vulnerability data: Wordfence Intelligence, Copyright Defiant Inc., terms: https://www.wordfence.com/wordfence-intelligence-terms-and-conditions/

• Domain expiry check (opt-in, off by default): only after you enable “Sprawdzanie daty wygaśnięcia domeny” in the settings, the plugin sends your site’s registrable domain name (e.g. example.com) to the public RDAP service at https://rdap.org once a day and reads the registration expiry date and registrar. Nothing else is sent. RDAP.org terms and privacy: https://about.rdap.org/

• File integrity check (on by default, can be switched off in the settings): once a day the plugin downloads the public checksum lists for the installed WordPress version from https://api.wordpress.org/core/checksums/1.0/ and for each installed plugin from https://downloads.wordpress.org/plugin-checksums/ (the request URL contains only the WordPress version and locale, or the plugin slug and version). Your files are compared on your own server; nothing about your site is sent.

• Leaked password check (opt-in, off by default): only after you enable “Sprawdzaj hasło administratora w bazie wycieków”, when an administrator logs in (at most once a week per account) the plugin sends the first 5 characters of the SHA-1 hash of the password to the Have I Been Pwned “Pwned Passwords” API at https://api.pwnedpasswords.com/range/ (k-anonymity: the password and its full hash never leave your server). Terms: https://haveibeenpwned.com/API/v3#AcceptableUse, privacy: https://haveibeenpwned.com/Privacy
• Captcha key check (only when a form plugin has reCAPTCHA, Cloudflare Turnstile or hCaptcha configured): once a day the plugin sends the secret key stored in that form plugin’s settings, together with a dummy token, to the captcha provider’s own verification endpoint (https://www.google.com/recaptcha/api/siteverify, https://challenges.cloudflare.com/turnstile/v0/siteverify or https://api.hcaptcha.com/siteverify). This is the same request your form already makes on every submission; no visitor data is sent. The answer tells whether the key is valid.
• Form test (“mystery shopper”, connected sites only, switched on per site only after the owner agrees): EyeSite’s test browser opens a page with a form, fills it with obviously fake data (“Test EyeSite”, probe@eyesite.pl) and submits it, carrying a signed cookie valid for at most 30 minutes. For those requests the plugin redirects the form notification to the EyeSite test inbox (probe@eyesite.pl) instead of your recipients, and blocks outgoing requests and newly scheduled jobs to other services (CRM, newsletter, webhooks) except the captcha check and the e-mail sending itself. Integrations that queue data in their own database tables may still process the test entry later, and the form plugin may keep the test entry in its own entries list; this is why the test is enabled per site only on request. The EyeSite backend then reports the result to the plugin (form accepted, e-mail delivered). The plugin also exposes the list of pages with forms (URL, form plugin, title) to the EyeSite backend, authenticated with the site’s API token.
• Security event log (connected sites only): important admin events (a new administrator account, an administrator’s e-mail or password change, plugin installs and activations, a change of the site address or of the default role for new accounts, an administrator login from a new address, a login attempt on the trap account, changed files) are sent as they happen to https://n8n.bielecki.cloud/webhook/eyesite-blackbox with the connection token: event type, a short description, the login of the user who caused it, the site address and the time. E-mail addresses in the description are masked (ja***@example.com). No IP addresses and no content. This lets EyeSite e-mail you at the address given when connecting even if an intruder changes the site’s admin e-mail, and keeps a copy of the log that cannot be erased on the server. When you deactivate the plugin or click “Rozłącz”, the disconnect request also carries the reason and the login of the user who did it, so you get an e-mail if someone else switched the protection off.
• Visitor behaviour analysis (opt-in, off by default, connected sites only): only after you open the “Jak ludzie zachowują się na stronie” card, accept the data-processing agreement and switch it on, the plugin loads the analytics and session-recording scripts from the EyeSite analytics server at https://analityka.eyesite.pl (self-hosted Umami, https://umami.is, MIT licence, server in the EU). From then on that server receives, for each visit: page paths, page titles, referrer domain, browser, device type, screen size, language and country, and a recording of the rendered page (mouse movement, scrolling, clicks and DOM changes). It does not store IP addresses, city or region, URL query strings or ad click identifiers. Form fields are masked by the recorder, so what visitors type is not recorded, and WooCommerce billing, shipping and checkout fields are excluded entirely. No cookies are set. Recordings are deleted after 30 days and visit statistics after 13 months. By default the scripts start only after the visitor accepts statistics cookies in your consent banner (Complianz, CookieYes, Borlabs and Real Cookie Banner are recognised; without a recognised consent nothing is recorded); you can instead choose your legitimate interest, in which case visitors can opt out with the [eyesite_rezygnacja] shortcode. The plugin adds a suggested paragraph to Settings -> Privacy -> Policy guide. Your acceptance of the agreement (version, date, WordPress login and e-mail) is sent to EyeSite together with the request that switches the feature on. While the feature is on, the plugin asks https://eyesite.pl once a day whether recording should continue (sending the connection token and the analytics site ID) and fetches the ready-made written conclusions for the dashboard card and the monthly report (same data). When you switch it off, disconnect the monitoring or deactivate the plugin, it notifies https://eyesite.pl so that all data of your site is deleted within 30 days. You can switch it off at any time from the same card; disconnecting the monitoring switches it off as well. Terms and privacy: https://eyesite.pl/regulamin/ and https://eyesite.pl/polityka-prywatnosci/

AI visibility check (once a day): the plugin reads your own home page and /robots.txt, and requests the home page once more with the user agent string of an AI search bot (OAI-SearchBot) to see whether your server or firewall turns such bots away. These are requests to your own site only; nothing is sent to OpenAI, Anthropic or any other service.

Database leak trap (created only on sites connected to EyeSite, can be switched off in the settings): the plugin creates one WordPress user account with a random login, no role, no posts, an undeliverable e-mail address (…@pulapka.invalid) and a random 40-character password that is never stored or shown. Logging in to it and resetting its password are always refused. It is hidden from the REST API, the users sitemap and author archives, and marked “Pułapka EyeSite” in the Users list. Its login exists only in your database, so a login attempt or a password-reset request for it means someone has read the database; you are alerted at once. The plugin also adds one Disallow line with a random path to the virtual robots.txt: only bots that ignore robots.txt visit it, which helps tell targeted login attempts from background noise. Switching the option off or uninstalling the plugin deletes the account.

Tracking tag detection (Google Tag Manager, Google Analytics, Meta Pixel, etc.), SSL certificate, SEO, checkout and hardening checks only read your own site (loopback requests to your home page, robots.txt, sitemap, cart and REST endpoints). The plugin does not load, call or send data to these services. The e-mail DNS check (SPF, DKIM, DMARC, MX) uses your server’s normal DNS resolver.

The EyeSite service (eyesite.pl) and its automation backend (n8n.bielecki.cloud) are provided by Bielecki Consulting. Terms of use and privacy policy:

• Terms of service: https://eyesite.pl/regulamin/
• Privacy policy: https://eyesite.pl/polityka-prywatnosci/

Privacy

Visitor data stays on your site. The plugin stores in your site’s own database: for a front-end error (a JavaScript error) the error message, script source and stack trace; for a contact-form submission whether it succeeded; for a visitor who leaves the WooCommerce cart or checkout page with products in the cart the cart total and whether a technical error happened. Each record also has the page URL, browser and device type, the user-agent string and a random session identifier. It does not store IP addresses, cart contents or customer details, and none of this data is sent to EyeSite or any other service.

Form copies (on by default only on connected sites, can be switched off): each contact-form message is also kept encrypted on your own server for 30 days, so an enquiry is not lost when e-mail fails. Copies never leave your site.

Visit statistics: daily page-view totals stored on your site only, without cookies.

Cookie: the browser sets a first-party cookie eyesite_session holding a random identifier, valid for 30 minutes, only when one of the events above happens: a JavaScript error, a contact-form submission (successful or not), or leaving the cart or checkout page with products in the cart. It is used solely to group these reports from the same visit and is never sent to EyeSite. Pages viewed without any of these events never set it, so full-page caching is not affected. Treat it as a functional cookie in your consent banner.

Retention: records are deleted automatically after 60 days, resolved errors after 3 days. Uninstalling the plugin removes its tables and options.

The plugin adds a suggested paragraph to Settings -> Privacy -> Policy guide that you can copy into your privacy policy.

1. Upload the plugin folder to the /wp-content/plugins/ directory, or install it from the WordPress admin under “Plugins” -> “Add New”.
2. Activate the plugin from the “Plugins” menu in the admin panel.
3. Open the Eyesite menu to view monitoring results and the API credentials.

1. 

   Dashboard view with system monitoring status tiles.

2. 

   PHP error history.

3. 

   List of recorded front-end errors with form context.

8.8.60

• New: when a contact form shows an error (or an anti-spam plugin blocks it), what the visitor typed is saved as an encrypted form copy, so you can still get back to them. Failed attempts raise the “someone tried to contact you” alert; anti-spam blocks are kept for review without an alert. Passwords, card fields and technical fields are never saved.

8.8.59

• Fix: form submissions blocked by an anti-spam plugin (for example CleanTalk) are no longer counted as sent forms in traffic stats and reports.
• Change: conversion rate is shown from 10 visitors in the period (was 30).

8.8.58

• Change: the first check is no longer completely silent. Serious findings (changed WordPress core files, a publicly downloadable backup or configuration, high or critical vulnerabilities) are e-mailed once as a first review; minor findings stay in the panel only.

8.8.57

• Fix: compiled template caches that plugins write themselves (for example ReviewX storage/cache/views, Laravel storage/framework/views) are no longer reported as new files; a cached template with suspicious code is still reported.

8.8.56

• Change: a publicly downloadable backup now has a “I removed it, check again” button that re-checks the files at once (instead of “these are my changes”), and the panel says to change the database password and administrator passwords afterwards.

8.8.55

• Change: the public backup check looks first in the folders used by backup plugins (WPvivid, UpdraftPlus, All-in-One WP Migration, Duplicator, Backup Migration, BackWPup and others, also the folder set in UpdraftPlus and WPvivid), then in the site root and its subfolders, and only at the end in uploads, where it reports only database dumps and files named as backups. It asks about the newest one or two files per folder, retries when the host answers 429, and recognises backups by their first bytes, so error pages and JSON answers are never reported.
• Fix: “Refresh data” in the panel showed a blank page on servers without output buffering.

8.8.54

• New: the “Backups or configuration publicly available” check now also finds backup files with any name (for example WPvivid, UpdraftPlus or Backup Migration archives, .sql dumps, copies of wp-config) on the server and checks whether they can be downloaded from the internet, also when the folder listing is switched off. Ordinary zip files meant for download are not reported.

8.8.53

• Fix: the one-time switch-on of the three checks on older connected sites (8.8.52) did not run.

8.8.52

• Fix: sites connected to EyeSite before version 7.8.3 now get the vulnerability, domain and speed checks switched on once (connecting is already the consent); checks switched off on purpose stay off. The “the plugin can watch 3 more things” card no longer shows on connected sites.
• Change: the review request after a fixed problem now says what fixed it (for example the XML-RPC block and how many login attempts stopped), and is not shown when a problem went away on its own.

8.8.51

• Fix: visits through a hosting preview domain (Hostinger *.hostingersite.com) were treated as a site address change, which wiped check results, the score history and the event log on every such request and could send a false “problem gone” email. Preview requests are now ignored, and a second address change within 6 hours no longer resets anything.
• Fix: “Someone is trying to guess the password” now follows the actual login attempt statistics. It stays for 7 days after the alert and longer while attempts are still above the alert threshold, instead of disappearing when the alert entry leaves the event log.

8.8.50

• Change: the review request card after a fixed problem is titled “Problem rozwiązany” with the name of the problem and the date it was fixed.

8.8.49

• New: a short request for a review on wordpress.org, shown only in the EyeSite dashboard and only to administrators, at a moment when the plugin has helped: right after a one-click fix, after updating a plugin or theme with a known vulnerability, or after a detected problem has been fixed (at least 7 days after installation). “Maybe later” postpones it by 30 days, and after the second postponement it is not shown again.

8.8.48

• Docs: the plugin description now starts from the problems it catches (a store that stops selling, a contact form that stops sending, a site that goes down) instead of a generic feature list.

8.8.47

• Fix: visits of the EyeSite form test browser (“mystery shopper”, cookie eyesite_formtest) are no longer counted in traffic statistics and are not recorded by visitor behaviour analysis.

8.8.46

• Change: in the one-off “Zaawansowana analiza klientów” e-mail, numbers in the conclusions (for example “7 z 12”, “15 sekund”) are highlighted in purple so they are easier to spot.

8.8.45

• Change: the monthly report again lists the five most viewed pages and the five main traffic sources with numbers, one below the other so they fit on a phone.

8.8.44

• Change: new monthly report layout that fits phone screens (Gmail no longer shrinks it): dark header with a one-line availability summary and 30 thin day bars, site status listed row by row, fixed problems, short list of recommendations, traffic in one box, and a plan Alarm box with a 30-day free trial. Nothing in the report forces a width wider than the screen.

8.8.43

• New (forms and mail reliability): a diagnostic report for EyeSite form and mail alarms (monitor API, token protected): the outage timeline, the message the visitor saw, how often the site normally receives submissions (per 7/30/90 days, typical and longest gap, whether the current silence is normal for this site), mail status, form e-mail copies (status only) and recently updated plugins. It contains no submission content, addresses or IPs.

8.8.42

• Fix: a single rejected Elementor submission without an error message (or with an anti-spam message) followed by a day without submissions no longer opens a form outage. Small sites often go several days without messages. A server error, a failed e-mail, or failures from two different visitors within a day still open it.

8.8.41

• Change: the one-off “Zaawansowana analiza klientów” e-mail no longer mentions recordings; it says only that conclusions come from anonymous visits and that IP addresses and form input are not stored.

8.8.40

• Fix: JetBackup stores its own settings in wp-content/plugins/backup/config/config.php; the file check no longer reports that file as changed. Changes to the plugin code itself are still reported.

8.8.39

• Fix: false “files changed on the server” alert (wp-includes/version.php) right after a WordPress update on sites installed from a translated package (for example en_GB). Checksums of the translated package appear on wordpress.org a few hours after the release; until then the check compares with the English package and now skips version.php, which differs there by one line.

8.8.38

• Fix: a contact form rejected by an anti-spam plugin (for example CleanTalk “*** Forbidden. Sender blacklisted ***”) is no longer treated as a broken form. Elementor shows that rejection the same way as a server error, so a single blocked spammer could open a form outage.
• New: when a form submission fails, the plugin stores the message the visitor saw (one line, up to 200 characters, e-mail addresses hidden). It is shown in the event log entry about the form outage and returned by the forms monitor, so an alarm tells whether the site broke or a sender was blocked.

8.8.37

• New: one e-mail when the first conclusions from visitor behaviour analysis are ready (usually 7-10 days after switching it on): “Zaawansowana analiza klientów” with the number of analysed visits, pages per visit and the conclusions (each finding in bold, followed by what to check). Sent once to the address given when connecting; later conclusions come in the monthly report. Conclusions calculated before the analysis was switched on (for example copied from a staging site) are not sent.

8.8.36

• Fix: the plugin’s own e-mails (security alerts, vulnerable plugins, reports, the first-day e-mail) go to the address given when connecting the monitoring, the same one that receives the EyeSite server alarms. Until that address is known (sites connected before this version or not connected), they go to the WordPress administrator address as before.

8.8.35

• Fix: the list of important events under “Co sprawdzamy” can be folded to its heading (“Zwiń” / “Rozwiń”); the choice is remembered in the browser.

8.8.34

• Fix: the changelog lists versions 8.8.27 to 8.8.33 again (no code changes).

8.8.33

• Fix: “Co sprawdzamy” cards: bold titles and a light background in the status colour (green, amber, red), otherwise unchanged.

8.8.32

• Fix: the “Co sprawdzamy” cards are back to their previous look (the 8.8.31 redesign is withdrawn). The buttons on the “Do zrobienia” list stay.

8.8.31

• Fix: every item on the “Do zrobienia” list has its own button. Changed files, PHP files in uploads, public copies and code in the database: “To moje zmiany” (the current state becomes the baseline, every next change is reported). A new third-party script: “To jest OK” (also for scripts added inside page content). Other recommendations: “Ignoruj na tej stronie”, remembered for the site; ignored items stop lowering the health score, leave the report and can be restored under the list. Urgent problems cannot be hidden for good (alarms must keep working); they get “Już naprawione? Sprawdź ponownie”, which re-runs all checks.

8.8.30

• Fix: the health score trend always ends with the score shown next to it (the daily point is saved once a day, so the line used to end on yesterday’s value and could point down while the score went up).
• Fix: after the site address changes (staging to production), the score history starts again instead of showing the staging site’s scores.

8.8.29

• Fix: Meta Conversion API is detected by what the site really sends. Every request WordPress makes to graph.facebook.com//events is noted locally (time, HTTP status and Meta’s short error message only, never the event data), so the analytics card shows “CAPI works, last event 2 h ago” or “Meta rejects the events: HTTP 400 (e.g. expired access token)”, for any plugin, theme code or custom solution. When nothing was sent for 7 days, detection falls back to known plugins and theme code.

8.8.28

• Fix: in the first-day e-mail a single short blip (under 3 minutes in 24 hours, usually a momentary network hiccup) no longer turns the e-mail into the “there was an outage” version; it is mentioned in one line instead.

8.8.27

• New: one e-mail a day after connecting the monitoring: how many times the site was checked in the first 24 hours, uptime and response time, which checks are in place (forms, e-mail, cart and payments, SSL certificate, plugins with known vulnerabilities, named), what happens when something breaks, and a link to the status page. Replies go to EyeSite. Sent once per connection, only for sites connected from this version on.
• Fix: after the site address changes (for example moving from staging to production) the plugin discards results collected under the old address and runs all checks again, instead of showing the staging data.
• Fix: the “Odśwież dane” button now re-runs every check in the background (e-mail, analytics, SEO, AI visibility, domain, certificate, vulnerabilities, forms, checkout), not just a few cached warnings. Results that are still valid stay on screen until the new ones arrive.
• Fix: “To jest OK, nie pokazuj” for signals the owner may know about: the Meta Conversion API row in the analytics card and the list of new third-party scripts. The choice is remembered for the site; a script from another new domain is reported again.
• Fix: Meta Conversion API is also recognised when it is hand-written in the theme or a must-use plugin (calls to graph.facebook.com/…/events), not only through known plugins. The scan is local and runs at most once every 6 hours.
• Fix: the checkout test also works in shops that sell only configurable products: it uses a fully specified variation (size, colour) when there is no simple product to buy.

8.8.26

• Fix: form submissions are also recognised by what the visitor typed (e-mail address or message) travelling in the request, so a server error is still caught for any form plugin and for external form services (HubSpot, MailerLite), while unrelated requests are ignored.

8.8.25

• Fix: a server error counts as a contact-form failure only when it comes from the request that actually submits the form (the form plugin’s own endpoint or the form’s action address). Errors of unrelated requests made shortly after a submission (chat widgets, newsletter pop-ups, statistics) no longer raise form alarms.

8.8.24

• Fix: fewer false “contact form not working” alarms. EyeSite’s own requests (scanner, speed test, visit counter) and the EyeSite scanner forms no longer count as contact-form submissions, and a single server error within 2 minutes after a successful submission (double click, momentary hiccup) no longer opens an outage after a quiet day.

8.8.23

• New: security e-mails offer a one-click order for busy owners. Under the main button of the vulnerable plugins e-mail there is a “Let us update it” link (79 PLN net, within 1 business day); the suspicious files e-mail offers a free quote. The link is signed with the site’s API key and opens a confirmation page on the EyeSite service; nothing is ordered without pressing the button there.

8.8.22

• Fix: a copy of the site (e.g. a staging clone with the same database) can no longer disconnect the real site from monitoring: the disconnect request now carries the site’s domain and the EyeSite server ignores requests from a different domain.

8.8.21

• Fix: the mystery-shopper form test reroutes e-mail and blocks integrations only in the request that submits data (POST); simply loading a page with the test cookie changes nothing.
• Fix: honeypot (trap account) alarms at most once per hour per type, further attempts are only logged; the alarm waits at most 5 s for the EyeSite server.
• Performance: with a persistent object cache (Redis, Memcached) visit statistics are buffered in memory and written to the database at most once a minute or every 50 visits.

8.8.20

• Fix: honest e-mails when a suspicious file problem disappears. If the files are still there but are now recognised as safe (e.g. Sucuri logs), the e-mail says it was a false alarm and apologises. If the files were removed, it no longer says “good news”: it says we do not know who removed them, lists what we checked (core and plugin files, new administrators, logins from new places) and what to do if it was not you.
• Improvement: the real EyeSite logo in all plugin e-mails (served from your own site, nothing loaded from other servers); one header for alerts, vulnerability e-mails and reports; clearer “problem solved” wording.

8.8.19

• Fix: no false “files changed” alarm for protected data files in uploads (Sucuri logs, Smush logs) that start with a die/exit guard and contain no further PHP code, also for large files.
• Security: a stub file whose line comment is followed by PHP code on the same line is no longer treated as empty.

8.8.18

• Change: shorter privacy wording in the readme (WordPress.org description limit).

8.8.17

• Fix: fewer false alarms. The daily form display check treats firewall answers (401, 403, 429, 503, Cloudflare challenge pages) as inconclusive instead of “form broken”. An e-mail outage opens only after two failures at least 5 minutes apart, and an administrator testing SMTP settings in the dashboard no longer counts.
• Change: encrypted copies of contact-form submissions are on by default only on sites connected to EyeSite; the Privacy section now describes them and the visit statistics.
• Fix: compatibility with PHP 7.2 (no array_key_first()).

8.8.16

• New: mystery-shopper cleanup works with any form plugin: during a signed test request the plugin records which third-party tables receive new rows and afterwards deletes only the new rows that carry the test’s unique number (plus new posts with that number). Sites without a recognised form plugin offer the contact page (or home page) for the test.

8.8.15

• Improvement: mystery-shopper form test hardened: runs only on sites that opted in (eyesite_formtest_enabled), accepts results only for tests the site actually handled, a first failed test is a suspicion with an automatic retry (alarm only after a second failure), background self-requests and form-plugin queues stay blocked while SMTP plugin queues are allowed, detection starts on plugins_loaded, cleanup runs only after a real submission. Panel shows a failed-and-retrying or inconclusive test plainly.

8.8.14

• Improvement: test-entry cleanup also covers MetForm (ElementsKit forms in Elementor); entries are deleted one by one with prepared queries (no warnings in WordPress Plugin Check).

Older versions: see changelog.txt in the plugin folder.