At the moment we have all Moodle plugin type directories spread over the entire filesystem. This is not a terrible thing, but it's also a pain in the butt and many senior devs have lamented this decision).

I have been wondering about the feasability of a broader code restructure and how that would help us. Ideally we should look to migrate to a single plugin directory (for example /plugins) which holds all plugins.

In an ideal world we would make it possible to provide an alternative value for this to overload plugins, for example:
/some/other/path/plugins

This would mean that a host such as MoodleCloud can have per-site plugins in the alternative directory, and the standard Moodle plugins shipped with core, thus allowing for per-client theming, and per-client installation of plugins.

In addition to this, we should start to migrate our directory structure to not be all-public. This must include a breaking change - that is to create a new parent directory for all current code that is public_html.

The result would be something like:

.

├── config.php

├── plugins

└── public_html

    ├── [ALL CURRENT CODE]

    ├── index.php

    └── lib

This gives us the benefits:

• we can have private code which is not web accessible - things like config.php for example
• we can force plugin code to not do things it shouldn't, and improve security of plugins
• we can more-easily migrate to composer-managed depednencies
• we can migrate to a composer-managed plugin system

Now this won't be a simple change, and we will find a lot of things which break (mostly where people are doing things they shouldn't).

Ideally we should start to prepare for this change in parallel to migration of all files to use routed endpoints. By migrating to routed endpoints, we cease the need to have relative file paths such as require_once('../../config.php');.

Once we are in a position to start supporting this, we will have to migrate plugins piece by piece (not all in one) and ideally we can perform some other changes at the same time, including:

• adding routing and ditching individual endpoints - no more mod/forum/view.php but an endpoint such as mod_forum/view and loads the correct route and displays it.
• migrating things like config.php

Once such a migration is complete, it allows Moodle to change it's deployment structure to be entirely composer-based with a MoodleCore product. We can move all plugins out of core and put them as separately hosted and managed plugins.

I feel that this combination of changes will help us to:

• improve security
• improve coding standards
• support much-desired features (like per-client theming on shared hosting)
• focus on our web service architecture and functions
• migrate to a more core-light platform