Troubleshooting
System report and activity log
System report
The About tab in Wynko’s settings runs a diagnostic check against your WordPress, PHP, database, and server environment — comparing them to the versions the plugin is tested against — and is downloadable so you can attach it to a support request. A version below what’s tested shows as a warning, not a failure: Wynko tries not to block you over something that might still work fine.
The report also reads your caching and security posture, so a caching-related support question starts with visibility into what’s running:
- Page caching — whether a page-caching drop-in is active, named where Wynko can identify it (WP Super Cache, WP Rocket, W3 Total Cache, LiteSpeed Cache, and others).
- CDN / proxy — a fronting CDN or reverse proxy guessed from request headers (Cloudflare, Sucuri, KeyCDN, and others).
- Signup form protections — nonce verification and rate limiting on or off, the configured rate limit, and current per-form window usage.
- Whether a database-stored API key is encrypted.
Each is a plain on/off reading next to the version rows. See Page caching and CDNs for what to do with them.
Activity log
Every connection check, sync, and signup attempt is recorded in the
activity log, filterable by level (error, warning, info) and
exportable as a .txt file. If something is failing silently, this is
the first place to look — start with Error-level entries.
Critical email alerts
If you’d rather be notified than have to go check, turn on critical email alerts and add recipient addresses in Wynko → Settings → Notifications. Wynko mails you when an error is logged, capped at one email per hour per site.
Common issues
"Invalid API key"
The key is checked live against Laposta on save; double-check you copied the whole key with no surrounding whitespace.
A form stops accepting signups
Check the activity log for a rate-limit warning; the per-form cap is a high catastrophe backstop, so hitting it usually means unusual traffic rather than normal use.
A list disappeared from Laposta
Wynko names the list by the name it last saw, rather than an opaque ID, and reports it once so the alert doesn't repeat on every sync.
A form rejects a submission that looks correct
The form's cached field definitions may be a step behind a recent change in Laposta. This self-corrects: the failed attempt triggers an automatic resync, logged in the activity log, and the visitor's next attempt is validated against the current definitions.
"…carried an outdated field fingerprint…" in the log
A page cache or CDN is serving a copy of a form page from before a new optional Laposta field was added. Nothing is broken; purge that page from your cache to pick up the new field. See Page caching and CDNs.