Announcement

  •  » Engine
  •  » Plugins: externalize metadata

#1 2014-11-24 19:30:33

mistic100
Former Piwigo Team
Lyon (FR)
2008-09-27
3277

Plugins: externalize metadata

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:

Code:

{
  "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

 

#2 2014-11-24 19:53:50

rvelices
Former Piwigo Team
2005-12-29
1960

Re: Plugins: externalize metadata

Do you intend to load this file on every page hit for every plugin ?

Offline

 

#3 2014-11-24 19:56:09

mistic100
Former Piwigo Team
Lyon (FR)
2008-09-27
3277

Re: Plugins: externalize metadata

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

 

#4 2014-11-24 20:29:52

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13809

Re: Plugins: externalize metadata

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

 

#5 2014-11-24 20:46:29

mistic100
Former Piwigo Team
Lyon (FR)
2008-09-27
3277

Re: Plugins: externalize metadata

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:

Code:

<?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

 

#6 2014-11-25 08:54:46

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13809

Re: Plugins: externalize metadata

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

 

#7 2014-12-15 18:54:56

mistic100
Former Piwigo Team
Lyon (FR)
2008-09-27
3277

Re: Plugins: externalize metadata

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

 

#8 2014-12-16 09:16:59

rvelices
Former Piwigo Team
2005-12-29
1960

Re: Plugins: externalize metadata

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

 

#9 2014-12-16 12:03:04

mistic100
Former Piwigo Team
Lyon (FR)
2008-09-27
3277

Re: Plugins: externalize metadata

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

 

#10 2014-12-19 16:33:38

mistic100
Former Piwigo Team
Lyon (FR)
2008-09-27
3277

Re: Plugins: externalize metadata

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

 
  •  » Engine
  •  » Plugins: externalize metadata

Board footer

Powered by FluxBB

github twitter newsletter Donate Piwigo.org © 2002-2024 · Contact