Possibility to manage Moodle site with Composer

Possibility to manage Moodle site with Composer

Juho Jaakkola -
回帖数：6

I've been working on an experimental way to manage the code of a Moodle site as one single Composer project. This means that both Moodle itself and all third-party plugins are dependencies of the project.

The benefits of this approach are:

  • It's easy to duplicate the code between environments (developer1, developer2, staging, production) so that it is completely identical between them all.
  • Possibility to update both Moodle core and all third-party plugins to latest version (within the version constraints defined in composer.json) with one single `composer update` command.
  • Possibility for automation
    • For example the `composer install` command could be configured to also automatically run upgrades via admin/cli/upgrade.php.
  • Composer is de-facto standard package manager for PHP. Learn it once, and you will be able to use it with all kinds of PHP applications!

My project can be found here: https://github.com/juho-jaakkola/moodle-project. I would very much like to get feedback about it.

In order to test it, you need command line access to git and composer.

You can try out the project like this (change the name of "your_project"):

  1. git clone https://github.com/juho-jaakkola/moodle-project.git your_project
  2. cd your_project
  3. composer install

After this you should have the following directory structure:

composer.json
composer.lock
README.md
vendor/
web/

Now you can install plugins with the `composer require` command.

For example:

composer require netspotau/moodle-mod_lightboxgallery

Thanks to a special Composer installer, the plugin will get automatically installed to `web/mod/lightboxgallery/`.

Both composer.json and composer.lock will get updated automatically. Composer uses these two files to save the status of the project. Thanks to them, the same versions of the same plugins get installed also to the other environments. (Once shared to other devs e.g. through git.)

Once installed, the domain of the site should be configured to point to the `web/` directory.

Known issues:

The only challenge with the project is that only a handful of Moodle plugins currently support Composer.

I believe the main reasons for this are:

  • Many people do not manage their Moodle code through command line (and don't even want to, which is OK)
  • It hasn't been possible to use Composer properly with Moodle before

I'm hopeful that popularity of Composer will increase in time in the Moodle community. Also there are different kinds of workarounds that allow Composer to install also plugins that do not yet have support for it.

Please post any questions about the project's usage here in the forums, and report any found bugs to the Github issue tracker!


平均分：Useful (1)
回复Juho Jaakkola

Re: Possibility to manage Moodle site with Composer

Jan Dageförde -

Hi Juho, 

your idea is quite intriguing, seeing that I am sometimes unhappy with our Git submodule approach of adding plugins to our installation(s). Today I found out about http://moodleplugarit.mmg.fi (based on the proof-of-concept http://micaherne.github.io/moodle-plugin-repo/), which ties to the official Moodle plugin directory. On packagist I think it could become hard to find authoritative versions plugins that you are looking for, increasing the chance of falling for development forks or even malicious "versions" of a plugin you are looking for – so having a go-to repository that mirrors from moodle.org/plugins is great.

So I have to check out your approach soon. What I am wondering is,

  1. how reliable is the third-party repo http://moodleplugarit.mmg.fi (or how hard is it to run it yourself, i.e. is there any chance that this could become an official way of obtaining plugins as an extension of Moodle HQ's directory?)
  2. plugins may define their own subplugin types, and new ones could be introduced from core in new Moodle versions. How hard would it be to install such a plugin? Do you have to add new types to the (rather fixed) list in composer.json of the installation (your example), or can it be computed transitively from plugins' composer.jsons?
  3. is it (easily) possible to have custom patches on top of core and plugins after running `composer install`? After all, we deploy some patches on top of core and plugins. Right now we need to maintain forks of plugins' repos to achieve this.

Thanks for posting your current solution, I definitely need to evaluate this.

平均分： -
回复Jan Dageförde

Re: Possibility to manage Moodle site with Composer

Juho Jaakkola -

On packagist I think it could become hard to find authoritative versions plugins that you are looking for, increasing the chance of falling for development forks or even malicious "versions" of a plugin you are looking for

I don't think anything prevents using packages from Packagist once you've found a stable and secure version from Moodle's official plugin repository. simply mark in composer.json that you want to use that specific version. After all the code itself is the same both in Moodle's plugin repo and Packagist. Those are simply two different ways of storing the same code.

Answers to your other questions:

  1. Currently that particular repo is completely experimental (it doesn't for example even use HTTPS), so don't use it for anything else but testing! Moodle HQ isn't (at least currently) interested in maintaining their own version of such repo, but it would absolutely be the best option to have one single repository. It doesn't make sense for everyone to maintain their own. For me it would be completely sufficient if people would simply submit their plugins to Packagist. As I stated before, you can first assess a plugin at https://moodle.org/plugins/ and then install it with Composer.
  2. New plugin types and subtypes must be manually added to the installer in order to get them installed in the correct directories. Nothing however prevents you from creating your own installer that works exactly as you like. Your idea of computing the values somehow might be very much possible!
  3. Yes, you can apply patches on top of the installed plugins with the cweagans/composer-patches package (https://github.com/cweagans/composer-patches). Simply require that in your project, and you can start defining patches in your project's composer.json.

I'm very interested to hear any feedback and opinions of my project, so keep me up-to-date of your progress! 微笑

平均分：Useful (1)
回复Juho Jaakkola

Re: Possibility to manage Moodle site with Composer

Jan Dageförde -

> I don't think anything prevents using packages from Packagist once you've found a stable and secure version from Moodle's official plugin repository [...] Those are simply two different ways of storing the same code.

I totally agree. It's just that finding the "correct" ones may become hard as soon as forks of the same plugin can be found there, or plugins that coincidentally share the same name (because they are not checked for uniqueness, unlike in the plugin directory). But I don't think that would  be a reason to avoid Packagist (or Composer altogether) at all. On the contrary, it would be a great addition to the plugin directory for developers or development-savvy system administrators. This merely means that we would need a way to express that two instances of a plugin (in directory and in Packagist) relate, maybe by establishing a convention.

ad 1.

> It doesn't make sense for everyone to maintain their own.
Oh god, no, definitely not, and HTTP also isn't  a good idea. But it's a great proof of concept, so I am wondering how hard this would be to maintain, especially for someone who wouldn't have to scrape the plugin directory 微笑 . Maybe, if the additional effort wouldn't be too high, we could make a case for adding this as a feature to the official plugin directory – that would be very convenient.

ad 3. 

Thanks for pointing me to `composer-patches`, this is useful.

Cheers

平均分： -
回复Jan Dageförde

Re: Possibility to manage Moodle site with Composer

Juho Jaakkola -

It's just that finding the "correct" ones may become hard as soon as forks of the same plugin can be found there, or plugins that coincidentally share the same name (because they are not checked for uniqueness, unlike in the plugin directory).

The package names are in fact unique also in Packagist, so it isn't possible to accidentally install a wrong one.

But I agree it would be nice to have some kind of direct relation between them. For example the name of the Composer package (if one exists) could be mentioned in Moodle's plugin repository.

For anyone not familiar on finding the Composer package name of a Moodle plugin, here are the steps for it:


1. Find the plugin at Moodle's plugin repository



2. Find the "Source control URL" link from the plugin page



3. In the source control repository select the "composer.json" file



4. You can now read the package name from the file


For example in this case the name is "fmcorz/moodle-block_xp", so the command for installing the plugin would be:

composer require fmcorz/moodle-block_xp


平均分： -