juhl

@hristo-sg @stinamariechris @sageallott

The only work around we found is to install the SG Optimizer plugin and disable Dynamic Cache and memchached in the plugin. We use WP Rocket for speed optimizations vs the SG Plugin, so all other features are disabled as well.

Since SiteGround will not acknowledge this issue we are moving to WP Engine for hosting.

@grailpr I was looking in the wrong place. To customize the popup display rules, conditions, design etc. it is available only when creating/editing a Popup. So it is specific to each popup created. You do have the option to clone a popup if you want to reuse all of the same designs that you created in an existing one.

@hristo-sg Can you please read back through this thread and our shared experiences with this issue? If SG ignores everything in the UTM then functional or tracking parameters would both be ignored? We still do not understand what you are referring too as functional parameters since everything is passed within the UTM code.

@stinamariechris I doubt I can do that against live (reenabling Dynamic Cache) since we have had 5 outages with this redirect loop issue. We cannot reproduce the error in staging which makes it very hard to find a fix without a potential impact to production.

I do see a correlation but would really like SG to confirm and provide a potential reason.

@stinamariechris Our FB campaign (below) also has a lot more spaces than Google campaigns hitting the site. So if we rule out gclid and fbclid and your fix was removing keyword due to spaces in the UTM parameters that would seem to narrow down the potential cause to either URL length or spaces although does not answer the why? Especially since per SG they “ignore” tracking parameters.

I wonder if we change to dashes vs. spaces that would potentially fix the issue? I cannot ask the Ad agencies to remove or change how they track campaigns because it is not an issue on WPEngine. Ultimately we may need to just change hosting providers to fix “our problem”.

&utm_campaign=HLMS%20-%20No%20Program%20-%20Traffic%20-%20On%20Going%20Nurturting
&utm_term=HLMS%20-%20On%20Going%20Nurturing%20-%20Allied%20Health%20and%20Cosmo

@stinamariechris After looking at it further I believe they are referring too fbclid and gclid or other “functional” tracking codes, not the PHPSESSID/cookies? So including a Hubspot tracking ID in your UTM parameters (i.e. Hubspot visitorID) vs relying on tracking pixels to show visitor attribution specific information based on cookies.

I have other tracking codes that include Google gclid but the one that is always involved with an issue is actually a Facebook UTM code. Facebook does have a much larger clid ID (206 characters) than Google (97 characters) but I’m not sure that is a factor.

Did this issue get resolved?

We are experiencing the same problem which only started after being migrated to NGINX. The response from support seems too vague to be actionable. Because the new Caching method does not use Vary:User-Agent, I believe this may be a factor in these new caching issues. I am trying to determine which functional tracking parameters they are referring too (i.e. PHPSESSID or Cookies)?

I am not sure how anyone can say it is not our problem because they cannot recreate it, especially when it directly correlates to the migration to NGINX and caching changes?

I updated to 3.76, cleared cache and still have the issue. Please let me know how I can send you a screenshot.

Changing to another theme and back again corrected the issue for me.