Piwigo.org

mistic100 · 2014-02-05 16:11:51

Hello everyone,

In 2.5 I added a method request_plugin_update (or similar) which moved in 2.6 into PluginMaintain interface, in addition to PLUGINNAME_VERSION constant.

This mechanism is usefull for manual upgrade of plugins and internal usage on piwigo.com : detect when the plugin version change and apply upgrade task if needed.

Now the problem of my pattern is that the maintain.inc.php file is loaded everytime, and 99.999% times for nothing.

So I though this could be directly handled by Piwigo in load_plugin function : compare database and file version and if needed include maintain.inc and execute a particular method (or function if the plugin does not use PluginMaintain interface).

Problem is Piwigo has no way to know which is the current file plugin version without loading main.inc with file_get_contents and parsing the header, so instead of loading main.inc and maintain.inc once we load main.inc twice (one time with file_get_contents and one with include).

What I would like to do is to remove this concept of plugin metadata in a PHP comment and use a plain array instead ($pluginconf for example), no more comment parsing needed (even in plugins.class.php).

In addition, the same changes can be applied to themes : move metadata to the already existing $themeconf

If this changes is done, every plugin will need an update for Piwigo 2.7 (retrocompatiblity will still be possible by using both comment and $pluginconf)

rvelices · 2014-02-05 17:06:10

what about displaying metadata for inactive plugins/themes

mistic100 · 2014-02-05 17:14:21

in that case the parsing is still needed (parse the array and not the comment)

rvelices · 2014-02-05 17:42:58

Since this is only needed for the version, let's leave the rest as it is (at least in the first step).

However we still have an issue: the core piwigo will know the file version and that an upgrade is required only AFTER executing main.inc.php . Wouldn't be that an issue with some plugins/themes ?

mistic100 · 2014-02-05 17:46:53

rvelices wrote:
Since this is only needed for the version, let's leave the rest as it is (at least in the first step).

why ? why using a two-speed system ? in my sense it's way more easier and comprehensive for developers to update the whole block

rvelices wrote:
However we still have an issue: the core piwigo will know the file version and that an upgrade is required only AFTER executing main.inc.php . Wouldn't be that an issue with some plugins/themes ?

perhaps, but plugins should not do something else than registering triggers, if they do something else there is a problem of conception (or a missing trigger)

flop25 · 2014-02-05 20:33:08

mistic100 wrote:
rvelices wrote:
However we still have an issue: the core piwigo will know the file version and that an upgrade is required only AFTER executing main.inc.php . Wouldn't be that an issue with some plugins/themes ?
perhaps, but plugins should not do something else than registering triggers, if they do something else there is a problem of conception (or a missing trigger)

seems a bit naive

mistic100 · 2014-02-05 20:37:49

look I try to find a way to have a fully automated process with minimal performance impact
it obviously need strict rules to not ends up in unexpected behavior
and you can propose changes...

flop25 · 2014-02-05 20:58:36

I do understand. Your class is great but if it becomes mandatory etc we will loose the simplicity of plugins and not skilled enough people
You know I'm not skilled like you guys
could we build a form were people upload the zip to do a manual udpate, instead of unzipping themself?

mistic100 · 2014-02-05 21:22:44

I never said the class would be mandatory

mistic100 wrote:
include maintain.inc and execute a particular method (or function if the plugin does not use PluginMaintain interface).

Piwigo 2.6 is compatible with both version, there is no reason it changes

mistic100 · 2014-02-24 15:35:49

Both of you are obviously right :)

Including main.inc.php before performing an upgrade can produce severe issues
so I though about reading the file by 100 bytes blocks with fopen until we reach the end of the first comment block, it's certainly faster than loading the whole file.

Thus I abandon the idea of $pluginconf array.

--

And about maintain.inc.php : I forgot the case of multiple upgrades in the same process (function names conflict) and that's exactly why I created the PluginMaintain interface.
The problem is that we can't know if the file uses the procedural or OOP structure before loading it.

So my plan is to introduce a new file named maintain.class.php, if (and only if) this file exists, my "auto update" patern is used (in load_plugin() certainly) otherwise nothing changed.

(this induces changes in plugins.class.php to load maintain.class.php if present, or maintain.inc.php if present).

developpers could use OOP in maintain.class.php OR procedural in maintain.inc.php (or OOP also for compaitibility with Piwigo 2.6, but not advised).

Piwigo.org

Announcement

#1 2014-02-05 16:11:51

[resolved] Plugins: structure, loading and update

#2 2014-02-05 17:06:10

Re: [resolved] Plugins: structure, loading and update

#3 2014-02-05 17:14:21

Re: [resolved] Plugins: structure, loading and update

#4 2014-02-05 17:42:58

Re: [resolved] Plugins: structure, loading and update

#5 2014-02-05 17:46:53

Re: [resolved] Plugins: structure, loading and update

rvelices wrote:

rvelices wrote:

#6 2014-02-05 20:33:08

Re: [resolved] Plugins: structure, loading and update

mistic100 wrote:

rvelices wrote:

#7 2014-02-05 20:37:49

Re: [resolved] Plugins: structure, loading and update

#8 2014-02-05 20:58:36

Re: [resolved] Plugins: structure, loading and update

#9 2014-02-05 21:22:44

Re: [resolved] Plugins: structure, loading and update

mistic100 wrote:

#10 2014-02-24 15:35:49

Re: [resolved] Plugins: structure, loading and update

Board footer