The function pkgdown::deploy_to_branch modifes the URL provided by the user by extending it by the specified build subdirectory:
|
if (!is.null(subdir) && !is.null(pkg$meta$url)) { |
|
pkg$meta$url <- path(pkg$meta$url, subdir) |
|
} |
When the URL starts with a protocol, as it should, the fs::path method will replace the double forward slash with a single one, turning a valid URL like https://www.hostname.org into http:/www.hostname.org.
I think the behavior of automatically appending the subdir argument to the URL is also an issue:
- This equates the documented intent of
subdir, a filesystem directory within the gh-pages branch in which the generated code tracked, with the URL location at which the documentation will be served. A user may very well want to keep the documentation in a docs/ subfolder in the gh-pages branch, but not serve the documentation at a URL that has to end in /docs/
- This leads to inconsistent behavior with
pkgdown::build_site(...) and other methods: a setting for url that works for one will generate incorrect absolute URLs with the other. I think there are various good reasons that the generated HTML and links should be identical whichever build method is used. For one, build_site(...) is useful for checking for issues before calling deploy_to_branch(...), since the latter makes a git commit before the generated HTML could be previewed.
The function
pkgdown::deploy_to_branchmodifes the URL provided by the user by extending it by the specified build subdirectory:pkgdown/R/deploy-site.R
Lines 147 to 149 in c40ba2c
When the URL starts with a protocol, as it should, the
fs::pathmethod will replace the double forward slash with a single one, turning a valid URL likehttps://www.hostname.orgintohttp:/www.hostname.org.I think the behavior of automatically appending the
subdirargument to the URL is also an issue:subdir, a filesystem directory within thegh-pagesbranch in which the generated code tracked, with the URL location at which the documentation will be served. A user may very well want to keep the documentation in adocs/subfolder in thegh-pagesbranch, but not serve the documentation at a URL that has to end in/docs/pkgdown::build_site(...)and other methods: a setting forurlthat works for one will generate incorrect absolute URLs with the other. I think there are various good reasons that the generated HTML and links should be identical whichever build method is used. For one,build_site(...)is useful for checking for issues before callingdeploy_to_branch(...), since the latter makes a git commit before the generated HTML could be previewed.