-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a straightforward way to export error pages with adapter-static
#1209
Comments
The |
The |
If you're using |
Oh, right, thanks, I missed this one. An option would be nice indeed. However, the resulting fallback doesn’t render a 404 using What am I still missing? |
What I'm doing now is So then I add a {
// ...
"scripts": {
"build": "svelte-kit build",
"postbuild": "mv build/404/index.html build/404.html"
}
} |
I've run into the same issue. A static error page is missing. I'd like to see an option to export // svelte.config.js
import adapter from '@sveltejs/adapter-static';
export default {
kit: {
adapter: adapter({
error: 'mypath/myname.html'
})
}
}; This is needed for Cloudflare Pages to show an error page. By default, Cloudflare Pages redirects all invalid URLs back to the root, because it assumes SPA mode if there is no Currently, it's even impossible to export such |
@vwkd Right now, the best way is to build a Before the recent output dir changes, this would look like: {
"scripts": {
// ...
"postbuild": "mv build/404/index.html build/404.html"
}
} |
Svelte Kit doesn't offer a good way to generate single HTML pages like 404.html, so I have to generate a regular page and then move it. Solution suggested here: sveltejs/kit#1209 (comment)
I am trying to understand the working concept of __error.svelte. When a user inputted a non-exist address in his browser and press enter. I believe this GET request is sent to the server. According to my back-end (non-NODE) program, it cannot find this non-exist page file for sure so it sent index.html in the build folder of SK back to the browser. But in my browser, the error page is shown instead of index.html. This is a reasonable result and what I want. Just I don't know how this happens. I don't know how and when the error page is involved. |
This involves using a really dumb `postbuild` script to make sure the generated `404.html` is actually in the right place. See sveltejs/kit#1209 (comment).
|
Summary for future readers You can have your cake and eat it too. 🍰 i.e. :
Step 1: create error page Step 2: update
Step 3: let your static host service know how to handle not found resources. As an example, I'm using the Azure Static Websites config
|
See sveltejs/kit#1209 The "prerender" instruction on the `kit` config from that thread didn't seem necessary, probably because my `+layout.server.ts` had that set up already? Regardless, putting `prerender: { default: true }` wasn't liked by vite in my current setup...
A remix of the above comment (thanks for that! <3), because
Below is the tweaked setup that did work for me. I have a full SSR app (well, I guess the
Further notes:
If I "Disable Javascript" in my browser, all normal pages work well with their SSR version. The |
I ended up reaching the exact same conclusion as @jeroenheijmans, but it not working with javascript off is a bit of a bummer. It's the one thing missing here. Hoping there's a solution for this |
I agree with @Raicuparta, this results in a blank page if JS is disabled in the browser. It seems like the fallback page is not prerendered along with the other routes, and instead relies on CSR. |
Note that this issue is closed because the original request was handled. If there's a feeling that something needs to happen to enable this kind of 404 fallback pages that work without javascript, we should consider asking the team/community in a fresh issue if that can be considered. (Caveat: I have not checked yet if there's such an issue already, closed or not. Perhaps it's been considered and rejected for the moment?) Personally I find having a non-SSR-404-fallback just fine, at least for my current use cases. |
This solution doesn't work for Cloudflare Pages. The 404 page renders a blank page with a JS error:
|
It seems like the problem with the solution proposed by @jeroenheijmans is that
I also didn't like using My solution was to create the 404 file as:
It can still use data from Do not use After build, you will get a |
Is your feature request related to a problem? Please describe.
There doesn’t seem to be a proper way to export a 404 for static sites. In Sapper, adding
/404
as a second entry point would export an additional/404/index.html
; in SvelteKit, there is currently no similar option.Related to #1172, but with the specific goal of handling non-SPA exports.
Describe the solution you'd like
Assuming this has no value outside of static export, it probably should be a separate option for
adapter-static
. Error routes should not be required to explicitly exist and should be exempt from the default ‘fail on error’ policy.(A nice touch would be the ability to trigger specific errors from here, e.g. by passing error codes for prerendering. This way, websites that need more than a simple 404 (e.g. sites operating within larger systems may also want 502 and 504) could be catered for. I wonder, however, if this is common enough to mind.)
Describe alternatives you've considered
In theory, offering a way to force prerendering no matter the status code would allow simply adding separate entries in the config, effectively replicating Sapper’s behaviour. This would be undesirable, as I believe SvelteKit’s ‘all errors are build errors’ behaviour is excellent and should remain otherwise intact.
A workaround currently requires error routes to exist as normal pages. This works, but leads to some duplication between
$error.svelte
and404.svelte
, is not very portable (a404.svelte
that in fact returns200
makes no sense with, say,adapter-node
), and generally ticks all boxes to qualify as a hack.How important is this feature to you?
A 404 page is important in static export, and relying on hacks in performing such a common task shouldn’t be necessary.
The text was updated successfully, but these errors were encountered: