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: https://github.com/Elgg/community_web_services
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.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
Looking at plugin site, I´ve found a way used by 'MOBILE':
@Cerceau: Our approach is similar, but a bit complex. We need to set the ELGG target version and make a code reusable to all plugins. Thats the reason to create a "hash" with developer´s name, creation date and plugin´s name.
I am coding here the client side to cash´s appreciation.
Ray - Yes, I think a single call with all of a site's enabled plugins is a good idea. I'm updating the documentation on the github repository right now based on a comment by Evan Winslow. I think I may be able to deploy a mock implementation by the end of today.
@Cash, I have a "elgg_update_services" plugin here. The code needs some polishment and the random cronjobs is not done yet. But the plugin gets the plugin´s list, checks if the plugin manifest complains the requirements for autoupdate and creates a json array with all the plugin´s data. The next step is integrate with your webservice.
I will try to make some code this week. ELGG is still a hobby, so I code in my spare times.
Thanks for your partnership and confidence in my job.
@Ray Thanks. Elgg is also not my full-time job so I understand.
I have deployed a mock web service at this site: http://community.elgg.org/services/api/rest/json/?method=plugins.update.check&version=1.8.1&plugins[]=cdaa7ed69575933d516e0b82bcfd642a&plugins[]=8e8494d1ec10116457bae463cbe74b4a
It randomly decides whether a plugin should be updated and then returns the same data each time.
The hash identifier should be md5($plugin_dir . $plugin_version . $plugin_author)
My next step is to start implementing the plugin look-up for the web service.
@Cash: How do you will know if a version is newer than a version parsed by update plugin? Using the "uploaded date" from ELGG community? If you store a hash in ELGG plugin´s database, you can know if a hash is newer, right?
I will adapt my client to your webservice. Wait a few days.
Ps.: In your webservice, think about a update check for ELGG core and, maybe, show the release notes of each plugin. (Hmmm.... maybe a litle verbose for a webservice)
You should read the documentation that I put up at https://github.com/Elgg/community_web_services
The hash will be per plugin release (each plugin has a project and many releases). I'll be able to look up the specific plugin release from the hash. From there, I can get the plugin project and see if there are any newer releases.
@Cash: Understood.
It would be great if there is a way to check the version of the ELGG itself. It may be a major or minor bux fix version.
@Purus: Lets hear what cash have to say. But is possible.
- Previous
- 1
- 2
- 3
- Next
You must log in to post replies.