URL 字符串中包含“utm_”會破壞 Wordpress 中的 $_GET 變量

Question

第一個注意事項：該站點托管在 WPEngine（清漆緩存）上，但我似乎無法在另一台服務器上復制該問題。

我們需要能夠訪問某些頁面上的 $_GET php 變量。 為了測試，我修改了我們的 Wordpress header.php 在第一行做一個 var_dump。

通常，一切正常。 但是，如果 URL 字符串包含“utm_”，則 $_GET 中的每個后續變量都會被剝離。 更奇怪的是，如果我登錄到 Wordpress，一切正常。

我們的 Paypal 返回 URL 如下所示：

http://oururl.com/buy/thankyou/?utm_nooverride=1tx=xxxxyyyy ...

utm_nooverride 導致 $_GET 為空數組。 如果我將其更改為“test=1&tx=xxxxyyyy”，則它可以正常工作。 如果我使用“utm_test=1&tx=xxxxyyyy”，我會再次得到一個空數組。

.htaccess 中沒有什么奇怪的，只有幾行標准的 Wordpress 行。

托管中是否有某些原因導致了這種情況？

Answer 1

如果其他人遇到同樣的問題，就像我剛剛做的那樣，我通過實時聊天和 WPEngine 支持團隊進行了交談。 他們在幾分鍾內糾正了它

這是我們聊天的簡短記錄：

• 我：我正在嘗試將一些 GET 變量放入 cookie 中，當訪問 $_SERVER['REQUEST_URI'] 全局變量時，它似乎適用於任意變量（如 my_name=bob），但出於某種原因，任何以“ utm_" 在查詢字符串中被刪除。 好像是你這邊的 php/cache 配置，你知道嗎？
• WPE：好問題； 不幸的是，我不知道有什么會自動去除查詢中的特定參數。 讓我和一些同事一起回顧一下。
• 我：k。 僅供參考，這里有一個堆棧溢出問題http://stackoverflow ...-the-get-variable-in-wordpress。 似乎也得到了其他人的經驗的證實： https ://twitter.com/…ey01/status/555584796785528832
• WPE：這是為了您的安裝：？
• 我可以
• WPE：我可以請你現在試試嗎？
• 我：好的，現在可以了。 問題是什么？
• WPE：太棒了！ 問題是我們默認去掉了“utm_”參數。 我很抱歉沒有意識到您建議的 arg。 我不得不從我們的緩存系統中排除這個參數。
• 我：好的，所以我自己不可能做到這一點，對嗎？
• WPE：沒錯。

參考鏈接： https : //wpengine.com/support/utm-gclid-variables-caching/

Answer 2

WP 引擎可能（錯誤）配置了 Varnish，以在它們引用 Google Analytics 活動變量時忽略查詢字符串參數。 他們可能已經這樣做了，以便他們可以在沒有查詢字符串的情況下引用頁面的緩存，因為活動變量是由分析提供商在客戶端（而不是服務器端）讀取的。 因此，在服務器端忽略這些變量表面上沒有任何影響，並且會提高大量使用入站 Google Analytics 跟蹤的網站的性能。

我說這是可能的，因為有一個 Stack Overflow 問題詢問如何做到這一點： “剝離選擇的查詢字符串屬性/值對，以便清漆不會因它們而改變緩存” 。 確定的唯一方法是聯系 WP Engine。

Answer 3

我目前正在與 WPEngine 聊天，希望能解決這個問題。

WPEngine 的 varnish 緩存實際上去除了 utm_ 和 gclid_ 參數以改進緩存。 可悲的是，在識別第一個 utm_ 或 gclid_ 參數后，WPEngines 實現此“功能”會刪除所有后續查詢參數。

例如 URL： www.example.com/test/?foo=bar&utm_source=email&page=1

您希望您的服務器收到什么： www.example.com/test/?foo=bar&page=1

您的服務器實際收到的內容： www.example.com/test/?foo=bar

請注意 page=1 參數是如何刪除的，即使它不是 utm_ 或 gclid_ 參數。

WPEngine 建議的解決方法是將 utm_ 和 gclid_ 應用於緩存排除列表，但這意味着如果您的 url 中有 utm_ 或 gclid_ 參數，則不會提供緩存。 這似乎不太理想，因為 URL 有一個 utm_ 或 gclid_ 參數，它很可能來自電子郵件，並且發送大量電子郵件意味着流量激增，而這正是您想要提供緩存頁面的時候。

下面是一些 javascript，它檢測 utm_ 或 gclid_ 是否在 URL 中，如果是，它會重新排列 url，以便 utm_ 和 gclid_ 參數位於查詢字符串的末尾，然后觸發頁面重定向。 下面的代碼專門查找名為 tfa_next 的參數，該參數是通過 FormAssembly 重定向添加到 URL 末尾的參數。 下面的代碼可以改進為更通用，但我希望它可以作為任何需要它的人的起點。

const params = new URLSearchParams(window.location.search);
var newParams = "";
console.log("This is working");
if(params.has('tfa_next')){
  console.log("it has a tfa_next param");
  if(window.location.href.includes("UTM_") || window.location.href.includes("utm_") || window.location.href.includes("GCLID_") || window.location.href.includes("gclid_")){
    console.log("it has a utm param");
    var count = 0;
    for(const [key, value] of params) {
      if(count == 0 && key == "tfa_next"){
        break;
      } else {
        count += 1;
      }
      if(key.includes("UTM_") || key.includes("utm_") || key.includes("GCLID_") || key.includes("gclid_")){
        newParams = newParams + key + "=" + encodeURIComponent(value) + "&";
      } else {
         newParams = key + "=" + encodeURIComponent(value) + "&" + newParams;
      }
      console.log("NewParams: " + newParams);
    }
    if(newParams.slice(newParams.length - 1) == "&"){
      newParams = newParams.slice(0, newParams.length - 1);
      console.log("final query string: " + newParams);
    }
    if (count > 0) {
        console.log("end result: " + window.location.protocol + "//" + window.location.hostname + window.location.pathname + "?" + newParams);
     window.location.replace(window.location.protocol + "//" + window.location.hostname + window.location.pathname + "?" + newParams);
    }

  }
}