| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deprecate the interfaces in MimeAnalyzer that return lists as
space-separated strings in favor of replacement methods that return
arrays.
Deprecated:
- ::getExtensionsForType( $mime ) : string|null
- ::getTypesForExtension( $ext ) : string|null
- ::guessTypesForExtension( $ext ) : string|null
Added:
- ::getExtensionsFromMimeType( $mime ) : string[]
- ::getMimeTypesFromExtension( $ext ) : string[]
- ::getExtensionFromMimeTypeOrNull( $mime ) : string|null
- ::getMimeTypeFromExtensionOrNull( $ext ) : string|null
- "From" is clearer than "For"[1] and is neatly symmetrical with "To"
(viz. ::mExtToMime and ::mMimeToExt).
- "MimeType" is less ambiguous than "Type", which in this context may
refer either to media type or MIME type.
- "{..}OrNull" is better because it helps users remember to handle a null
return value. Putting the "OrNull" at the end (getXFromYOrNull) is
better than putting it in the middle (getXOrNullFromY) because it's
harder to ignore that way, at the cost of a very slight grammatical
ambiguity.
Usage in Core will updated in a separate commit.
Lastly, this change prepares for the deprecation of mutating the public
'mExtToMime' attribute as a means of registering extensions. It will be
formally deprecated in a follow-up change.
[1]: Positive signal: https://developer.android.com/reference/android/webkit/MimeTypeMap#getMimeTypeFromExtension(java.lang.String)
Bug: T252228
Change-Id: I93bd71ec18492722f05c66e0a2945d93281c3100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, MimeAnalyzer builds the internal mappings of MIME types <=> file
extensions by concatenating several string buffers in mime.type format into a
giant string, and then parsing it. The mapping of MIME types to internal
media types is built up in a similar way, except we use a dubious homegrown
format with undocumented conventions. It's a mess, and an expensive one --
~1.5% of api.php CPU time on the WMF cluster is spent building these buffers
and parsing them. Converting the mappings to PHP associative arrays makes
them much cheaper to load and easier to maintain.
Doing this without breaking compatibility with existing behaviors requires
some delicate footwork. The current mime.types buffer is made up of the
following fragments, in order:
1) MimeAnalyzer::$wellKnownTypes
2) If $wgMimeTypeFile == 'includes/mime.types' (sic!):
the contents of includes/libs/mime/mime.types.
If $wgMimeTypeFile is another file path (e.g., '/etc/mime.types'):
the contents of that file.
If !wg$MimeTypeFile, this fragment is blank.
3) MimeAnalyzer::$extraTypes (populated by extensions via hook).
The mime.info buffer is built up in the exact same way, except it's
MimeAnalyzer::$wellKnownInfo, $wgMimeInfoFile, and MimeAnalyzer::$extraInfo.
What this means in effect is that some built-in MediaWiki MIME mappings are
"baked in" (anything in MimeAnalyzer::$wellKnown*), and others can be
overridden (anything in includes/libs/mime/mime.*).
To avoid breaking backward compatibility, we have to preserve the
distinction. Thus this change has two MIME mappings, encapsulated in two
classes: 'MimeMapMinimal', which contains just the baked-in mappings, and
'MimeMap' which contains both the baked-in and overridable mappings. We also
have to keep the code for parsing mime.types and the ad-hoc mime.info format,
at least for now.
In a FUTURE change (i.e., not here), I think we can:
* Deprecate $wgMimeTypeFile in favor of a new config var,
$wgExtraMimeTypeFile. $wgMimeTypeFile is evil because if you are using to
add support for additional MIME types, you can end up unwittingly dropping
support for other types that exist in MediaWiki's mime.types but not your
file. The new $wgExtraMimeTypeFile would only be used to add new MIME
mappings on top of the standard MimeMappings, which was probably the
original intent for $wgMimeTypeFile.
* Deprecate $wgMimeInfoFile. I don't think we need to provide a replacement,
because extensions can use the hook, and I doubt anyone is using the config
var. But if we wanted to provide an alternative, we could have a
$wgExtraMimeInfoMap that has an array of extra mappings.
* Deprecate MimeAnalyzer::addExtraTypes and MimeAnalyzer::addExtraInfo, and
provide alternative interfaces that take structured input instead of string
blobs.
I tested this by dumping the internal state of MimeAnalyzer before and after
this CL using the script in Ib856a69fe, using both default and custom values
for $wgMimeInfo(File|Type).
Bug: T252228
Change-Id: I9b2979d3c9c0dee96bb19e0290f680724e718891
|
|
|
|
|
| |
Bug: T233992
Change-Id: Ie401180ac968210c9f923ad920bf15955c8551d7
|
|
|
|
| |
Change-Id: I0acca592c6909e91b28b904da49dcbd6a43cd2a5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove code paths that were unreachable for me.
* Remove display_errors/error_reporting overrides.
These can be set as-needed from LocalSettings.php if desired,
and similar (but slightly different) settings are already set
by DevelopmentSettings.php.
* Default to text/plain instead of letting PHP handle it.
This makes makes the result more predictable, instead of varying
by PHP version and underlying OS behaviour. Anything we want to
support is already in our 'mime.types' file, and ours is a
superset of PHP's anyway.
Change-Id: I46608ebd8e225642cfeb804ec32739c2fcbd4d25
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using the PHP built-in webserver with maintenance/dev/start.sh,
requests made to regular files do show in the console output but
requests to .php files do not log anything in the console. It is a bit
annoying since one is left wondering whether the requests are actually
honored.
The reason is the request router maintenance/dev/includes/router.php
does a require of the PHP file and abort the router (return true). That
causes the built-in php server to not produce the access log requests.
Based on the comment note, some earlier PHP version had POST data
stripped preventing login. The related upstream bug is
https://bugs.php.net/bug.php?id=60159:
"Router returns false, but POST is not passed to requested resource"
750eac7e41d introduced the workaround on Nov 24th 2011. PHP 5.4.0 got
released in March 2012 and refers to that bug. The development of our
router thus must have used a development/beta version of PHP 5.4.
Since the fix made it to the PHP final release, there is no need for
workaround anymore.
Bug: T190503
Change-Id: Ia8c4f1610ea0ef5b04ea30d6e91199b8e597065b
|
|
|
|
| |
Change-Id: I1d52f60c20317efb3c36763fd47be09dc6dd57dd
|
|
|
|
| |
Change-Id: I9304d830744238e4733240dd65c285fed61d0416
|
|
|
|
|
|
|
|
|
| |
It has been stuck on 5.4 since it was added to the repository
in 9e25a8e32e6d. It also contained some typos and updating
the version required multiple changes, so that has been fixed.
Bug: T165079
Change-Id: I30b4d6d0701dc60651d3c07fd364312a78a45800
|
|
|
|
|
|
|
|
| |
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
|
|
|
|
|
|
|
|
|
|
|
| |
* The later resides in /libs with related files.
* Explose MimeAnalyzer as a service.
* Keep MimeMagic::singleton() as a b/c alias.
* MimeMagic::applyDefaultConfig() will bootstrap the service
with all of the old config, extension hook handler, and
detector command shell-out behavior.
Change-Id: Ie2695a52e7a3bcfda9f7fa83659a9ff31b372bc3
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are not meant to be complete shell scripts, so
shebang lines don't really make sense here. Rather, as
noted by the author (Daniel Friesen), scripts in the
parent directory include these files using the "source"
or "." command.
This reverts commit 96e0ed45a81dfb4783c74353a8e70d0b926ad900.
Change-Id: I7a0b7bb2a5ea1b1c141cb36f38736fe562b22c10
|
|/
|
|
| |
Change-Id: I51391f45d0f81e4245ccc0e435a71ccd5b0e3ca3
|
|
|
|
|
|
| |
I hope these are the last ones.
Change-Id: I281531d8f90932b2cb4a8a99554d4b80607fbaee
|
|
|
|
|
|
| |
Writing MIME as written in Wikipedia and some documentation clean up.
Change-Id: I9dfc36d2bf55d72d9374c4075bd6d45eef0415a4
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
* shellcheck script used: https://github.com/koalaman/shellcheck
* includes/php.sh: Use $(..) instead of deprecated `..`.
Change-Id: Ie1dfff97b548aca75d76c762b74f8fcab84d46fb
|
|/
|
|
| |
Change-Id: I2b791d3bff0de464b6bdaaeae0622c065389c31c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
|
|
|
|
|
|
|
| |
Added spaces before if, foreach
Added some braces for one line statements
Change-Id: I9657f72996358f8c1c154cea1ea97970d973723c
|
|
|
|
|
|
|
|
|
|
| |
The PHP_SAPI constant has been available since PHP 4.2.0. It's more
concise to use the constant and has less overhead than a function call.
Furthermore, PHP_SAPI rhymes with "happy", whereas "php_sapi_name"
rhymes with "lame". QED, etc.
Change-Id: Ie8c121cb8fcef50536af8d3f66723b458f0bf9af
|
|
|
|
| |
Change-Id: I46a2611cccf9bd7af20be5fcc497c0dacc13cbb7
|
|\
| |
| |
| | |
Change-Id: I8e953eaa22f9d331b0af5e780fbeff6d702b23e3
|
| |
| |
| |
| | |
Change-Id: I768abad1ad4642263519d39c50c88437aed47e15
|
| |
| |
| |
| | |
Change-Id: Id78f14c220bbaa21b78c0c669a324f6169b3109d
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Add php binary and a program which might
be set as $PHP.
- Check for the correct php version.
The break shell builtin is not too commonly used,
but should beperfectly safe to use, since it's specified by POSIX
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#break
Change-Id: Iefbe991426f0e9a7178363a30b613f57110e1953
|
| |
| |
| |
| | |
Change-Id: I36b7f2f63ab8c08f8412d521dc68ea45c8b67711
|
|/ |
|
|
|
|
|
|
|
| |
cli-server sapi.
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/114324
|
|
|
|
| |
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/111566
|
|
|
|
| |
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/105822
|
|
|
|
|
|
|
|
|
| |
- Update maintenance/dev/ to install php inside ~/.mediawiki/php instead of ~/.mwphp
- Tweak README a bit
- Move the router.php into an includes along with two helper .sh files to cut out some of the repetition
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/105821
|
|
|
|
| |
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/105092
|
|
|
|
|
|
|
| |
/wiki/File:Foo.png which end up with a SCRIPT_NAME but not SCRIPT_FILENAME.
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/104148
|
|
|
|
|
|
|
| |
discarded and you can't login inside the dev environment.
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/104137
|
|
|
|
|
|
|
| |
variety of file types we support.
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/103678
|
|
|
|
|
|
|
| |
maintenance/dev/data already existsy
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/102210
|
|
|
|
|
|
|
| |
them.
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/102208
|
|
5.4, install it in an isolated area, install a quick development copy of MediaWiki, and then start up a local webserver.
Notes:
http://mediawiki.org/wiki/Special:Code/MediaWiki/102201
|