We need to modernise the look-and-feel of our Wayback playback, and make it more consistent with the new website.

I've started this on the 2017-style-reset branch, which just resets things to use a minimally-modified version of the default OpenWayback theme. This should provide a good basis for development.

• Switch to a logo consistent with the new UKWA site.
• For unknown reasons the Welsh language support package for dates etc. is not being used.
• Reinstate navigation between /archive/ and /archive-cy/ in toolbar
• There is much un-translated text in the BubbleCalendar page, and no links between Welsh/English versions.

One option might be an enhanced timeline using https://timeline.knightlab.com/, but this may make more sense as part of the main website engine.

Also/alternatively, merging in the timeline graph from Mementos may be a good idea here.

The idea is to log missing resources so we can send them to a 'patch crawl' queue and add them back in again. A partial implementation is here

The idea is to shift to using that for all Wayback instances (not just under wayback-ldwa) and ideally make it POST the 404 URLs to the to-crawl queue. We'd probably want to push them over via in a background thread to avoid 404 responses being delayed and hanging the client.

When viewing items in wayback-ld we get very little information or context. For example, should we make the OA/NPLD terms clear, so the user knows they can access it outside the reading room?

Tricky to implement because the system has to somehow check against the whitelist but treat it as advisory rather than dropping the non-OA items. It's not clear if this is possible without significant changes to Wayback.

When we added HTTP 451 support we broke the no-whitelist support. If there's no whitelist, the whole thing fails with a NPE.

To try to stop leaking to the live web, particularly the comScore web bug, we need to try adding a Content-Security-Policy. To block all, non-www.webarchive.org.uk resource we can use:

Content-Security-Policy: default-src 'unsafe-eval' 'unsafe-inline' 'self' data: blob: mediastream: ws: wss: ; form-action 'self'

We have reports of people visiting Wayback and finding they get the 451 error page while they are in a reading room. The current implementation expects the reading-room-or-not re-direction to happen upstream in the user journey (as part of the main website). However, it is reasonable to expect that people will end up here sometimes and need a way to get to their secure gateway.

The simplest option is just to add links to each secure gateway into the error page.

A more sophisticated version could try to detect which link is relevant and only provide links that work.

We need to deploy the LD Wayback player with a new backend configuration. I've removed the old custom configuration, so the build should now inherit the new configuration for the back end. i.e. the current set-up should work.

However, this needs to be tested thoroughly, including the LD-specific functionality. So, here's a suggested plan of work:

• Build this project locally, and check you can deploy wayback-qa to a local Tomcat. @GilHoggarth should be able to supply suitable back-end service endpoints to run like QA Wayback.
• Then try deploying wayback-ldwa locally, this should work exactly like wayback-qa except if you try to go to the same page in two separate browsers, you should be locked out of one of them.
• If this seems to be working, check you can visit the lock management UI. IIRC documentation for that is on our internal Wiki.
• You should also check the 7 day embargo works when configured.

Once this appears to be working, we'll need to merge these changes into the branch for #1.

The toolbar says '0 captures', which is silly. We just need a link to the 'calendar' page, so it should just say 'show captures'.

This should be done on the 2017-style-reset branch.

Seems like the code to read the whitelist of urls to allow to be shown correctly reads new urls but fails to remove urls that have previously been added (i.e., attempting to reverse a whitelist allowance).
Presumably, though this wasn't tested, restarting wayback would solve this but such an action should not be required.

Can we ensure 404's/missing records are logged cleanly, so we can parse the logs and try to get the missing resources?

Or, is there some other way to do this? Could be part of the screenshotting-of-proxy-playback?