Experimental community plugins mirror as composer repository

Last updated by Paweł Sroka Comments (14)

If you hear for the first time about composer, that's not a thread for you. Go learn about it and come back when you're familiar.

Introduction

I was experimenting for some time with making elgg plugins distribution easier. One of the approaches was to add plugins search and install directly to dev install. It's still work in progress, but already works and is available here: https://github.com/Srokap/srokap_plugin_installer

Another approach is following trend of many other frameworks that already use composer as optional way of installation or sometimes as the only way. My experience with annoying conflicts on git submodules made me think to replace them with composer dependencies as well as simplification of our community.elgg.org updates process.

This is not officially supported way of installing plugins! It might be at some point, but that's still decision to be made and scheduled for 1.10 milestone.

Repositories

You can use composer for installing elgg plugins already, since I wrote installer for Elgg plugins to composer/installers that got merged into version 1.0.8. You can already find few Elgg plugins on https://packagist.org/ that I've been using for testing.

Having littile plugins available would be a main blocker for this to be used, so I'm also setting up experimental mirror of plugins uploaded to community.elgg.org, so they can be installed with composer as well. It's currently set up at: http://composer.i.srokap.pl/ and running on my raspberry pi, so please don't benchmark it and forgive awful connection ;-)

How is repository made?

It's made from an older snapshot of community data (more than 1 month old), so new plugins will be missing. Currently there are missing .tar.gz archives, archives containing other than exactly one manifest.xml file, containing corrupted manifest.xml, versions restricted by composer version format (fancy suffixes mostly).

Author name is the same as community username of project owner. Package name is taken from 'id' field in manifest.xml or directory name inside archive if first option is not set. It's not perfect - I'll be fixing it.

I'm running it using satis which is very leightweight repository version, but handles our more than 1500 plugins and over 2000 versions nicely so far. We might want to move to packagist fork, but I see no real benefit so far.

It will be upgraded more often in future of course.

How to make elgg plugin work with composer?

First option is to just upload to community and wait for http://composer.i.srokap.pl/ update. This way has it's limitations, ie. can't checkout dev-master

Second and recommended option is to add comoser.json to your plugins project root and ping packagist.org to fetch it. You need to take care of 3 aspects:

  • Set type field to 'elgg-plugin'
  • Require "composer/installers" in version  >=1.0.8
  • Use name of the package the same as the target name of plugin directory in /mod/. Plugins with name AUTHOR/PLUGIN get installed into /mod/PLUGIN/

Installed plugins are not being enabled. Source code is delivered to /mod/ and you manage it from admin panel as usual.

Working example: https://github.com/Srokap/code_review/blob/master/composer.json
The rest of the fields are the same as for every other composer package.

How to use it?

Simplistic example ot adding tidypics to your project is here: https://gist.github.com/Srokap/10608474

What's required/recommended:

  • Add composer.i.srokap.pl repository if you want to fetch plugins from there in addition to packagist.org
  • [recommended] set "minimum-stability" to "dev", otherwise you won't be able to install development versions of some plugins (composer will report that can't find particular package)

It works fine with requiring "classical" composer plugins in parallel. They go to vendor dir, elgg plugins go to /mod/ dir.

Is it stable?

No. It's still under development. Some details may change. Most importantly - package names may change in future, so feel free to use it, but don't be supprised if you'll need to update your composer.json now and then.

I'd very appreciate feedback on the feature, if you find it useful or if you have problems other than not knowing composer ;-)

  • The plugin installer didn't work for me (action/fetch was not found). Well, the download part, but the search part is working!

    I think this is really good, don't have the experience with composer (reading, still) but would like to help once I test it out

  • Tested on a clean install of elgg  1.8.19 only core plugins.

    Same results.

  • Only situation I was able to replicate problem, was to have wrong name of plugin directory, ie. leave default github 'srokap_plugin_installer-master' which should be 'srokap_plugin_installer'. Might that be the problem? That would give exactly described results.

  • You know what? I'm gonna follow your advice more deeply:

    Go learn about it and come back when you're familiar.

    Yep, that was the problem. Feel so silly now.

    Anyways, the plugin works as expected, downloaded the plugin and install it successfully. I don't know, but I really like the way it works. I think it is better not to 'activate' on installation, like you have it.

    Great work!!!

  • Actually about learning I was refering to composer itself. Plugin installer plugin is a separate thing ;-)

  • Will we be able to use composer for managing Elgg core's dependencies if sites are using it to manage their plugin dependencies?

    Hopefully we can come up with a solution that doesn't put these two at odds.

  • If Elgg 2.x or 1.9.x comes with composer that would be good becuase composer run the site faster!

  • How do you anticipate composer will help run Elgg faster?

  • What i mean by faster is performance. Composer is designed to manage dependencies but it can also help with the performance.

  • Composer does not affect performance. It's just a package manager.

  • @Pawel

    Hi! Plugin installer is extremely good! I've been testing it during the last month and it has been very reliable and useful.

    I was wondering, if there's a way to change the repository, instead of elgg use mine (Like using the community plugins plugin in my own site)

  • I didn't make any settings AFAIR, but it should be single place in code to change. If you use community plugins in reasonably fresh version, it should work just fine.

    Edit: Here you are 

  • @Pawel Sroka

    Thanks! I was looking at the wrong place.

    So far, Sroka Plugins Installer doesn't create problems. It has been working with no issues, and no extra bandwidth is used. Overall I like this plugin, hopefully it will be bundled in version 1.10

    The only thing that could be annoying is developers uploading plugins with a short non-descriptive Manifest file.

  • After heavily using and testing this installer for a couple of weeks, I found some problems that it might face in case *hopefully* it gets fully integrated within elgg:

    -Elgg Community Repository URL Changes:

    This could somehow be addressed by encouraging users to upgrade their elgg networks, but some won't do it due to time. I experienced this issue after the https swithc.

    -Plugin Updates

    Some developers release updates on GitHub rather than here, which brings to another point:

    -Extra Configuration Steps

    Some developers instead of writing the extra configuration steps on the readme file, they just put it on the plugin page, which cannot be seen while using the installer.

    -No Screenshots

    Still no screenshots support, which is not a big deal but the installer will look modern.

    -Developers not updating the Manifest File

    This is an issue with some plugins. Developers forget to do this small but important part.

     

    Hopefully, we will see a plugin/theme installer integrated with the core. The majority of CMS has this, and we should not stay behind.

     

Paweł Sroka

Former Core Elgg team member, freelance developer.