-
Notifications
You must be signed in to change notification settings - Fork 38
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
Support sites deployed on paths other than "/" (by generating relative links) #291
Conversation
@eddgrant looks like there are some linter warnings, are you happy to fix these? |
Sure, I'll give give that a go. |
I've just realised the |
You can run them locally with |
Got it! I was using EC6 |
@@ -65,7 +67,7 @@ | |||
// We need JavaScript to do search, so if JS is not available the search | |||
// input sends the query string to Google. This JS function changes the | |||
// input to instead send it to the search page. | |||
$searchForm.prop('action', '/search') | |||
$searchForm.prop('action', pathToSiteRoot + 'search/index.html') |
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.
I think it's best if this doesn't have the index.html
file name, to be consistent with other URLs. Is there a reason that you changed it?
$searchForm.prop('action', pathToSiteRoot + 'search/index.html') | |
$searchForm.prop('action', pathToSiteRoot + 'search/') |
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.
If we don't include the index.html
then I think we become reliant on the web server that the site is deployed behind being configured to have a default page value of index.html
. Having said that I think there are other areas where we generate links which rely on the default page behaviour, so you could argue this is incongruous with that approach. Happy to try taking it out if you'd prefer consistency here.
I've just spotted the conflict arising between 3c629e7 (recently merged to master) and 3e8770e (my change). I'm not 100% sure yet but I think the change merged to master might be a more idiomatic as it seems to use a variable which is exposed by the I will do some testing to see if we can replace my change with the one already merged. |
This aims to address alphagov#271 by ensuring that all TOC links are generated as relative links, rather than absolute. The desired outcome being that the site no longer makes assumptions about being deployed at "/" which in turn makes it "portable" (i.e. possible to deploy it at an arbitrary path).
Also improved the naming of a few methods and variables.
… sites is configured to use relative links.
…n using generating sites using relative links.
To ensure test code fragment matches the actual generated code.
…ng absolute links. This configuration setting defaults to '/' so we can rely on it to always have a value.
After inspection I can now see that the 2 commits do subtly different things. One provides the relative path to the site root and the other provides the path to the search index page. I have rebased my changes to include the other change and everything seems to be working. If I push my rebased branch is it going to destroy all of our conversation above @lfdebrux ? 🤔 If it will (and that's a problem) then I could perhaps try pulling the changes in as a merge commit instead. Let me know what you'd rather? |
@eddgrant thanks for looking into it! A rebase and force push won't affect the conversation on this pull request page, so feel free to go ahead. It's preferred to a merge commit anyway. |
c0c061c
to
babdeb7
Compare
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.
I think this is almost ready to be merged <3, just one small suggested change 🙏
@@ -51,7 +53,7 @@ | |||
this.downloadSearchIndex = function downloadSearchIndex () { | |||
updateTitle('Loading search results') | |||
$.ajax({ | |||
url: searchIndexPath, | |||
url: pathToSiteRoot + (searchIndexPath.startsWith('/') ? searchIndexPath.slice(1) : searchIndexPath), |
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.
Unfortunately this means we're getting http_prefix/http_prefix
here as well.
I'd suggest we remove some of the complexity here and go back to just hardcoding search.json
. Then we don't need both data-search-index-path
and data-path-to-site-root
.
url: pathToSiteRoot + (searchIndexPath.startsWith('/') ? searchIndexPath.slice(1) : searchIndexPath), | |
url: pathToSiteRoot + '/search.json', |
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.
Aah that's a shame. Happy to revert to a hardcoded search.json
, however I should note we'll be undoing the changes made in 3c629e7. Is that ok?
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.
Yep, fine by me.
lib/source/layouts/_search.erb
Outdated
@@ -1,5 +1,5 @@ | |||
<% if config[:tech_docs][:enable_search] %> | |||
<div class="search" data-module="search" data-search-index-path="<%= search_index_path %>"> | |||
<div class="search" data-module="search" data-path-to-site-root="<%= path_to_site_root config, current_page.path %>" data-search-index-path="<%= search_index_path %>"> |
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.
<div class="search" data-module="search" data-path-to-site-root="<%= path_to_site_root config, current_page.path %>" data-search-index-path="<%= search_index_path %>"> | |
<div class="search" data-module="search" data-path-to-site-root="<%= path_to_site_root config, current_page.path %>"> |
@lfdebrux sorry for the delay, it's been a busy week. I've just pushed the change reverting back to always using |
No worries, thanks so much for all the time you've spent on this! |
No worries at all, likewise thanks for all your effort reviewing it! 🙏 |
Hey @lfdebrux I forgot to ask, do you have plans to tag this as a release and publish a new rubygem? I'm interested so I can plan when to deprecate our fork and move back to using this directly. |
@eddgrant I've discussed this with the other working group members, we will try and put out a release soon. |
This change has been released in release v3.2.0 🎉 You can now configure your Tech Docs Template (TDT) to build your documentation site to use relative links to pages and assets. Thanks @eddgrant for contributing this feature and the associated fixes. |
On non-hompage page, rails helper check this config and updated the path to include nesting. This is related to alphagov/tech-docs-gem#291 and since we deploy to root, these can be removed
What are you trying to do?
Make it possible to generate a fully working site, in which all intra-site links (i.e. links within the site, between pages, to assets etc) are generated as relative links, so that the site can be deployed at a path other than "/".
Identifying a user need
At HMRC we use the tech-docs-template to deploy multiple docs-as-code sites at different paths on a single domain e.g.
Without these changes the site links do not function correctly.
Is it a change or a bug fix?
Change.
What’s changed?
The changes are driven via standard Middleman configuration:
When enabled, the above configuration causes the following changes to happen:
/api/pages.json
endpoint returns relative links, such that thetech-docs-monitor
can correctly generate page URLs when raising Slack notifications (16396e7). This requires a companiontech-docs-monitor
change for which the PR is here.Testing
We are testing these changes at HMRC at the moment and haven't yet observed anything which has broken as a result of the changes. We don't believe the changes cause any regressions when building sites in the normal way using absolute links. However we'd be grateful for any additional testing people can do.