بناءً على هذه الصفحة ، هناك معلمات يتم تجاهلها افتراضيًا. على سبيل المثال ، gclid
واحد منهم. وفقًا لنفس الصفحة ، من الممكن أيضًا تخزين سلاسل الاستعلام مؤقتًا. يُظهر المثال الموجود في تلك الصفحة country
كمثال.
مما أفهمه ، عنوان URL التالي:
http://www.mysite.com/؟country=canada&gclid=1234
... يجب تجاهل المعلمة gclid
وتقديم ملف ذاكرة التخزين المؤقت من country=canada
. يجب أن يكون هذا الملف موجودًا في:
wp-content/cache/wp-rocket/www.mysite.com/?country=canada/index.html
بدلاً من ذلك ، يقع في:
wp-content/cache/wp-rocket/www.mysite.com/?country=canada&gclid=1234/index.html
هذا يعني أنه لا يتم تجاهل gclid=1234
عند دمجه مع سلسلة استعلام مخبأة مثل country
.
هل فاتني شيء؟ أنا أقوم بترميز قواعد Rocket-Nginx وأريد التأكد من أنني أفهم المنطق بشكل صحيح. مما أفهمه ، هذا خطأ. فعلا؟
يتم تجاهله إذا كان هو المعامل الوحيد لسلسلة الاستعلام في عنوان URL. في هذه الحالة ، تستمر العملية ويتم استخدام إصدار ذاكرة التخزين المؤقت الافتراضي.
إذا كان هناك معلمة سلسلة طلب بحث أخرى يجب تخزينها مؤقتًا ، فسيظل عنوان URL المستخدم لذاكرة التخزين المؤقت هو المعامل الكامل ، بما في ذلك جميع معلمات سلسلة الاستعلام.
إنه أمر محير وليس مثاليًا أتفق معه. ربما يجب إزالة المعلمات التي تم تجاهلها من اسم ملف ذاكرة التخزين المؤقت في جميع الحالات لمنع ذلك.
أوافق تمامًا على أنه أمر محير وليس مثاليًا. الطريقة التي تصف بها ما تم فعله هي بالضبط كيف فهمت ذلك.
يجعل ذاكرة التخزين المؤقت عديمة الفائدة في معظم الحالات. يجب أن يكون هذا علامة على أنه خطأ وثابت ، IMHO.
أيضًا ، لماذا يجب مراعاة جميع معلمات utm_ * الثلاثة؟
أعتقد أنه إذا تم تعيين الثلاثة ، يمكننا أن نعرف على وجه اليقين أنها للحملات ويمكننا تجاهلها بأمان. ولكن هناك الآن معلمات أخرى موجودة أيضًا ، لذلك يحتاج هذا أيضًا إلى التحسين.
يبدو أنها حالة مشابهة ، ومع ذلك ، لم يكن المستخدم يخزن أي سلاسل استعلام مؤقتًا. كان التخزين المؤقت غير متوقع وتسبب في بعض المشكلات:
https://secure.helpscout.net/conversation/691607800/83647؟folderId=1391600