Adding the ability to check for plugin updates

To do this will require a plugin that implements the web services on the community site and code in Elgg that hits those web services.

I created a github repository for the web services on this site:

I sketched out a basic API. Comments and suggestions welcome.

This is going to require creating a unique signature per plugin, unzipping the uploaded plugin archives, and some logic to check versions.

  • I visualize that for each plugin in the Admin Plugin page, a notification will be displayed about the availablity of the new version.

  • @Cash:

    Key point for *not doing as an Elgg PlugIn is :=
    There are Elgg Developers who already do host
    PlugIns code on non-Elgg sites -- eg WP, Joomla --
    b/c of more matured eCommerce hookups.

    For this reason - the Auto-Updater should operate 
    on a neutral platform - straight PHP, etc.

    Can discuss off-line if wanna go thru how
    a platform-neutral approach might work.. or..

    I will do my design notes and post later.

  • Dhrup: I think that the update services must be done for ELGG community site and for plugins hosted in elgg comunity site. Its the first goal.

    If a developer want to make their own update services in commercial plugins, we can only offer a good API documentation, so the developer can create a webservice to Drupal, Joomla, etc.

    The Cash´s idea (If I understood well) is customize the elgg comunity to, in a automated way, grab new uploads and update de metadata without manual intervention. And the update API, in client´s plugin, just check if a new version was upload.

    The problem: Portability to Drupal, etc. But we can, in plugin manifest, create a metatag with the URL of the update service. So, if commercial developers want to use our standards, its almost done. Just change de URL and create a custom webservice.

  • @Cash: Pre requisites:

    Server: Unzip the plugin, read the manifest and grab the informations. The manifest must have a creation date and a ELGG target version. If a new plugin is uploaded, the plugin is treated like "new" if the target is the same AND the creation date is greater than client´s plugin. Why use date? We dont have naming standards to plugin versioning. We have only a problem: Plugin´s unique id. A lot of plugins uses the same name, because are forks. We need a plugin´s guid or something like it. I think that the community site has that information. So we must include in the plugin´s manifest before download.

    Client (Plugin): Register a weekly cronjob, read the manifest and check the webservices parsing the unique id, creation date and target ELGG version. If a new version exists, mail the administrador with plugin´s URL and release notes.

    You can leave the cliente code with me (The easy one) ;)

    Ps.: What your plans to webservice returns? JSon? XML?

  • PS: A plugin can have two or more target ELGG versions. To be simple, we can, in manifest, create a field with comma separated versions.

    Example: <auto_update_target_version>1.7,1.8</auto_update_target_version>






    Ps2.: I hate XML.

    1. Definitely focused on plugins in the community repository
    2. JSON data (though the community web service would also support XML...and serialized PHP)
    3. For plugin ID, I think we can create a hash of the plugin name, version, and author name. That way plugin authors do not need to create a GUID for their manifest. Plugins are stored with a project as the container and a release for each version ( If we pass a unique id for a particular plugin version, we can get back to the project. I can explain this further if needed.
    4. For the client, I like using a cron job for this. It needs to be randomized so that every server is not hitting the community server at the same time.
    5. Elgg added admin notices in Elgg 1.8. They stay around until a user dismisses them. This could be a good mechanism for telling the admin user about the updated plugins.
  • 1 - Agreed.

    2 - JSon is easy to manipulate. Agreed.

    3 - Why not use the project guid? In my antispam plugin, I have a guid for each release, but the project´s guid is always the same: 774755. This number could be added in manifest after the upload.

    4 - Dont worry about the client. I will make a good API and a test plugin. And liked about the randomized cron jobs. I will make some studies here.

    5 - Deal. But think about 1.7 if possible (Sending notifications by e-mail). Some users dont have plans to migrate to 1.8 for a while.

    My 1 - I have a code to make assincronous http calls. I use in spam login filter. If the stopforumspam service is down, my plugin is not afected. I think that http function should be a reusable plugin or a elgg function, to be reused in all plugins.

    My 2 - Explain better how we can check the ELGG target version.

  • 3 - Extracting the entire zip file, inserting xml into the manifest, and then repacking it? Why do all of that when we can get a unique ID from combining the name/version/author? Seems like a lot less work.

    Right now the manifest contains the minimum version for the plugin. (We've been using a datetime value for version, but 1.8 adds support for the human readable version.) We can expand the plugin repository to include all the versions that a release supports. I think it is easier to maintain that information on the community site (and even get user feedback on this).

    Have you looked at the readme I put up at ?

  • This will be a great addition. Much appreciated, Cash!

  • Cash, I´ve working and doing some research here about the ELGG auto update.

    What you think about a plugin that list all enabled plugins, gets the manifest and make a unique call to ELGG webservice? With this approach, we dont need to change the code of existing plugins. Just a few changes in the manifest, to create the hash.

    I will code a proof of concept and show to you, ok?

    Best regards

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.