Toolforge , formerly known as wmflabs, is changing its URLs. Where there was one host (tools.wmflabs.org) before, each tool now gets its own sub-domain (eg mix-n-match.toolforge.org).
Until now, I have used my WiDaR tool as a universal OAuth login for many of my tools, so users only have to sign in once. However, since this solution only works within the same sub-domain, it is no longer viable with the new Toolforge URL schema.
I am scrambling to port my tools that use OAuth to their own sign-in. To make this easier, I put my WiDaR tool into a PHP class, that can be reused across tools; the individual tool API can then pick up the requests that were previously sent to WiDar. Some tools, like Mix-n-match, have already been ported.
This brought me back to something that has been requested of some of my tools before – portability, namely to MediaWiki/Wikibase installations other then the Wikimedia ones. A tool with its own WiDaR would be much more portable to such installations.
But the new WiDaR class is included via the shared file system of Toolforge; how to get it portable? Just copying it seems like a duplication of effort, and it won’t receive updates etc.
The solution, in the PHP world, is called composer, a package manager for PHP. While I was at it, I ported several of my often-reused PHP “library scripts” to composer, and they are available in code here, or as an installable package here.
Since the source files for composer slightly differ from the ones I use internally on Toolforge, I wrote a script to “translate” my internal scripts into composer-compatible copies.
The first tool I equipped with this composer-based WiDaR is Tabernacle. It should be generic enough to be useful on other Wikibase installations, and is very lightweight (the PHP part just contains a small wrapper API around the WiDaR class). Installation instructions are in the repo README.
I will continue converting tools to the new URL schema, as time allows. I hope I will beat the hard deadline of June 15.