Hi,
I’m developing omeka-cli and one of its features is to download plugins from omeka.org. The solution I used for this is to parse the HTML of http://omeka.org/add-ons/plugins/ and plugins page like http://omeka.org/add-ons/plugins/simple-pages/.
I wonder if there is a better solution, like a REST API for example, that would allow to also retrieve data from plugin.ini (or theme.ini) file without having to download the zip file.
Another problem with parsing omeka.org is that it lacks one important info : the plugin’s directory name, which is the unique identifier of the plugin. On omeka.org we have the archive’s filename and the name of the Wordpress post, but they do not always match with the directory name in the zip file.
The only alternative I could come up with is to download all zip files, extract the needed info into a big JSON file and publish it online so that omeka-cli can use it.
An example of that is here : https://github.com/jajm/omeka-addons-index
It is updated automatically every night thanks to Travis CI, but that means every add-on page is fetched once a day (only new add-ons are downloaded), and omeka-cli will depend on a file on Github to be able to download plugins from omeka.org, and I would like to avoid that.
Is there any other solution ?
1 Like
First off, omeka.org is currently undergoing a complete redesign, so in the near future the HTML parsing you are doing will no longer work. Hopefully, though, the redesign will make things easier. We’re aiming toward a system that is based on GitHub’s API, with a registration system letting people point to the appropriate repo, possibly similar to your index, but I’m not sure of the details there. I think we’ll generally focus on the releases data from GitHub.
The directory name is a good question. I can see the possibility of adding that data to the plugin.ini files to ensure consistency.
I’ll ask around the omeka dev team to share more about the new upcoming system.
I have the same issue with the module Easy Install, so I parse and fetch data from omeka.org, github.com and gitlab.com.
In fact, I have my own parser for https://daniel-km.github.io/UpgradeToOmekaS, and data are available as csv here https://github.com/Daniel-KM/UpgradeToOmekaS/tree/master/docs/_data), updated via a script.
I’m not sure how this will be helpful, it can already be found in the zip file, or guessed from the name of the <name>Plugin.php file. And it will require all plugins to be updated in order to be used consistently, which is unlikely to happen IMO. Unless, of course, if it is made mandatory in the next Omeka Classic release, which is not desirable I think.
I knew about that list, but it has some downsides too : it lacks the plugin’s directory name, it has only the latest version of each plugin, and, as with my list, it would make omeka-cli depend on a file on github that is not maintained by the Omeka Team.
I guess I’ll wait until the new system is in place.
Thanks.
1 Like
In fact, there is not a need only for a new site and a new api, but for a newer management of the community too.