- use tab as indent instead of spaces
- Added space after closures "function"
- Added spaces around string_concat
- Added newline inside empty blocks
- Removed four spaces after comma
Change-Id: I4425b0c6a69b36f40acfea6511b8950cf09ce2b2
Follows-up 5ca94d2d26.
In thumb.php an undefined variable ($width) was used, triggering
fatal errors while processing requests that were passing thumbnail
width with px (pixel) suffix.
Change-Id: I2dc4f4d2979f8225d2a6211ec50cdc79438539a9
Otherwise if there is a broken file, and somebody fixes the file,
it could take an hour before thumbs are generated again. This
might confuse the user, and they may revert back to the broken
version thinking their fix didn't work.
Originally reported by Fae on wiki.
Change-Id: I024702391e5f7ccf10a406a29485601f64069405
Depends on Ic62984e0f4a761642b2bdd1bfa362301ed94c284
and If40e223c328ddd15310d13f2a49000bf6e08200e
Bug: 65691
Change-Id: Ic737673b5a31974d866b9bf5afa4b4036baa03bb
A large percentage (40-50%) of the 500s that are emitted in production
are for a single URL,
https://commons.wikimedia.org/w/thumb.php?f=Crystal_Clear_action_viewmag.png&width=21px
The reason this fails is because thumb.php expects width to be "21", not
"21px", and it currently tries to fetch (and generate) the "21pxpx"
thumb size, which is obviously an invalid size. (an invalid size
shouldn't result in a 5xx but rather to a 4xx. though; that's a separate
bug that needs to be fixed).
This URL is embedded by a gadget, Gadget-searchbox-js, that is copied in
a lot of our wikis, including a big one, frwiki. mwgrep reveals that
there are a bunch of other URLs in various Gadgets that have width
values with "px" in them, so this presumably worked at some point in the
past.
While we could in theory fix all those URLs in these dozens of gadgets
across wikis to not suffix width with "px", this sounds like a herculean
effort and we're probably better off adding this compatibility branch to
thumb.php that strips the "px" suffix, if existent.
Change-Id: I3a00c9634b1c6af49fb8503cc3ff4cafdaff6b43
* Generally, either the height or width is used for each description page
link when using $wgImageLimits. This depends on the $wgImageLimits values
and the file dimensions. Description page links should better pass the
wfThumbIsStandard() method now, and thus have weaker rate-limiting.
Change-Id: Id1c3b0fc57f8ed3c14929a1a1661842a069b805d
* Now thumbnails with default lossy/lossless values will still count as "standard",
for example. This makes use of the file media handler.
Change-Id: Ia69301dfbf85bb26a17f8eee0939d690021343ec
* This can limit how many workers work on a given file at once,
regardless of which specific thumbnail parameters are requested.
* Also added a BagOStuff::incrWithInit() method per DRY.
* Tweaked the register_shutdown_function() callback to avoid
File/MediaTransformOutput references, since they may involve
TempFSFile objects.
Change-Id: Ic01461cb974ab23b179ac3b60cf6de12e36360f6
* Specifically check isDeleted() instead of relying on the file
being moved to the deleted zone alone.
* Made img_auth.php skip some unnecessary checks for public wikis.
Also made it set the private cache control headers only if needed.
Change-Id: If82589acd53c02943d5f3bbafd29381fd63f8f68
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.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
This parameter triggers Content-Disposition: Attachment which
makes the browser download the image instead of displaying it.
This is needed by Media Viewer to allow users to click a button in
order to download an image at a given resolution or the original.
Change-Id: I470a24a09139ac65588312104995e34d97a89b0f
This should fix most of the "No width specified" exceptions. I guess
most of this code will be rewritten to fix bug 56926, superseding this
patch, but I thought this might be a useful stopgap.
Bug: 56924
Change-Id: I5bcaaafc81e1e2a8a33819fa64790d5509dc6aa6
Return type of $handler->parseParamString() wasn't evaluated,
instead $handler value was compared again
Bug: 55437
Change-Id: Iedb940d9f1ad4d137b9732e7e624e55d05bc2c96
Only added if $wgShowHostnames is on. Adding the host name as a
header makes it much easier when debugging with command line tools,
since one often throws away the response body. This still keeps
the host name in an html comment in the response body as well,
like it was previously.
Change-Id: I9d15bd5e2abb4e7a8d3fe2a17fc546a1c5f3b70f
Use MediaHandler::parseParamString to parse the parameter string
of a thumbnail. This seems to make much more sense given the
design of the Handler class. Also mark ExtractThumbParameters hook
as deprecated.
This should be reviewed by someone familar with the 404 thumbnailing
infrastructure. I'm unclear if there was a reason for why it wasn't
using MediaHandler::parseParamString in the first place.
Bug: 49629
Change-Id: I43a0e7d6f0e45536e4e24b72140157791f5f027f
See bug 22390 for some of the background. Basically there's two
reasons why we want this:
* Hotlinkers to commons. We don't want to break their links when
we move a file (Wikimedia blog is a prominent hotlinker)
* Cached entires. On wikis using commons files, a file move doesn't
trigger HTMLCacheUpdate jobs for the downstream wiki (it only
triggers it on commons). This means that these pages will still
use the old version of the html (with img tags that have the old
url) until the next edit or purge action. But these urls won't
work as soon as the file is moved.
I'm pretty confident that redirects will work at this point
in the thumb stack, as the redirects for long file names work
fine (provided no thumb exists in swift with the wrong name).
Change-Id: I40350121cf902f66fcbd3cf788335a988fa7ee33
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
hphpc has been superseded by hhvm, so support for hphpc is no longer
needed.
* Continue to use Preprocessor_Hash under HipHop since it is still
faster under hhvm
* Keep $wgCompiledFiles for now, so that wikihiero doesn't give an error
before Ic9d1e795 is merged
* Migrate the run-server script and associated configuration file to
hhvm. Enable EnableStaticContentFromDisk since it doesn't seem
ridiculously inefficient at first glance. Run from $IP rather than
$IP/.. since hhvm is apparently not picky about sourcing files from
outside of the current directory.
Change-Id: Ic3e769f1fbad4f7ad26dd819406796fee48c6b45
* Using $_REQUEST is bad since cookie data is also in there.
* Also made a few tiny code cleanups.
Change-Id: Ib7064b95a2788484d05cf457034fe1d5be298bc4
* Made thumb_handler.php "just work" in a way similar to img_auth.
It no longer needs any "handlerUrl" setting to be set.
Change-Id: I557ba1f94db3cef0f21f5c0e2b60d8e381ea3f96
ExtractThumbParameters might be able to extract more params but still
match the local regexp. To be able to extract all params, check
ExtractThumbParameters first and only fallback to regexp.
Change-Id: I26efdec1af5fb2bd5e3cc503f36692d12668b2e2
