Wp-rocket: Cache de string de consulta com parâmetro ignorado

Criado em 9 out. 2018  ·  4Comentários  ·  Fonte: wp-media/wp-rocket

Com base nesta página , existem parâmetros que são ignorados por padrão. Por exemplo, gclid é um deles. De acordo com essa mesma página, também é possível armazenar em cache strings de consulta. O exemplo dessa página mostra country como exemplo.

Pelo que entendi, o seguinte URL:

http://www.mysite.com/?country=canada&gclid=1234

... deve ignorar o parâmetro gclid e servir o arquivo de cache de country=canada . Este arquivo deve estar localizado em:

wp-content/cache/wp-rocket/www.mysite.com/?country=canada/index.html

Em vez disso, ele está localizado em:

wp-content/cache/wp-rocket/www.mysite.com/?country=canada&gclid=1234/index.html

Isso significa que gclid=1234 não é ignorado quando combinado com uma string de consulta em cache como country .

Estou esquecendo de algo? Estou codificando as regras do Rocket-Nginx e quero ter certeza de que entendi a lógica corretamente. Pelo que entendi, isso é um bug. É isso?

cache low bug

Todos 4 comentários

Ele será ignorado se for o único parâmetro de string de consulta no URL. Nesse caso, o processo continua e a versão do cache padrão é usada.

Se houver outro parâmetro de string de consulta que deva ser armazenado em cache, o URL usado para o cache ainda será o completo, incluindo todos os parâmetros de string de consulta.

É confuso e não ideal, eu concordo. Parâmetros ignorados provavelmente devem ser removidos do nome do arquivo do cache em todos os casos para evitar isso.

Concordo totalmente que é confuso e não ideal. A maneira como você descreve o que é feito é exatamente como eu entendi.

Isso torna o cache inútil na maioria dos casos. Isso deve ser sinalizado como um bug e corrigido, IMHO.

Além disso, por que todos os 3 parâmetros utm_ * devem ser considerados?

Acredito porque se o 3 for definido, podemos saber com certeza que é para campanhas e podemos ignorá-los com segurança. Mas agora existem outros parâmetros também, então isso também precisa ser melhorado.

Parece ser um caso semelhante, no entanto, o usuário não estava armazenando em cache nenhuma string de consulta. O armazenamento em cache foi inesperado e causou alguns problemas:

https://secure.helpscout.net/conversation/691607800/83647?folderId=1391600

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

Tabrisrp picture Tabrisrp  ·  5Comentários

webtrainingwheels picture webtrainingwheels  ·  5Comentários

crystinutzaa picture crystinutzaa  ·  4Comentários

NataliaDrause picture NataliaDrause  ·  4Comentários

Screenfeed picture Screenfeed  ·  5Comentários