domjudge icon indicating copy to clipboard operation
domjudge copied to clipboard

Add way to download static scoreboard with all linked files

Open nickygerritsen opened this issue 2 years ago • 3 comments

Add an export to export the static scoreboard together with:

  • All CSS
  • All Javascript
  • All images
  • A way to view team pages, either creating separate pages or doing something smart with some JSON. The latter is probably cleaner

Requested by @verwoerd and I like the idea.

nickygerritsen avatar May 31 '22 18:05 nickygerritsen

Is this not just documenting the right wget/curl/... invocation that will do just this?

thijskh avatar Jun 01 '22 06:06 thijskh

Not really. First of all you also need CSS/JS. This you could do with some wget flag but is that ideal? Second: we use absolute URL's for these CSS/JS and images (i.e. starting with /), while you might want to put the code on a different page. We could maybe change that in the Twig templates but I'm not sure. Second: you either need to remove all <a href> link to team detail pages or find a way to also get them. They are in a 'subdir' in DOMjudge. This is one of the reasons we use absolute URL's for JS/CSS/images, but if you want those pages, you need a way to fix this.

For SWERC I once did this by writing a script that downloads all pages and did some regex replaces on it. But this was very ad-hoc.

nickygerritsen avatar Jun 01 '22 06:06 nickygerritsen

wget -m -k -p -nH --restrict-file-names=ascii,windows 'http://localhost:12345/public/?static=1' seems to almost do what we want, but not entirely:

  • It DOES rewrite the CSS/JS files to not have a ? in them, but they get an @ in them, i.e. style_domjudge.css@v=8.1.0DEV%2F864eaa5d5. This makes at least a default nginx setup not serve them with a CSS mimetype, making browsers angry.
  • The root file gets saved as public/index.html@static=1, which doesn't end in .html, making the default nginx setup (and I suspect Apache as well) have it such that the file gets downloaded instead of displayed.

We could document how to fix both issues per webserver, but is that really what we want? Isn't the alternative of having some command to produce a folder be better?

nickygerritsen avatar Jun 06 '22 13:06 nickygerritsen