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

invalid user_cache_categories.count_categories hides valid albums #347

New Issue
Closed
opened 2026-10-04 23:53:25 +02:00 by adam · 0 comments
adam commented 2026-10-04 23:53:25 +02:00
Owner
Copy link
Copy source

The computation of user_cache_categories.count_categories sometimes lead to inconsistent result and hides albums while it should be displayed.

Let's take an example, where all albums are public, but some have no photo (because photos are private or just because there is no photo yet). Remember that empty albums must stay hidden.

cc = count_categories
ci = count_images

2015             (cc=7, ci=15)
  September      (cc=6, ci=15)
    Parties      (cc=4, ci=0)
      Party1     (cc=0, ci=0)
      Party2     (cc=0, ci=0)
      Party3     (cc=0, ci=0)
      Party4     (cc=0, ci=0)
    Anniversary  (cc=0, ci=15)

Here we have to remove "Parties" because it is an empty album. The function getuserdata will detect this emptiness and call remove_computed_category to do the job. remove_computed_category will decrement cc on all parents ("2015" and "September") and then will remove album "Parties" from the category list.

Album "Party1" will also go into remove_computed_category (because ci=0) and be removed from category list, but it won't decrement count_categories on parent albums because album "Party" will have been removed from category list before.

This algorithm strongly relies on the order of category list. It is currently sorted by category id. It implicitely requires that child id is always bigger than parent id (kid created after its parent).

Now imagine you create album "Party1" and later you decide to reorganize your albums and create 2015/September/Parties. Album "Parties" will have a bigger id (auto increment in table piwigo_categories) and it breaks our requirement for correct computation of user_cache_categories.

On my test, I have even seen count_categories to -22 ! We don't see it in the database because user_cache_categories.count_categories is unsigned and MySQL changes -22 to 0 (which led me on a wrong way at first...)

The computation of user_cache_categories.count_categories sometimes lead to inconsistent result and hides albums while it should be displayed. Let's take an example, where all albums are public, but some have no photo (because photos are private or just because there is no photo yet). Remember that empty albums must stay hidden. cc = count_categories ci = count_images ``` 2015 (cc=7, ci=15) September (cc=6, ci=15) Parties (cc=4, ci=0) Party1 (cc=0, ci=0) Party2 (cc=0, ci=0) Party3 (cc=0, ci=0) Party4 (cc=0, ci=0) Anniversary (cc=0, ci=15) ``` Here we have to remove "Parties" because it is an empty album. The function getuserdata will detect this emptiness and call remove_computed_category to do the job. remove_computed_category will decrement cc on all parents ("2015" and "September") and then will remove album "Parties" from the category list. Album "Party1" will also go into remove_computed_category (because ci=0) and be removed from category list, but it won't decrement count_categories on parent albums because album "Party" will have been removed from category list before. This algorithm strongly relies on the order of category list. It is currently sorted by category id. It implicitely requires that child id is always bigger than parent id (kid created after its parent). Now imagine you create album "Party1" and later you decide to reorganize your albums and create 2015/September/Parties. Album "Parties" will have a bigger id (auto increment in table piwigo_categories) and it breaks our requirement for correct computation of user_cache_categories. On my test, I have even seen count_categories to -22 ! We don't see it in the database because user_cache_categories.count_categories is unsigned and MySQL changes -22 to 0 (which led me on a wrong way at first...) <!-- github-sync-id:104977009 -->
adam closed this issue 2026-10-04 23:53:25 +02:00
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#347