Plugins management #343

New Issue

2026-10-04T23:53:17+02:00

adam commented

2026-10-04 23:53:17 +02:00

Original discution: http://piwigo.org/forum/viewtopic.php?id=24861

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)

4. extension.json
Remove plugins metadata from main.inc.php and put them in a separated json file

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

Original discution: http://piwigo.org/forum/viewtopic.php?id=24861 **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) **4. extension.json** Remove plugins metadata from main.inc.php and put them in a separated json file ``` js { "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" } } ```

adam commented

2026-10-04 23:53:18 +02:00

2 is very important since more and more plugins are on Github with a repository name different from the historical name

**2** is very important since more and more plugins are on Github with a repository name different from the historical name

adam commented

2026-10-04 23:53:19 +02:00

I remember this topic has already been (partly) discussed on http://piwigo.org/forum/viewtopic.php?id=24861 : I think I agree with all of these improvements. Plugins is one clear strength of Piwigo and we have to make it as good as possible :-) but keep it simple for newcomers.

Piwigo tries to rename it before install

So if the directory is "foobar" or "whatever", if the extension.json:id is "pluginABC" then Piwigo will try to rename to "pluginABC" when you click on "install". Renaming might be dangerous if the user has opened some plugin files (for edition), but I don't think it will be a real problem.

declare which plugins are required with their version

It makes things cleaner of course. It also means that when a new Piwigo version is out, we will have to edit the plugin and publish a new version. Let's imagine 2 cases, where we have set :"piwigo": ">=2.7.x" in the plugin:

the plugin is still compatible with 2.8.0, perfect, nothing to change
the plugin is not compatible with 2.8.0, we have to edit the plugin and publish a new version. As long as the plugin owner does not edit his plugin, we have a problem because users will think the plugin is compatible while it's not and may generate blocking errors in Piwigo.

=> for me, it's nice to have the dependency to Piwigo version in extension.json, but I like the current way we do when someone checks (the owner or a Piwigo team member) the compatibility and set it on PEM before Piwigo says it's compatible or not.

I remember this topic has already been (partly) discussed on http://piwigo.org/forum/viewtopic.php?id=24861 : I think I agree with all of these improvements. Plugins is one clear strength of Piwigo and we have to make it as good as possible :-) but keep it simple for newcomers. > Piwigo tries to rename it before install So if the directory is "foobar" or "whatever", if the extension.json:id is "pluginABC" then Piwigo will try to rename to "pluginABC" when you click on "install". Renaming might be dangerous if the user has opened some plugin files (for edition), but I don't think it will be a real problem. > declare which plugins are required with their version It makes things cleaner of course. It also means that when a new Piwigo version is out, we will have to edit the plugin and publish a new version. Let's imagine 2 cases, where we have set :"piwigo": ">=2.7.x" in the plugin: 1) the plugin is still compatible with 2.8.0, perfect, nothing to change 2) the plugin is not compatible with 2.8.0, we have to edit the plugin and publish a new version. As long as the plugin owner does not edit his plugin, we have a problem because users will think the plugin is compatible while it's not and may generate blocking errors in Piwigo. => for me, it's nice to have the dependency to Piwigo version in extension.json, but I like the current way we do when someone checks (the owner or a Piwigo team member) the compatibility and set it on PEM before Piwigo says it's compatible or not.

adam commented

2026-10-04 23:53:20 +02:00

Actually renaming the folder depending on the "id" is perhaps not the right solution. It might confuse everyone.

If I am correct the only problem with the folder name is the name guessing of the Maintain class (Maintain_PLUGINNAME). So it would also solve the problem to use the id to guess the class name. Or even better: add an entry in the json file to specify the name of the class.

Actually renaming the folder depending on the "id" is perhaps not the right solution. It might confuse everyone. If I am correct the only problem with the folder name is the name guessing of the Maintain class (**Maintain_PLUGINNAME**). So it would also solve the problem to use the id to guess the class name. Or even better: add an entry in the json file to specify the name of the class.

adam referenced this issue

2026-10-05 00:29:52 +02:00

[quick search] include sub-albums photos in search results #1056

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#343