ORCID
ORCID identifier as HTTP URI in profile page depends on dynamic JavaScript functions
Below behaviour may be very well be the intended design but it is arguably an issue for reuse. Just FYI:
https://github.com/ORCID/ORCID-Source/blob/5ea29cd8fea53e18f9597043a7ef5dfb523c729e/orcid-web/src/main/resources/freemarker/includes/ng2_templates/id-banner-ng2-template.ftl#L26
is assembling the ORCID identifier with JavaScript functions relying on varying data.
Putting the issue of requiring JavaScript to be enabled by the User Agent aside (for accessibility), this leads to the following issue when the ORCID resource is archived due to a call to getBaseUri (and then getBaseUriHttps in https://github.com/ORCID/ORCID-Source/blob/5ea29cd8fea53e18f9597043a7ef5dfb523c729e/orcid-web/src/main/webapp/static/javascript/script.js#L330 which just depends on location.host that can differ based on where the script is called from):
https://orcid.org/0000-0002-0880-9125 -> https://web.archive.org/0000-0002-0880-9125
So, no good.
If the identifier is intended to be used/displayed as HTTP URI, it should conform to https://support.orcid.org/hc/en-us/articles/360006897674-Structure-of-the-ORCID-Identifier ... even when the ORCID resource (eg. with the HTML representation) could be used somewhere besides orcid.org - as is the case with archived snapshots.
If the resource is not intended to be used anywhere outside of the orcid.org service, the template should either hardcode https://orcid.org/ as prefix to the ORCID string id, or treat the HTTP URI as the "identifier".
Live demos on accessibility and archivability:
- https://twitter.com/csarven/status/1345704010746048512 ( https://web.archive.org/web/20210103125645/https://twitter.com/csarven/status/1345704010746048512 )
- https://twitter.com/csarven/status/1345704040387194881 ( https://web.archive.org/web/20210103125351/https://twitter.com/csarven/status/1345704040387194881 )
Hi Sarven, thanks for pointing this out. I had no idea this was impacting the web archive!
I've created a card so that we can prioritise a fix: https://trello.com/c/ijTJCyoR/179-orcid-ids-rendering-wrong-in-wayback-machine
Interestingly, it used to work in the past, not sure when it stopped working, but that example is from 2018.
Hi Sarven. we're looking into server side rendering of certain elements - specifically those in the
to start, followed by the body itself. https://trello.com/c/oUatN9W4/8383-rd-investigate-server-side-rendering-of-headWe hope that this will become a non-issue once this is done. Sadly it's a TON of work, but we'll get there.
Shouldn't this issue be closed if and when the changes either fix the issue or makes it no longer a non-issue?
We use github issues as a feedback channel and then prioritise them alongside all the other feature requests and bug reports we get. This is a very low volume communication channel for us - we get orders of magnitude more feedback and feature requests via our support desk - they are shown here: https://trello.com/b/LzoesER2/community-feedback
If we had any volume of open source contributions it would be different, but we don't,
Where is your canonical place to track issues? Are you tracking this specific exact issue in trello? Is there another issue in trello that's a duplicate of this issue? - I'm assuming that this issue predates the others.
I took the time to file a bug: dug into your source code and highlighted the relevant parts, described the issue, demonstrated with screencasts, and gave concrete links/examples. Hope that's adequate amount of work from external contributors?
In the past you've acknowledged the issue impacting accessibility and archivability. What's mentioned in trello appears to be described in terms of "seo".
Closing this issue with the hope that it may be addressed in the future doesn't make sense to me but... your call. Let me know if I should not be contributing to this repository. You may want to consider archiving it so that people don't spend time on it if they should be contributing elsewhere.