Title: Resource always locked by self — lock sid never matches evo_session cookie (Evo 3, PHP 8.3)
Body:
On a fresh install of the latest Evolution CMS 3.x, the admin (and only) user cannot save any resource. Saving the user's own resource triggers the "admin is editing this resource" lock alert. "Remove locks" clears it, but it returns immediately on the next save.
Environment:
Evolution CMS: latest 3.x release
PHP 8.3
Shared hosting (HTTPS only)
Single admin user
What I checked:
Server PHP error log is empty (no warnings, no deprecations, no "headers already sent").
server_protocol is https; the evo_session cookie has the Secure flag and is sent correctly.
The evo_session cookie value is stable across page reloads (session persists).
active_user_locks always contains exactly one row: internalKey = 1 (admin), elementType = 7, elementId = 1, recent lasthit.
Root cause (as far as I can tell): The sid stored in active_user_locks does not match the evo_session cookie value, even within the same session.
evo_session cookie value: 40 chars, mixed-case alphanumeric (e.g. XXXXXXXX…)
lock sid: 32 hex chars (e.g. yyyyyyyy…)
The two differ in both format and value. I deleted the lock row, opened the resource for editing, and the newly created lock row again had a 32-hex-char sid unrelated to the cookie value. So the lock is always written with a session id that differs from the actual session cookie, which makes the lock check always treat the current user as "another user."
This looks like a session-id mismatch between the manager session and the value used by the lock mechanism on PHP 8.3. Could you confirm whether this is a known issue / how the lock sid is derived versus session_id() on PHP 8.x?
Title: Resource always locked by self — lock sid never matches evo_session cookie (Evo 3, PHP 8.3)
Body:
On a fresh install of the latest Evolution CMS 3.x, the admin (and only) user cannot save any resource. Saving the user's own resource triggers the "admin is editing this resource" lock alert. "Remove locks" clears it, but it returns immediately on the next save.
Environment:
Evolution CMS: latest 3.x release
PHP 8.3
Shared hosting (HTTPS only)
Single admin user
What I checked:
Server PHP error log is empty (no warnings, no deprecations, no "headers already sent").
server_protocol is https; the evo_session cookie has the Secure flag and is sent correctly.
The evo_session cookie value is stable across page reloads (session persists).
active_user_locks always contains exactly one row: internalKey = 1 (admin), elementType = 7, elementId = 1, recent lasthit.
Root cause (as far as I can tell): The sid stored in active_user_locks does not match the evo_session cookie value, even within the same session.
evo_session cookie value: 40 chars, mixed-case alphanumeric (e.g. XXXXXXXX…)
lock sid: 32 hex chars (e.g. yyyyyyyy…)
The two differ in both format and value. I deleted the lock row, opened the resource for editing, and the newly created lock row again had a 32-hex-char sid unrelated to the cookie value. So the lock is always written with a session id that differs from the actual session cookie, which makes the lock check always treat the current user as "another user."
This looks like a session-id mismatch between the manager session and the value used by the lock mechanism on PHP 8.3. Could you confirm whether this is a known issue / how the lock sid is derived versus session_id() on PHP 8.x?