adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-11-03 07:22:22 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

The 13.x_to_13.3.0 upgrade archive lacks the include/functions_comment.inc.php file. #1590

New Issue
Closed
opened 2026-10-05 00:49:18 +02:00 by adam · 4 comments
adam commented 2026-10-05 00:49:18 +02:00
Owner
Copy link
Copy source

include/functions_comment.inc.php was last changed on 2022-11-22 (commit 117c7c7530) on the 13.x branch but is not included in the 13.x_to_13.3.0.zip upgrade archive (as downloaded per https://piwigo.org/download/dlcounter.php?code=13xto1330). The recently updated check_files_integrity plugin rightly complains in an upgraded installation.

This might actually be responsible for some weird "apostrophes in comments work / do not work / are not escaped /are escaped" reports in the forum.

Question remains, what else is missing..

`include/functions_comment.inc.php` was last changed on 2022-11-22 (commit 117c7c7530c0072ac1782f6b374d5107f81f18da) on the 13.x branch but is not included in the 13.x_to_13.3.0.zip upgrade archive (as downloaded per https://piwigo.org/download/dlcounter.php?code=13xto1330). The recently updated `check_files_integrity` plugin rightly complains in an upgraded installation. This might actually be responsible for some weird "apostrophes in comments work / do not work / are not escaped /are escaped" reports in the forum. Question remains, what else is missing.. <!-- github-sync-id:1483083524 -->
adam closed this issue 2026-10-05 00:49:18 +02:00
adam commented 2026-10-05 00:49:19 +02:00
Author
Owner
Copy link
Copy source

Great investigation, thank you erAck. I understand what the problem is. When I generate the upgrade archive 13.x_to_13.3.0.zip I simply do:

perl create_patch.pl --start=1300 --target=1330 --patch=13.0.0_to_13.3.0

Which compares 13.0.0 directly to 13.3.0. Which is a problem here because functions_comment.inc.php has been modified in version 13.1.0 but the change has been reverted on version 13.3.0.

So, instead of making a direct comparison between 13.0.0 and 13.3.0, I should "cumulate" changes on each version, like this:

perl create_patch.pl --start=1300 --target=1310 --patch=13.0.0_to_13.1.0
perl create_patch.pl --start=1310 --target=1320 --patch=13.1.0_to_13.2.0
perl create_patch.pl --start=1320 --target=1330 --patch=13.2.0_to_13.3.0

cp -r 13.0.0_to_13.1.0 13.0.0_to_13.3.0-cumulative
cp -r 13.1.0_to_13.2.0/* 13.0.0_to_13.3.0-cumulative/
cp -r 13.2.0_to_13.3.0/* 13.0.0_to_13.3.0-cumulative/

Question remains, what else is missing..

Let's compare with the previously generated patch:

perl create_patch.pl --start=1300 --target=1330 --patch=13.0.0_to_13.3.0-direct

perl create_patch.pl --start=13.0.0_to_13.3.0-direct --target=13.0.0_to_13.3.0-cumulative --dry-run
N include/functions_comment.inc.php
N plugins/AdminTools/include/events.inc.php

So to answer precisely to your question : plugins/AdminTools/include/events.inc.php

So what to do now?

  1. change the procedure to generate the upgrade archive (done)
  2. update the current upgrade archive 13.x_to_13.3.0.zip (done)
Great investigation, thank you erAck. I understand what the problem is. When I generate the upgrade archive `13.x_to_13.3.0.zip` I simply do: ``` perl create_patch.pl --start=1300 --target=1330 --patch=13.0.0_to_13.3.0 ``` Which compares 13.0.0 directly to 13.3.0. Which is a problem here because `functions_comment.inc.php` has been modified in version 13.1.0 but the change has been reverted on version 13.3.0. So, instead of making a direct comparison between 13.0.0 and 13.3.0, I should "cumulate" changes on each version, like this: ``` perl create_patch.pl --start=1300 --target=1310 --patch=13.0.0_to_13.1.0 perl create_patch.pl --start=1310 --target=1320 --patch=13.1.0_to_13.2.0 perl create_patch.pl --start=1320 --target=1330 --patch=13.2.0_to_13.3.0 cp -r 13.0.0_to_13.1.0 13.0.0_to_13.3.0-cumulative cp -r 13.1.0_to_13.2.0/* 13.0.0_to_13.3.0-cumulative/ cp -r 13.2.0_to_13.3.0/* 13.0.0_to_13.3.0-cumulative/ ``` > Question remains, what else is missing.. Let's compare with the previously generated patch: ``` perl create_patch.pl --start=1300 --target=1330 --patch=13.0.0_to_13.3.0-direct perl create_patch.pl --start=13.0.0_to_13.3.0-direct --target=13.0.0_to_13.3.0-cumulative --dry-run N include/functions_comment.inc.php N plugins/AdminTools/include/events.inc.php ``` So to answer precisely to your question : `plugins/AdminTools/include/events.inc.php` So what to do now? 1. change the procedure to generate the upgrade archive (done) 2. update the current upgrade archive `13.x_to_13.3.0.zip` (done) <!-- github-comment-id:1342421996 -->
adam commented 2026-10-05 00:49:20 +02:00
Author
Owner
Copy link
Copy source

I don't know what your create_patch.pl does, it's not in the git repository, but this generates a list of all changed files between 13.0.0 and 13.3.0 (in sequence) tags on the same branch:

(for y in {1..3}; do git diff --name-only 13.$((${y}-1)).0..13.${y}.0 ; done) | sort -u

So you could use it as

mkdir 13.0.0_to_13.3.0-cumulative
cp -r --parents $((for y in {1..3}; do git diff --name-only 13.$((${y}-1)).0..13.${y}.0 ; done) | sort -u) 13.0.0_to_13.3.0-cumulative/

Note that if files were removed the list would include also those, which would make cp output a warning message, though without harm.

So to answer precisely to your question : plugins/AdminTools/include/events.inc.php

That's odd, the installed file for me is identical to the one in the repository of Nov-17.

I don't know what your create_patch.pl does, it's not in the git repository, but this generates a list of all changed files between 13.0.0 and 13.3.0 (in sequence) tags _on the same branch_: ``` (for y in {1..3}; do git diff --name-only 13.$((${y}-1)).0..13.${y}.0 ; done) | sort -u ``` So you could use it as ``` mkdir 13.0.0_to_13.3.0-cumulative cp -r --parents $((for y in {1..3}; do git diff --name-only 13.$((${y}-1)).0..13.${y}.0 ; done) | sort -u) 13.0.0_to_13.3.0-cumulative/ ``` Note that if files were removed the list would include also those, which would make `cp` output a warning message, though without harm. > So to answer precisely to your question : plugins/AdminTools/include/events.inc.php That's odd, the installed file for me is identical to the one in the repository of Nov-17. <!-- github-comment-id:1343804066 -->
adam commented 2026-10-05 00:49:21 +02:00
Author
Owner
Copy link
Copy source

The git sub-commands are very interesting. Thank you.

We can't really use them in this case, because some operations to build a release are performed outside Git (such as adding default plugins or changing version number in language files)

That's odd, the installed file for me is identical to the one in the repository of Nov-17.

Maybe you simply updated the plugin.

By the way, it's a real question from me: should we take default plugins/themes into account for creating the patch. We could perfectly remove them and let the "extensions updater" do its job. For now I've kept it as it was for years but it could evolve.

The git sub-commands are very interesting. Thank you. We can't really use them in this case, because some operations to build a release are performed outside Git (such as adding default plugins or changing version number in language files) > That's odd, the installed file for me is identical to the one in the repository of Nov-17. Maybe you simply updated the plugin. By the way, it's a real question from me: should we take default plugins/themes into account for creating the patch. We could perfectly remove them and let the "extensions updater" do its job. For now I've kept it as it was for years but it could evolve. <!-- github-comment-id:1348735897 -->
adam commented 2026-10-05 00:49:22 +02:00
Author
Owner
Copy link
Copy source

I'm quite unbiased.. it might be better to have them in the patch just in case there would be some inter-dependency between changes of core and default plugins/themes. On the other hand, having separate updates may more clearly point out what exactly will get updated and gives one a chance to chase after details. Best would be both worlds, including them in the patch only if there is an inter-dependency, but that's probably not automatically to track so easily forgotten.

I'm quite unbiased.. it might be better to have them in the patch just in case there would be some inter-dependency between changes of core and default plugins/themes. On the other hand, having separate updates may more clearly point out what exactly will get updated and gives one a chance to chase after details. Best would be both worlds, including them in the patch only if there is an inter-dependency, but that's probably not automatically to track so easily forgotten. <!-- github-comment-id:1351816509 -->
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#1590