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.
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>
or:
<auto_update_target_versions>
<version>1.7<version>
<version>1.8<version>
</auto_update_target_version>
Ps2.: I hate XML.
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 https://github.com/Elgg/community_web_services ?
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
- Previous
- 1
- 2
- 3
- Next
You must log in to post replies.