Hello team (and others)
For 2.7 I added the maintain.class.php file in replacement to maintain.inc.php
see [Forum, topic 23328] Plugins: structure, loading and update
don't know if people other than plg and I use it, but I'm very happy with it :-)
-------------
Now I would like to improve the metadata associated with a plugin, with three two and half new features:
1. dependencies
declare which plugins are required with their version (following http://semver.org specification)
people used to NPM, Bower and Composer should know that syntax
if a dependency is not fulfilled the plugin won't activate
2. internal name (identifier)
with the maintain.class.php file comes a new requirement (whereas it existed before in some cases) : the plugin directory name MUST be correct and be what the developer choosed
It is know a bigger problem since we opened PEM to Github (I prefixed all my repositories name by "Piwigo-" for example). If someone download the plugin from github and simply drop it in "plugins", it won't work
I propose to add an "identifier" metadata (for example "gvideo" for Embedded Videos), if the directory name mismatch, Piwigo tries to rename it before install, it the rename fails it displays an error
3. compatible version
what about declaring compatible version in the metadata ? (automatically filled by PEM)
interest: check available for "offline" galleries (no access to piwigo.org)
-------------
I also would like to move all the metadata from main.inc.php to a new extension.json file, like this:
{ "name": "Embedded Videos", "id": "gvideo", "version": "2.7.0", "description": "Add videos from Dailymotion, Youtube, Vimeo, Wideo and Wat.", "license": "MIT", "authors": [{ "name": "Mistic", "url": "http://www.strangeplanet.fr" }], "homepage": "https://github.com/mistic100/Piwigo-Embedded-Videos", "pemUrl": "http://piwigo.org/ext/extension_view.php?eid=136", "dependencies": { "piwigo": ">=2.7.x", "GrumPluginsClasses": ">=3.5.0" } }
of course: retrocompatibility, etc.
Offline
Do you intend to load this file on every page hit for every plugin ?
Offline
for every loaded plugins yes
it's the same cost as what is done currently (perhaps lower): parse the beginning of main.inc.php (if maintain.class.php exists) and then include main.inc.php
Offline
mistic100 wrote:
for every loaded plugins yes
it's the same cost as what is done currently (perhaps lower): parse the beginning of main.inc.php (if maintain.class.php exists) and then include main.inc.php
And we had already checked that the current method is very fast (less than 1ms for 20 plugins if I remember correctly). But of course a benchmark will make it obvious that performances are still very good!
I confirm that the new maintain class is very nice.
Good idea this plugin metadata dedicated file (if performances are at least as good, and I have no doubt about that).
So if I understand correctly Piwigo will check if extension.json exists and if yes no need to parse main.inc.php
A problem might exist: if extension.json is not a php file, it may be served "as is" by the web server. It can be a problem if you don't want to give any information.
Offline
do you imagine someone scrapping "plugins/*/extension.json" to know which plugins are activated and then use know exploits ?
it could be extension.php with:
<?php return array( "name" => "Embedded Videos", "id" => "gvideo", "version" => "2.7.0", "description": "Add videos from Dailymotion, Youtube, Vimeo, Wideo and Wat.", "license" => "MIT", "authors" => array(array( "name" => "Mistic", "url" => "http://www.strangeplanet.fr" )), "homepage" => "https://github.com/mistic100/Piwigo-Embedded-Videos", "pemUrl" => "http://piwigo.org/ext/extension_view.php?eid=136", "dependencies" => array( "GrumPluginsClasses" => ">=3.5.0" ) );
but JSON is more a standard for thins kind of stuff
in a distant future we could even imagine Piwigo and plugins using Composer as dependency manager (composer.json is almost the same as nodejs package.json)
Offline
mistic100 wrote:
do you imagine someone scrapping "plugins/*/extension.json" to know which plugins are activated and then use know exploits ?
Well... you're right, the probability is very low and even if someone do that, it would not be a "security failure".
mistic100 wrote:
in a distant future we could even imagine Piwigo and plugins using Composer as dependency manager (composer.json is almost the same as nodejs package.json)
I have no idea about "Composer" for now, we will see that in the "future" :-)
Offline
rvelices, is this JSON file a concern for you in term of performances ?
knowing that after some benchmark it's at least as fast as the current parsing of the head of main.inc.php, but perhaps you don't like it either :-)
--
any thoughs about the other features ?
Offline
mistic100 wrote:
rvelices, is this JSON file a concern for you in term of performances ?
knowing that after some benchmark it's at least as fast as the current parsing of the head of main.inc.php, but perhaps you don't like it either :-)
Hello,
Yes. It's performance and I don't like the main.inc.php parsing... But I'm not against it either ... (I commented out the parsing on my site).
Even if it's less elegant, I would have prefered each relevant (relevant means probably a half) plugin to call a method from main.inc.php with $plugin['version'] and a string containing current version that would do all the work.
BTW. Now in the trunk, the version is never updated in the db on deactivate/activate for plugins without maintain.class; (so your changes were not really backward compatible)
Offline
rvelices wrote:
Even if it's less elegant, I would have prefered each relevant (relevant means probably a half) plugin to call a method from main.inc.php with $plugin['version'] and a string containing current version that would do all the work.
I remember we already discussed that and the problem in the rest of the code in main.inc.php which expect to be executed with the new config
rvelices wrote:
BTW. Now in the trunk, the version is never updated in the db on deactivate/activate for plugins without maintain.class; (so your changes were not really backward compatible)
that's a mistake and it should be the case
Offline
the version is effectively not updated anymore in "activate" action
but it is update in autoupdate_plugin() wether the plugin uses maintain.class.php or not (of course not for you if you deactivated the function)
Offline