- Mentioned In
- rRWWS4bb3d14aa83b: 2020: upgrade bootstrap
rRWWS2cfba8a48f15: 2019: Upgrade bootstrap
rRWWSfc4dd637c9be: 2017: Upgrade bootstrap
rRWWS1f90253f9cc2: 2016: Upgrade bootstrap
rRWWSb2f0700f7de6: 2015: remove YUI js and (most of) CSS
rRWWS7f193567f684: Copy external assets to the repo
rRWWSda2abb4cbd15: remove more stat counters
rRWWS8f54476435cf: remove statcounter
rRWWS5a47edab2152: remove Facebook button
@leila head's up that one of the patches is removing the Facebook button. Another is removing statcounter. We probably want to use https://wikitech.wikimedia.org/wiki/Tool:Event_Metrics instead. What do you think?
@bmansurov thanks for the heads up. those removals are fine. (and btw, I expect James Fishback to provide more update requests in the coming weeks per an internal thread to clean up such aspects of the site).
Re Event Metrics: sounds good to me if it's relatively straightforward for you to set up.
The last things I see are:
- Remove as much of the YUI and Bootstrap CSS and JS as possible. We don't want to leave vulnerable libraries out there needlessly.
- Update what remains of those libraries to newest stable versions.
- There are several assets being hosted at stanford.edu that should either be removed if not needed, or moved into the repo so we host them
I pinged @leila about whether she wanted me to do that or she had someone else, but I haven't heard back (I think because of no-email Friday).
Just a little status update: I've removed YUI and working on upgrading bootstrap. Since a lot changed between versions 2 and 4, it'll take some time to fully upgrade years 2016 through 2020. I'll let you know when I'm done.
Minor issue (so to some extent, still a HTTPS to HTTP redirect), I going to https://wikiworkshop.org/2019 (and other older sites, rather than one with a trailing /) results in a 301 against a HTTP resource before being kicked back to HTTPS
404s from favicon.ico but that obviously doesn't matter
Other than that, LGTM
curl -I -L https://wikiworkshop.org/2019 HTTP/2 301 date: Thu, 18 Jun 2020 15:17:14 GMT server: Apache location: http://wikiworkshop.org/2019/ content-length: 303 content-type: text/html; charset=iso-8859-1 vary: X-Forwarded-Proto age: 332 x-cache: cp3064 miss, cp3062 hit/2 x-cache-status: hit-front server-timing: cache;desc="hit-front" HTTP/1.1 301 TLS Redirect Date: Thu, 18 Jun 2020 15:22:46 GMT Server: Varnish X-Varnish: 816772390 X-Cache: cp3050 int X-Cache-Status: int-front Server-Timing: cache;desc="int-front" Location: https://wikiworkshop.org/2019/ Content-Length: 0 Connection: keep-alive HTTP/2 200 date: Thu, 18 Jun 2020 15:17:14 GMT server: Apache last-modified: Thu, 28 May 2020 00:11:13 GMT vary: Accept-Encoding cache-control: max-age=3600, must-revalidate content-type: text/html etag: W/"9740-5a6aa2a9d38b2" age: 331 x-cache: cp3058 miss, cp3062 hit/2 x-cache-status: hit-front server-timing: cache;desc="hit-front" accept-ranges: bytes
assert_headers: Location: http://wikiworkshop.org/2020/
That's obviously wrong, even if the test is just confirming what happens now..
I think this was just an oversight! Patch incoming for that part.
On the other redirects - the ones that read as 301 TLS Redirect that go in the http->https direction are from our generic Varnish coverage, while the downgrade ones are coming from something down in the applayer side.