check_links.js does not find bad hyperlinks to bookmarks
See original GitHub issueWhere to find the issue
cypress/integration/check_links.js
Describe the issue
check_links.js does not find bad links to bookmarks.
Steps to reproduce
- Introduce a bookmark hyperlink error into one of the .json source files
For instance, in faq.json change the first occurrence of
#international_phone_numbers
to#international_phone_number
(remove last letter) - run
npm run test:open
- select check_links.js to run in cypress console
- Note that the error is not found. Instead the test shows a success
Link: http://localhost:8000/en/faq/#international_phone_number: expected 200 to equal 200
The bad link
<a href='#international_phone_number' target='_blank' rel='noopener noreferrer'>click here to see the phone numbers</a>
shows as success.
In the next paragraph the link is correct
<a href='#international_phone_numbers' target='_blank' rel='noopener noreferrer'>click here to see the phone numbers</a>
Both the bad link and the good link show as success.
Suggested change
Since there is a lot of use of hyperlinks to bookmarks (aka anchors) in faq.json and faq_de.json, implement a link check for these hyperlinks either in check_links.js or in a separate cypress JavaScript script.
This is an enhancement request.
Internal Tracking ID: EXPOSUREAPP-9752
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:8 (8 by maintainers)
Top GitHub Comments
I found an example of a bad hyperlink to a bookmark in
https://github.com/corona-warn-app/cwa-website/blob/master/science/2021-07-08-science-blog-2/index.md on line 22
1. [Basic survey](#24-basic-surveys)
The target should be
#24-basic-survey
with no “s” at the end.I found this manually.
Edit: Unfortunately there are several more broken hyperlinks in the science 2 blog in both the English and German versions. I will document these in a separate issue and then submit a PR to correct them.
The previous https://github.com/corona-warn-app/cwa-website/issues/1836#issuecomment-948488964 has been remediated by PR #1943, so this issue is now completely resolved and ready for closure.