Hello I have this error when i go to the manage permissions edit profiles section here and click the Default group
(https://i.gyazo.com/0a3c0f9bf466c9fd760d1667488a9c78.png)
I get this fatal error here.
(https://i.gyazo.com/677c28e214b9521322ce08059ef4fe7b.png)
I run PHP 8.2 when i drop it down to 7.4 the error goes away and i'm able to edit the permission in that profile but put it back and the error comes back.
Running SMF 2.1.4 and i have these mods installed.
(https://i.gyazo.com/302ea1fbaebfc5a32ae68c2e97d4be96.png)
Has anyone encountered this? Whenever i change the PHP version it fixes it so not sure what's causing it. If this was mentioned before I apologize.
Could be any mod that adds permissions ...
Nope, this one is a PHP 8.2 bug.
ManagePermissions.php line 325-329 (and present in both 2.1.4 and 2.1-release)
while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
$context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += $row['num_permissions'];
}
328 is the second to last here, and you're doing an addition on a string; earlier versions of PHP would correctly coerce the numeric string at this point, 8.2 does not.
Replace with:
while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
$context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += (int) $row['num_permissions'];
}
Quote from: Arantor on June 18, 2024, 03:58:23 PMNope, this one is a PHP 8.2 bug.
ManagePermissions.php line 325-329 (and present in both 2.1.4 and 2.1-release)
while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
$context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += $row['num_permissions'];
}
328 is the second to last here, and you're doing an addition on a string; earlier versions of PHP would correctly coerce the numeric string at this point, 8.2 does not.
Replace with:
while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
$context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += (int) $row['num_permissions'];
}
Thanks maybe move it to the bug section.
I tried changing the code you mentioned replace with but still get the error.
The error must be different now. It literally cannot be giving you the error you had before on that line because the error says "string + string" and that code forces it to not be string + string...
Though actually one other route occurs to me how this might happen and that's also in the camp of 'it shouldn't' but I could see a badly written mod causing it.
The way to tell would be to look at the database with the following query:
SELECT * FROM smf_board_permissions
WHERE (id_group = 1) OR (id_group = -1 AND add_deny = 1)
Quote from: Arantor on June 18, 2024, 05:47:42 PMThough actually one other route occurs to me how this might happen and that's also in the camp of 'it shouldn't' but I could see a badly written mod causing it.
The way to tell would be to look at the database with the following query:
SELECT * FROM smf_board_permissions
WHERE (id_group = 1) OR (id_group = -1 AND add_deny = 1)
This is what i see
(https://i.gyazo.com/8e8cc63287289988f1bd0dbd090b7349.png)
Quote from: Arantor on June 18, 2024, 05:34:17 PMThe error must be different now. It literally cannot be giving you the error you had before on that line because the error says "string + string" and that code forces it to not be string + string...
Yes i tried again it's giving sting+int instead of string+string
(https://i.gyazo.com/ca5551d80d37b5641318bc17db1aa6b4.png)
On a brand new test forum on PHP 8.2 everything is ok. My forum originally was upgraded from 2.0.19 to 2.1.4 so it looks like an old mod somewhere in the database is messing with it the problem is i don't know which one as i installed the same mods exactly on the test forum copying from my main one as well and i don't get the error.
Quote from: KittyGalore on June 18, 2024, 06:01:10 PMQuote from: Arantor on June 18, 2024, 05:47:42 PMThough actually one other route occurs to me how this might happen and that's also in the camp of 'it shouldn't' but I could see a badly written mod causing it.
The way to tell would be to look at the database with the following query:
SELECT * FROM smf_board_permissions
WHERE (id_group = 1) OR (id_group = -1 AND add_deny = 1)
This is what i see
(https://i.gyazo.com/8e8cc63287289988f1bd0dbd090b7349.png)
You need to go to the query tab and copy/paste the bit of code I gave you. The structure is fine, but there's possibly some rogue data and that piece of code run in the query tab should identify what it might be.
This was the results I hope i done this right.
(https://i.gyazo.com/46708dc8e99e6f6924358ece0364f6f3.png)
(https://i.gyazo.com/66936ba10869f84a23ada1ad28926349.png)
Ugh, those are some not so well behaved (if well meaning) mods.
So the issue you have is that you have board permissions set up in contexts where board permissions can't ever be accessed by the UI because they don't make sense (e.g. there's no universe in which it's possible to deny permissions to an admin, nor to deny board permissions to guests because of how guest permissions are constructed)
So let's fix that. More queries to run.
First, let's fix admin permissions; there's never a situation where any admin permissions are ever applied; group 1 is special and always automatically has all permissions, so there's no need to set board permissions of any kind.
DELETE FROM smf_board_permissions WHERE id_group = 1;
Second, let's ensure there aren't any guest permissions kicking around that shouldn't be.
DELETE FROM smf_board_permissions WHERE id_group = -1 AND add_deny = 0
Quote from: Arantor on June 19, 2024, 02:13:04 PMUgh, those are some not so well behaved (if well meaning) mods.
So the issue you have is that you have board permissions set up in contexts where board permissions can't ever be accessed by the UI because they don't make sense (e.g. there's no universe in which it's possible to deny permissions to an admin, nor to deny board permissions to guests because of how guest permissions are constructed)
So let's fix that. More queries to run.
First, let's fix admin permissions; there's never a situation where any admin permissions are ever applied; group 1 is special and always automatically has all permissions, so there's no need to set board permissions of any kind.
DELETE FROM smf_board_permissions WHERE id_group = 1;
Second, let's ensure there aren't any guest permissions kicking around that shouldn't be.
DELETE FROM smf_board_permissions WHERE id_group = -1 AND add_deny = 0
So i ran the first code and it told me 11 rows got deleted and the second code told me 0 rows got deleted.
I then went into the section which was giving me the error and it's now fixed. Thank you so much Arantor.
Do i need to do anything else or check if it's all ok.
Running that previous code this is the new result it's gotten much smaller.
(https://i.gyazo.com/c1222fa205f9f981ff9f84b9e00209ae.png)
If you can go into the area that used to have an error, and it now works, it now works and is all good. You had some rows you shouldn't have had, and that was what was causing the problem.
On a broader note for the team's consideration: this isn't the first time rogue permissions have gotten into the system (and it's inevitably admins permissions rather than rogue guest deny permissions, exactly as it was here), perhaps some way to ignore that when building the UI and perhaps even cleaning it out if discovered.
Quote from: Arantor on June 19, 2024, 02:25:00 PMIf you can go into the area that used to have an error, and it now works, it now works and is all good. You had some rows you shouldn't have had, and that was what was causing the problem.
On a broader note for the team's consideration: this isn't the first time rogue permissions have gotten into the system (and it's inevitably admins permissions rather than rogue guest deny permissions, exactly as it was here), perhaps some way to ignore that when building the UI and perhaps even cleaning it out if discovered.
Thank you yes the problem is now fixed.
Quote from: Arantor on June 19, 2024, 02:25:00 PMperhaps some way to ignore that when building the UI and perhaps even cleaning it out if discovered.
That's a good idea.