• I received this email multiple times: We have detected connection errors for your site [site URL]. Potentially a failed signup has been detected and will be retried automatically once a new connection has been established. Otherwise, issues with token refreshing have been detected. Please visit your site and perform the steps to reconnect the plugin at your earliest convenience.

    I’ve reconnected the site with the application authorization code just 3 days ago after the first error and it disconnected again.
    Plugin is Version 2.19.0 running wordpress 6.9.4

    Here are the logs from the last two days.

    [2026-5-17, 14:07] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-17, 14:09] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-17, 15:25] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-17, 19:17] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-17, 21:05] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-18, 00:09] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-18, 00:40] API.INFO: A failed API attempt was caught and will be retried after reconnection. [] []
    [2026-5-18, 13:02] Refresh Token:.INFO: Refresh token triggered [] []
    [2026-5-18, 13:02] Refresh Token: .INFO: Old Refresh Token: vnzI0FJ1* [] [] [2026-5-18, 13:02] Access Token: .INFO: Old Access Token: eyJraWQi* [] []
    [2026-5-18, 13:02] Refresh Token: .INFO: Refresh token successfully received [] []
    [2026-5-18, 13:02] Refresh Token: .INFO: New Refresh Token: voeqlOBJ* [] [] [2026-5-18, 13:02] Access Token: .INFO: New Access Token: eyJraWQi* [] []
    [2026-5-18, 13:02] Expiration time:.INFO: Current time: 2026-5-18, 09:02 Estimated expiration time: 2026-5-19, 09:02 [] []

Viewing 2 replies - 16 through 17 (of 17 total)
  • From what I can tell all users are logged in at https (the site naturally redirects to this / this is set as the site_url in the options table). Not sure how the initial storage of http is happening, but in our case the stored hash is being generated without https. I’ll confirm with webmasters that they are using https- is there some way that it could be the inverse and the initial token is saved with https but a cron based token refresh would happen over http and the hash would break then?

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    @matthensley

    Just for sake of separation of threads between people, would you be willing to create a new thread for your findings specifically?

    We’ll respond/cross-post etc there to make sure yours and my conversation is preserved.

    Definitely possible that something with cron could be occurring, and I’m wondering at the moment if we could somehow seamlessly transition to perhaps not using http/https in the stored values in a future release.

Viewing 2 replies - 16 through 17 (of 17 total)

You must be logged in to reply to this topic.