It's a blog

Tag: PHP (Page 1 of 2)

VSCode & PHP XDebug from Localhost, WSL2 and Docker containers

VSCode seems to be one of the up and coming IDEs over the last year. I personally switched from Jetbrains IDEs to VSCode fo most of my development work at some point in 2020.

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

PHP 7 composer docker image digest

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
Continue reading

mediawiki-docker-dev v1 rewrite

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

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!

Continue reading

My Joomla Component development workflow

Joomla20Symbol20Color20FLATMy 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.

Continue reading

mediawiki-api-base 2.0.0

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!

The new release really only uses the new version of the Guzzle HTTP library which makes use of PSR-7 and adds async get and post methods using the Guzzle promise library.

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'] )

 

MediaWiki CRAP – The worst of it

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.

Continue reading

« Older posts

© 2021 Addshore

Theme by Anders NorénUp ↑