Add rough custom 404 page in astro with quick search

[nbogie]

Addresses #1256

changes

1. adds custom 404 page with populated search link
2. configures cloudflare to look for it

1. custom 404 page with populated search link

Adds a rough custom 404 page in astro (/src/pages/404.astro) which presents user with a quick search option to search the website (using the website) for pages matching the last part of their path.

Example:
When the user visits the broken URL: https://beta.p5js.org/reference/p5.font/texttocontours/
the custom 404 page includes a search link to: https://beta.p5js.org/search/?term=texttocontours

2. Cloudflare config

per the astro docs for cloudflare deployment
https://docs.astro.build/en/guides/deploy/cloudflare/#404-behavior

this PR changes wrangler.jsonc to set not_found_handling as follows:

"assets": {
    "directory": "dist",
    "not_found_handling": "404-page"
  },

This will cause it to look for a 404 page in .dist/404.html. I have confirmed locally astro build is putting our custom 404 page at that file path.

(Note to anyone testing with other their own astro stuff: the popular "starlight" theme will overwrite this page by default with its own 404 page. (this can be disabled.))

[ksen0]

@nbogie for the config, I think that goes in here? If I understand correctly, can be addable to this PR. https://github.com/processing/p5.js-website/blob/2.0/wrangler.jsonc

[ksen0]

Do you have any ideas on how to get the user's browser from insisting on lowercase? That seems like a pretty big problem even with 404 implemented

[nbogie]

Do you have any ideas on how to get the user's browser from insisting on lowercase? That seems like a pretty big problem even with 404 implemented

I'm hopeful that it seems this correction only happens when the user tries hand-correcting the capitalisation of an all-lower-case url in the url bar, and then presses enter, when their browser "knows better" (or can't differentiate wrt to cache lookup). It doesn't seem to happen if the user clicks a link with a corrected capitalisation - this seems to bypass any browser correction, if indeed that's what's happening in the former case.

Steps to repeat: (on chrome)

1. open chrome://history
2. search for beta.p5js.org/reference
3. find a multi-word page name that is (or should be) camel-cased (it will be displayed correctly, in history!)
4. click it
5. observe a 404 due to all-lowercase url path
6. try to fix the url capitalisation manually, and press enter
7. observe chrome adjusts your edit to lowercase so you get the 404 again

As for preventing this relatively minor correcting, in chrome it looks like it is only possible with "clear browsing history". https://stackoverflow.com/questions/50298340/chrome-changes-url-case
The couple of test cases I was using, I think i fixed by removing the specific search suggestion on the url bar (x there).
(There used to be a way to turn off search autocomplete in chrome, but not now, it seems.)

[nbogie]

Testing:

• tested the 404 search locally
• tested the cloudflare 404 config by building and deploying a tiny astro project of my own on cloudflare using github CI wrangler action
  • limitation: not p5js-website repo. But similar config wrt 404.

Update: now using wrangler action on github actions, not wrangler manually from cli

[nbogie]

Good to go, i think!

[ksen0]

Thanks so much for your work on this ! It did look reasonable and I did deploy, however the routes are doing a different thing than expected. Here is me clicking on "curveDetail"* and getting into weird 404:

404.mov

Reproduced with both /curveVertex/ and /curveVertex in path. But feels like surely it's related to trailing slash handling in dev vs prod

I have now redeployed from 2.0 without this patch.

*"It doesn't seem to happen if the user clicks a link with a corrected capitalization - this seems to bypass any browser correction, if indeed that's what's happening in the former case." Alas, not so in general. In Chrome I consistently get the browser talking to itself loop if I click on something I've clicked on before / which is cached.

[nbogie]

That looks like clicking on a search result was taking you to the 404 page?

And (perhaps) the 404 page wasn't presenting any part of your original link in the search link? (Or perhaps when you get taken to 404 it is snapping to a certain url).

[nbogie]

So, the JS in the 404 astro page was getting statically compiled and the values locked in from the first render during build. My bad for not test-deploying the full 404 in my toy astro site.

I have successfully recreated the problem now with a cloudflare deploy of the the website repo and will change it to use JS that definitely runs client-side instead!

[nbogie]

Fixed! You can test it out here: https://p5-js-website-beta.neillzero.workers.dev/reference/p5/basestrokeshader/

(The above is a deploy of a branch that's very slightly different from this PR branch, with (only) some necessary removals of custom p5.js domains from the wrangler config)

[nbogie]

In my tests I can't recreate the (possible routing) issue shown in Kit's video where the user clicks a search result and it goes to the 404 page.

I wonder if that's not actually a routing issue, but this other issue of the browser "correcting" the "wrong" capitalisation of a URL it's been to before.

One easy way to tell is to use a browser that's not been to those URLs before.

[ksen0]

In my tests I can't recreate the (possible routing) issue shown in Kit's video where the user clicks a search result and it goes to the 404 page.

I wonder if that's not actually a routing issue, but this other issue of the browser "correcting" the "wrong" capitalisation of a URL it's been to before.

Yes I believe that must be it! Was fine in incognito.

[ksen0]

Something weird with style (actually also on https://p5-js-website-beta.neillzero.workers.dev/reference/p5/buildfiltershader/):

1. Footer is unmoored from the bottom of the page
2. Social arrows incorrect encoding?

[nbogie]

I fixed the social arrows by using a Head + BaseLayout , bringing it into line with most of the pages on the site. But I wasn't able to reproduce the "footer unmoored" issue.

(The Head component sets encoding - that was likely the social arrows issue.)

deployed here: https://p5-js-website-beta.neillzero.workers.dev/reference/p5/buildstrokeshader/

[ksen0]

Wonderful, thanks so much! Updating.

The footer floating away from bottom of the window is a normal outcome of page not being long enough to be scrollable:

Not introduced in this PR, and anyway 404 design will continue, so will ignore.