pwg_unique_exec_begins() read the token back with a SELECT after its
INSERT IGNORE. If the holder released the token in between, the SELECT
returned no row and explode() received null: under parallel requests a
"Deprecated: explode()" message ended up in front of the JSON response
(reported by Eddy Lelièvre-Berna). The number of rows affected by the
INSERT IGNORE now tells whether we got the token.
A stale token is now removed only if it still holds the value we have
seen, and pwg_unique_exec_ends() accepts the execution id: an execution
which exceeded the timeout no longer releases the token of the call which
took it over. Existing callers pass their execution id.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vty6FTwtZ3ezEncagFo2FQ
The optional $condition is added to the WHERE clause with an AND. It lets
pwg_unique_exec_begins/ends delete a token only if it holds the expected
value, without writing their own DELETE query on the config table.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vty6FTwtZ3ezEncagFo2FQ
Persons and their association to photos, with an optional face box.
Admin: People page (merge, bulk actions, cover), People tab on the photo edit page (identify a face), access settings in Permissions.
Gallery: faces on the photo page, person page, People filter in the search.
API: pwg.people.* methods, new events for plugins. Core has no AI: source manual, auto or imported is stored for plugins.
... token_name must not exceed 32 characters (config.param is varchar(40)
and "_running" suffix is added), a longer token_name was silently
truncated in the database and the function always returned false.
-Update cookie to use pwg_lang to avoid conflicts with other potential apps.
-Add cookie path to the pwg_lang cookie to help with conflicts also.
-Be less restrictive in load_cookie_language function
-We can't use pwg_set_cookie because it is set in js not PHP so we force it to be called pwg_lang
Add a more granular container detection
Replace is_in_container by get_container_info
Currently detect Official container (once they update a version with a tagfile) and LinuxServer container
All other container are marked as Unknown
Report two field :
- container_type ( none | Official | LinuxServer | Unknown
- container_version ( build Version number like 16.2.0a, only reported if Official container is detected )
If the user as added open_basedir restriction the function will fail with a Warning :
Warning: file_exists(): open_basedir restriction in effect. File(/proc/2/sched) is not within the allowed path(s)
This fix add a check that assume piwigo is not in a container when open_basedir is set
Updated user activity display to show when a user is connected via API key, including an icon and updated tooltip. Modified backend to set a 'connected_with' flag in activity details when API key authentication is used.
Append info on PHP_OS in the template of `admin/maintenance_env.php` and in `include/functions.inc.php` -> `send_piwigo_infos()`
Detection works by checking if PHP is running on Linux then check if PID2 is kthreadd
Kthreadd is useless in a container so PID2 should not exist of be another process
If unable to read /proc/2/sched for some reason, assume a SELinux restriction and that PHP is not running in a container
`is_in_container()` doesn't differentiate between VMs or bare metal, it only check if PHP is running in a containerized environement via tools like docker or podman
Introduced a new format_date function that uses IntlDateFormatter for proper internationalization when available, falling back to the legacy implementation otherwise. The previous format_date function was renamed to format_date_legacy.
* Front end development according to the mockup
* Save changes in ajax
* Implement the delete album behaviour with Jconfirm in ajax
* Adding a new Css component : infos (factorized in the tag page)
* Add a new general admin template variable : ADMIN_PAGE_OBJECT_ID (adding the id of an object on the page)
* Modify the pwg.categories.setInfo api method to fit the need of the album edition pages
* Slightly change the method time_since, add a parameter to display only the greates time unit
* Popin to change parent album, and changed it as a re-usable component
* Dropdown to replace the checkbox for comments
* migration task to update activity.performed_by (with object_id) for logout action (was always user guest instead of the real user)
* activities: use the actual regrouped lines to list filter users (instead of performing a separate SQL query)
* at the end of the upload of after a maximum duration, move the photos from the lounge to their actual categories.
* do not invalidate user cache when photos are added in the lounge, thus avoiding to rebuild cache on every photo uploaded
* the lounge system activates itself only beyond 50k (by default) photo
In order to change from versions 2.10.x to 11.x.y, Piwigo needs to only consider 11 as the branch, and not 11.x. Or else it will mess up with minor and major updates.
