adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

Wiki: document GitLab (and the archive fields) in "Use a source code manager for your extension" #2223

New Issue
Open
opened 2026-10-05 01:10:17 +02:00 by adam · 3 comments
adam commented 2026-10-05 01:10:17 +02:00
Owner
Copy link
Copy source

The wiki page Use a source code manager for your extension only documents GitHub and piwigo.org SVN, even though the intro says the managers are compatible with any Git host. In practice PEM clones any Git URL, so GitLab works — but the page actively steers people wrong for it:

"Select Git or SVN and change the URL, don't change the other fields."

For a generic Git host that isn't GitHub, the other fields (Archive root directory and Archive name) are exactly what has to be right, because they depend on the host's tag/archive naming. Leaving them at defaults produces a marketplace that silently fails with "Archive cannot be downloaded" on "Add a new revision", with no hint as to why. Wikis don't take PRs, so I'm proposing the replacement text below for a maintainer to paste.

Proposed change to the "Configure your Git or SVN repository" section

Replace the GitHub-only example list and the "don't change the other fields" line with:

Select Git or SVN and set the URL to the root URL of your repository:

  • example on GitHub: https://github.com/Piwigo/ContactForm
  • example on GitLab: https://gitlab.com/yourname/ContactForm
  • example on Piwigo.org SVN: http://piwigo.org/svn/extensions/ContactForm

For GitHub and Piwigo.org SVN you can leave the remaining fields at their defaults. For GitLab (or another generic Git host), check the two archive fields, because GitLab names its tag archives differently:

  • Archive root directory — the destination folder name PEM should use, i.e. your plugin's ID (e.g. ContactForm). This field accepts letters, digits and underscores only. PEM strips the wrapper folder GitLab puts inside the downloaded archive (e.g. ContactForm-v1.0/) and uses this value instead. It must match your plugin's install-folder ID.
  • Archive name — the filename pattern of the archive to download, with % standing in for the version number. If your tags are prefixed with v (e.g. v1.0), this must be ContactForm-v%.zip so the v lines up with the tag.

Validate. You should see the correct GitHub / GitLab / SVN information in the bottom block; if not, double check the form — especially the two fields above.

Optional note for the "Release a new revision" section

PEM reads the version from the plugin header at the tag you point it to, so tag your release first (e.g. v1.0) and make sure the version in main.inc.php matches. On GitLab, the project and any parent group must be public, otherwise PEM's anonymous clone of the archive fails with an authentication error.

The wiki page [Use a source code manager for your extension](https://github.com/Piwigo/Piwigo/wiki/Use-a-source-code-manager-for-your-extension) only documents **GitHub** and **piwigo.org SVN**, even though the intro says the managers are compatible with any Git host. In practice PEM clones any Git URL, so **GitLab works** — but the page actively steers people wrong for it: > "Select Git or SVN and change the URL, **don't change the other fields**." For a generic Git host that isn't GitHub, the *other fields* (**Archive root directory** and **Archive name**) are exactly what has to be right, because they depend on the host's tag/archive naming. Leaving them at defaults produces a marketplace that silently fails with **"Archive cannot be downloaded"** on "Add a new revision", with no hint as to why. Wikis don't take PRs, so I'm proposing the replacement text below for a maintainer to paste. ### Proposed change to the "Configure your Git or SVN repository" section Replace the GitHub-only example list and the "don't change the other fields" line with: > Select Git or SVN and set the **URL** to the root URL of your repository: > > - example on GitHub: `https://github.com/Piwigo/ContactForm` > - example on GitLab: `https://gitlab.com/yourname/ContactForm` > - example on Piwigo.org SVN: `http://piwigo.org/svn/extensions/ContactForm` > > For **GitHub** and **Piwigo.org SVN** you can leave the remaining fields at their defaults. For **GitLab** (or another generic Git host), check the two archive fields, because GitLab names its tag archives differently: > > - **Archive root directory** — the destination folder name PEM should use, i.e. your plugin's ID (e.g. `ContactForm`). This field accepts letters, digits and underscores only. PEM strips the wrapper folder GitLab puts inside the downloaded archive (e.g. `ContactForm-v1.0/`) and uses this value instead. It **must** match your plugin's install-folder ID. > - **Archive name** — the filename pattern of the archive to download, with `%` standing in for the version number. If your tags are prefixed with `v` (e.g. `v1.0`), this must be `ContactForm-v%.zip` so the `v` lines up with the tag. > > Validate. You should see the correct GitHub / GitLab / SVN information in the bottom block; if not, double check the form — especially the two fields above. ### Optional note for the "Release a new revision" section > PEM reads the version from the plugin header at the tag you point it to, so tag your release first (e.g. `v1.0`) and make sure the version in `main.inc.php` matches. On GitLab, the project and any parent group must be **public**, otherwise PEM's anonymous clone of the archive fails with an authentication error. <!-- github-sync-id:4772654220 -->
adam commented 2026-10-05 01:10:18 +02:00
Author
Owner
Copy link
Copy source

I guess instructions would be similar for Codeberg.org as well.

I guess instructions would be similar for Codeberg.org as well. <!-- github-comment-id:4839090874 -->
adam commented 2026-10-05 01:10:19 +02:00
Author
Owner
Copy link
Copy source

I perfectly agree PEM (Piwigo Extension Manager you can found at piwigo.org/ext) should work with Gitlab (or Forgejo like codeberg.org) as good as we do with Github : automatic link, new revision release, language detection.

@GravisTechGregB I don't understand:

PEM reads the version from the plugin header at the tag you point it to, so tag your release first (e.g. v1.0) and make sure the version in main.inc.php matches.

When I release a new revision, where do I use a tag?

I perfectly agree PEM (Piwigo Extension Manager you can found at piwigo.org/ext) should work with Gitlab (or Forgejo like codeberg.org) as good as we do with Github : automatic link, new revision release, language detection. @GravisTechGregB I don't understand: > PEM reads the version from the plugin header at the tag you point it to, so tag your release first (e.g. v1.0) and make sure the version in main.inc.php matches. When I release a new revision, where do I use a tag? <!-- github-comment-id:4886127447 -->
adam commented 2026-10-05 01:10:19 +02:00
Author
Owner
Copy link
Copy source

I just made the test and this is what I get:

Image

... and it looks perfectly fine for me. There is no need to "line up" with the tag names with v% instead of % of it is just for esthetic reasons?

I just made the test and this is what I get: <img width="829" height="460" alt="Image" src="https://github.com/user-attachments/assets/406ef5fd-05e8-4a70-b552-96c413d39c1e" /> ... and it looks perfectly fine for me. There is no need to "line up" with the tag names with `v%` instead of `%` of it is just for esthetic reasons? <!-- github-comment-id:5017027486 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#2223