New plugin environment checks

New plugin environment checks

by Neill Magill -
Number of replies: 8
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

I have been playing with the new plugin based environment checks in Moodle (https://tracker.moodle.org/browse/MDL-39840) and found that they seem to have to be attached to a specific version of Moodle, i.e.

<COMPATIBILITY_MATRIX>
    <MOODLE version="2.6">
        <PHP_EXTENSIONS>
            <PHP_EXTENSION name="xml" level="required" />
            <PHP_EXTENSION name="xsl" level="required" />
        </PHP_EXTENSIONS>
    </MOODLE>
</COMPATIBILITY_MATRIX>

Is there a way to make the requirement across all versions, without having to create an entry for each version of Moodle?

Average of ratings: -
In reply to Neill Magill

Re: New plugin environment checks

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Neill,

I'm afraid, environmental checks, right now, only match for exact versions by design (we always add a new section to the main .xml) and the recent incorporation to plugins has inherited that restriction.

In any case, I really think it's a good feature that would help a lot, especially for plugins, so I'd recommend you to fill a new feature request in the Tracker about that (don't forget to link it back to this discussion).

Surely some special syntax (>, >=, 2.*..., composer like, surely) should be accepted to be able to implement that feature. Feel free to make a proposal.

Ciao smile

PS: In any case, I'm 90% sure that any change like that will require a complete refactor of the environmentlib stuff, modernizing it, moving from global scope to proper classes... just noting it.
In reply to Eloy Lafuente (stronk7)

Re: New plugin environment checks

by Neill Magill -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

I have been playing a little today to see what I could do. By allowing a slightly different syntax in plugin environemt.xml files only minimal code changes would be needed. The syntax for plugins would be like:

<COMPATIBILITY_MATRIX>
    <PLUGIN>
        <PHP_EXTENSIONS>
            <PHP_EXTENSION name="xml" level="required" />
            <PHP_EXTENSION name="xsl" level="required" />
        </PHP_EXTENSIONS>
    </PLUGIN>
</COMPATIBILITY_MATRIX>

The solution I have got working has the following properties:

  • The Environment file would not break versions of Moodle that do not support the PLUGIN syntax, as the PLUGIN tag would be ignored by them.
  • Specific versioned MOODLE tags could be defined for 2.6, 2.7 and 2.8 if you wanted all versions of Moodle that support plugin environment.xml files to work.
  • If both MOODLE and PLUGIN tags exist the PLUGIN tag will be used in preference.
  • The PLUGIN tag will not function in the main Moodle environment.xml file.

Should have the code in the main ticket soon.


In reply to Neill Magill

Re: New plugin environment checks

by Eoin Campbell -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers
I have been attempting to add an environment file to my contributed plugin for question formatting, but cannot see any effect when I install it. I wonder am I misssing something? I am running 2.9 on Windows, and am adding a file named environment.xml with the following contents to the main (root) folder of the plugin.


 

<COMPATIBILITY_MATRIX>
  <PLUGIN>
    <PHP_EXTENSIONS>
      <PHP_EXTENSION name="xsl" level="required" />
      <PHP_EXTENSION name="tidy" level="required" >
        <FEEDBACK>
          <ON_ERROR message="iconvrequired" />
        </FEEDBACK>
      </PHP_EXTENSION>
    </PHP_EXTENSIONS>
  </PLUGIN>
</COMPATIBILITY_MATRIX>

I have attached a plugin Zip file which I have been installing using Site administration > Advanced features > Plugins > Install plugins. I have disabled the HTML Tidy extension in my php.ini file, and expected to see an error at some point during the installation, but it just installs without any problems. I also tried setting the level for 'tidy' to 'optional', but this had no effect either. Am I misunderstanding what is supposed to happen, or is my environment specification incorrect, or is it not supported with contributed plugins, or could there possibly be a bug in the implementation?

In reply to Eoin Campbell

Re: New plugin environment checks

by Neill Magill -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

During the integration review the plugin tag changed to require a name attribute. 

The name must be the plugin's frankenstyle name, i.e.

<PLUGIN name="block_navigation">

In reply to Neill Magill

Re: New plugin environment checks

by Eoin Campbell -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi Neill, thanks for the quick response. For my particular plugin, I have tried both
<PLUGIN name="question_format_htmltable">
and <PLUGIN name="qformat_htmltable">
and neither of them seem to trigger any environment checks. I also tried changing the attribute names to all uppercase, with no effect either. Any other ideas?

In reply to Eoin Campbell

Re: New plugin environment checks

by Neill Magill -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

I just noticed you may have been looking for the checks in the wrong place. Did you look for your checks in: Home ►Site administration ►Server ►Environment

In reply to Neill Magill

Re: New plugin environment checks

by Eoin Campbell -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi Neil,

I assumed any checks would be displayed immediately on the current page as I installed the plugin, and prevent me from proceeding further until I had corrected any errors. I now see the warning on the Server Environment page, but only after I have completed the installation process and browsed to this page. 

It seems to me that an immediate warning would be of far more benefit to administrators, but thanks for clearing up the issue.