Last modified: 2013-04-22 16:15:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42641, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40641 - Link to CREDITS on Special:Version should not trigger a download dialog
Link to CREDITS on Special:Version should not trigger a download dialog
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: 1.20.x release
Assigned To: Nobody - You can work on this!
http://translatewiki.net/w/CREDITS
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-30 15:56 UTC by Niklas Laxström
Modified: 2013-04-22 16:15 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Niklas Laxström 2012-09-30 15:56:46 UTC
Clicking "others" in Special:Version asks to download a file.
Comment 1 Jesús Martínez Novo (Ciencia Al Poder) 2012-09-30 16:09:17 UTC
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 ]
Comment 3 Alex Monk 2012-09-30 16:12:05 UTC

*** This bug has been marked as a duplicate of bug 38609 ***
Comment 4 Niklas Laxström 2012-09-30 18:55:25 UTC
Unduplicating. Fixing Apache on WMF wont fix it for other installations out there.
Comment 5 Sam Reed (reedy) 2012-09-30 20:48:51 UTC
(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
Comment 6 Alex Monk 2012-09-30 20:53:06 UTC
(In reply to comment #4)
> Unduplicating. Fixing Apache on WMF wont fix it for other installations out
> there.

In that case it's WFM.
Comment 7 Nemo 2012-10-02 15:22:37 UTC
(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.
Comment 8 Alex Monk 2012-10-02 15:25:59 UTC
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.
Comment 9 Nemo 2012-10-02 15:32:43 UTC
(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.
Comment 10 Nemo 2012-10-02 15:58:32 UTC
Cc Yaron who had objections similar to bug 38609 comment 7 on Gerrit change #13558.
Comment 11 Alex Monk 2012-10-02 16:19:31 UTC
(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.
Comment 12 Nemo 2012-10-02 16:29:04 UTC
(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.
Comment 13 Alex Monk 2012-10-02 16:38:33 UTC
(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.
Comment 14 Marius Hoch 2012-10-02 17:20:56 UTC
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).
Comment 15 Marius Hoch 2012-10-02 17:23:10 UTC
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.
Comment 16 Krinkle 2012-10-22 23:18:48 UTC
(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.
Comment 17 Krinkle 2012-10-22 23:21:15 UTC
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.
Comment 18 Daniel Friesen 2012-10-22 23:34:35 UTC
(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.
Comment 19 Marius Hoch 2012-10-22 23:39:10 UTC
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.
Comment 20 Marius Hoch 2012-10-23 00:37:10 UTC
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.
Comment 21 Daniel Friesen 2012-10-23 02:39:05 UTC
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.
Comment 22 Marius Hoch 2012-10-23 14:54:59 UTC
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.
Comment 23 Marius Hoch 2012-10-28 22:37:51 UTC
The change implementing Special:Version/Credits has been merged.
Comment 24 MZMcBride 2012-10-30 15:40:34 UTC
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? :-)
Comment 25 Bartosz Dziewoński 2012-10-30 15:50:17 UTC
Ugh, I just created bug 41556 for this exact renaming before I saw the comment.
Comment 26 Andre Klapper 2012-10-30 16:00:12 UTC
Restoring previous status - let's use bug 41556 for discussing this.
Comment 27 Andre Klapper 2012-10-30 16:01:06 UTC
Correction: 
bug 41556: Rename Special:Version/Credits to Special:Credits
bug 41555: Rename Special:Version to Special:About
Comment 28 Nemo 2012-11-01 12:14:02 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links