Hi,
I create (for me) simply plugin to check if some installed plugins are availible to update.
https://github.com/vician/PluginsUpdate
I downloading data from github from plugin incubator.
If you use it, I will be glad.
Martin
-
-
Hello ;
The idea is not bad but:
- The parsing of local / remote info files on every admin page load is something crazy. I would recommend to register your listener on the onBeforeUpdatePluginList event, which is triggered when you clicks on the Update Plugins button, instead of the onAdminScriptStart event. Also, you should cache the parse result and set an expiry time (such as one hour).
- Instead of reading the plugin directory to get the plugin list and parse all info files with you own function, you should instead use the plugin manager class which allows you to retrieve all plugins and query them (See the sample bellow).
- Data provided in the plugin repository on github are not really relevant. Generally, it's not recommended to use any plugin from the incubator. Instead, you should try to parse RSS feed from our plugin store.
At the moment, I would recommend all our users to not use your plugin (as long as the first point is not fixed).
Howto retrieve plugin info:
PHP- /** @var iMSCP_Plugin_Manager $pluginManager */
- $pluginManager = iMSCP_Registry::get('pluginManager');
- $pluginNames = $pluginManager->getPluginList('all', false);
- foreach($pluginNames as $pluginName) {
- $plugin = $pluginManager->loadPlugin($pluginName, false, false);
- $pluginInfo = $plugin->getInfo();
- // Do something with info for this plugin ...
- }
-
-
Hello,
I agree with points 2 and 3. I'm not sure if exists some more specific documentation to create plugins like this. In future versions I do local version like you write,
But in RSS is not information about tag of version. Only if RSS publis date is equal to publis date in info file it will be work. Maybe I will add two way to search updates.To 1 of your points. This plugins run parsing if you click to admin/pluginsupdate in Settings menu, which is created by this plugin. So, it's not like you write in every onAdminScriptStart.
To the future I would:
1) Run search update in cron on background in specific time, edited by admin and mail notificitation to admin.
2) Create specific site in settings like now, but with table of plugins and "search update" button. I think that, I can't including this to Plugins manager site by another plugins.
3) I thinking about external server which watching new update (parse some sources), and simply answer question from my plugin about updates.So, please explain me, if is the first point realy that bad as you wrote, I don't think it.
Thank you,
Martin -
Re
Point 1: Sorry, this is a mistake (I've read the code too faster). In fact, your listener is responsible to setup the navigation for your plugin interface, which provides only one button ATM to trigger the check for plugin updates. Does this really needed to provide a page only for that purpose? Does it not better to just simply listen on the onBeforeUpdatePluginList event and then trigger the plugin check at this moment (when the event is propagated)?
About the cron task:
You can add a backend part which will register a cron task but I doubt it's really necessary.About the RSS feed (http://i-mscp.net/filebase/index.php/FilebaseFeed), I can add the last available version info if you want.
For the whole thing: You can also try to provide a pull request and in such a case, we can merge your work in the plugin management interface directly.
-
