Thank you for letting us know.
Please follow up on GitHub: https://github.com/XOOPS/XoopsCore25/issues/1588

Hello,
good job!

I always use an old version of Xoops (2.0.16...) on my site aquaportail.com but sometimes, I use the most recent versions of Xoops to hack "my" code for a better compatibilty with recent versions of PHP.

There's a real problem with PHP 8.4 in kernel/common.php with implications in kernel/functions.php. Fonctions to open, read, etc., a session are not compatible with 8.4 for session_set_save_handler with xoops_gethandler. "$sess_handler = xoops_gethandler('session');
session_set_save_handler..."

Just my two pences...

Jef

I just submitted a solution which hopefully will self-correct the issue:

https://github.com/XOOPS/XoopsCore25/pull/1578

Please check it out and let me know if it works.

Actually, instead of specifying the domain like this:


you can use:


And to give you more background, the old, incorrect setting only worked because browsers used to have very relaxed security rules for cookies, which they have since tightened significantly.

Old Behavior (Pre-XOOPS 2.5.11 & Older Browsers)
In the past, when a cookie was set, browsers defaulted to a SameSite=None policy. This meant a cookie could be sent even if its domain (myhoster.com) didn't match the website's domain (mywebsite.com). The browser saw it as a "third-party" cookie but allowed it to work for logins. This was a fragile setup that relied on insecure defaults.

New Behavior (XOOPS 2.5.11+ & Modern Browsers)
To prevent security vulnerabilities like Cross-Site Request Forgery (CSRF), all major browsers (Chrome, Firefox, Edge) now default to SameSite=Lax for cookies.
• SameSite=Lax means the browser will only send a cookie if the domain in the cookie matches the domain of the website you are currently visiting.
• When your user on mywebsite.com tried to log in, XOOPS told the browser to set a cookie for "myhoster.com".
• On the next page load, the browser looked at the cookie for myhoster.com and said, "Nope, you're not on "myhoster.com", you're on mywebsite.com. I'm not sending this cookie."

So again, if you have set the XOOPS_COOKIE_DOMAIN to something that is not your domain, just replace it your domain name, or simply with:

I had a problem with two of my websites. Suddenly, I couldn't log in anymore.
The problem was that XOOPS couldn't set the cookies properly. The cause was an incorrect value in the mainfile.php.
Example:
Web host's domain: https://myhoster.com
My website's domain: https://mywebsite.com
In the mainfile.php, there was

instead of

Since it worked for years, I didn't recognize the problem. I suspect the host made some changes to the settings, causing the issue to suddenly appear.
You may have/get the same problem. If yes, then check your mainfile.php.

Many thanks to Mamba for identifying the issue.

Thank you so much for your support and for all the testing!

Thanks for all your hard work!
I'm still testing, but from what I can see, everything is fine to move on to an RC version.

The XOOPS Development Team is pleased to announce the release of XOOPS 2.5.12-Beta-8

What's Changed

• language fixes by @mambax7 in #1550
• copyright update by @mambax7 in #1551
• fix Admin help toggle by @mambax7 in #1553
• fix for Admin users search by @mambax7 in #1554
• Bootstrap 5.3.7 by @mambax7 in #1557
• Feature/updates by @mambax7 in #1555
• Fix Deprecated addSlashes by @GregMage in #1566
• Fix: #1564 by @GregMage in #1565
• Hide empty userinfo value by @GregMage in #1568
• User Search Issue #1559 by @mambax7 in #1560
• add abstract methods for error(), errorno(), query() to XoopsDatabase by @mambax7 in #1571
• cosmetics by @mambax7 in #1570
• Criteria cleanup by @mambax7 in #1572
• cleanup mailer by @mambax7 in #1574
• update XMF by @mambax7 in #1573


Please help make XOOPS better by testing and reporting any issues!

Well you don't in a version run remove features mid way through; ever, people can adjust that as they go;

I just looked into the theme, but unfortunately, it won't run on the current XOOPS version, as the <{php}> tags have been removed from Smarty.