NOTE: The php code described below is an experimental technique and should be used with caution.

Sometimes a package installation copies code in or out of the package. Perhaps there is a situation that overriding or inheritance cannot solve. This could involve copying files from the concrete5 core, copying files into root overrides, or copying files to/from another installed package.

This is all fine when the package installation or update is made. But what happens when the other package is updated, or the concrete5 core is updated? Can a package update be made automatically available whenever the concrete5 core or another package is updated?

Here is a trick to play with adding minor version digits to a package version. In the example, the concrete5 core version digits are automatically appended to the actual package version. If the concrete5 core is updated, then the package will now think it has a new minor version and the package update will appear in the dashboard Update Addons page.

class MyPackage extends Package {

  protected $basePkgVersion = '1.0.0.';
  public function __construct(){
    /* 
    This makes the package version increment in minor digits with the core 
    version, so facilitating a package update after the core is updated.
    */
    $this->pkgVersion = $this->basePkgVersion.APP_VERSION;
  }

  public $pkgVersion = '1.0';

  // more package code

   public function upgrade() {    
    // do special upgrade code
    // and then 
     parent::upgrade();
  }

}

A similar trick can be used to make a package minor version map from another package's version. Rather than concatenating $basePkgVersion with APP_VERSION, a little more code can load another package controller, get its version, and concatenate it to give minor digits on the end of $pkgVersion.

This is a trick to only use where absolutely necessary. Loading another package just to read its version carries an overhead. Using code in a __construct() method rather than constants or on_start() is also less efficient. Blindly updating just because another package or the concrete5 core has been updated carries its own technical risk that the 'special upgrade code' in the upgrade() method may no longer be compatible.

Another variation useful during development is to append the date or time as the last digits in a minor version number. The package will then always appear ready for update, very useful if you are adjusting block dialog sizes or making frequent changes to the database schema. Just remember to remove any date or time dependant versioning and simply set the version to 0.9 before submitting to the PRB!

REMEMBER: The php code described below is an experimental technique and should be used with caution.

Read more How-Tos by JohntheFish.