Skip to content
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

Compute canonical path before adjusting parent path #856

Merged
merged 3 commits into from
Nov 27, 2019

Conversation

phil-opp
Copy link
Contributor

Fixes #854

@phil-opp
Copy link
Contributor Author

I think we also need to strip the language tag from the filename when generating the canonical path, otherwise translations are not found. Do you want me to add this change to this PR or do you prefer when I open a new one?

@Keats
Copy link
Collaborator

Keats commented Nov 26, 2019

I mean that's weird that it was not doing it, I swear I had code to handle that.. :(
Can you add some tests while you're there? At least a regression test with a link to the GH issue.

@phil-opp
Copy link
Contributor Author

I mean that's weird that it was not doing it, I swear I had code to handle that.. :(

Maybe you mean this code?

/// Look for a language in the filename.
/// If a language has been found, update the name of the file in this struct to
/// remove it and return the language code
pub fn find_language(&mut self, config: &Config) -> Result<String> {
// No languages? Nothing to do
if !config.is_multilingual() {
return Ok(config.default_language.clone());
}
if !self.name.contains('.') {
return Ok(config.default_language.clone());
}
// Go with the assumption that no one is using `.` in filenames when using i18n
// We can document that
let mut parts: Vec<String> = self.name.splitn(2, '.').map(|s| s.to_string()).collect();
// The language code is not present in the config: typo or the user forgot to add it to the
// config
if !config.languages_codes().contains(&parts[1].as_ref()) {
bail!("File {:?} has a language code of {} which isn't present in the config.toml `languages`", self.path, parts[1]);
}
self.name = parts.swap_remove(0);
self.canonical = self.parent.join(&self.name);
let lang = parts.swap_remove(0);
Ok(lang)
}
}

This line seems to have the same problem:

self.canonical = self.parent.join(&self.name);

You're using the adjusted parent field to create the canonical path again.

@phil-opp
Copy link
Contributor Author

I pushed a second commit that also fixes the issue in find_language.

- Test for correct canonical field when calling `new_page`
- Test for correct canonical field after calling `find_language`
@phil-opp
Copy link
Contributor Author

I added some basic regression tests for the two commits.

);
let res = file.find_language(&config);
assert!(res.is_ok());
assert_eq!(file.canonical, Path::new("/home/vincent/code/site/content/posts/tutorials/python/index"));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the reason for those bugs is that in my mind the canonical path was /home/vincent/code/site/content/posts/tutorials/python.
Anyway, thanks a lot!

@Keats Keats merged commit 53df9f1 into getzola:next Nov 27, 2019
@phil-opp phil-opp deleted the fix-page-canonical branch December 12, 2019 10:05
Keats pushed a commit that referenced this pull request Feb 3, 2020
* Compute canonical path before adjusting parent path

* Don't use adjusted `parent` to recalculate `canonical` in `find_language`

* Add regression tests

- Test for correct canonical field when calling `new_page`
- Test for correct canonical field after calling `find_language`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants