registering namespace with Extension_default_namespaces

* re: assembla/159 - sort out content namespace

Change-Id: I47e95f194e718b21e13645028c27c0314a958dd4
SpecialGWTooset clean-up & fix

* added 'allow-get' key to $_registered_modules and logic to determine
  the action to take when a module allows a get request or not
* added missing $this->outputHeader();
* removed extra $this->setHeaders();
* removed @return {void} comment

Change-Id: If571b9be56a2670616fe5d03642e6d5b621b7dbb
wikichecks - additional check & cleaned-up

* added param '' where lang key 'gwtoolset-permission-not-given' is used without a param
* added checkMediaWikiVersion()
  - used wfUseMW instead of using version_compare() directly
* added Config::$required_mediawiki_version for use with checkMediaWikiVersion()
  - set requireved version to 1.22c
* moved self::checkMediaUploadSettings() to the bottom of pageIsReadyForThisUser()
* removed @return {void} comments
* renamed verifyPHPVersion to checkPHPVersion

Change-Id: Ia5a7661c5c0b6854e9ed5e9dd2e14b4bb9f25f8b
Rename wfIsHipHop() to wfIsHHVM()

From I81e4ce5 in core.

Change-Id: I3a490efae9d63b96debddbdafee81f9cf5f9ccef
secure <metadata_raw>

currently, the raw metadata snippet is placed in the media file’s page in an
HTML commented <metadata_raw> tag. the concern is that the raw metadata may
contain a closing HTML comment tag. this patch handles this situation using
htmlspecialchars().

Change-Id: I0543fe92091efbb7e2dcf8301ca8b52367a2ac9f
second source field mapping dissapears

the main issue here was that in step 2 of the upload process, when adding metadata mappings,
categories or item specific categories with the + button; they were added with javascript. if the
user stepped back in the upload process, e.g., from step 3 back to step 2, those added fields
would be lost.

the solution implemented was to use javascript and cookies to maintain the state of those added
fields and re-apply them if the user comes back to step 2.

* includes/Config.php
  - added resource jquery.json so that it can be used in the js createCookie() method

* includes/Forms/MetadataMappingForm.php
  - added ids to form tables for quicker js access to the individual tables

* resources/js/ext.gwtoolset.js
  - added line breaks to code that is > 100 characters
  - added logic to handle cookies
    + createCookie()
    + removeCookies()
    + restoreJsFormFields()
    + storeJsFormFields()
  - alphabatized initial gwtoolset variables
  - attempted to improve the option search while still using jQuery
  - changed .html() to .append() when adding jQuery objectsto an html element
  - fixed an issue where the restore of js fields did not always correspond with field/values
    previously present in the form
  - re-worked the logic of handleButtonAddClick() and handleFormSubmit() so that they work
    in conjunction with the new cookie handling methods

* re: assembla/169 - Second source field mapping disappears

Change-Id: I7afe3d2fb01becccd586afed2ead490dbcd01784
Merge "second source field mapping dissapears"
re-work exception handling

Gergő Tisza was concenred about the fact that the extension was catching MWExceptions.
the solution we agreed upon was to use an extension specific exception object for user
errors and another for system/non-user correctable errors, which has been implemented
in this change-set.

a few files also include php doc clean-up, shortening of lines > 100 characters, and
removal of a few functions no longer used by the extension.

Change-Id: Ie9493be07ecb74cf382bf3561e1c036af6538ac2
re-factor save metadata mapping

Bryan Davis and Gergő Tisza mentioned concern about the special page handler AjaxHandler
use of exit() and set_error_handler(), which is used to save the metadata mapping created by the user.
after reviewing the code and the possibility of extending the API instead i was able to instead
make use of the existing API action=edit call to achieve what is needed; the saving of the
metadata mapping created by the user. this change-set addresses those issues.

Change-Id: I56b661cb58b85eaac7571100e25ab6c47d1cca0c
filebackend

i ran into an issue while looking into developing a chunked upload solution for uploading
xml metadata. the plan was to use the mw api to upload the metadata in slices and keep
them in the upload stash for use, and dispose of them when no longer needed.

after i sorted out the initial functionality, the mw api came back with a message that
xml file uploads were not allowed. this could be overcome by altering LocalSettings.php,
but i brought up the issue in irc with aaron schulz and chris steipp. chris said that
we should not be uploading xml data this way.

chris and aaron discussed a few ideas and came back with a few concepts:

1. download metadata from an external url.
   a. js could be used to poll the download and then allow continuation with the upload
      process once the metadata file has been received by the wiki.
   b. i mentioned that i would like to keep the form upload for this step and implement
      the download from url method in phase 2 or later; aaron was okay with this.

2. store the metadata in a private file backend.
   a. SwiftFileBackend on mediawiki servers.
   b. FSFileBackend locally or for wikis that do not have alternative FileBackend stores

3. cleanup the backend when finished with the metadata file.
4. make sure the documentation mentions the need to secure the file backend directory.

this changeset address this issue.

Change-Id: I5b7426bcfceec67909b81d561cad5e4526e51520
lang-attribute

discovered an issue that occured when there were several description elements
in a record and the first description had no lang attribute while the other
description elements did; the application would throw an error.

this change-set addresses that issue.

* also added additional comments and reduced lines > 100 characters

Change-Id: Id46de9c04ad89f9d456ba3b122f857c27a62c908
adviseStat

aaron schulz requested that cleanupGWTFileBackend.php add 'adviseStat' => true to the
$GWTFileBackend->FileBackend->getFileList() call.

-------
version 0.1.6

Change-Id: If8e1630c2e97b6f4b64d3d7313fd1da4f292cb21
whitelisted-post

aaron schulz mentioned a concern about how the extension was storing the full $_POST in the
batch jobs. he requested that we, “take the fields that matter and do any sanity filtering needed”.

while working on this issue, i noticed that there is potential for a form field name clash between
the extension’s form fields and the form fields that are dynamically created based on the
mediawiki template chosen. in order to avoid this conflist, i “namespaced” the extension’s form
fields by prefixing them all with “gwtoolset-”.

this change-set addresses these issues.

* have also shortend code lines > 100 characters

Change-Id: I4dd6514b8d8f54f1efcc13aa88dc50cabe0b9977
mediafile-job-array

aaron schulz requested that we, “create an array of mediafile jobs and push them all at once
(this makes it a bit more atomic)”.

Change-Id: I52b0f57b8c2cda382635fc6480675ea8704208a7
config-clean-up

aaron schulz requested that we move non configurable variables out of Config.php
and just hard code it as used; some variables i have moved into a new Constants.php
class in order to encapsulate them within the GWToolset namespace.

Change-Id: I2dc355ee6e39d6f173c3dfe5dcd41c5f340749fa
job-queue-size

aaron sschulz requested that we use the JobQueueGroup::singleton()->getQueueSizes() in addition
to the Config::$job_throttle to avoid flooding a queue. optimized version which was implemented
is JobQueueGroup::singleton()->get( <job queue name> )->getSize().

Change-Id: I5ef09adb92d2bd6f790a8fab9c62aeb65450cb54
autoload-classes

aaron schulz suggested, if you did : $wgAutoloadClasses = $wgAutoloadClasses + array( ... )
this wouldn't need to repeat '$wgAutoloadClasses' so much.

Change-Id: I954086e690c6290dd8ae0ae2c78749c6c7cf38f7
input-field-size

aaron schulz requested that we validate input sizes for sanity. i also added a method to
XmlDetectHandler.php that will display field labels for mediawiki template parameters
without the - or _ and without gwtoolset- for script added gwtoolset fields.

Change-Id: If02a21bbb2c35210c778b40d6fe1084debcacb3b
Merge "autoload-classes"
filter

chris steipp requested that we:

* $filter_sanitize === null in sanitize() should not be allowed. Since you use
Filter::evaluate() to sanitize for xss in several places, there can't be a
chance that would return without any filtering. If you can remove setting a
custom filter, that would be even better.

* Split array handling into another class that calls the scalar version, so all
filtering logic is in one class, but when you filter, it's explicit if you're
expecting an array or scalar.

* Attack can get arbitrary values through getWhitelistedPost by passing in a
whitelisted name as an array with 'filter-sanitize'=null. Fixing Filter should
prevent this from being an issue.

i have removed the Php\Filter class and created a GWToolset\Util class, also for
use in another request chris made, that contains static methods that replace those
that were used in Php\Filter. while re-factoring the code i realized that the
array handling in Php\Filter was no longer needed, so i did not create a method
for that at this time.

Change-Id: I3d118a4fdc4c1726815ab735527e636b883c41c7