We migrated to storing subplugin metadata as JSON in MDL-65646 and created JSON with a plugintypes array containing a mapping of the subplugintype => path.

That path is relative to the Moodle project root, for example:

{

    "plugintypes": {

        "assignsubmission": "mod/assign/submission",

        "assignfeedback": "mod/assign/feedback"

    }

}

Ultimately it is not possible for a subplugin to be outside the root of the plugin that it relates to. In the above examples they must be inside mod/assign.

At the moment this isn't an issue, but in MDL-83424 I am proposing to change the project root and move all existing content into a public folder. That means that mod/assign/submission will now be in public/mod/assign/submission for example.

Technically this still isn't an immediate problem because all paths are currently relative to $CFG->dirroot, which will now be our new public folder, but a part of the longer term goal is to support plugin code being web private – that is to say that plugins would be outside of the public directory.

in this case we would therefore need to update all subplugins.json to be relative to the new project root.

However, rather than doing this, I am proposing that we instead make them relative to their parent plugin.

Really this path should always have been the case, but I didn't adequately consider this when I made the transition several years ago. This was further complicated by supporting the subplugins.php variant.

Now that the subplugins.php files have been removed (MDL-83703) I feel that we can more easily make this change in preparation for MDL-83424.

To do so though we need to create a new object in the json structure and support use of both the old, and new, keys for a while.

I would propose that we:

• create a new subplugintypes object with the same form of plugintype => path mapping
• the new object's path should be a path relative to the plugin's root
• we should continue to support the old way, with deprecation/debugging, so that plugins can be used on multiple Moodle versions
• we should add validation to check that the two objects are in-sync
• we should stop supporting (remove) the project-relative values in 6.0.

An example of the dual mapping would be:

{

    "subplugintypes": {

        "assignsubmission": "submission",

        "assignfeedback": "feedback"

    },

    "plugintypes": {

        "assignsubmission": "mod/assign/submission",

        "assignfeedback": "mod/assign/feedback"

    }

}

Note: Technically any core plugin does not need to define the current plugintypes, but there may be external code making use of this data so it is best to preseve it for some time.