A link to a non-existing file like
[[File:To be uploaded.jpg|right|300px|Text]]
returns a redlink with "300px" as link text. Instead it should be "To be uploaded.jpg".
http://www.mediawiki.org/wiki/User:Subfader/Watch_Test_2
This behaviour makes no sense at all...
Found it in 1.16.5 and 1.17 trunk. Did not behave that way in 1.16a.
Version: unspecified
Severity: normal
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| images: Use registry based caching where available | repos/releng/kokkuri!19 | dduvall | review/registry-caching | main | |
| Test using reggie as a buildkit cache | repos/releng/scap!28 | dancy | review/dancy/use-reggie-for-buildkit-cache | master | |
| ci: Build and publish a new image version for every tag push | repos/releng/reggie!5 | dduvall | review/build-and-publish-on-tag-push | main | |
| Populate the deleteme repo w/ scap's code and an experimental gitlab-ci.yml | dancy/deleteme!2 | dancy | review/pulled-in-scap | main | |
| buildkit: Handle client cache import options | repos/releng/blubber!32 | dduvall | review/handle-cache-imports | main |
your mw.org sample page shows a redlink with "300px" only when you have no "Text". Was that intended?
Default install of 1.16.0 shows the same behavior as MW.org
Default install of 1.15.5 shows no redlinks and "To be uploaded.jpg" as the link text in all cases.
I'm not sure what you mean by "1.16a" as I can't find that version at http://dumps.wikimedia.org/mediawiki/1.16/
You are against all bugs I report. That's annoying.
You are right, it's not a bug, it's a feature.
(In reply to comment #2)
You are against all bugs I report. That's annoying.
You are right, it's not a bug, it's a feature.
Mark's reply doesn't contain anything to suggest that this isn't a valid bug ?
(In reply to comment #2)
You are against all bugs I report. That's annoying.
Please don't interpret my response as being "against" you.
What you've reported is not a regression -- it didn't have non-buggy behavior in the past that you want to restore, AFAICT. That is why I've marked this "enhancement" -- you are requesting new behavior, a feature request.
I apologize for the offense I've caused by marking this feature request as "lowest" priority. There is a workaround, the pipe trick:
[[File:To be uploaded.jpg|300px|]]
which shows "File:To be uploaded.jpg". Because of this workaround, I feel it doesn't deserve a lot of the WMF's attention.
But its a feature request and this is open source software. You, or anyone else that has the capabilities can submit a patch to get the behavior you want. I'll even apply it after reviewing it.
I'm not request an enhancement change.
As you already realized it wasn't that way before 1.16.0 (like 1.16alpha and 1.15.X).
"Default install of 1.15.5 shows no redlinks and "To be uploaded.jpg" as the link text in all cases."
Yes, and that's how it's expected to work. "300px" as link text in my test examples makes no sense at all, esp since it's a redlink to the upload form.
I'm using templates for article creation like this: http://www.mediawiki.org/w/index.php?title=User:Subfader/Watch_Test&action=edit&preview=yes
and a workaround like [[File:To be uploaded.jpg|300px|]] would add false syntax to all pages and is also no solution to this bug which could easily be solved to the way it was.
As you already realized it wasn't that way before 1.16.0 (like 1.16alpha and
1.15.X)."Default install of 1.15.5 shows no redlinks and "To be uploaded.jpg" as the
< link text in all cases."
Yes, and that's how it's expected to work.
Are you saying no redlinks is expected?
1.15 was released 2 years ago. Meanwhile, 1.16 has been out over a
year (and live on WMF sites for longer) and 1.17 is out now. I think
redlinks on un-uploaded files are expected now.
If you're fine with the redlinks, then it seems were just quibbling
about the link text. And, I agree that having “NNNpx” in the link
text is not desired. But there is a workaround.
a workaround like [[File:To be uploaded.jpg|300px|]] would add false syntax
to all pages and is also no solution to this bug which could easily be solved
to the way it was.
If you know this is so easily solved, then you can solve it. Patches
welcome! I've previously spent a substantial amount of fixing a link
bug, only to have my work reverted (see Bug #542), so I am personally
aware of how careful we have to be about these things.
Incidentlly, “Patches welcome!” isn't a way to say “go away”. I
really mean it — I want more people involved and contributing.
“Patches welcome!” does mean “I don't think we have time to track down
and solve what appears to be a minor problem, but you have the source
code and this bug database to provide any patches you can come up
with. We'll integrate your fixes if they meet our quality standards.”
"Are you saying no redlinks is expected?"
No I don't rolleyes
Well, I would like to fix it if someone told me where in the source code the links are generated.
Well, I would like to fix it if someone told me where in the source code the
links are generated.
I don't know offhand. I've asked someone on IRC to update this bug
witht the location, but if that doesn't happen soon, feel free to pop
into MediaWiki-General and ask.
Bryan.TongMinh wrote:
The code is in includes/parser/Parser.php and includes/Linker.php. The relevant functions are Parser::makeImage() and Linker::makeImageLink2().
I'm going to make a guess, but the code is too complicated to fully understand what is going on without extensive debugging. In Parser::makeImage() fetchFileAndTitle() returns false, because wfFindFile() does not find the file. getImageParams() returns a parameter map which does not provide the width magic, causing the 300px to be not recognized as a width parameter, thus causing it to be interpreted as text.