Override or extend footer function in plugin, not theme

Re: Override or extend footer function in plugin, not theme

by I V -
Number of replies: 1

Sorry to get back after a while but just wanted to check the activity on this thread. Do we have any alternate solution ?

If the only option is to go down the route of overriding footer() function in custom theme, then it raises another question for me - How to determine which theme to override? 

Meaning if we need to install our block plugin across different Moodle installs that are already using their own custom theme then how do we create a plugin that has our
  --- custom block functionality  
  --- AND custom theme_overridden_renderer_factory within that determines the current "theme" (standard OR custom) to override footer()?

I'm hopeful to find an answer to this as I'm sure this could solve the problem for lots of people with similar issue. 

Average of ratings: Useful (1)
In reply to I V

Re: Override or extend footer function in plugin, not theme

by John Doyle -

A few rough ideas below on possible approach. No problem to move to tracker if a better place there for it - unfort. short on time to look through tracker right now.

  • Default behavior:  Themes applied to plugins using framework currently defined (site, user, course, sess)
  • New capability:  Extend theme and plugin frameworks to enable opt-out of default theme behavior from within a plugin. 
  • If opt-out is set in a plugin:
  1. Would look somewhere in plugin for renderer class
  2. Renderer class in plugin would apply only to that plugin
  3. Plugin would still rely on default theme framework for anything not specifically defined in plugin renderer class
  4. To the previous points on priorities, perhaps extend the existing $CFG->themeorder capability to include 'plugin' as a new type for prioritization to handle conflicts
  5. If opt-out enabled in plugin but no renderer class defined, or no functions in renderer class, could fall back to default theme behavior (fatal still possible if something in plugin is relying on specific plugin renderer, but hopefully reduces potential.)
  • At global level, could enable/disable via theme settings, similar to what exists already for course- and category- specific themes 
  • At plugin level, could set opt-out somewhere like settings.php or in a required plugin file
  • Core update to enable this could perhaps work similarly to existing course or category theme customization?