Web Team issueshttps://gitlab.torproject.org/tpo/web/team/-/issues2023-02-02T19:49:51Zhttps://gitlab.torproject.org/tpo/web/team/-/issues/47enable "pipelines must succeed" setting on all web repos2023-02-02T19:49:51ZKezenable "pipelines must succeed" setting on all web reposlavamind found a "pipelines must succeed" setting under `gitlab.torproject.org/tpo/web/<repo>/-/settings/merge_requests` under the section "Merge checks", and suggested we apply it to all the web repos.
- [x] blog
- [x] community
- [x] ...lavamind found a "pipelines must succeed" setting under `gitlab.torproject.org/tpo/web/<repo>/-/settings/merge_requests` under the section "Merge checks", and suggested we apply it to all the web repos.
- [x] blog
- [x] community
- [x] dev
- [x] donate-static
- [x] gettor-web
- [x] manual
- [x] newsletter
- [x] research
- [x] social-bank
- [x] styleguide
- [x] support
- [x] tpohttps://gitlab.torproject.org/tpo/web/team/-/issues/46Tor browser URLs with (ga-IE) locale code are not always redirected2022-12-06T14:54:38ZhenryTor browser URLs with (ga-IE) locale code are not always redirectedWithin tor browser, we have a few links that insert the application locale into the URL
- `https://support.torproject.org/<locale>/`
- `https://tb-manual.torproject.org/<locale>/`
- `https://community.torproject.org/<locale>/`
However,...Within tor browser, we have a few links that insert the application locale into the URL
- `https://support.torproject.org/<locale>/`
- `https://tb-manual.torproject.org/<locale>/`
- `https://community.torproject.org/<locale>/`
However, these do not redirect when the locale code is "ga-IE", even though that is one of the application locales we supply. "ga" still works though.
I haven't tested all the locales, but most of them seem to work. Maybe this is the only exception, but it would be nice if the rules could be checked against all the locales we ship with https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/3afab9a8af2b41f6b3cb4714d94ecab690911edb/rbm.conf#L98emmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/team/-/issues/44Archive and redirect gettor.torproject.org landing page to support portal2024-01-11T13:54:11ZGusArchive and redirect gettor.torproject.org landing page to support portalAlthough GetTor service is very important and useful for users where torproject.org website is blocked, I don't get what's the point of having GetTor landing page since all the instructions are available on Support portal and on Tor Brow...Although GetTor service is very important and useful for users where torproject.org website is blocked, I don't get what's the point of having GetTor landing page since all the instructions are available on Support portal and on Tor Browser Manual, which is bundled in TB.
So, here is my proposal to archive and redirect gettor.torproject.org:
- Improve gettor entry on https://support.torproject.org/censorship
- Archive the repository: https://gitlab.torproject.org/tpo/web/gettor-web
- Redirect gettor.torproject.org to support.torproject.org/censorship
- Remove gettor-web from weblateSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetemmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/team/-/issues/43compress more ressources2023-02-13T21:03:48Ztrinity-1686acompress more ressourcesWhile looking at tpo/tpa/team#40900, I found that `SourceSansPro-*.ttf` fonts are consuming a substantial amount of bandwidth. Over the 22nd, they collectively account for around 258GB of bandwidth usage for www.tpo (a bit more including...While looking at tpo/tpa/team#40900, I found that `SourceSansPro-*.ttf` fonts are consuming a substantial amount of bandwidth. Over the 22nd, they collectively account for around 258GB of bandwidth usage for www.tpo (a bit more including other domains, and for context it was a very busy day).
They are served raw, but could be served compressed. That would have been around 114GB if everything was sent gzipped, 89GB if it was compressed with brotli.
Compressing would then reduce the load on webservers, but also make the website load faster for slower clients (290kB ~= 2.2s at 1Mbps), so I think it would be a good thing to do on all accounthttps://gitlab.torproject.org/tpo/web/team/-/issues/39merge the two web wikis2023-07-04T19:16:14Zanarcatmerge the two web wikisi hadn't realized this, but we have two web wikis. that is bad. let's not do that and merge them both... here?
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/home
https://gitlab.torproject.org/tpo/web/team/-/wikis/home
/cc @emmapeeli hadn't realized this, but we have two web wikis. that is bad. let's not do that and merge them both... here?
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/home
https://gitlab.torproject.org/tpo/web/team/-/wikis/home
/cc @emmapeelanarcatanarcathttps://gitlab.torproject.org/tpo/web/team/-/issues/38Broken link on archive.torproject.org2022-05-12T16:23:06ZsreadyBroken link on archive.torproject.orgIn README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?In README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?anarcatanarcathttps://gitlab.torproject.org/tpo/web/team/-/issues/37Extend merge permissions for web projects2022-09-08T14:00:45ZJérôme Charaouilavamind@torproject.orgExtend merge permissions for web projectsCurrently, when members of other teams such as comms or applications want to publish a blog post or a new software release, they need someone from the web team (who have `Maintainer` permissions in tpo/web projects) to accept (merge) the...Currently, when members of other teams such as comms or applications want to publish a blog post or a new software release, they need someone from the web team (who have `Maintainer` permissions in tpo/web projects) to accept (merge) their Merge Request and also to push the latest CI build to production.
This process puts extra load on the web team, as their intervention is required on all web changes, even though some changes are quite trivial and should not require any manual review of MRs. Furthermore, it also puts extra load on the other teams as they need to follow-up at different moments of the publishing process to ensure someone from the web team steps in, otherwise the process is blocked.
I would like to propose to grant the members of projects under [tpo/web](/tpo/web) with **Developper** permission, the power to accept Merge requests. This change would also allow them to trigger manual deployments to production. This way, we will avoid blocking on the web team for small, common and regular website updates. Of course, the web team will remain available to review all the other, more substantial or unusual website updates.
To make this change, under each project's `Settings -> Repository -> Protected branches`, for the `main` branch, the **Allowed to merge** option would change from `Maintainers` to `Maintainers + Developpers`. **Allowed to push** would remain set to `Maintainers` (so Developpers would still always need to submit MRs).
In order to ensure no one is granted permissions they should not have, we should, at the same time, verify that only core contributors of the Tor Project are assigned Developper permissions on these projects.
* [x] [tpo/web/blog](/tpo/web/blog)
* [x] [tpo/web/tpo](/tpo/web/tpo)
* [ ] ~~[tpo/web/donate-static](/tpo/web/donate-static)~~
* [ ] ~~[tpo/web/gettor-web](/tpo/web/gettor-web)~~
* [ ] ~~[tpo/web/manual](/tpo/web/manual)~~
* [ ] ~~[tpo/web/newsletter](/tpo/web/newsletter)~~
* [ ] ~~[tpo/web/research](/tpo/web/research)~~
* [ ] ~~[tpo/web/styleguide](/tpo/web/styleguide)~~
* [ ] ~~[tpo/web/support](/tpo/web/support)~~
/cc @gaba @gus @emmapeel @anarcat @kezGabagaba@torproject.orgGabagaba@torproject.org2022-05-20https://gitlab.torproject.org/tpo/web/team/-/issues/36Rework GitLab-IRC bot alerts for #tor-www2022-06-08T17:37:43ZJérôme Charaouilavamind@torproject.orgRework GitLab-IRC bot alerts for #tor-wwwThere are several events in GitLab for which alerts in #tor-www would be very useful:
* Blocking on manual `deploy-prod` jobs
* New merge requests
* Failed pipelines
Maybe there's more. At the moment, using the KGB IRC bot, it's not p...There are several events in GitLab for which alerts in #tor-www would be very useful:
* Blocking on manual `deploy-prod` jobs
* New merge requests
* Failed pipelines
Maybe there's more. At the moment, using the KGB IRC bot, it's not possible to filter messages at that level of precision. For example, we can only control whether all "Pipeline events" are shown or not.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/team/-/issues/35Conceal staging and review sites behind simple HTTP auth2022-03-29T20:10:12ZJérôme Charaouilavamind@torproject.orgConceal staging and review sites behind simple HTTP authDuring the March 17 S9 meeting, we discussed concerns about the potential for our public staging and review sites to confuse visitors who may stumble upon those sites by accident. To address this, we agreed to conceal those sites behind ...During the March 17 S9 meeting, we discussed concerns about the potential for our public staging and review sites to confuse visitors who may stumble upon those sites by accident. To address this, we agreed to conceal those sites behind a basic HTTP web authentication prompt.
The goal is to keep out web crawlers and casual visitors while making it as easy as possible for actual and potential contributors to access those sites. To that end, we decided the user/password would be very simple and identical across both review and staging sites.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/team/-/issues/34Deploy staging sites for all web projects2022-03-29T20:10:35ZJérôme Charaouilavamind@torproject.orgDeploy staging sites for all web projectsAs agreed at the March 17th S9 meeting, the web team agreed to implement the same review/staging/production workflow across our different projects. This issue will track this progress.
Subdomains of `staging.torproject.net` will be crea...As agreed at the March 17th S9 meeting, the web team agreed to implement the same review/staging/production workflow across our different projects. This issue will track this progress.
Subdomains of `staging.torproject.net` will be created for this purpose. They will have a new static component in our web mirror system and an associated ssh private key will be added to each project's CI variables..
* [x] blog.staging.torproject.net
* [x] community.staging.torproject.net
* [x] ~~dev.staging.torproject.net~~ (in development, not on static mirrors yet)
* [x] donate.staging.torproject.net
* [x] gettor.staging.torproject.net
* [x] tb-manual.staging.torproject.net
* [x] newsletter.staging.torproject.net
* [x] research.staging.torproject.net
* [x] status.staging.torproject.net
* [x] styleguide.staging.torproject.net
* [x] support.staging.torproject.net
* [x] www.staging.torproject.net
Cleanup (vhost, docroots and LE configs):
* [x] blog-staging.torproject.org
* [x] support-staging.torproject.org
* [x] www-staging.torproject.orgJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/team/-/issues/21Working around the POT templates being inserted into lektor contents2024-01-18T14:39:00ZKezWorking around the POT templates being inserted into lektor contentsI've spent a few hours digging into lektor-i18n-plugin and trying to figure out what causes lego#37. I've discovered that running `lektor b` with python 3.9+ creates different .po/.pot files than running with python 3.8.x. The main diffe...I've spent a few hours digging into lektor-i18n-plugin and trying to figure out what causes lego#37. I've discovered that running `lektor b` with python 3.9+ creates different .po/.pot files than running with python 3.8.x. The main difference is that the buggy translation files translate the empty string `""` as the PO text.
I'm writing this up in detail in case someone else wants to pick up where I've left off, and also to document where exactly the bug is occuring.
The lektor-i18n-plugin code goes through each translation block, and if translating linewise (the default, also what we use), splits each translation block on `\n`, and then translates:
```py
def __trans_linewise(self, content, translator):
"""Translate the chunk linewise."""
lines = []
for line in content.split('\n'):
line_stripped = line.strip()
trans_stripline = trans(translator, line_stripped) # translate the stripped version
# and re-inject the stripped translation into original line (not stripped)
lines.append(line.replace(line_stripped,
trans_stripline, 1))
return '\n'.join(lines)
```
This means that translation blocks that end in a newline end up split into a list like this:
```py
content = 'lorem ipsum\ndolor sit amet\n'
split_lines = ['lorem ipsum' 'dolor sit amet', '']
```
Notice the empty string at the end of the list; this will get translated to the PO text we've been seeing. A simple workaround is to just not translate empty strings:
```py
...
for line in content.split('\n'):
line_stripped = line.strip()
if line_stripped == '':
trans_stripline = ''
else:
trans_stripline = trans(translator, line_stripped)
...
```
I'm not entirely happy with this since the bug is still *present*, we're just avoiding the consequences of it by ignoring empty strings. It feels fragile, but as long as we don't do anything with the buggy translation files that the plugin generates, we should be fine.
I'm hesitant on sending a patch for this upstream because it's not an actual fix. The alternative is maintaining a fork of the plugin in lego with our patch applied.https://gitlab.torproject.org/tpo/web/team/-/issues/15establish staging workflow for static sites in GitLab CI2022-01-18T16:04:15Zanarcatestablish staging workflow for static sites in GitLab CIin the rush migration surrounding tpo/tpa/team#40501, we moved the main prod websites, but not the staging sites. figure out how those work in GitLab CI and migrate them.in the rush migration surrounding tpo/tpa/team#40501, we moved the main prod websites, but not the staging sites. figure out how those work in GitLab CI and migrate them.Retire JenkinsJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/team/-/issues/9Fix and document process to update the web wikis2021-08-31T18:42:21ZemmapeelFix and document process to update the web wikisThe web wikis are supposedly synchronised, but since a while they are out of sync.
AFAIK, the main wiki is at https://gitlab.torproject.org/tpo/web/wiki/ and it should appear under wiki in https://gitlab.torproject.org/tpo/web/community...The web wikis are supposedly synchronised, but since a while they are out of sync.
AFAIK, the main wiki is at https://gitlab.torproject.org/tpo/web/wiki/ and it should appear under wiki in https://gitlab.torproject.org/tpo/web/community/-/wikis/home , https://gitlab.torproject.org/tpo/web/support/wikis/home, https://gitlab.torproject.org/tpo/web/manual/-/wikis/home etc.
But there is a big 'edit' button on each of the wikis, and changes have been made to the different versions
We should:
- [x] Unify the updates on the main wiki
- [ ] Remove the edit buttons or make sure they go to the proper wiki to edit
- [x] Document the best way to edit and check that it works.emmapeelemmapeel