jesus/mdbook
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
mdbook/tests/testsuite/redirects.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

50 lines
1.5 KiB
Rust
Raw Normal View History

Migrate redirects_are_emitted_correctly to BookTest
2025-04-21 19:25:44 -07:00
//! Tests for the HTML redirect feature.
use crate::prelude::*;
use snapbox::file;
// Basic check of redirects.
#[test]
fn redirects_are_emitted_correctly() {
BookTest::from_dir("redirects/redirects_are_emitted_correctly")
.check_file(
"book/overview.html",
file!["redirects/redirects_are_emitted_correctly/expected/overview.html"],
)
.check_file(
"book/nested/page.html",
file!["redirects/redirects_are_emitted_correctly/expected/nested/page.html"],
);
}
Add support for fragment redirects This adds the ability to redirect URLs with `#` fragments. This is useful when section headers get renamed or moved to other pages. This works both for deleted pages and existing pages. The implementation requires the use of JavaScript in order to manipulate the location. (Ideally this would be handled on the server side.) This also makes it so that deleted page redirects preserve the fragment ID. Previously if you had a deleted page redirect, and the user went to something like `page.html#foo`, it would redirect to `bar.html` without the fragment. I think preserving the fragment is probably a better behavior. If the new page doesn't have the fragment ID, then no harm is really done. This is technically an open redirect, but I don't think that there is too much danger with preserving a fragment ID?
2025-07-08 15:37:46 -07:00
// Invalid redirect with only fragments.
#[test]
fn redirect_removed_with_fragments_only() {
BookTest::from_dir("redirects/redirect_removed_with_fragments_only").run("build", |cmd| {
cmd.expect_failure().expect_stderr(str![[r#"
Switch from log to tracing This switches to using the tracing crate instead of log. Tracing provides a lot of nice features which we can take advantage of moving forward. This also adjusts the output fairly significantly. This includes: - Switched the environment variable from RUST_LOG to MDBOOK_LOG. - Dropped the timestamp. I experimented with various different time displays, but ultimately decided to omit it for now. I don't think I've ever found it to be useful, and it takes up a very significant amount of space. It could potentially be useful for basic profiling, but I think there are other, better mechanisms for that. We could consider leveraging tracing itself for doing some basic profiling (like using something like tracing-chrome). - Dropped the target unless MDBOOK_LOG is set. The target tends to be pretty noisy, and doesn't really convey much information unless you are debugging or otherwise trying to adjust the log output. - Added color. - Slightly reworked the way the error cause trace is displayed. - Slightly changed the way html5ever filtering is done, as well as add handlebars to the list since they both are very noisy. You can override this now by explicitly listing them as targets. I still expect that mdbook will eventually change how it displays things to the console, possibly switching away from tracing and printing things itself. However, that is a larger project for the future.
2025-09-12 06:13:45 -07:00
INFO Book building has started
INFO Running the html backend
ERROR Rendering failed
[TAB]Caused by: Unable to emit redirects
[TAB]Caused by: redirect entry for `old-file.html` only has source paths with `#` fragments
Add support for fragment redirects This adds the ability to redirect URLs with `#` fragments. This is useful when section headers get renamed or moved to other pages. This works both for deleted pages and existing pages. The implementation requires the use of JavaScript in order to manipulate the location. (Ideally this would be handled on the server side.) This also makes it so that deleted page redirects preserve the fragment ID. Previously if you had a deleted page redirect, and the user went to something like `page.html#foo`, it would redirect to `bar.html` without the fragment. I think preserving the fragment is probably a better behavior. If the new page doesn't have the fragment ID, then no harm is really done. This is technically an open redirect, but I don't think that there is too much danger with preserving a fragment ID?
2025-07-08 15:37:46 -07:00
There must be an entry without the `#` fragment to determine the default destination.
"#]]);
});
}
// Invalid redirect for an existing page.
#[test]
fn redirect_existing_page() {
BookTest::from_dir("redirects/redirect_existing_page").run("build", |cmd| {
cmd.expect_failure().expect_stderr(str![[r#"
Switch from log to tracing This switches to using the tracing crate instead of log. Tracing provides a lot of nice features which we can take advantage of moving forward. This also adjusts the output fairly significantly. This includes: - Switched the environment variable from RUST_LOG to MDBOOK_LOG. - Dropped the timestamp. I experimented with various different time displays, but ultimately decided to omit it for now. I don't think I've ever found it to be useful, and it takes up a very significant amount of space. It could potentially be useful for basic profiling, but I think there are other, better mechanisms for that. We could consider leveraging tracing itself for doing some basic profiling (like using something like tracing-chrome). - Dropped the target unless MDBOOK_LOG is set. The target tends to be pretty noisy, and doesn't really convey much information unless you are debugging or otherwise trying to adjust the log output. - Added color. - Slightly reworked the way the error cause trace is displayed. - Slightly changed the way html5ever filtering is done, as well as add handlebars to the list since they both are very noisy. You can override this now by explicitly listing them as targets. I still expect that mdbook will eventually change how it displays things to the console, possibly switching away from tracing and printing things itself. However, that is a larger project for the future.
2025-09-12 06:13:45 -07:00
INFO Book building has started
INFO Running the html backend
ERROR Rendering failed
[TAB]Caused by: redirect found for existing chapter at `/chapter_1.html`
Add support for fragment redirects This adds the ability to redirect URLs with `#` fragments. This is useful when section headers get renamed or moved to other pages. This works both for deleted pages and existing pages. The implementation requires the use of JavaScript in order to manipulate the location. (Ideally this would be handled on the server side.) This also makes it so that deleted page redirects preserve the fragment ID. Previously if you had a deleted page redirect, and the user went to something like `page.html#foo`, it would redirect to `bar.html` without the fragment. I think preserving the fragment is probably a better behavior. If the new page doesn't have the fragment ID, then no harm is really done. This is technically an open redirect, but I don't think that there is too much danger with preserving a fragment ID?
2025-07-08 15:37:46 -07:00
Either delete the redirect or remove the chapter.
"#]]);
});
}
Reference in a new issue Copy permalink