Apparently up until now I have avoided running the PHP debugger Xdebug. I had to do a little search around to figure out the correct settings for my setup decided to write them down in this handy blog post.Continue reading
At some point in the last weeks the composer docker image that can be found on docker hub switched from PHP7 to PHP8. Some projects, such as wikibase-docker, still require PHP7 for installation.
It looks like the composer image is not going to be providing an additional tag using a pre PHP 8 version, thus an old digest will be needed.
tldr; here is the digest that you want for composer with PHP7 (tag-details)
docker pull composer@sha256:d374b2e1f715621e9d9929575d6b35b11cf4a6dc237d4a08f2e6d1611f534675
Back in 2017 at the Wikimedia Hackathon, I played around with Docker and docker-compose in relation to MediaWiki and testing with multiple setups at once while developing, meaning multiple PHP versions, web servers and databases. My original slides can still be found here.
Since then mediawiki-docker-dev evolved into less of a testing system and more of a development environment, allowing the use of a master replica DB setup, easily swappable PHP versions, debugging and more. The project on GitHub currently has 40 stars, 38 forks and has seen 17 people contributing back.
Over the past couple of years, developer productivity and development environments have been a big discussion area. The Wikimedia technical conference in 2019 had the main topic of Developer Productivity. There have also been a few efforts in a few directions trying to figure out what is best for the majority of people. These include local-charts (Kubernetes based environment) and MediaWiki-Docker (simple docker-compose based environment).Continue reading
sMite stands for ‘simple Mite’, which to most people still means nothing at all. Mite is a time tracking web service, and depending on how companies make use of it things can become more complicated than they should be.
smite is how I tried to tackle this complexity in less than 8 hours!
My first and currently only Joomla component development was for the SWA UK website. The component manages memberships, events, tickets, results and more and is a rewrite of a previous component for Joomla 1.
But in this post lets ignore what the component does and instead concentrate the development workflow that is used. After lots of research at the beginning of development I decided to ignore other methods of developing a component and this is what I ended up coming up with.
Recently I switched from using Guzzle 5 to Guzzle 6 in my mediawiki-api-base PHP library. Everything went very smoothly except for there being no compatible version of the retry-subscriber that I had previously used. The subscriber has been replaced by retry middleware of which I was provided an extracted example. In this post I cover my implementation for the mediawiki-api-base library.
Roughly a year and a half ago I started writing a collection of PHP libraries to make interaction with the Mediawiki API and extension APIs super easy. The base library has just made it to 2.0.0!
This library is the first of the addwiki collection that has actually reached 1.0.0 let alone 2.0.0! All of the other libraries, including wikibase-api and mediawiki-api are still a work in progress with lots to be added. The next likely to be released will be the wikibase-api library once I try to also add async functionality there!
A snippet of the async functionality added in mediawiki-api-base can be seen below:
// Get an API object and login $api = MediawikiApi::newFromPage( 'https://en.wikipedia.org/wiki/Berlin' ); $api->login( new ApiUser( 'username', 'password' ) ); // Initiate each request but do not block $requestPromises = array( 'Page1' => $api->postRequest( FluentRequest::factory()->setAction( 'purge' )->setParam( 'titles', 'Page1' ) ), 'Page2' => $api->postRequest( FluentRequest::factory()->setAction( 'purge' )->setParam( 'titles', 'Page2' ) ), 'Page3' => $api->postRequest( FluentRequest::factory()->setAction( 'purge' )->setParam( 'titles', 'Page3' ) ), ); // Wait on all of the requests to complete. $results = Promise\unwrap( $requestPromises ); // You can access each result using the key provided to the unwrap function. print_r( $results['Page1'], $results['Page2'], $results['Page3'] )
Recently I have been spending lots of time looking at the Wikimedia graphite set-up due to working on Grafana dashboards. In exchange for what some people had been doing for me I decided to take a quick look down the list of open Graphite tickets and found T116031. Sometimes it is great when such a small fix can have such a big impact!
I don’t mean Mediawiki is crap! The Change Risk Anti-Patterns (CRAP) Index is calculated based on the cyclomatic complexity and code coverage of a unit of code. Complex code and untested code will have a higher CRAP index compared with simple well tested code. Over the last 2 years I have been tracking the CRAP index of some of Mediawikis more complex classes as reported by the automatic coverage reports, and this is a simple summary of what has been happening.