(Sorry, I wanted this to be a generic task, and I can't see how to remove the "Bug" tag)

@Jdforrester-WMF I realise now that this change reversed your last commit to .gitattributes https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+log/HEAD/.gitattributes I'm sorry I didn't see that earlier and include you in this ticket. What are your thoughts?

@abi_ did research, described a solution and opened discussion in the Mediawiki.org village pump, but is not currently working on this. I'm not sure where the WMF wiki configs are stored, and I don't know how to locally test, but I would be happy to help push forward on this one.

Did anyone try and reach out to Docker to reclaim control?

I re-positioned the comment that I mentioned above for extra clarity, this change has been merged.

@SD0001 Reading through the wiki and finding T318977 shows there are no official docker images for third party production to begin with. There are official images in https://docker-registry.wikimedia.org/ but I believe these are only intended for WMF use. I think this task should be clarified, merged, etc.

This has been merged! Thanks for the advice, support and review: it made my first contribution experience really nice and encourages me to do more ☺️

Thanks @taavi I'll try and submit my first patch 🍿

Closing this. Task better understood and formulated at T393183

Pull request was merged, Docker hub docker-compose.yml updated 🎉

Thinking about this a little more, it is strange that docker-compose.yml should be included in the standard, zipped package at all. Perhaps removing it is the best solution.

I am a person running a mediawiki instance using docker. I went straight to Docker Hub, searched for MediaWiki, found the docker-official-wikimedia-unofficial image (🥲) and adapted the docker-compose.yml. Although the instance seems to be going fine, the strong warnings against the Docker Hub images found in the mediawiki-wiki are quite disconcerting.

Thanks @brennen for confirming my suspicions. On this basis, I would say the best option would in fact be to remove docker-compose.yml from the bundling process alongside DEVELOPERS.md. Do you know how that process works?

I have submitted this pull request on github to remove version attribute.

I recently got caught out by this one, also found my way to the Stackoverflow...

It seems Docker Hub has somewhat changed its pull limit policy to for each ... unauthenticated user ... 100 per IPv4 address or IPv6 /64 subnet per 6 hours. In contrast, authenticated users get 200 per hour, not magnitudes more.

I had a chat with @Novem_Linguae about this, and he made the pragmatic suggestion to just copy the docker-compose.yml from core to docker hub. On top of this, I would add a comment that "this example may be out of date, and you should check <link> for up-to-date".

@xSavitar I believe this issue refers to the exact same issue as T362669 and T364815, namely that the version attribute is obsolete and that docker compose as of v2.26 will give a warning. The only difference is that this issue refers to the docker-compose.yml on the docker hub example whereas the other two issues refer to the docker-compose.yml found in mediawiki/core.

Looking more closely, this issue is technically different, since it refers to docker _hub_. I notice the example manifest on docker hub diverges significantly from the one contained in mediawiki/core — should this be so? Intuitively it would be nice if the mediawiki/core manifest propagated to hub.

I think this can be marked duplicate to:

• T362669
• T364815

Sorry, the manifest I'm talking about is in Dockerhub: https://hub.docker.com/_/mediawiki/ which I believe is ultimately sourced from https://github.com/docker-library/docs/blob/master/mediawiki/README.md#-via-docker-compose-or-docker-stack-deploy

@thcipriani thank you for looking into this. However it seems I am at fault here and that there is no bug 🙈 I had not logged into gerrit, and had rather added my SSH key to IDM. Logging into gerrit and adding my key worked as documented. Sorry for any inconvenience.

Thank you for your swift responses. Installation on our production server (quite a different environment) was issue free https://wiki.kanthaus.online/Wiki_tasks I will contact the provider https://uberspace.de/en/ and update the guide I wrote for their service https://lab.uberspace.de/guide_mediawiki/

@Wargo Yes, this problem presents on every Page where the Discussion does not yet exist. Disabling DiscussionTools does resolve the issue: I only noticed the issue after installing DiscussionTools. The testing instance I linked has minimal customization/configuration, only:

Visual editor → Insert → Images and media → Search

I see that T284206 and T96535 significantly overlap with this task.

I just installed MediaWiki for the first time and bumped into this issue while user testing. It would be wonderful to be able to rely on the native search!

Related and more recent: T188236

This issue seems to be address with open task T188236

This seems to be a duplicate of T188236