Moodle
  1. Moodle
  2. MDL-38322

POLICY: Use /local as the place for "generic plugins"

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.4
    • Fix Version/s: 2.4.3
    • Component/s: Policy
    • Labels:
      None
    • Affected Branches:
      MOODLE_24_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE
    • Rank:
      48188

      Description

      /local was designed for local plugins that you never intend to distribute, and where you don't need to worry about namespace clashes with core code. We can never distribute plugins in this location.

      It's not meant to be the generic plugin place, but unfortunately a lot of people are starting to see it that way, see https://moodle.org/plugins/browse.php?list=category&id=18

      I think we need to decide one of the following:
      A. Create a new plugin place (eg /general, /other or /plugin) and leave /local clean as intended, or
      B. Re-define /local once and for all and live with the silly name

      Discussion and/or votes?

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          Pinging some core people about this.

          Show
          Martin Dougiamas added a comment - Pinging some core people about this.
          Hide
          Dan Poltawski added a comment - - edited

          > It's not meant to be the generic plugin place, but unfortunately a lot of people are starting to see it that way

          Me included and I suppose that came about in 2.x, when we added proper plugin hooks for it. It became the plugin point which doesn't fit in the other categories.

          Regarding a 'proper place' - one thing i've often wanted with local_ is a distinct context for it like a course_module. e.g. In MDLSITE-2137 - it would be nice to apply the skype filter only to local_chatlogs and not system context, it would also be nice to assign roles there rather than needing to do it at system context.

          Show
          Dan Poltawski added a comment - - edited > It's not meant to be the generic plugin place, but unfortunately a lot of people are starting to see it that way Me included and I suppose that came about in 2.x, when we added proper plugin hooks for it. It became the plugin point which doesn't fit in the other categories. Regarding a 'proper place' - one thing i've often wanted with local_ is a distinct context for it like a course_module. e.g. In MDLSITE-2137 - it would be nice to apply the skype filter only to local_chatlogs and not system context, it would also be nice to assign roles there rather than needing to do it at system context.
          Hide
          Dan Poltawski added a comment -

          ps. I know how other new contextlevel discussions have gone in the past (are remote learner still maintaining their additional contextlevel?). To me, this seems to be about things which do not fit inside a course, perhaps they should be front page course modules?

          Show
          Dan Poltawski added a comment - ps. I know how other new contextlevel discussions have gone in the past (are remote learner still maintaining their additional contextlevel?). To me, this seems to be about things which do not fit inside a course, perhaps they should be front page course modules?
          Hide
          Aparup Banerjee added a comment -

          with local - i do get the idea that the contents are somewhat more unique than a generic distribution but could be possibly distributed in future by it being re-written for another location. i think this has come about due to the lesser need for local hacks possibly but i'm not sure.
          i think another place (/generic etc) just seems more confusing imo.

          Show
          Aparup Banerjee added a comment - with local - i do get the idea that the contents are somewhat more unique than a generic distribution but could be possibly distributed in future by it being re-written for another location. i think this has come about due to the lesser need for local hacks possibly but i'm not sure. i think another place (/generic etc) just seems more confusing imo.
          Hide
          Sam Hemelryk added a comment -

          Presently +1 for sticking with just local plugins and living with a silly name.

          Best reason I can think of is duplicity.
          We'd end up with many duplicate hooks if we introduced a new "generic" plugin type.
          More hooks, more explaining, and no doubt an element of confusion about why there are two generic plugins.
          Then to boot I think even if you created a generic plugin and told/lectured people of the ideas behind local plugins people would still contribute and share them. If we didn't have a place for them in the plugins database it would happen through the forums or elsewhere.

          I'm not set on this, feel free to convince me otherwise.

          Show
          Sam Hemelryk added a comment - Presently +1 for sticking with just local plugins and living with a silly name. Best reason I can think of is duplicity. We'd end up with many duplicate hooks if we introduced a new "generic" plugin type. More hooks, more explaining, and no doubt an element of confusion about why there are two generic plugins. Then to boot I think even if you created a generic plugin and told/lectured people of the ideas behind local plugins people would still contribute and share them. If we didn't have a place for them in the plugins database it would happen through the forums or elsewhere. I'm not set on this, feel free to convince me otherwise.
          Hide
          Sam Hemelryk added a comment -

          Also I think it would be great to have an additional context level, somehow able to be customised to a local plugin.
          There were several times during my work on the plugins database that I would have loved to have a separate context to work with.

          Show
          Sam Hemelryk added a comment - Also I think it would be great to have an additional context level, somehow able to be customised to a local plugin. There were several times during my work on the plugins database that I would have loved to have a separate context to work with.
          Hide
          Martin Dougiamas added a comment -

          Sam can you explain what you mean about duplicated hooks exactly?

          Show
          Martin Dougiamas added a comment - Sam can you explain what you mean about duplicated hooks exactly?
          Hide
          Tim Hunt added a comment -

          I am with Sam, we have local, and although the name sucks, it does everything a generic plugin type should do, and changing the name is more trouble than it is worth.

          Martin's statement "designed for local plugins that you never intend to distribute" seems weird to me. The plugin type tells you what sort of functionality you add to Moodle (an admin tool, a report a block). It whether you intend to distribute that or not is an orthogonal bit of metadata. You could well have auth plugins, admin tool and reports that you never intend to distribute. Indeed the OU has several of each.

          For me, the mistake was adding the admin/tool plugin type. As far as I can see, all three of report_, tool_ and local_ plugins have almost exactly the same possibilities in terms of how they can extend Moodle functionality (and where there are slight differences, we could eliminate them). So, with hind-sight, I would have created a single tool_ plugins type in Moodle 2.0 (stored in the top-level tool folder) and deprecated the other types. However, I don't think we should break backwards-compatibility now.

          I think we should just change our documentation about what are valid uses for local plugins.

          Show
          Tim Hunt added a comment - I am with Sam, we have local, and although the name sucks, it does everything a generic plugin type should do, and changing the name is more trouble than it is worth. Martin's statement "designed for local plugins that you never intend to distribute" seems weird to me. The plugin type tells you what sort of functionality you add to Moodle (an admin tool, a report a block). It whether you intend to distribute that or not is an orthogonal bit of metadata. You could well have auth plugins, admin tool and reports that you never intend to distribute. Indeed the OU has several of each. For me, the mistake was adding the admin/tool plugin type. As far as I can see, all three of report_, tool_ and local_ plugins have almost exactly the same possibilities in terms of how they can extend Moodle functionality (and where there are slight differences, we could eliminate them). So, with hind-sight, I would have created a single tool_ plugins type in Moodle 2.0 (stored in the top-level tool folder) and deprecated the other types. However, I don't think we should break backwards-compatibility now. I think we should just change our documentation about what are valid uses for local plugins.
          Hide
          Martin Dougiamas added a comment - - edited

          It's not wierd if you look at the name "local", Tim. It was originally a place where you can safely store all sorts of local custom code and be assured that core is not going to send something down on an update that will conflict. I agree it's a small benefit and also with everything else about tools etc. In fact I totally wish we'd just gone for /plugins with hooks into various parts of Moodle but that train sailed off down the highway a long time ago.

          I still think we have a chance now to fix the silly name (by adding a new plugin area while keeping the existing), but really it's just to fix the silly name. Whatever we decide, this bug will document the decision for future devs.

          BTW, if we keep /local, then we should go the whole hog and do this too: MDL-26943

          Show
          Martin Dougiamas added a comment - - edited It's not wierd if you look at the name "local", Tim. It was originally a place where you can safely store all sorts of local custom code and be assured that core is not going to send something down on an update that will conflict. I agree it's a small benefit and also with everything else about tools etc. In fact I totally wish we'd just gone for /plugins with hooks into various parts of Moodle but that train sailed off down the highway a long time ago. I still think we have a chance now to fix the silly name (by adding a new plugin area while keeping the existing), but really it's just to fix the silly name. Whatever we decide, this bug will document the decision for future devs. BTW, if we keep /local, then we should go the whole hog and do this too: MDL-26943
          Hide
          Sam Hemelryk added a comment -

          My thoughts on duplicity were originally based upon the hooks within navigation, an area I know well, that has a couple of hooks for local plugins.
          I'm not sure but I'm guessing there are other hooks within Moodle for local plugins, the ability to have settings for is about, no doubt there are more.
          It got me thinking if you created a new plugin type what would make it different from local plugins, and I figured nothing really, just a name and a concept.
          I completely agree the name isn't great, and for sure if we had a /plugins, or /tool and 3 or 4 less plugin types that would be ideal. Really the only thing that separates those other plugin types is where there hooks are (determining where they function).
          Lets assume to begin with the two plugins are identical, we duplicate the hooks for the local plugin to make it easy to upgrade a local plugin to a general plugin and then scream from the roof tops that people should upgrade. If we created this new plugin type at what point would we draw the line? if someone requests a new hook for the general plugin, do we add it just for the local plugin or do we add it for both. If we add it for just the general plugin really we are phasing out the local plugins or at least adding a reason for people to write local plugins as general plugins (because there is more functionality there).
          At that point I found the logic began to blur for me (or perhaps just my interest in this issue) and I figured really all we are doing is creating a duplicate plugin we'd be best to keep sync.

          Perhaps that's a narrow view, sorry if it is.

          ... perhaps Moodle 3 we try to tidy up our plugins structure properly? don't shoot me for suggesting!

          Hope you are all having a good night by the way!

          Show
          Sam Hemelryk added a comment - My thoughts on duplicity were originally based upon the hooks within navigation, an area I know well, that has a couple of hooks for local plugins. I'm not sure but I'm guessing there are other hooks within Moodle for local plugins, the ability to have settings for is about, no doubt there are more. It got me thinking if you created a new plugin type what would make it different from local plugins, and I figured nothing really, just a name and a concept. I completely agree the name isn't great, and for sure if we had a /plugins, or /tool and 3 or 4 less plugin types that would be ideal. Really the only thing that separates those other plugin types is where there hooks are (determining where they function). Lets assume to begin with the two plugins are identical, we duplicate the hooks for the local plugin to make it easy to upgrade a local plugin to a general plugin and then scream from the roof tops that people should upgrade. If we created this new plugin type at what point would we draw the line? if someone requests a new hook for the general plugin, do we add it just for the local plugin or do we add it for both. If we add it for just the general plugin really we are phasing out the local plugins or at least adding a reason for people to write local plugins as general plugins (because there is more functionality there). At that point I found the logic began to blur for me (or perhaps just my interest in this issue) and I figured really all we are doing is creating a duplicate plugin we'd be best to keep sync. Perhaps that's a narrow view, sorry if it is. ... perhaps Moodle 3 we try to tidy up our plugins structure properly? don't shoot me for suggesting! Hope you are all having a good night by the way!
          Hide
          Marina Glancy added a comment -

          I also think that we should keep the name 'local' because renaming is a pain. At the same time everywhere in documentation and in comments we should encourage developers to create "Admin tool" plugins instead of "Local". For example by saying that Local plugins with admin-only interface will not be approved in plugins database

          Browsing through "Local" category on moodle.org/plugins I can see that at least half of plugins are in fact admin tools. But a lot of people just don't realise it. We could tag those plugins with some highlighted note so both developers and people who browse understand that this plugin is misplaced and it will bring people's attention to "Admin tool" category.

          Saying that I do agree with new context level and subplugins for proper "local" plugins.

          Show
          Marina Glancy added a comment - I also think that we should keep the name 'local' because renaming is a pain. At the same time everywhere in documentation and in comments we should encourage developers to create "Admin tool" plugins instead of "Local". For example by saying that Local plugins with admin-only interface will not be approved in plugins database Browsing through "Local" category on moodle.org/plugins I can see that at least half of plugins are in fact admin tools. But a lot of people just don't realise it. We could tag those plugins with some highlighted note so both developers and people who browse understand that this plugin is misplaced and it will bring people's attention to "Admin tool" category. Saying that I do agree with new context level and subplugins for proper "local" plugins.
          Hide
          Tim Hunt added a comment -

          "But a lot of people just don't realise it."

          Admin tools are a relatively new sort of plugin. The other explanation is that people started their plugin before core introduced admin tools, and have never seen any value in coverting it.

          (Another good reason not to change plugin types unless you really, really have to. How many coursereport_ plugins are there in the plugins DB still?)

          Show
          Tim Hunt added a comment - "But a lot of people just don't realise it." Admin tools are a relatively new sort of plugin. The other explanation is that people started their plugin before core introduced admin tools, and have never seen any value in coverting it. (Another good reason not to change plugin types unless you really, really have to. How many coursereport_ plugins are there in the plugins DB still?)
          Hide
          Juan Leyva added a comment - - edited

          My two cents, (from a Moodle partner deveoper and contrib developer also).

          • Admin tools and reports plugins are available since Moodle 2.2, prior to admin tools the only way to make some types of customizations was local plugins
          • A local plugin has hooks for manipulating the navigation and settings tree. Not present in other types of plugins
          • Local plugins is the recommended way for creating new WebServices (if local plugins aren't suitable for distributing then Moodle must change this recommendation)
          • My contrib local plugins must be local plugins because I use some hooks for adding CSS files on the fly depending on the context, forcing a user to only be able to browse inside a course or context, adding extra javascript depending on the context, etc... This can be only achieved using local plugins
          • I think that makes more sense unify admin/tools, reports and local plugins into a generic plugin with standard hooks to settings and navigations than having 3 types of similar plugins each one with their own hooks (see lib/navigationlib.php, you will see the code for the different hooks easily)
          • There is also a historic request of having the possibility of managing renderers inside plugins. Some themes are 30% layout code and 70% code customizations, and this seems not to be a proper way for doing things.
          • If local plugins are not for distributing, remove the option for upload local plugins in the plugins database

          My proposal is:

          • Create a new generic plugin with capabilities for overwrite renderers and different hooks to navigation and settings.
          • Remove the old Custom script injection feature, and add a new hook in this new generic plugin to be executed when the initial setup is finished.
          • Deprecate local plugins and make easy the conversion from local to the new generic plugin. Local plugins and generic plugins can works together two major versions and then deprecate local plugins.
          • Add subplugins support for this new type of generic plugin
          • Optional: Convert admin/tools and reports to the new type of generic plugin.

          I think that creating a "super generic plugin" with all these capabilities will solve a lot of current and future problems.

          Show
          Juan Leyva added a comment - - edited My two cents, (from a Moodle partner deveoper and contrib developer also). Admin tools and reports plugins are available since Moodle 2.2, prior to admin tools the only way to make some types of customizations was local plugins A local plugin has hooks for manipulating the navigation and settings tree. Not present in other types of plugins Local plugins is the recommended way for creating new WebServices (if local plugins aren't suitable for distributing then Moodle must change this recommendation) My contrib local plugins must be local plugins because I use some hooks for adding CSS files on the fly depending on the context, forcing a user to only be able to browse inside a course or context, adding extra javascript depending on the context, etc... This can be only achieved using local plugins I think that makes more sense unify admin/tools, reports and local plugins into a generic plugin with standard hooks to settings and navigations than having 3 types of similar plugins each one with their own hooks (see lib/navigationlib.php, you will see the code for the different hooks easily) There is also a historic request of having the possibility of managing renderers inside plugins. Some themes are 30% layout code and 70% code customizations, and this seems not to be a proper way for doing things. If local plugins are not for distributing, remove the option for upload local plugins in the plugins database My proposal is: Create a new generic plugin with capabilities for overwrite renderers and different hooks to navigation and settings. Remove the old Custom script injection feature, and add a new hook in this new generic plugin to be executed when the initial setup is finished. Deprecate local plugins and make easy the conversion from local to the new generic plugin. Local plugins and generic plugins can works together two major versions and then deprecate local plugins. Add subplugins support for this new type of generic plugin Optional: Convert admin/tools and reports to the new type of generic plugin. I think that creating a "super generic plugin" with all these capabilities will solve a lot of current and future problems.
          Hide
          Petr Škoda added a comment -

          Hello,

          our plugins are specialised because otherwise we would have more performance problems - it is expensive to load all plugins into memory to find out what plugin supports which feature. Once we have some mechanism to cache plugin features we can add more hooks all over the place. Subplugin support is problematic - naming, performance, AMOS, etc. I believe renderers are a separate topic.

          Removing of features is imo not an option, for backwards compatibility we need to keep all plugin types.

          I believe that admin/tool was a success, we need to migrate more stuff from admin/ there such as site registration. I designed the local plugin support for ''hacks'' that were not supposed to be part of official distribution, place where standard rules do not apply. The only major problem I see now is language packs in AMOS - they need to have unique name which was not required in older versions, the plugin database is good for name reservation, forbidding local plugin uploads would break translation workflows.

          I already proposed to add cohort contexts, I do not understand why there should be any other context type or how it could be used.

          One general plugin would be nice, but so would be standard CamelCase for classes, request routing, class loading - pretty much exactly what Symfony2 does. Maybe the new plugin type could define a completely new API and modern coding style...

          I vote for B/

          Show
          Petr Škoda added a comment - Hello, our plugins are specialised because otherwise we would have more performance problems - it is expensive to load all plugins into memory to find out what plugin supports which feature. Once we have some mechanism to cache plugin features we can add more hooks all over the place. Subplugin support is problematic - naming, performance, AMOS, etc. I believe renderers are a separate topic. Removing of features is imo not an option, for backwards compatibility we need to keep all plugin types. I believe that admin/tool was a success, we need to migrate more stuff from admin/ there such as site registration. I designed the local plugin support for ''hacks'' that were not supposed to be part of official distribution, place where standard rules do not apply. The only major problem I see now is language packs in AMOS - they need to have unique name which was not required in older versions, the plugin database is good for name reservation, forbidding local plugin uploads would break translation workflows. I already proposed to add cohort contexts, I do not understand why there should be any other context type or how it could be used. One general plugin would be nice, but so would be standard CamelCase for classes, request routing, class loading - pretty much exactly what Symfony2 does. Maybe the new plugin type could define a completely new API and modern coding style... — I vote for B/
          Hide
          Michael de Raadt added a comment -

          +1 for option B, and I'll take what's in the box.

          Show
          Michael de Raadt added a comment - +1 for option B, and I'll take what's in the box.
          Hide
          Martin Dougiamas added a comment -

          OK, I'll declare this closed then.

          Henceforth let it be known throughout the land that /local is actually a stupid name for our "generic plugin" type and that we encourage people to use it when no better plugin type fits the purpose.

          Apu can you make sure that moodle.org/plugins treats it properly?

          Show
          Martin Dougiamas added a comment - OK, I'll declare this closed then. Henceforth let it be known throughout the land that /local is actually a stupid name for our "generic plugin" type and that we encourage people to use it when no better plugin type fits the purpose. Apu can you make sure that moodle.org/plugins treats it properly?
          Hide
          Aparup Banerjee added a comment -

          Aye Cap'n

          ps: i've added a little FAQ here : http://docs.moodle.org/dev/Plugin_validation#Frequently_asked_questions. Does that look alright?
          The doc linked there seems to be saying the right things too.

          Show
          Aparup Banerjee added a comment - Aye Cap'n ps: i've added a little FAQ here : http://docs.moodle.org/dev/Plugin_validation#Frequently_asked_questions . Does that look alright? The doc linked there seems to be saying the right things too.
          Hide
          Juan Leyva added a comment -

          So /local is the name for Moodle generic plugins, what about the issue that started this discussion MDL-26943 (Enable sub-plugins in Local plugins) then? Is ok enable subplugins for 2.4 now that there is a cache system?

          Show
          Juan Leyva added a comment - So /local is the name for Moodle generic plugins, what about the issue that started this discussion MDL-26943 (Enable sub-plugins in Local plugins) then? Is ok enable subplugins for 2.4 now that there is a cache system?

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: