How can plugins devs handle these API changes

How can plugins devs handle these API changes

by Justin Hunt -
Number of replies: 6
Picture of Particularly helpful Moodlers Picture of Plugin developers

I have a few plugins in the plugins database, and few outside of it. Every now and then a Moodle API change breaks one of my plugins. Well if we didn't have API changes there wouldn't be much to Moodle with. So I grumble a bit, sometimes a lot, and then just get on with it.

In one of these breakages last year a function declaration in the plugin parent class (the repository), that I need to override, changed to static,

ie the function in v2.2 was:

    public function instance_config_form($mform) {

But in 2.3 that became:

    public static function instance_config_form($mform) {

So my plugin now has a 2.2 and a 2.3+ version because I don't know any way of dealing with that in PHP

Now I just found that another of my plugins, has a similar issue, though I think it just throws strict warnings. The function get_files in /mod/assign/assignmentplugin has gone from:

public function get_files(stdClass $submission) {

to

public function get_files(stdClass $submissionorgrade, stdClass$user){

Now this has happened sometime between 2.4 being released and now. So I can't just do a simple "is it version 2.3 or 2.4" check. 

Can anyone offer a clever way of handling either of these situations within my code, so I don't need to manage  2 versions of the plugin that differ only in a single line.

Thanks

 

Average of ratings: -
In reply to Justin Hunt

Re: How can plugins devs handle these API changes

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

You might be able to get away with:

public function get_files(stdClass $submissionorgrade, stdClass $user=null) {

(but you'll probably get a debugging warning about it).

In reply to Davo Smith

Re: How can plugins devs handle these API changes

by Justin Hunt -
Picture of Particularly helpful Moodlers Picture of Plugin developers

Actually all I get is a debug message now on that one. I didn't think it would work, but actually adding that stops the debug message on 2.3 and 2.4 . Great, thanks.

Any ideas on the other one, the static function declaration ? 

In reply to Justin Hunt

Re: How can plugins devs handle these API changes

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

No, I'm afraid I can't help with the static one - that may just be the point where you need two versions of the code (at a real push, you might be able to do something like this: if ($CFG->version < xxx) { require_once('/path/to/lib23.php'); } else { require_once('/path/to/lib24.php'); }, but at that point you are onto a bit of a loser).

 

In reply to Justin Hunt

Re: How can plugins devs handle these API changes

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Hi Justin,
interesting question! Maybe reflection could help here with a small performance hit:

<?php
header('Content-Type: text/plain');

class Test {
    public function instance_config_form_pre($mform) {
        // Public in 2.2-
    }
    public static function instance_config_form_post($mform) {
        // Public Static in 2.3+
    }
}

// ...
//
// Code branching
$testclass = new ReflectionClass('Test');
$fnpre  = $testclass->getMethod('instance_config_form_pre');
$fnpost = $testclass->getMethod('instance_config_form_post');
// http://www.php.net/manual/en/class.reflectionmethod.php
// ReflectionMethod::isStatic() could be the key
var_dump($fnpre->isStatic());
var_dump($fnpost->isStatic());
//
// ...

HTH,
Matteo

In reply to Matteo Scaramuccia

Re: How can plugins devs handle these API changes

by Justin Hunt -
Picture of Particularly helpful Moodlers Picture of Plugin developers

Cor, great answers.

I agree Davo, that your suggestion (would it work?) could make a guy feel unclean. But it is an interesting approach.

 And Matteo I did not even know that PHP had reflection. That raises a few possibilities.

But I think I won't get too carried away by this problem. The ways you guys suggested out of the problem, are clever.  But ultimately I think I should avoid both of them, for different reasons. But in a pinch, they might come in handy 

Thanks

In reply to Justin Hunt

Re: How can plugins devs handle these API changes

by Damyon Wiese -

Sorry about the one in assignment - I should have made it default to null.