document_test.php does not yet have full coverage on Scripto_Document. (By full coverage I mean that SimpleTest touches all methods and validates their return values.) However, given the class is merely a bridge between MediaWiki and an external system, and that testing already includes Scripto_Service_MediaWiki and Scripto_Adapter_Interface, I wonder if full coverage is needed.

Add methods that 1) enable users to add pages to their watchlist, and 2) gets a list of pages on the current user's watchlist.
http://www.mediawiki.org/wiki/API:Watch
http://www.mediawiki.org/wiki/API:Watchlist

This may require the developer to install a testing MediaWiki instance, separate from the production instance. The upshot is test coverage of Scipto's interface with MediaWiki, the reliability of which should be considered unresolved.

See https://forum.omeka.org/t/unknown-login-error-failed/2993

Since MediaWiki 1.27.0 it appears that a successful login action does not return a cookieprefix. Scripto's MediaWiki service depends on this prefix to identify and set cookies needed to maintain state between requests. It's unclear exactly why it was removed, but it might be related to login being deprecated in favor of the new clientlogin action (available since 1.27.0).

Regardless of an eventual update from login to clientlogin (see #26), we'll need to find another way to extract the cookie prefix. For example, in Scripto_Service_MediaWiki::login(), we could set do something like this:

$cookies = self::getHttpClient()->getCookieJar()->getAllCookies();
preg_match('/^(.+)_session$/', $cookies[0]->getName(), $matches);
$mediawikiCookiePrefix = $matches[1];

Until this is fixed we could instruct users to use MediaWiki 1.23.15.

Scripto_Service_MediaWiki::getRevisions() returns the following array when a page is not yet created:

(
  [query] => Array
      (
          [pages] => Array
              (
                  [-1] => Array
                      (
                          [ns] => 0
                          [title] => .MQ.Ng
                          [missing] => 
                      )
              )
      )
)

Check for this response in Scripto_Document::_getPageHistory() and return an empty array before the foreach(). Otherwise calls to the function using an uncreated page result in an "Invalid argument supplied for foreach()" warning.

Fully featured in the sense that methods should accept a wider range of API parameters. Follow the example of Scripto_Service_MediaWiki::getRecentChanges() and ::getRevisions().

Though Scripto_Service_MediaWiki::_getResponse() is accurately descriptive, ::_request() follows Zend's HTTP client nomenclature more closely. Remember to change all calls to the method.

Include API URL validation in Scripto_Service_MediaWiki::__construct(). Check against a valid MediaWiki API URL pattern, and catch Zend_Uri_Exception (for invalid URLs), throwing Scripto_Service_Exception when encountering an error.

Extend the library to enable sysop and burocrat users to import document transcription to the external system. Page protection could signify a finished transcription, but it does not have to. Utilize Scripto_Adapter_Interface::importDocumentTranscription() and Scripto_Adapter_Interface::importDocumentPageTranscription().

http://lists.wikimedia.org/pipermail/mediawiki-api/2011-June/002293.html

Extend the library to enable sysop and bureaucrat users to protect an individual document page and an entire document (i.e. all the document's pages). Protected pages are locked to prevent further editing by lower user groups. This may mean that the transcription is finished and ready to be imported to the external system.

See https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2017-June/000134.html

While rvdifftotext, rvdiffto, rvexpandtemplates,and rvgeneratexml are present in the MediaWiki service class, we only use rvdiffto (to get the difference between two revisions). Remove them all from the $_actions list. Instead of revids/rvdiffto in getRevisionDiff(), use action=compare. (Note that the compare action was not added until 1.18 and the fromid/toid properties were not added until 1.20.)

Maybe add Scripto::getMediawikiInfo() using Scripto_Service_MediaWiki::getSiteInfo() and return a parsed/formatted array including a URL path prefix for article pages. Also add Scripto::getMediawikiPageUrl($title) that uses Scripto::getMediawikiInfo() and the provided title to build and return a URL.

Catch Zend_Http_Client_Exception in Scripto_Service_MediaWiki::isValidApiUrl() to prevent "Unable to Connect" errors, such as "Name or service not known" and "Connection refused." Return false.

Currently it's impossible to get from the raw MediaWiki site to the CMS hosting the page images. Until MediaWiki features like Recent Changes are hooked to the CMS, could Scripto at least point MediaWiki users to the page images?

Scripto_Adapter_Interface needs a getDocumentPageTitle() method, complimentary to getDocumentTitle().

See https://www.mediawiki.org/wiki/API:Login

Since MediaWiki 1.27.0 the login action has been deprecated in favor of the new clientlogin action. We've already seen an inconsistency in the API result (see #25) but we need to prepare for login's eventual removal.

In Scripto_Service_MediaWiki::login() we'll need to replace the existing login requests with the clientlogin interactive flow:

$params = array('meta' => 'tokens', 'type' => 'login');
$response = $this->_request('query', $params);
$logintoken = $response['query']['tokens']['logintoken'];

$params = array(
    'username' => $username,
    'password' => $password,
    'logintoken' => $logintoken,
    'loginreturnurl' => 'http://example.com',
    'rememberMe' => '1',
);
$response = $this->_request('clientlogin', $params);

On top of this we'll need a way to determine when to use the login action for older installations.

Add a method that returns revisions for a given document page.
http://www.mediawiki.org/wiki/API:Properties#revisions_.2F_rv

A change to the MediaWiki API, described here, may eventually require a small change to Scripto's MediaWiki API client. I'm not sure why the change is described as backwards compatible since it appears to have changed a parameter name in the response. (The description of the changes are pretty confusing, but the commit may shed some light.)

For now the only change that may need to happen is in Scripto::getAllDocuments():

$from = $response['query-continue']['allpages']['apfrom'];
// changes to
$from = $response['query-continue']['allpages']['apcontinue'];

Another change, described here, will eventually require a small change to the client. Again, this change should not be described as backwards compatible.

For now the only change that will need to happen is in Scripto::getRecentChanges():

$start = $response['query-continue']['recentchanges']['rcstart'];
// changes to
$start = $response['query-continue']['recentchanges']['rccontinue'];

A possible new feature. Some users may want to use an already existing MediaWiki installation to store their transcriptions. This may be possible with MediaWiki custom namespaces. During configuration, include the custom namespace name in the appropriate places and query the MediaWiki API using that namespace. An optimal solution will be to ensure backwards compatibility.

Add a method that returns recent changes to the wiki.
http://www.mediawiki.org/wiki/API:Recentchanges

Loading XML responses into SimpleXMLElement slows things down unnecessarily when a JSON response format is available. JSON would also simplify data traversal.

Scripto_Document::canEdit() should determine whether the current user can edit the MediaWiki page that corresponds to the current document page. It currently depends on Scripto_Service_MediaWiki::getEditCredentials() to return NULL if the user doesn't have edit rights. Regrettably, this doesn't account for users with edit rights who attempt to edit a protected page. There must be a way to determine if the current user can edit the current page.

Ideally we'd separate account creation (user registration) from the MediaWiki Web interface, but the API does not provide an account creation feature, though it is proposed. Unless there is some other way, all accounts will need to be created via the MediaWiki Web interface.

The most common complaint about installing Scripto is the Zend Framework dependency, in particular, determining the path to the ZF library. Removing this dependency would streamline the installation process, but using a custom HTTP client (which is the extent of ZF needed by Scripto) may be more trouble than it's worth.

An alternative would be to package the ZF library (or only the requisite ZF components) alongside the Scripto library. However, this would greatly, and perhaps unjustifiably, increase the size of Scripto downloads.

A related change would be to update to ZF 2.

The Scripto repository should follow a more traditional software directory structure, such as:

Scripto/
  |_README
  |_lib/
    |_Scripto/
      |_[...]
  |_tests/
  |_examples/
    |_shared/
      |_images/
        |_[...]
      |_[files in OpenLayers/ and layout/]
    |_SideBySide/
      |_[...]
    |_Simple/
      |_[...]
    |_TopAndBottom/
      |_[...]