I am pretty damn pleased to finally be announcing the long awaited vBulletin upgrade.
This weekend we will be starting the process of upgrading to vBulletin 3.8.5.
As a result there will be a 2 hour maintenance outage from 1600 to 1800 on Sunday, AEST.
That’s Australian time. I’m going to leave it to the rest of you to figure out when that will be in your part of the world. 
so it will be (if I am not wrong) Sunday 6:00-8:00 A.M. GMT
I will be probably sleeping…
phew, I’m just back and I would be cold turkey - least I can sleep through it also 
It’s not going to make the place look really weird though, is it?
Another certain web design forum went through some upgrade (though it might have been to vBull 4) and it’s pretty unreadable for me now. And finding stuff when their old position had no problems is an unnecessary chore.
The best upgrades are the ones where you barely notice a change, except the little annoyances are gone : )
This will mostly be one of those. The changes from vBulletin 3.7.1 (what we’re running now) and 3.8.5 are mostly minor.
4.0 is a major update that will be a massive undertaking if and when we decide to take that plunge. I can promise it won’t be in the next few months, at least.
4.x is horrible, stay on 3.x 
Kevin did something go wrong with the upgrade? According to the footer we’re still running version 3.7.1
Not any more…
Just as scheduled, we’re done - upgrade complete!
There were some template changes made by the upgrade scripts in the process, and so some of our wonderful community-designed buttons have been replaced by vBulletin standard ones. This will be rectified over the next few days.
Please let me know if you find anything else weird or awry and I’ll do my best to sort it out.
Thank you for your patience!
Cool, I was wondering why that had suddenly happened. Glad to know they’re coming back. The SP fora look much nicer than other ones, so I hope that will continue into the future.
Jeesh, I also had to log in! It’s been so long since I did that, I couldn’t remember my login details. Took a while to dig them out, too.
this falls under the “weird” category
i thought i was having some problems with the forums not remembering me, requiring me to log in several times, despite the “Remember me” box being checked
i think that’s working okay now
but in the course of my investigation into the cookies, i discovered that logging on to sitepoint forums also creates cookies for the following domains:[list][]1and1.com[]live.com[]msn.com[]atdmt.com[]bing.com[]windowsmarketplace.com[*]zune.net[/list]
why is this? and how is it that you are able to set a cookie for other domains?
I don’t seem to get any of those cookies Rudy. I use a plug in (firefox) that lets me pick and chose what cookies to keep and which ones to delete and these have not appeared for me.
I just cleared all cookies in Firefox, verified they were cleared, logged into the SitePoint forums, and checked the cookie list again. All I got were cookies on the domains adscluster.aws.sitepoint.com, google.com and sitepoint.com.
Browsing into some forum pages added a cookie for 1and1.com, due to the banner ad at the bottom fo the page. I suspect the other domains you picked up are for the same reason – remotely hosted banner ads for those sites at the bottom of the page at some point while browsing.
Yup, that’s the ticket - some of our ads set cookies when they’re loaded.
We appear to have our community designed buttons back, too! If there’s any missing, please let us know.
i was just a bit shocked that a site could/would set cookies outside its own domain… isn’t that a security risk?
A site can’t set cookies outside its own domain. Cookies are created through Set-Cookie headers, which are tied to the domain of the HTTP response such headers appear in.
The ads at the bottom of the forum pages are served by JavaScript. This JavaScript writes yet more JavaScript. This javascript sometimes writes an iframe which points to a webpage with an ad hosted on the domain of the advertiser (1and1.com, for example). This iframe, which generates its own HTTP request and response, sets the cookie.
The JavaScript can also inject more <script> tags pointing to JavaScript on another domain. This again generates an HTTP request to another domain which can set cookies on that domain.
The page in that iframe or script does not have access to SitePoint’s cookies because it’s on a different domain – the browser only sends cookies as headers in HTTP requests to the domain that set the cookies.
The purpose of the cookies is usually to track whether you see an advertiser’s ads on multiple sites. There’s no security hole there, just a weak privacy one in that your viewing of ads from one company can be tracked across multiple sites.
If you turn off third party cookies then the javascripts loaded from the ad sites can’t load cookie onto your computer. With third party cookies disabled only the site you are actually viewing that shows in the address bar can set cookies.
thanks stephen, i turned off third party cookies
but i will be doggoned, 3rd party cookies are still being set
in post #11, i mentioned that cookies for 7 domains were being set
it turns out that only one of them was a sitepoint advertiser, the other 6 (i’m surprised i did not notice this sooner) are somehow related to microsoft, yes?
they are still being set, despite 3rd part cookies being blocked, by IE8
i naively assumed that after completely clearing my cache, then visiting the sitepoint forum, that all 7 were being set by sitepoint, when in fact 6 of them are set by IE8 every time i open the browser
things that make you go “hmmm…”
What is your default homepage?
about:blank
still sets those 6 cookies