Check module compatibility on install

[instantflorian]

Each info.php of a module has a value $module_platform. But actually this value is currently not used. So even if the value of $module_platform is set to 2.0.0, the module can be installed in lower WBCE versions. Instead, the installation process should be halted and a warning / error message should appear. Issue about this: the (sub-)versoin has to be given in exact syntax and there's no way to define a minimum and a maximum version, so this needs some more overthinking...

[mrbaseman]

hmm... $module_platform sometimes is a string that contains minimum requirements, such as 2.7.x, 2.8.x, > 2.8.3, 2.8.3 SP7, WebsiteBaker 2.8.3, WebsiteBaker 2.8.x or WBCE, WBCE 1.2.x, WBCE 1.4.x,...

so, we should do some matching, extract numbers... or the modules need to be updated, at least in this respect. Sometimes a clear cut is better than many workarounds

[WebDesignWorx]

I agree, Martin. To really make use of it a standard should be put in place and modules would need an update in the info.php A new variable would be even better to avoid confusion with earlier mechanisms. (IMHO at least.)

Something like: $compatibility = '>=,1.4.5';

or for "from to" checks maybe something like:

$compatibility = array(
                      '>,1.4.1',  // from
                      '<,1.4.5'  // up to 
             );

alternative syntax for the above: $compatibility = ['>,1.4.1', '<,1.4.5'];

That's just a first thought I have how it could be approached.

Most of WBCE modules won't work with Forks anyways...

[webbird]

For compatibility checks, there's precheck.php.

[mrbaseman]

Most of WBCE modules won't work with Forks anyways...

but the other way round... several older WB modules which don't use newer special features from one or the other code base still work with WBCE - at least up to now.

I try to keep the modules that I maintain compatible with both solutions. Actually, so far it wasn't too much work - just a few if defined(){ ... } blocks around code sections that really use features newly introduced in the core.

[WebDesignWorx]

For compatibility checks, there's precheck.php.

Yes, you're right WebBird. My approach would be for the lazy ones, a quick handle by use of a variable -- visible/accessible -- in the info.php Another upside of this would be, you can easily read the view.php and return the compatibility on a module listing for example (won't work so easy with a precheck.php file).

In any event, for me personally it's low priority atm.