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

Support sites deployed on paths other than "/" (by generating relative links) #291

Merged
merged 14 commits into from
Feb 11, 2022

Conversation

eddgrant
Copy link
Contributor

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.

docs.tax.service.gov.uk/site-1
docs.tax.service.gov.uk/site-2
docs.tax.service.gov.uk/site-3
... etc

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:

set :relative_links, true
activate :relative_assets

When enabled, the above configuration causes the following changes to happen:

  1. The Table of Contents is generated using relative links (824116a)
  2. The Table of Contents expands, collapsed and is highlighted using relative links (a2dde29)
  3. The search function works using relative links (a2dde29)
  4. The /api/pages.json endpoint returns relative links, such that the tech-docs-monitor can correctly generate page URLs when raising Slack notifications (16396e7). This requires a companion tech-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.

@lfdebrux
Copy link
Member

@eddgrant looks like there are some linter warnings, are you happy to fix these?

@eddgrant
Copy link
Contributor Author

Sure, I'll give give that a go.

spec/table_of_contents/helpers_spec.rb Outdated Show resolved Hide resolved
lib/assets/javascripts/_modules/search.js Outdated Show resolved Hide resolved
lib/assets/javascripts/_modules/search.js Outdated Show resolved Hide resolved
@eddgrant
Copy link
Contributor Author

eddgrant commented Jan 20, 2022

I've just realised the spec Rake task doesn't run the Jasmine tests (which are failing). I'm not familiar with Jasmine but I'll see if I can figure out what's going on there.

@lfdebrux
Copy link
Member

I've just realised the spec Rake task doesn't run the Jasmine tests (which are failing). I'm not familiar with Jasmine but I'll see if I can figure out what's going on there.

You can run them locally with bundle exec rake jasmine:ci, let me know if I can be more helpful, good luck!

@eddgrant
Copy link
Contributor Author

Got it! I was using EC6 const variable declarations, which work fine in my browser, but I think Jasmine may be configured to build at a prior version to ES6 and didn't like the const declarations. Changing them to var declarations has done the trick, tests are now all passing.

@@ -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')
Copy link
Member

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?

Suggested change
$searchForm.prop('action', pathToSiteRoot + 'search/index.html')
$searchForm.prop('action', pathToSiteRoot + 'search/')

Copy link
Contributor Author

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.

@eddgrant
Copy link
Contributor Author

eddgrant commented Feb 3, 2022

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 middleman-search gem, rather than relying on my method of walking back to the site root.

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.
…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.
@eddgrant
Copy link
Contributor Author

eddgrant commented Feb 3, 2022

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?

@lfdebrux
Copy link
Member

lfdebrux commented Feb 3, 2022

@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.

Copy link
Member

@lfdebrux lfdebrux left a 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),
Copy link
Member

@lfdebrux lfdebrux Feb 4, 2022

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.

Suggested change
url: pathToSiteRoot + (searchIndexPath.startsWith('/') ? searchIndexPath.slice(1) : searchIndexPath),
url: pathToSiteRoot + '/search.json',

Copy link
Contributor Author

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?

Copy link
Member

Choose a reason for hiding this comment

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

Yep, fine by me.

@@ -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 %>">
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<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 %>">

@eddgrant
Copy link
Contributor Author

@lfdebrux sorry for the delay, it's been a busy week. I've just pushed the change reverting back to always using /search.json for the search results.

@lfdebrux
Copy link
Member

@lfdebrux sorry for the delay, it's been a busy week. I've just pushed the change reverting back to always using /search.json for the search results.

No worries, thanks so much for all the time you've spent on this!

@lfdebrux lfdebrux merged commit 66cc7ab into alphagov:master Feb 11, 2022
@eddgrant
Copy link
Contributor Author

No worries at all, likewise thanks for all your effort reviewing it! 🙏

@eddgrant
Copy link
Contributor Author

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.

@lfdebrux
Copy link
Member

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.

@lfdebrux
Copy link
Member

lfdebrux commented Mar 9, 2022

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.

@eddgrant eddgrant deleted the TRG-128-for-GDS-review branch March 24, 2022 17:16
kr8n3r added a commit to alphagov/paas-team-manual that referenced this pull request Sep 23, 2022
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
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.

Make docs portable by using relative URLs
2 participants