Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Some work, some don't.
g.d.o does not work
assoc.d.o works.
sec.d.o works (SSL-only)
Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Some work, some don't.
g.d.o does not work
assoc.d.o works.
sec.d.o works (SSL-only)
Comments
Comment #1
gregglessubscribe. I don't think I can do anything to help with g.d.o but if I can, let me know.
Comment #2
deekayen commentedqa and api don't work either
Comment #3
gábor hojtsylocalize.d.o does not work either.
Comment #4
damien tournoud commentedinfra works.
Comment #5
gregglesFrom d.o bakery settings a fairly full list:
need work
http://localize.drupal.org/
http://api.drupal.org/
http://docs.drupal.org/
http://groups.drupal.org/
http://chicago2011.scratch.drupal.org/ (this one on scratchvm only needs to be in bakery for another ~2 weeks, but then the live site will need to be in bakery)
http://london2011.drupal.org is a placeholder.
Working:
http://association.drupal.org/
https://security.drupal.org/
Drupalcon sites:
In my opinion we should archive these to static html (much like drupalcamp colorado) so we retain SEO/archival benefits without worrying about out of date modules and things like ssl.
http://barcelona2007.drupalcon.org/ - static archive! Yay!
http://boston2008.drupalcon.org/
http://szeged2008.drupalcon.org/
http://dc2009.drupalcon.org/
http://paris2009.drupalcon.org/
http://sf2010.drupal.org/
http://cph2010.drupal.org/
Comment #6
gerhard killesreiter commentedThe archiving of old 'con sites is a sore point.
1) nobody gets around to do it
2) Kieran wants it to be postponed until we figure out a way to search the resulting html from solr to include it in our global search. I couldn't care less about this.
3) I am not sure we actually have a working script for this. The barca site needed a lot of work from Robert to fix it after the original tarball was discovered to have no css/JS whatsoever...
4) we should however take them out of bakery and disable new account creation to prevent spam.
5) docs.d.o should probably be disabled until the docs team figures our what to do with it.
Any objections to removing sf2010 and cph2010 from bakery?
Comment #7
greggles1. I can spend time on it.
2. How convenient: http://twitter.com/#!/robertDouglass/status/28021386867
3. webhtttrack works fine on Linux. htttrack works great on Windows. I assume "there's an App for that" and "it just works" for OSX, right?
4. Sure.
5. Seems fine to me. Someone should alert them? I posted into #drupal-docs, but I'm not sure that will get noticed.
Comment #8
gerhard killesreiter commented1) yay!
2) I'll leave this to whoever volunteers. But it's good to know this can be done _after_ making the site static.
3) Sure it works, but we'd want to check that it does, find out the optimal way to do that, etc.
4) ok, removed for now.
5) created http://drupal.org/node/953262
Comment #9
damien tournoud commentedI would like to see paris2009 archived.
Comment #10
Amazon commentedI am fine with archiving sites. We should stop account creation on all the old drupalcon sites. I do believe that some of our most valuable content in the Drupal community is from Drupalcons and is captured in those sites. The content should be discoverable by search. I know that the redesign team has been discussing how this is going to happen several times a week in our redesign stand-ups.
Comment #11
gerhard killesreiter commented@Kieran: Robert D seems to know how to do this, maybe you can get him involved? For me the important point is that this can be done /after/ a site was staticized.
Comment #12
nnewton commentedHi all,
FYI: I know some of the subsites (most) don't work with SSL. That was actually intentional. Our biggest issue with SSL is we don't have a setup that will support it infrastructure-wise (from a performance standpoint). I'm working on this currently and will expand our SSL usage when its resolved.
-N
Comment #13
meba commentedIs there a way to speed this up? I recently spent a lot of time on public wifi networks and with Firesheep, it's pretty dangerous...
Somebody developed a rule for HTTPS-Everywhere Firefox extension that includes groups.drupal.org - altough the rule is in Git only, it might be introduced to stable version soon.
Comment #14
rootworkThis is still active. I had the default HTTPS-Everywhere rule for d.o installed -- which serves an https for every subdomain of d.o -- and I've started seeing a 403 Forbidden error when I go to https://groups.drupal.org.
Here's the HTTPS-Everywhere rule in their git repository, but note it's pretty out of date:
https://gitweb.torproject.org/https-everywhere.git/blob/HEAD:/src/chrome...
If we could identify which subdomains work and which don't, we could submit a new rule (and perhaps default to non-SSL to prevent having to specifically address every Drupalcon subdomain).
Comment #15
gregglesShould be fixed now.
Comment #16
rootworkHooray! That's been bugging me forever.