The feasibility of adding blocks as part of local plugins

@fulldecent

I have been deeply diving into the current task of adding:

1. Dashboard Context block (CONTEXT_USER) to display content on student dashboards ("My home")
2. Course content block (CONTEXT_COURSE) to display content on course pages
3. Activity block (CONTEXT_MODULE) to display content on activity pages

I’m not sure that adding blocks as part of the local plugin is the best Moodle practice and modularity principle. If you check the Moodle [README](https://github.com/moodle/moodle/tree/main/local#readme) file related to local plugins, you can see the purposes and main features of this type of plugin.

In our initial conversation, I mentioned that Moodle has a lot of plugin types and asked if you were sure that this type would be sufficient. You told me that it suits all purposes. If we return to the README file, we can see that the purposes of local plugins are:

Local plugins are used in cases when no standard plugin fits, examples are:
* event consumers communicating with external systems
* custom definitions of web services and external functions
* applications that extend moodle at the system level (hub server, amos server, etc.)
* new database tables used in core hacks (discouraged)
* new capability definitions used in core hacks
* custom admin settings

Standard plugin features:
* /local/pluginname/version.php - version of script (must be incremented after changes)
* /local/pluginname/db/install.xml - executed during install (new version.php found)
* /local/pluginname/db/install.php - executed right after install.xml
* /local/pluginname/db/uninstall.php - executed during uninstallation
* /local/pluginname/db/upgrade.php - executed after version.php change
* /local/pluginname/db/access.php - definition of capabilities
* /local/pluginname/db/events.php - event handlers and subscripts
* /local/pluginname/db/messages.php - messaging registration
* /local/pluginname/db/services.php - definition of web services and web service functions
* /local/pluginname/db/subplugins.php - list of subplugins types supported by this local plugin
* /local/pluginname/lang/en/local_pluginname.php - language file
* /local/pluginname/settings.php - admin settings

We have already covered all the standard features of a local plugin (and even more).

Additionally, I'm not sure that this approach will work. Adding blocks to the relevant [blocks folder ](https://github.com/moodle/moodle/tree/main/blocks) in Moodle doesn't present any issues; it's very easy to register a new block this way.


However, when I add a block as part of a local plugin, it doesn't appear.

In the end, I started a conversation in the [Moodle forum](https://moodle.org/mod/forum/discuss.php?d=463917) to see what suggestions other Moodle experts have.

Start with the Moodle local plugin README and the blocks folder referenced in the issue, then compare how each plugin type registers and exposes blocks. Reproduce the reported local-plugin behavior and review the linked Moodle forum discussion. Done means documenting whether local plugins can support these blocks and identifying the appropriate plugin structure.

Written by the indexing model from the issue text.