Combining HTML files with a Django website

My website at www.gyford.com has accumulated a lot of stuff over the years. The bulk of the site (the weblog and associated pages) is currently running on Movable Type with a lot of custom PHP, and that’s the part I’m slowly re-writing in Django.

However, there are lots of other bits and pieces that I don’t want to lose, but don’t easily fit into the structure of the main website. For example:

• All the flat HTML examples of old versions of this and other sites at /phil/archive/.

• This 1995 demo version of Hotwired in flat HTML (more about that).

• Some old GeoCities pages, also flat HTML, that I archived when GeoCities disappeared.

• Domesday Witham an old, flat HTML website version of a local history booklet by my mother.

Ideally I’d like to keep all these online, at the same URLs, when I move the rest of gyford.com to a new Django site, but I’m not sure whether that’s feasible. And if it feasible, what would be the least bad way to do it.

Here are the options I’ve thought of so far:

1. Create a new site, under a subdomain of gyford.com, for static HTML and its images etc. Redirect the current URLs to this site. This seems simplest, but will mean changing URLs.

2. Host gyford.com on WebFaction which, I think, will allow me to combine a Django website with one or more “Static” websites under different directories. This sounds like it should work, and I already have PHP/HTML sites on WebFaction, but it feels fiddly.

3. Host gyford.com on Heroku (which was my initial aim) and use multiple buildpacks to serve the Django site and the static directories. However, I can’t see anything in the docs that say multiple buildpacks let you do this, so maybe it’s not possible.

4. Somehow serve HTML pages through the Django site, maybe using something like django-staticflatpages. I’ll probably do this for a couple of currently-single HTML pages (like /japanese/) but I think it’s a non-starter for larger quantities of pages (laborious to set up, very inefficient, and there are issues with relative links to in-page graphics etc).

5. Use Nginx on DigitalOcean (or wherever) to serve Django and then certain directories as static files. This ticks all the boxes except I really don’t want to administer servers any more.

Leaving aside option 5, option 1 seems simplest, but it feels a shame that the URLs of pages and files should be so dependent on the differing technologies used to code the site.

After so many years of running sites that are either solely Django/Flask/etc, or else solely uploading-PHP/HTML-files-to-a-shared-server, trying to combine these different things seems unnecessarily awkward.

Do you have any other ideas? Do let me know on email or Twitter. I can’t be the first to want to do this.

UPDATE, 27 Oct 2017: Thanks to those of you who offered suggestions. We now have a couple of further options:

6. Use a reverse proxy like Amazon CloudFront or Cloudflare to serve the static files and the Django app from different places. e.g. Put static files on Amazon S3 and the Django app on Heroku, then, I think, use CloudFront’s Behavior Path Pattern to set them as different origins. (Thanks, Frankie Roberto.)

7. Use WhiteNoise to serve all the static files from your Django app on Heroku. e.g. Put directories of static files in the folder specified by WHITENOISE_ROOT and set WHITENOISE_INDEX_FILE (currently only in v4.0b4) to 'index.html' or whatever works for you. (Thanks Matthew Somerville.)

Option 7 seems almost too good to be true, for someone who wants a relatively simple life. I haven’t tried it in production with a lot of directories of a lot of files yet, but hopefully it’ll work fine. You could always use a CDN to help with the load if necessary. I like that it keeps all the files — static HTML files, Django app, plus its images, CSS, etc — in one location. And it’s easy to add new directories of static files by putting them in the WHITENOISE_ROOT directory and pushing to Heroku.

Commenting is disabled on posts once they’re 30 days old.