This suddenly stopped working. We have Google Analytics on our page and a couple of months ago we tweaked the code so that GA's cookies would only be set for www.igre123.com and not it's subdomains (we do a redirect from igre123.com to www.igre123.com, so that users are always using www.).
We did this because we have two subdomains that serve static content (css, js, thumbnails, etc) from (s.igre123.com and static.igre123com).
To prevent cookies being set for the subdomains (and only for www.) we modified our GA code to look something like this:
...
_gaq.push(['_setDomainName','www.igre123.com']);
_gaq.push(['_trackPageview']);
...
This did the trick but now it's not working anymore. Anybody have some idea why this stopped working? Unfortunately I don't know when exactly this stopped working :/
edit: tracking otherwise works without a problem.
OK after much head banging I managed to solve this mystery. Turns out that the order of the _gaq.push([]);'s is relevant. If you have, besides the usual _setAccount and _trackPageView, any other GA calls (like _setCustomVar), that set cookies, you have to tell GA which domain to set cookies for first. Seems obvious in retrospect but to be fair, that's not really clear from the documentation.
Anyhow be sure to put the call to _setDomainNamefirst, and then any other GA calls you might have.
Related
I am looking for some way how to save exact cookie in Cypress through whole test case.
Was using
Cypress.Cookies.defaults({ preserve: 'cookie_name' })
and
Cypress.Cookies.preserveOnce('cookie_name')
but this doesn't work anymore. And the new cy.session() is not working for me, because I use custom addresses per user and per new form.
Does anyone know of anything that works better than cy.session()?
The use pattern of cy.session() is a bit opaque, but since it replaces the older cookie config it probably can be made to work.
I have seen a note somewhere that session is likely to be revamped shortly.
Since Cypress.Cookies.preserveOnce('cookie_name') is deprecated but still available, maybe use that until session mark 2 comes along.
Where can I make changes if I want to make permanent changes in cookie-path value for my website. will that be in context.xml or web.xml or will that be using newCookie.setPath() method only? The server is Tomcat 6.0. I did look online but have not found anything, to the point.
Its just that there is some problem with the session tracking and admin thinks that this requires changing path of my session cookies from /site-folder to /. Is he wrong?
It might not be something considered good programming trick, but to change the sessioncookiepath value, web-app>METAINF>context.xml file is the place. For perticulary my problem, putting following code helped: Context sessionCookiePath="" This might be due to my website structure.
I've switched in my wordpress blog from urls like this:
/blog/2012/01/01/how-to-build-a-website
To shorter urls like this
/blog/?p=123
Wordpress has a search engine who works like this
/blog/search/?s=how to build a website
And search for the s params.
I'm trying to use .htaccess Redirectmatch to redirect all the old urls to the search url with the title of the post as the s params.
So if the user serf to
/blog/2012/01/01/how-to-build-a-website
should be redirect to
/blog/search/?s=how to build a website
I've coded this
Redirectmatch blog/\d+/\d+/\d+/(.+) http://www.mysite.com/blog/?s=$1
But this regex grap the whole string after the last / within the - symbol inside it.
In this way if a user serf to
/blog/2012/01/01/how-to-build-a-website
Will be redirected to
/blog/search/?s=how-to-build-a-website
while I want the user redireced to
/blog/search/?s=how to build a website
How can I write the regex to do this?
EDIT:
Yes guys, I know that this kind of urls are ugly :) But I just would know how to do it, because behind this there are some technical issues I'm trying to solve..
Please don't do this. I know it can seem tempting to go for short URLs; after all, you get things like TinyURL and such. Isn't it better to have /blog/?p=123 than /blog/2012/01/01/how-to-build-a-website?
No. It's not.
The reason is because when someone posts a link to your blog article, the longer URL means something. It tells the person how old the article is. It gives the title. It helps people find your article; after all, the URL is given a lot of weight by Google when indexing your site.
URLs used to be built for computers. Something like /blog/?p=123 is perfect for computers; it's easy to parse, it doesn't require any extra database lookups. You can write two articles named "How to Build a Website" and the blog engine doesn't have to make sure it adds a -2 on the second one. It maps easily to the actual structure of files on the server, without making up structure in the URL.
But we've realized since that URLs can be built for humans, too. The URL /blog/2012/01/01/how-to-build-a-website has a form that can be easily understood by humans. Sure, it's a bit longer to type, but all the bits you're typing are easier, and most URLs are copy'n'pasted anyway or just clicked on. It's more work for the computer, sure, but it's worth it. It makes the Internet friendlier.
So I'm sorry, but I won't help you. :)
I use both Google Analytics and Google Website Optimizer on www.britely.com, and want to limit their cookies to that domain only. (To avoid cookie overhead in requests for static assets loaded from other subdomains of britely.com that should get some CDN love.)
An example page that uses both (and that currently sets the __utma, __utmb, __utmc and __utmz cookies on .britely.com, instead of on the wanted www.britely.com), is http://www.britely.com/ninjamom/s-t-dogs-think
As far as Google's docs go, it seems that a _gaq.push(['_setDomainName', 'none']); call (or ditto 'www.britely.com' instead of 'none') at the top of the page should be enough to achieve this goal.
Somehow, it isn't. I think we used to have even more cookies set on .britely.com before I read through the source of GWO's siteopt.js, which doesn't seem to know _setDomainName. It's responsive to a page-global constant _udn declaring the cookie domain it should use though - so leading in the page with this, at least GWO's __utmx and __utmxx cookies are handled correctly:
<script>
var _gaq = _gaq || [], _udn = 'www.britely.com';
_gaq.push(['_setDomainName', 'none']);
</script>
I know the common way of fixing the cookie overhead issue is to serve static content from some domain entirely different from the one using GA and GWO. That is not the solution I seek.
Besides the above tweaks, the Google Website Optimizer control script also needs its own _gaq.push(['gwo._setDomainName', 'none']); call - similar to the GA one, which only seems to be system global, but isn't.
With the above setup, all cookies get scoped to www.britely.com except for the __utmx and __utmxx ones, which end up scoped to .www.britely.com for some reason. Good enough for me.
I am working on a DotNetNuke application using the iFinity URL Master module. (that may be irrelevant, as a solution may be platform independent)
What I have is a site with addresses based on language.
so
www.thesite.com/en/products/towels/redtowel
is the english version and
www.thesite.com/de/products/towels/redtowel
is the german version.
What I need to do is allow a user (who has already visited the site and set a cookie with their language) to be able to go to www.thesite.com/products/towels/redtowel and get to www.thesite.com/en/products/towels/redtowel if their cookie is set to english, and /de/products/towels/redtowel if it is set to german.
How would I do this?
if it was me and i didnt want to spend a lot of time programming I would look at something like this
http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=10059
then it could do a redirect based on the cookie - otherwise with iFinity I think you can do that sort of but not exactly. (I may be wrong on that - not a fan of iFinity url rewriter)