Note: @GoranSMilovanovic find the old Wikitonary-Analytics domain.

@GoranSMilovanovic are the lists complete? If something is missing, please add!

See T295057: Consultation on persistent URL scheme for Wikidata analytics-related products .

@GoranSMilovanovic can you add some more WMDE people to the wmde-dashboards Cloud VPS project? The current members list is fairly short. (Current Team A Hearth people would be Michael, Noa and myself.)

As far as I can see the current members list remains limited. Maybe @Addshore can help with adding members of the Hearth to the project?

@noarave @Manuel @Addshore

I would have already added new members but it turns out that I am not authorised to do so in Horizon.

wikidata-analytics.wmcloud.org goes to wikidata-analytics.wmde-dashboards.eqiad1.wikimedia.cloud
So the project is wmde-dashboards, and I have added kara to this project now, and will guide kara to the access panel soon!

Thank you Adam!

Heads-up @Addshore: @GoranSMilovanovic might come back to you about a related topic in the context of T299568.

sprint 10 planning: blocked until goran has completed moving all the instances

@karapayneWMDE [Also in a recent email to @Manuel]

Move WMDE analytics into a new CloudVPS project

is not a blocker of T295396 (this ticket) in any way.

The issue in the first ticket is related to some problem in the internal communication of ShinyProxy with its Docker containers.

The redirect thing in this ticket, if I understand the problem correctly, could be solved by placing Nginx in front of ShinyProxy as described in

• Shiny Proxy Docs, and maybe in
• Custom Domain and Security for ShinyProxy with Nginx

Thank you, Goran, for the clarification! This is what I hoped for!

As stated before, I'm not sure if we are able to achieve this configuration in our CloudVPS project. I have contacted the WMF Cloud Services team to enquire about our options of setting redirects, and hope to get an answer soon.

Received a response from the Cloud Services team, and it appears that there isn't a simpler way to set up redirects than to just fully install nginx and enable as a reverse proxy (similarly to the instruction in the blog post Goran shared) and then creating redirects to ensure users reach the correct dashboard (see github issue on ShinyProxy's repository).

In my opinion, as this is a considerable amount of work to be investing in CloudVPS instances that will have to be migrated in the next ten days, it is not worthwhile to go through twice, and it would be best that we wait until it has been fully migrated. On the bright side though, as the Wiktionary Cognate dashboard has already been migrated, we can start with that one already by creating a separate task for it, and putting it in the pipeline for the next iteration of work for our team.

as the Wiktionary Cognate dashboard has already been migrated, we can start with that one
already by creating a separate task for it

This is good news, thank you, Itamar! \o/

Hi @ItamarWMDE are rewrites feasible or should we better go for permanent redirects (301)? In the latter case, I would change the task description.

I think 301s are the best way forward for this. Rewrites can be more cumbersome to maintain, and HTTP redirects also alert the user to the current actual state of things.

I changed the description to reflect this. Also, as discussed, I have now split the CognateDashboard out into its own task: T311222: Redirect CognateDashboard users from deprecated URL to new URL

I am pulling this for now, as we have more important issues around the analytics infrastructure.