Give access to the raw Message instead of only to the HTML or text in
the RequestContext language.
Pass Message objects instead of strings from calling ->text() as the
parameters of Messages so if the outer Message's language is changed
things get parsed sensibly.
Change-Id: Ibd6c1217b6fed839c888b66e02900f8e21ed3e6b
This was requested because of 0px thumbnail requests, but there are
other cases where parameters are detected as invalid and 400 is
semantically more correct than 500 in that situation.
Bug: T147784
Change-Id: I4d24a93e655f04d8119e77798d5df5a45caaafcf
Add new streamFileWithStatus() methods to FileRepo and
MediaTransformOutput that can be used to get more detailed error
information on failure. The historic streamFile() methods become sinple
wrappers to the new methods. Thumb.php is changed to use the
streamFileWithStatus() methods so that failure reasons can be logged.
Change-Id: I3088cde2044a7ff00841e53ca252d0b222c8b518
Added a TransformTooBigImageAreaError to allow setting an extra message.
Added also size-*pixel messages to show the value of $wgMaxImageArea
with some formatting.
This error is still throwing for all files, to fix bug T34387 this needs
a follow up with a proper check. I am not sure, if a File::isLocal() is
okay, because files from a DBForeignRepo maybe transformed on the same
server, so the check needs to be done also for this. For APIForeignRepo
the check is done on the foreign server.
Change-Id: Ieba12e424c8bddb1961a30d3f9ea5c8ff241abb5
If an image has a title but isn't linked, set the title on the image
itself rather than not setting it at all.
Bug: T23454
Change-Id: I6302246cf28c84ade805a6a7d4a5e131b6f42e86
Due to use of empty(), the alt and query value was stripped and
replaced with an empty string if the input was "0".
Bug: 38910
Change-Id: I1aef143fc45eb1357e200ad2fcb488dc4876ffbd
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I8ebfbcea0e2ae2670553822acedde49c1aa7e98d
* Previously, the resulting thumbnail did not handle hasFile() and
stream() properly. This effected doCachedWork() in thumb.php
Change-Id: I8fd025204b5b41472be6c09924892fe8ee9dd260
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I7f605aa9e117b5fd80d9b1440864fe526d2b14a5
This extension adds a "mode" parameter to the gallery
tag, allowing different formats for the gallery tag
(galleries in the ui can be controlled by a global)
The added modes are:
*traditional - The original gallery
*nolines - Like the original, no borders, less padding
*packed - All images aligned by having same height.
JS also justifies the images.
(I think this one is the one that will go over best
with users.)
*packed-overlay - like packed, but caption goes over
top the image in a transloucent box.
*packed-hover - like packed-overlay, but caption only
visible on hover. Degrades gracefully on screen
readers, and falls back to packed-overlay if
you are using a touch screen. I kind of like
this mode when the caption is not that important
(ex a category where its just the file name).
This also adds a hook to allow people to make their
own gallery version. I believe there would be interest
in this, as different people have done different
experiments. For example:
* Wikia: http://community.wikia.com/wiki/Help:Galleries,_Slideshows,_and_Sliders/wikitext
* Wikinews: https://en.wikinews.org/wiki/Template:Picture_select
What I would like to see for this patch, is first it gets
enabled, with the default still "traditional". After
about a month or two we consult with users. If feedback
is positive, we change the default mode to one of the
others (probably "packed").
Adds a "mode" parameter to gallery for different
mode, including one 'height-constrained-overlay'
which looks much more like other modern websites.
Note: This makes one change to the old gallery format.
It makes Nonexistent files be rendered like thumbnails
(i.e. they are rendered with a little grey border).
One thing I'm slightly worried about with this patch,
is that I added an option to MediaTransformOutput::toHtml
to override the width attribute. I'm not sure if that
is the best approach, and would appreciate thoughts
on that.
This should be merged at the same time as Ie82c1548
Change-Id: I33462a8b52502ed76aeb163b66e3704c8618ba23
See bug for context.
The implementation is slightly untidy because I've written it so
as to avoid invalidating the existing SVG thumbs -- there will be
no immediate difference (visual/performance/other) as a result of
this.
Tested by me in both...
* [[File:Example.svg|thumb|lang=fr]] AND
* http://example.org/w/index.php?title=File:Example.svg&lang=fr
...modes. Example file on
https://commons.wikimedia.org/wiki/File:Gerrit_patchset_25838_test.svg
Added parser tests.
Bug: 32987
Change-Id: I4cadf96ecd5e169a88ad468a0478d355db980103
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Adds a new hook, ThumbnailBeforeProduceHTML, to ThumbnailImage::toHtml
method, in order to permit the user to manipulate the image and link
attributes before the HTML is rendered. For details see bug 41835
Note: Patch given by Victor <vdanilchenko@vistaprint.net>
Change-Id: Ib94967997e1303522d0081c7387e29af9c0ef0f0
By standardising the file parameters were handed around, the normalised
parameter "page" (set to 1) is being passed to the linker. Since
it's the default, I don't think we really need it in the link, where
it is (a) meaningless and (b) confusing, since it is set for some
media types that don't even have pages (e.g. SVGs).
Change-Id: Ib80a85125366ec32ab05b061b06d28144dc244fc
* adds $wgResponsiveImages setting, defaulting to true, to enable the feature
* adds 'srcset' attribute with 1.5x and 2x URLs to image links and image thumbs
* adds jquery.hidpi plugin to check pixel density and implement partial 'srcset' polyfill
** $.devicePixelRatio() returns window.devicePixelRatio, with compat fallback for IE 10
** $().hidpi() performs a 'srcset' polyfill for browsers with no native 'srcset' support
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images load
Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6, Chrome 21, Firefox 18 nightly on MacBook Pro Retina display, and IE 10 in Windows 8 at 150% zoom, 200% zoom, and 140% and 180%-ratio Metro tablet sizes.
Internally this is still a bit of a hack; Linker::makeImageLink and Linker::makeThumbLink explicitly ask for 1.5x and 2x scaled versions and insert their URLs, if different, into the original thumbnail object which (in default handler) outputs the srcset. This means that a number of places that handle images differently won't see the higher-resolution versions, such as <gallery> and the large thumbnail on the File: description page.
At some point we may wish to redo some of how the MediaHandler stuff works so that requesting a single thumbnail automatically produces the extra sizes in all circumstances. We might also consider outputting a 'srcset' or multiple src sizes in 'imageinfo' API requests, which would make ApiForeignRepo/InstantCommons more efficient. (Currently it has to make three requests for each image to get the three sizes.)
Change-Id: Id80ebd07a1a9f401a2c2bfeb21aae987e5aa863b
This is required for a full resolution of bug #32987. Per Brion's
commentary on that bug, for the long-term preservation of
sanity we can't just keep adding arguments to the constructor
whenever a new feature is added.
Instead, we can have an array of optional parameters. At the moment,
this situation is a bit iffy for width and height: we should really
specify either a default height / width or error if one is not found.
I'm open to ideas on that, but it's not a big deal since nothing
uses the new syntax yet. When that is agreed, I'll convert all usage
in core and maybe some extensions too.
Change-Id: I116f71aeb90ef7c786f0874b150c7bcca527e106
Add Parser's extLinkAttribs attributes when an image has a link
parameter, when generating the html. Currently, these may include
rel="nofollow" and the target attribute.
This will correctly add rel="nofollow", respecting $wgNoFollowLinks,
$wgNoFollowDomainExceptions, and $wgNoFollowNsExceptions settings.
Updated parser tests for expected results, added new tests for
$wgNoFollowLinks and $wgNoFollowDomainExceptions exceptions.
Change-Id: Ib4677760ec78a3f0c4ba781d893e0484cc8db3ed
* Added MediaTransformOutput::getExtension() function and use it instead.
* Also fixed getScriptedTransform() to not pass the page as the path parameter.
Change-Id: I6c530aa155d62a6bfd5727c6f3d104fe91453745
When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
* Updated outputLocallyScaledThumb() and outputLocalFile() to handle changes in r106752.
In MediaTransformOutput:
* Added a storage path field to the transformation output object and set it in File::maybeDoTransform().
In File:
* Fixed maybeDoTransform() handling if repo member is not set and made it fully respect $wgIgnoreImageErrors.
In BitmapHandler:
* Don't set bogus path if TRANSFORM_LATER in doTransform() for deffered renderings.
This shouldn't cause any back or forward compat issues since php treats method names as case-insensitive. So this change shouldn't break any old extensions, and extensions are free to start using getLinkURL and won't have any issue breaking with old versions of MediaWiki.
