Moodle in English: $plugindir/environment.xml

Hello everyone,
anyone has ever played with the environment.xml file in a plugin context e.g. to implement a custom check?

My goal?
Avoid a plugin to be installed in the wrong Moodle onward version, w/o applying the interesting hack proposed in https://moodle.org/mod/forum/discuss.php?d=353727#p1427140.

TIA,
Matteo

Here is my attempt:

<?xml version="1.0" encoding="UTF-8" ?>
<COMPATIBILITY_MATRIX>
    <PLUGIN name="local_twittercard">
        <CUSTOM_CHECKS>
            <CUSTOM_CHECK file="local/twittercard/environmentchecks.php" function="check_moodle_version_onwards" level="required">
                <FEEDBACK>
                    <ON_ERROR message="moodleonwardsversion" />
                </FEEDBACK>
            </CUSTOM_CHECK>
        </CUSTOM_CHECKS>
    </PLUGIN>
</COMPATIBILITY_MATRIX>

and my findings, having already read MDL-39840 (2.8+) and MDL-48177 (2.9+):

PLUGIN/CUSTOMCHECKS/CUSTOM_CHECK@file is not relative to $plugindir which is unusual and not expected, IMHO quite a bug since dirroot is hardcoded (https://github.com/moodle/moodle/blob/786d9cd3a1c129f577e3b19aecaf5adf0c6cd7c3/lib/environmentlib.php#L720)
PLUGIN/CUSTOMCHECKS/CUSTOM_CHECK/FEEDBACK/ON_ERROR@message: moodleonwardsversion cannot be a string local to the plugin since it is expected to be in lang/en/admin.php which is IMHO a bug. The setFeedbackStr() function doesn't implement the second parameter when called from a plugin, https://github.com/moodle/moodle/blob/786d9cd3a1c129f577e3b19aecaf5adf0c6cd7c3/lib/environmentlib.php#L1177
FEEDBACK/ON_CHECK is not implemented though documented into the wiki: https://docs.moodle.org/dev/Environment_checking#Custom_checks via https://docs.moodle.org/dev/Plugin_files#environment.xml. Better, it doesn't return the expected error when used with level set to required (https://github.com/moodle/moodle/blob/786d9cd3a1c129f577e3b19aecaf5adf0c6cd7c3/lib/environmentlib.php#L1166)
environmentrequirecustomcheck (this test must pass) looks like not override-able
The check never blocks the installation of the plugin when not verified

Has anyone ever successfully implemented a required/blocking custom check in a plugin?

TIA,
Matteo

PLUGIN/CUSTOMCHECKS/CUSTOM_CHECK@file is not relative to $plugindir which is unusual and not expected, IMHO quite a bug since dirroot is hardcoded

Your conclusions are incorrect here. The plugin being installed can not be treated as plugin already installed. Because of that all paths are relative to Moodle root not to the plugin root. That is because we do not know if plugin install will succeed or not.

PLUGIN/CUSTOMCHECKS/CUSTOM_CHECK/FEEDBACK/ON_ERROR@message: moodleonwardsversion cannot be a string local to the plugin since it is expected to be in lang/en/admin.php which is IMHO a bug. The setFeedbackStr() function doesn't implement the second parameter when called from a plugin,

Again wrong assumptions. Plugin that is not yet installed can not be source for error messages. The entire language strings systems works on assumption that plugin supplying string is installed. I think that implementation should be a bit more flexible and permit putting raw message text within the xml that will not be treated as language string.

Has anyone ever successfully implemented a required/blocking custom check in a plugin?

Probably not.

I'll check it out some more one of these days.

Hi Darko,
TNX a ton for your replies!

Mine to yours:

from a functional standpoint, when I'm under PLUGIN I should see everything relative to that named plugin: that's the reason why I wondered in my late night about the expected results - write your own plain environment.xml for a plugin and it will be clearer what I mean when coding that XML
from a technical standpoint, you're almost right: the plugin is still not installed at that time but for the purposes of the previous point we can actually source its en language file the same as we already do with version.php: https://github.com/moodle/moodle/blob/a73d7216698b3b46ebb57e4bfd6622f29ea78d45/lib/upgradelib.php#L468 (upgrade_plugins()). I know: it could be complicated and error prone, based on the assumptions made by the current code and, probably, built around some simpler use cases

I'm keen to understand if environment checks could be a resource for plugin development: I fell back to the hack you suggested but with serious drawbacks when using the CI to validate it (via moodle-plugin-ci).

At the end, I guess I'd be more happy w/o imposing any strict limit on the required Moodle version e.g. regarding a MOODLE_33_STABLE plugin branch - which is affected by a different implementation of the Privacy API which breaks Moodle privacy code if that plugin code is installed on 3.4+ by mistake.

HTH,
Matteo

Why don't you ping me on Skype (see my profile here), and we can continue directly. My timezone is -3UTC

I'm not sure what your error is but here is a fully working example of custom check within plugin that uses language strings from the plugin itself and works:

https://github.com/kiklop74/moodle-local_fooplug/tree/MOODLE_33_STABLE

WOW Darko, super-fast!
First, thanks for your kind collaboration and availability: I'm on CEST (+02:00), working on Moodle contributions mostly in my spare/night time.

I'll test your branch, and try to add the version constraint check too guessing that the way I've done via "your hack" is wrong - again, TNX a ton for your reply there, https://moodle.org/mod/forum/discuss.php?d=353727#p1487324 , will look at it.

At first glance, here I missed the include in https://github.com/kiklop74/moodle-local_fooplug/blob/17d5d111c74f21dffbd14be4bf1563e3add6500d/environmentchecks.php#L27.

On reading your code I still have the need of some potential Moodle enhancements in this "hidden" area (let us call it enhs and not bugs ):

[Easy?] Moodle could require a relative plugin path under PLUGIN
[Normal?] Moodle could "source" the plugin language to define its own messages under PLUGIN
[Medium?] Other potential localization issue starting from what described in PHPDoc e.g. https://github.com/moodle/moodle/blob/2bd26607512c36aeb17b2e788fa7e985788ca777/lib/environmentlib.php#L1346

I'll post here my feedback (not sure when) about your branch - we should update the Wiki at least with a pointer to this thread - and refined thoughts about the enhs above.

HTH,
Matteo

No problem, I'm glad to help.

BTW include is not needed. It works without it as well (which is reflected already in github).

However none of this prevents travis to execute the tests. I suggest you ask the maintainer of the moodle-plugin-ci how this can be accomplished.

[Normal?] Moodle could "source" the plugin language to define its own messages under PLUGIN

This already works when plugin is installed from browser GUI.

General developer forum

$plugindir/environment.xml