The combination of $out->addHTML() and the super call cause action=render for
File pages to have the text rendered twice. Wikis get commons descriptions via
action=render, so they were showing the description text twice.
This reverts commit ca13fde652.
Conflicts:
RELEASE-NOTES-1.20
Change-Id: Ib1072fd1d109c0d6706215ccad1413dd72cb201d
This changes action=render on file pages to include the shared image
description (if it exists). The reasons for this are two fold:
*Logically, most users would consider the shared description part of
the content of the page, and not part of the site chrome, so it
should be on action=render
*Foreign file repos use action=render to get image descriptions.
if you use say en.wikipedia.org as your file repo, commons images
get cascasively included, but all their descriptions end up
being the noarticletext message, which is bad. This makes
the shared image descriptions work.
Some notes on the implementation:
* on action=render the div containing the shared description
doesn't have the id that the one on normal page view has.
This is to prevent duplicate ids in the cascading repo scenario.
I added a class so people can identify them if they want, and this
allows people to easily identify the "outermost" shared description
as it would be the only one with the id.
* This doesn't include the "shareddescriptionfollows" message
(which is disabled by default) that would normally separate the
local from the non-local description. I wasn't sure, but thought
that would be considered part of the site chrome.
Patchset 2/3: trailing space/spelling mistake
Patchset 4: rebase
Change-Id: I18bdf29de62526d699740607b5015da4b01fd43d
Instead, show some text explaining that they cannot upload here.
Also remove a linebreak which someone complained about recently.
Change-Id: I92ab8ad5eebcdd38c0d5d9f7bab7d11e5c844586
This shows a warning on the image description page if the image
is animated, but thumbnails won't be. This includes
gif images that are too big, but also svg images that are animated,
and APNG files.
The message used is file-no-thumb-animation, but will also
check for file-no-thumb-animation-<image extension> so that
admins can do per image type explanations. Gif files have a built-in
explanation that is slightly different (Since its do to resolution).
Ideally one would pass the resolution limit to the gif message,
but I couldn't think of a clean way of doing that. (Also might be
complex to explain to user. They aren't used to resolution as a single
number but as a width x height type thing).
Moves isAnimatedImage from ImageHandler to MediaHandler, so I could
safely use it from any handler class.
Change-Id: I42ee11d889e0c41de53d0951f55a4338ca55311d
* Don't do expensive checks for display (for the consistency of the interface)
* Removed the logged-in check and changed it for 'upload' right (as the user need this right to execute the action)
Change-Id: Ie5752e5292a953cbcf81ab665365c3efbd4eba6a
* For some reason, when 404 handling is off, all the links for
$wgImageLimits were still generated but not put into the HTML.
They still triggered convert() calls - 7 times by default.
Change-Id: I0d12c7ec3c02039c1307a1a1d04d1d1cbd44b547
* Use context everywhere
* Fix comments, including two functions from other files it references
* Remove pointless function return value
Change-Id: I29a0a2a54432c8ef7185a210c7f2f73c64bfb71c
If the dirmark is immediately adjacent to the file name, the user
may copy it with and then paste an unneeded dirmark somewhere.
It can be adjacent to the file description, however.
Patch set 2: using getDirMarkEntity, according to MaxSem's suggestion.
Change-Id: I9567a90e9a4b32cdf31af5f26044c8f80961f986
Currently things outside of file namespace display the snippet, so file ns should display snippet for completeness. As far as I can tell, the only reason files don't is because ImagePage class overrides the Article class, and it was unintentional that the snippet was not included in ImagePage class.
ImagePage no longer needs to set the "redirectedfrom" header by itself. Seems Article.php is taking care of it now. I suspect this was caused by the refactoring of WikiPage, Article, etc.
Before it would get truncated when inserted into the 255 byte db field. This is bad as it can leave dangling multi-byte unicode sequences, additionally, since directly after upload we appearently cache the file object, this can result in the comment in the file history table being super-huge.
This also removes the parenthesis in the comment field in the table. Its a table, we don't need to use () to visually separate it from the rest of the page content.
This commit also causes '...' (or the i18n'ed equivalent) to be appended when truncated a comment. Previously that didn't happen. Also I changed it to use a method that doesn't check for '*' as a special value to mean no description. I looked at the toolserver db, and even uploads to enwikipedia from 2002 don't use '*' as special no-description marker.
* Moved $wgUploadMaintenance check after permissions and read only, so that the user doesn't think the error is temporary if he both doesn't have the permission and $wgUploadMaintenance is true
* Show normal error page when $wgUploadMaintenance and added a message for the error title
* Moved watchlist updating to FileDeletForm::execute(), it has nothing to do in doDelete() (would also be executed for api requests, etc.)
* Added $user parameter to FileDeletForm::doDelete() to pass the user doing the action
* Use WikiPage instead of Article
* Removed OutputPage::setPageTitleMsg() and OutputPage::setHTMLTitleMsg() and make OutputPage::setPageTitle() and OutputPage::setHTMLTitle() accept a Message object
* Updated core calls (including some that I missed last time because of non-matching case)
* Added Message::setContext() and use it in RequestContext so that I don't need to duplicate the call in OutputPage
* Yes, I'm calling $this->msg() on places and then setting the context one more time in OutputPage::setPageTitle() or OutputPage::setHTMLTitle(), but at least I won't be confused about which objects $
