Page MenuHomePhabricator

Link to CREDITS on Special:Version should not trigger a download dialog
Closed, ResolvedPublic

Description

Clicking "others" in Special:Version asks to download a file.


Version: unspecified
Severity: normal
URL: http://translatewiki.net/w/CREDITS

Details

Reference
bz40641

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:51 AM
bzimport set Reference to bz40641.
bzimport added a subscriber: Unknown Object (MLST).

Yep. It links to the CREDITS file on the installation. Since it has no .txt extension the servers sends it with an unknown MIME type so the browser doesn't know how to interpret it and prompts the user to download it.

That's very weird. We're using the latest web standards like HTML5, CSS and JavaScript and we're using a plaintext file for that?

What about a link to the MediaWiki.org site where all those names are listed on a nice wiki page? Although it may be inconsistent across different MediaWiki versions.

[ URL added ]

  • This bug has been marked as a duplicate of bug 38609 ***

Unduplicating. Fixing Apache on WMF wont fix it for other installations out there.

(In reply to comment #4)

Unduplicating. Fixing Apache on WMF wont fix it for other installations out
there.

Amusingly, on my dev server this works fine. visit /w/CREDITS see text!

And I didn't do anything to "fix" it

(In reply to comment #4)

Unduplicating. Fixing Apache on WMF wont fix it for other installations out
there.

In that case it's WFM.

(In reply to comment #6)

(In reply to comment #4)

Unduplicating. Fixing Apache on WMF wont fix it for other installations out
there.

In that case it's WFM.

What do you mean?
As long as the credits file doesn't work as expected on most installations, the link is serving no purpose and its (recent) addition should be reverted IMHO.

But it does work as expected. If it's not working for some sites (WMF and translatewiki are ones I'm aware of), then that's an issue with their webserver configuration, not MediaWiki. That's the first time I've heard it doesn't work on "most" installations.

(In reply to comment #8)

But it does work as expected. If it's not working for some sites (WMF and
translatewiki are ones I'm aware of), then that's an issue with their webserver
configuration, not MediaWiki.

Does the documentation specify that such a webserver configuration is a requirement for MediaWiki to run properly?

That's the first time I've heard it doesn't work
on "most" installations.

Have you tested the others? This link has just been introduced.

Cc Yaron who had objections similar to bug 38609 comment 7 on gerrit change 13558.

(In reply to comment #9)

That's the first time I've heard it doesn't work
on "most" installations.

Have you tested the others? This link has just been introduced.

I have tested mine, and it works for me. Reedy also confirmed it works for him in comment 5. It's impossible to test "most" or all installations, which is why I'm sceptical of your claim that most webservers have this problem.

(In reply to comment #9)

(In reply to comment #8)

But it does work as expected. If it's not working for some sites (WMF and
translatewiki are ones I'm aware of), then that's an issue with their webserver
configuration, not MediaWiki.

Does the documentation specify that such a webserver configuration is a
requirement for MediaWiki to run properly?

No, and it shouldn't do so. Such a file should always be sent as text/plain by default as far as I'm concerned.

(In reply to comment #11)

I have tested mine, and it works for me. Reedy also confirmed it works for him
in comment 5. It's impossible to test "most" or all installations, which is why
I'm sceptical of your claim that most webservers have this problem.

I've never claimed that, it was an if..then.

Does the documentation specify that such a webserver configuration is a
requirement for MediaWiki to run properly?

No, and it shouldn't do so. Such a file should always be sent as text/plain by
default as far as I'm concerned.

In my web experience it usually is not although some servers (and browsers) are smarter than others, but opinions aren't of much use, is there a standard defined for this? What is the default/most common apache configuration? Until someone checks this, the bug can't be closed WFM.

(In reply to comment #12)

In my web experience it usually is not although some servers (and browsers) are
smarter than others, but opinions aren't of much use, is there a standard
defined for this? What is the default/most common apache configuration? Until
someone checks this, the bug can't be closed WFM.

The default for Apache is none (https://httpd.apache.org/docs/current/mod/core.html#defaulttype ), which is what my one does. Chrome and Firefox just display the file.

As the CREDITS file already uses Wikisyntax, it should be rather trivial to implement a Special:Credits which would be well linkable.
If there's consensus for that I'm happy to write it ;)

An alternative would be to rename the CREDITS to CREDITS.txt, but that doesn't follow the naming scheme and would introduce new problems (eg. we would need to store two files to keep old links working).

Another option that just came to my mind is, that we could just list them all on Special:Version and maybe collapse it per default.

(In reply to comment #15)

Another option that just came to my mind is, that we could just list them all
on Special:Version and maybe collapse it per default.

No, that would make it significantly harder to refer to the authors (as it would be in the middle of a PHP file).

Parsing the wikitext from CREDITS sounds like a sane idea. Maybe as a subpage of Special:Version instead of a new special page.

  • Rename Special:Version to Special:About (separate issue) - this is overdue since the current name "Version" doesn't cover the contents (copyright, credits, authors, licensing, configuration, plugins, hooks, ..)
  • Create subpage Special:Version/credits that renders the CREDITS file.

We've been linking COPYING file for years, which has the same behaviour on misconfigured servers.

@mah This behaviour is not a 1.20 regression, please remove from "Known issues".

Converted this issue to a low priority enhancement.

(In reply to comment #16)

[...]
Parsing the wikitext from CREDITS sounds like a sane idea. Maybe as a subpage
of Special:Version instead of a new special page.

  • Rename Special:Version to Special:About (separate issue) - this is overdue

since the current name "Version" doesn't cover the contents (copyright,
credits, authors, licensing, configuration, plugins, hooks, ..)
[...]

Special:About sounds way to generic.

If it's about something like Special:AboutMediaWiki would be better... Special:SoftwareAbout, or maybe Special:PoweredBy.

+1 to using a subpage.

I already wrote the Special:Credits (I used a new page as Special:Version is a bit messy and this really doesn't belong.).

Renaming Special:Version IMO is another, unrelated issue.

I've put my change (Implement a new Special:Credits) to gerrit now https://gerrit.wikimedia.org/r/29523

I still consider it the cleaner solution over a sub page.

Special:Version is not a version page. So there is nothing wrong with this being part of it. Rather Special:Version the the page we have explicitly in charge of listing the license and contributors to the software so it is precisely where this belongs. Even if the name looks confusing till we fix our bad name.

I've now changed the patch to implement a Special:Version/Credits, though I still like the separate Special:Credits better.

Renaming Special:Version to whatever is a separate issue we shouldn't bother about here.

The change implementing Special:Version/Credits has been merged.

Re-opening this briefly. I really don't like the subpage ("Special:Version/Credits"). Can we please switch it out before we have to support it forever? :-)

Ugh, I just created bug 41556 for this exact renaming before I saw the comment.

Restoring previous status - let's use bug 41556 for discussing this.

Correction:
bug 41556: Rename Special:Version/Credits to Special:Credits
bug 41555: Rename Special:Version to Special:About

(In reply to comment #26)

Restoring previous status - let's use bug 41556 for discussing this.

Also restoring original summary, as it's what the status reflects.