thekatbrady

I’ve been trying to email the address as you typed it above and they keep bouncing. Is the email correct?

Yes, we already have our debug logs turned on.

These are the logs from yesterday around the time of our last round of dupplicate submissions. These are the only logs from yesterday. Please provide an email so that we can send the entire log.

[2023-08-27 07:46:49] Refresh Token:.INFO: Refresh token triggered [] []
[2023-08-27 07:46:50] Refresh Token:.INFO: Old Refresh Token: LijYOP29*** [] []
[2023-08-27 07:46:50] Access Token:.INFO: Old Access Token: eyJraWQi*** [] []
[2023-08-27 07:46:50] Refresh Token:.INFO: Refresh token successfully received [] []
[2023-08-27 07:46:50] Refresh Token:.INFO: New Refresh Token: SoCrbfNW*** [] []
[2023-08-27 07:46:50] Access Token:.INFO: New Access Token: eyJraWQi*** [] []
[2023-08-27 07:46:50] Expires in:.INFO: Expiry: 86400 [] []

Every form on our site is powered by Constant Contact.

Disabling the notifications is not an option we have.

Used to be once a month. Has increased to once a week or more since the last update.

I’ll inquire with my Host again but the fact that the issue increased more after the last update I feel points more to the pluggin.

Thank you.

Hi,

A few points of clarification.

1. This occurs for all of the forms on our site.
2. The Javascript functionality you mentioned works and is not related to this issue.
3. Unsure about that. In previous threads the support team mentioned that this was a bug that they know about but have no solution for. Also, in previous threads, other users of the pluggin mentioned a similar issue. For reference, this site is using Godaddy’s WordPress hosting. We have other plugins with email functionality as well and this is the only one with this issue.

Thank you.

Thank you.

The solution that I was able to arrive at with Godaddy was to disable their CDN as they do not allow for the types of settings you suggested; a very frustrating thing. Obviously not the best solution to disable a CDN but these issues only seem to be troublesome in environments like Godaddy which severely limit control.

Thank you again and I will be closing this thread.

Godaddy’s WordPress hosting does not have such an option; the information you gave is related to their standard hosting. Their support is also, at least has been, resistant to change anything related to the caching for my account.

• This reply was modified 1 year, 11 months ago by thekatbrady.

Quick note:

To restate what the issue is: on Firefox and Safari, after editing event entries, the “Next” and “Previous” button on the List view on the frontend doesn’t work and the console shows a 403 error.

Our current solution: Flush the server side cache set up by our host Godaddy (WordPress hosting plan).

This solution occasionally doesn’t work. In that case we need to: Ask the user to clear their browser cache.

So our current “solution” doesn’t work all the time and in that case we need to ask the user to clear their cache. This ALWAYS works but is clearly not a sustainable solution.

Thank you.

Hi Darian,

I’d like to reopen this thread as this issue is still ongoing. Communicating with Godaddy’s support, and information gathered from here, we identified the issue as being related to Godaddy’s caching service and security. Unfortunately, the only solution they gave us was to clear the server cache after each update. While this works most of the time, it does not work all of the time.

I noticed a fix in the latest updates that seems related to this issue: Fix – Fixed a situation where an invalid request header in our pagination would cause some strict security settings to block these AJAX requests. [TEC-4723]

As this seemed to describe an aspect of the issue I’m seeing I was hopeful for a resolution, however, my client has still seen this issue since the updates.

Wanted to reopen this to see if there might be any additional insights. My clients are getting antsy and want to move away from this plugin after years of dealing with this issue (they had been experiencing the same bug on a previous version of their site before me). This issue is likely affecting everyone using this plugin and Godaddy’s WordPress hosting.

Side note: I had opened up a separate thread inquiring about a way to disable AJAX. Allowing for that in settings seems like it may be a good way to address edge cases like this.

• This reply was modified 1 year, 11 months ago by thekatbrady.

Ok, so no easy way to do this then. Not a personal fan of directly editing plugin files so I’ll pass on this solution.

Is there any plans on giving control of whether or not to use AJAX in the settings? I can see many use cases where disabling AJAX would be useful and there’s easy solutions to do this with comparable plugins.

Thank you for your very detail response.

Just set up a staging site using the same server and settings. Strangely the issue was not recreated.

The main site, and Staging, are hosting on Godaddy’s WordPress hosting. This includes a site cache that Godaddy set up. Would caching be causing this issue?

Hi @d0153 ,

Apologies for the delayed response. I wanted to give the issue a week to see what it pattern was. What I found is that it comes and goes at random intervals but seems to be consistent for all users accessing the site at a given time. That is to say, that around the time you posted your reply my clients were also reporting it working but then later in the day that wasn’t again. Currently I am seeing the error in Safari and Firefox but not Chrome.

I will be conducting a conflict test soon but wanted to get this information to you first. I’ll post my results when ready.

PHP: 8.0

WordPress: 6.1.1

Theme: Gutenix 1.1.5

Thank you for the reply. I will let you know if I find any etiology to this weirdness.

Thank you for the reply. Unfortunately this development is only being done locally currently. If there’s any other way to provide information you need I will get it to you.