-
-
Notifications
You must be signed in to change notification settings - Fork 428
Fix 2 issues with custom html files in export #1118
Conversation
This reverts commit 2f48c89.
1. While exporting, if a route such as `[slug].html.js` is made that serves it's own html pages(with correct Content-Type header), those pages url's were being rewritten even though they were valid. Example: `simple.html` was being rewritten to `simple.html/index.html`. We now check for a `.html` on the end of the path before adding a `/index.html` to the end 2. When parsing exported html, the `<base>` element was checked for in the head of the doc. If this element didn't exist(for example if you generate your own html and miss adding this element) the error message is not clear what is wrong and is hard to track down. This change should avoid that confusion and use a sane default if not available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like this PR will need a rebase
src/api/export.ts
Outdated
@@ -186,7 +187,7 @@ async function _export({ | |||
const cleaned = clean_html(body); | |||
|
|||
const base_match = /<base ([\s\S]+?)>/m.exec(cleaned); | |||
const base_href = base_match && get_href(base_match[1]); | |||
const base_href = base_match ? get_href(base_match[1]) : '/' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: don't need the extra space before base_match
and should add a semi-colon to the end of the line
Some portion of this has been resolved in the recently merged #1049 - which is also part of what's making this PR conflict. So that should be bullet point 1 addressed. |
Issue #1202 has been opened, which sounds like the second, unaddressed issue this PR is intended to fix. |
1. While exporting, if a route such as `[slug].html.js` is made that serves it's own html pages(with correct Content-Type header), those pages url's were being rewritten even though they were valid. Example: `simple.html` was being rewritten to `simple.html/index.html`. We now check for a `.html` on the end of the path before adding a `/index.html` to the end 2. When parsing exported html, the `<base>` element was checked for in the head of the doc. If this element didn't exist(for example if you generate your own html and miss adding this element) the error message is not clear what is wrong and is hard to track down. This change should avoid that confusion and use a sane default if not available.
This patch looks wonky now, when all I did was try to merge in master and rebase, oh well, i'm going to close this and submit the one liner in another pull request so it's easier for you folks to review. |
While exporting, if a route such as
[slug].html.js
is made that serves it's own html pages(with correct Content-Type header), those pages url's were being rewritten even though they were valid. Example:simple.html
was being rewritten tosimple.html/index.html
. We now check for a.html
on the end of the path before adding a/index.html
to the endWhen parsing exported html, the
<base>
element was checked for in the head of the doc. If this element didn't exist(for example if you generate your own html and miss adding this element) the error message is not clear what is wrong and is hard to track down. This change should avoid that confusion and use a sane default if not available.Tests
npm test
oryarn test
)I added a
test.html
file to the export test that should test both of these scenarios