By Gerhard Killesreiter on

Some of you may have noticed it, but most probably have not:

the old DrupalCon sites that are still running Drupal are not accessible at the moment, they are locked by a htaccess script.

This is an unfortunate development, but in the end I didn't have any choice but to do this.

The reason for this is quite simple: the sites are unmaintained. With the associated DrupalCon, the various webteams dispersed and software updates weren't done anymore.

This means that the sites are insecure. And since they run on the same webservers as the main drupal.org site and all subsites as well as current DrupalCon sites, I had to act.
I should have acted much earlier. It is unfortunate that this caused troubles for some people who linked to the sites. But you can't really expect such a temporary site to be around forever.

Now, you can think that I should maintain the sites myself. But quite frankly I don't have the time for this.

What should happen now?

The old DrupalCon sites need to be converted to static HTML so that we can continue to host them accessible for all without fears of a security problem.

So, I am reaching out to the community to let me know any good solutions you've found to this problem. Last time we tried it, the result it wasn't really optimal and the DrupalCon Barcelona site lost its CSS and JS.

Got any well proven recipies? Please create an issue in the infrastructure queue at
http://drupal.org/node/add/project-issue/infrastructure

⋅ Categories: drupal.org

Comments

jpstrikesback’s picture

jpstrikesback commented

What kind of work is involved in maintaining said sites? (I.E. what is in place for dev-stage-live workflow? same as D.O.?) I wonder if we could have maintainer time slots, like sponsor (by maintaining) 1 site for 6 months, pick the one you love and keep it alive and well and get a badge?

muhleder’s picture

muhleder commented

Did you try Boost? I haven't used this for this purpose myself, but it seems like it might work?

christefano’s picture

christefano commented

Boost presupposes that the site is still running Drupal. It's possible to disable all the dynamic functionality (i.e. all the forms) and dropping a node at user/login but it's a whole lot easier to scrape the site with a tool that isn't Drupal-based.

mikeytown2’s picture

mikeytown2 commented

I think boost would be a good fit. At a minimum the htaccess rules would be very useful.

Some other alts:
http://drupal.org/project/savetoftp
http://drupal.org/project/html_export

Let me know, I would be willing to put in some time to make this happen

mikl’s picture

mikl commented

Maintaining sites like these that were hastily thrown together by ad-hoc teams does not sound like my idea of fun. I certainly don't miss dealing with the cph2010 site…

Of course, if someone is willing to undertake this effort, please be my guest :)

jpstrikesback’s picture

jpstrikesback commented

I think what's of value on these sites is the session Nodes with A/V, slides and comments right? What if we build a site for archiving conference session nodes...then when a conference site is EOL'd the archive site would have already imported/contained said nodes? It would certainly be an undertaking, but it could maybe perhaps possibly be a way forward...

The association could even charge for access to this hot-ticket mine of drupal knowledge :)

nicl’s picture

nicl commented

Just to echo, the videos/slides from these sites have incredible value to Drupal newbies and those coming into web-development. If they can be kept available in any way (for example, an archive site, not even with design), that would be the main thing really.

zorbtrauts’s picture

zorbtrauts commented

Why not have a single Drupalcon site, perhaps with subdomains for each separate event?

Amazon’s picture

Amazon commented

Hi, ideally a volunteer who will step forward who can apply security updates to the Drupalcon sites.

The content in those sites are too valuable to not have in Drupal.org multi-site search.

We just need an experienced site maintainer who can apply the updates.

Kieran

christefano’s picture

christefano commented

Exaltation of Larks can help with this. I've submitted an issue at http://drupal.org/node/1035558

ezra-g’s picture

ezra-g commented

Let's consider alternatives to updating, particularly as sites eventually outlive their Security team coverage.

Instead, you can create a static HTML archive of the whole site that can then be hosted on d.o.

You can see this approach in action with DrupalCamp Colorado 2010:
http://colorado2010.camps.drupal.org/drupalcampcolorado.org/index.html

rcross’s picture

rcross commented

Kieran brings up a good point about the search side of things.

If the content stays in Drupal, it something that can be part of the multi-site search.

I don't think this would be do-able (or at least would be much harder) if we converted these to static html sties.

I do agree that static html is probably the most appropriate way forward though considering there would be definitely be some D5 sites and probably some D4.7, 4.6 sites even and I doubt anyone wants to actually upgrade those.

good_man’s picture

good_man commented

Why not using the already awesome tools like wget & httrack ? wrapping them in a shell script will do the whole job for you.

Owen Barton’s picture

Owen Barton commented

I have used httrack many times for this kind of thing, it is much more reliable than wget in terms of getting the various js/css etc - I think it is most likely the easiest approach (certainly easier than trying to install new modules on these sites).

jredding’s picture

jredding commented

Ideally we could find a hybrid solution. If someone could write and volunteer to make static copies of the sites we can leave them available at .drupal.org but .html form (i.e. Boost-style). We could then leave the dynamic version of the site behind an .htaccess area (perhaps archive.drupal.org/con-site) so if we needed to make updates, grab dynamic data or pull information from the database we'd still have access to the data.

Re: Single site Multiple Cons
The DrupalCon teams have looked at using a single conference site that houses all of the content but it doesn't fit with the dynamic nature of the conference. Each conference team would like to be creative with the site and to really showcase and highlight the latest and greatest features of Drupal. True to the Drupal spirit the best way to accomplish this is to start with a fresh install of Drupal (i.e. removing backward compatibility) and build on top of it. Unfortunately this does mean the site is essentially abandoned a few weeks after the conference as the next team is already build the next and latest/greatest version of the DrupalCon site.