This is different from GraphQL which is a web service (rather than an extension)

In T210273#4957523, @dom_walden wrote:

But does not have VisualEditor. I don't know if that makes a difference. The pop-up occurs on the page before you get to the editor, so I guess not...

Also, I think it's totally fine if we build & host the same "base" release images as well. In my mind there's nothing wrong with that, but I think we should use the same Dockerfiles in order to reduce the maintenance overhead. If someone wants to use the ones built and hosted on Docker's infrastructure, great! If someone doesn't trust that and wants to use the ones built and hosted on our infrastructure, also great!

The docker image found here: https://hub.docker.com/_/mediawiki
uses these Dockerfiles: https://github.com/wikimedia/mediawiki-docker
and is built on Docker's infrastructure using this configuration: https://github.com/docker-library/official-images/blob/master/library/mediawiki

In T213318#4956647, @Joe wrote:

I do think that both in the short term and in the long term, having a single application written in PHP being able to do the basic job of a wiki is a must.

@Smalyshev again, it's impossible to justify (or not justify) a platform, because (afaik) there is no product strategy for MediaWiki. There's no "business case" to support a platform

In T213318#4955539, @Smalyshev wrote:

I am of course speaking out of my personal experience with (some) people running small wikis (including myself many years ago). It may be we're not targeting them or caring for their needs currently. But I'd like to raise this question so if we forgo support for this category, we do it with open eyes and not by accident.

In T213318#4955516, @Smalyshev wrote:

It's not targeting a seasoned DevOp, but a likely part-time IT person probably on limited hosting, possibly with no root access and may even never have heard of things like "docker".

If it's going to be deployed in this sprint, it can stay in this ticket, if it's in another sprint, new tickets! :)

@TBolliger & @SPoore When do you want this done?

@Tchanders are you working on this?

In T213318#4954278, @daniel wrote:

Note that moving from "good old shared hosting" to a Kubernetes environment is not at all trivial to people who run a wiki for their kid's school or their sports team in their spare time. They may not be the target audience for Wikibase, but they are for MediaWiki.

In T213318#4953461, @Smalyshev wrote:

I frankly have a bit of a hard time imagining an IT person of the kind that commonly installs smaller wikis being able to efficiently maintain a zoo of services that we're now running in WMF. I think the model of "unpack the code, start httpd, welcome to the wiki world" should still be supported. Maybe not at 100% functionality, but at least basic things (like editing Wikibase) should work.

That's great news! :)

MediaWiki-Docker has to do specifically with https://hub.docker.com/_/mediawiki so unless I'm missing how this issue is related to that image?

@Pablo-WMDE so to clarify (for my own sanity) this proposal is about unifying the existing logic (by rendering JavaScript on the server)?

In T213318#4947904, @Anomie wrote:

What happens when the Wikibase SPA is embedded in a larger page, which presumably wouldn't be updated when the SPA navigates?

Move towards implementing Wikibase/Wikidata UI as a Single Page Application (SPA) - written in TypeScript to mitigate the downsides of using an otherwise untyped language

In T210273#4938271, @Tchanders wrote:

suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

or even better might be to link to the block list... it looks kinda gross right now, but it at least lists the currently active blocks:
https://test.m.wikipedia.org/wiki/Special:BlockList?wpTarget=185.220.101.31

Can we link to the block log like this?
https://test.m.wikipedia.org/wiki/Special:Log?type=block&page=Koavf

I'm skipping QA on this since you have to have to be a global Staff to access the tool.

In T213220#4936526, @aezell wrote:

Could you possibly fudge some fixture data that causes the problem?

Hmm... I actually don't think there is a way to test this since the problem is theoretical.

In T213220#4934444, @aezell wrote:

In some instances, the name collision would cause a reversal of the effective block?

In T213220#4932221, @aezell wrote:

Can you describe what the effect of this would be (before and after your change) if the actions didn't match?

As for myself, I think T208175: Proposal: Blocks should exist as serialized pages is perhaps a better solution to the same problem, so I for one think this should be declined in favor of that, but as it doesn't look like I'll be working on either, I leave that up to TechCom

Yep. This all sounds good to me.

In T208355#4919585, @TBolliger wrote:

I was able to add Speciale:UltimeModifiche on Italian Wikipedia, and it still suggests special pages:

Put on the schedule to SWAT https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190124T1900

@TBolliger there is no testwiki or itwiki on the beta cluster (full list), so how about we enable on:
https://en.wikipedia.beta.wmflabs.org/
https://wikidata.beta.wmflabs.org/
?

I created a new issue to hopefully prevent this in the future: T214546: Title::loadFromRow() should return a new instance of Title

In T210739#4904082, @dbarratt wrote:

@Anomie ok, my only other question is... where is this being cached that it's being loaded again?

@Anomie ok, my only other question is... where is this being cached that it's being loaded again?

In T210739#4904044, @dbarratt wrote:

In T210739#4903798, @Anomie wrote:

which at some point triggers WikiPage->loadPageData() which loads the page data from a replica and then (in WikiPage->loadFromRow()) reloads the Title object from that loaded data.

Where? I'm not seeing where this would happen.

@Anomie Also, even if this is being loaded at that point, I'm not seeing where it would be statically cached?

In T210739#4903798, @Anomie wrote:

which at some point triggers WikiPage->loadPageData() which loads the page data from a replica and then (in WikiPage->loadFromRow()) reloads the Title object from that loaded data.