Fixing legacy guide 404

[kevinbluer]

Fix for #1100.

As per the issue, it now serves with the .html extension. Deployment preview here.

Note that it now 404s if the extension is omitted. It also breaks from the convention for all other guides, blog posts, etc. My preference would still be to find a more holistic solution that accommodates both; mkdocs-redirects is worth some exploration to see if it can assist.

Also of note is that we went with the current convention in preparation for hosting on IPFS (via Fleek). Something that’s still on the near-term roadmap and is also characteristically quite different to a traditional web server.

[haltman-at]

Hm, is it really a good idea to just move this? I think we should properly set up a redirect.

[kevinbluer]

Can you elaborate on "properly"? Given we're using a statically generated site, we aren't able to leverage web server config to handle redirection / resolution, which gives us a few alternatives (each with trade-offs re maintenance overhead, degree of duplication, etc). Totally could be missing an approach though so would love your take.

• Setup both src/guides/building-testing-frontend-app-truffle-3.md and src/guides/building-testing-frontend-app-truffle-3/index.md with one containing a redirect to the other. Works but duplicative and a bit of a maintenance pain
• Leverage something like mkdocs-redirects and thus move the redirect mapping to config. Cleaner than the above, but potentially overkill if we're just addressing a single link
• Setting a Page Rule / Worker (or equivalent) at the DNS level in Cloudflare. Also potentially overkill and even more of a maintenance pain 🙃

Also worth noting that the guide in question is from Feb 2017 (referencing Truffle 3) and technically not published anymore.

[haltman-at]

Oh, geez, I sort of assumed we had some sort of redirection solution already set up. >_> Like given how often this problem has come up in the past with other pages -- given how many pages we have that have changed URLs over time -- surely we would have a redirection solution set up to handle it, right? I just sort of assumed that had to have been done by now... by "properly" I just meant "using whatever solution that is to do an actual redirect"!

I mean, I don't really know anything about different ways of setting up redirection and so don't really have much of an opinion between them! Yeah, the original issue that this was meant to address should probably just be combined into the more general issue for this (obviously this particular page is not especially important as you point out), and this particular PR should probably be closed. But geez, I had no idea we've been going for this long with the whole redirection problem totally unsolved...

[kevinbluer]

Yeah, at least to my knowledge there was never a canonical solution for redirects on the previous version of the site (and such nothing "official" that got carried over to this new iteration). Also afaik things did get moved around at times, without redirects in place, which led to issues like #1144 🤷

That said, and as per the above thread, it would be great to put something robust in place. There's obviously a few approaches including the suggestion / POC in #1148. However, it would be prudent to ensure that whatever we put in place also accommodates IPFS-based hosting and it's nuance(s). Probably logical for us to discuss in a quick call (will go ahead and schedule something).