I am going to revert to before the update and do some testing on a test site and do what you have suggested. Once I get the process down ill update the main site and do the same
@R_J Is this clean database structure for the 2021.012 update or is this a clean database for 3.3?
Also one other note that I think shoudl be added to the update procedure is to turn on Debug mode when doing the update.. My system completely errored out without me recognizing it! Even if you capture it and display any errors after the update.
Sorry that I can't help with that. The only thing I can advice is to update to PHP 7.4 and to avoid Lighttp, since that has helped already with this problem
Thanks for responses, much appreciated. Ugh, after going round and round with my hosting company I have determined that they moved me to a Litespeed server when I requested access to the required version of MySql for the upgrade.
LiteSpeed V7.9 Cloudlinux 1.3
It's soooo close to working. Has anyone been able to make lightspeed work?
I found some fix for at least @pinchies Anybody else could try if this is improving your problems, too.
But I feel super uncomfortable with it, because the underlying problem is that the database that I had taken a look at is returning string values instead of integers. That needs to be fixed, but what you see below is just fixing the result in this case. Since I assume that the wrong data type is a general problem, other malfunctions may occur. You should really try to solve this on the server layer!
But to get you going again, please try the following: edit the following file: /applications/dashboard/models/class.permissionmodel.php
Search for the function permissionsByRoleDb and add this lines before the line return $permissions;:
array_walk_recursive($permissions, function (&$item, $key) {
if (is_numeric($item)) {
$item = intval($item);
}
});
It should look like that afterwards:
Since user permissions are cached in the user table, you need to run /utility/structure to clear the wrong permissions from the database.
But again: please check the PHP version, the MySql version and the MySql driver version. Some web servers come with their own PHP "module" which might cause issues, too.
If somebody knows how to debug that database behaviour, please give hints. I would love to be able to fix that misbehaviour by simply adding some connection options to the config.
OK, we're making progress and it's very close to working.
Member can now post. After making a comment they are not able to click back on the category link but I found a workaround.
They get the following error message:
Permission Problem
You don't have permission to do that.
From the navigation menu they can select discussions and categories. They can select the listed the discussions but if they click categories they get the permission problem error if they click anything listed.
I've gone into the category properties and selected "custom properties" and as a workaround.
Thanks for the offer, but I do not see any motivation to do anything further. From my understanding it could be solved with the correct PHP and MySQL version. I just wanted to give those people a chance who cannot change immediately, but as I stated above: it's only a dirty workaround and I wouldn't recommend it at all. The root cause could be fixed, so why not do that?
I'm just a little bit curious how a simple "SELECT SomeInteger FROM AnyTable" could return a string.
So I just ran my update again from 3.3 to 2021.012 and after I ran the /utility/update and get the success smile, I know this happened last time and I looked at my PHP logs and I am getting this error below. Is there anything you would like me to test why I am getting this error first?
[08-Aug-2021 19:06:26 UTC] PHP Warning: Error running structure: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(255) not null,
-- [Existing: `UrlCode` mediumtext null, New: `UrlCode` mediumte' at line 25 in /home/site/www/dev.site.com/applications/dashboard/models/class.updatemodel.php on line 722
Okay so I have replicated the same issues as last time, I did have some bad table structures in my database because of my import and once I altered my database to conform to the proper structure Vanilla is looking for, I was able to get the Database Structure Utility to run and it properly updated my database. Now I am running into the same issues as others which is what @R_J fixed above. I was able to implement his fix to allow my a user to see the forum and post to the forum.
So why is my server then returning string data when it is stored as tinyint(4)
@R_J Any ideas what to look for here? You saw my phpinfo() before? I have this now running on my dev site and the fix has to be applied to test to see if that's the same issue for me and it seems like it is.
EDIT: Also to confirm @R_J findings I did a var_dump($permissions) before and after his code and the entire array beside a few nulls were all string values and after his code they are all int values
I appreciate the workaround and the help but it seems like a bigger problem for me. I'm running the correct version of PHP and MySQL. I specifically upgraded my hosting account to accommodate the requirements.
A blank db and clean install works as expected. It's only when I switch to my production db that the category and permission problems occur. I've been running Vanilla for a 5+ years and haven't had problems upgrading versions before. It seems to me that there's something not being done in the DB upgrade between 3.3 and 2021.
I'm in limbo. I don't like running old versions (3.X) but I don't have confidence that my 2021 version is stable right now.
@aawolverine I might do what you did and do a fresh install of 2012.012 and check to see if the permissions returned are in string value or are in int value, because that would them eliminate the database server and point it back to a code issue. I also want to compare the two databases to see if I can pinpoint the issue
Do you by chance have a .sql copy of your blank database?
@R_J I just did a fresh install of 2021.012 and did a var_dump($permissions); on line 888 of /applications/dashboard/models/class.permissionmodel.php and the $permissions array key values are in string format. I did testing and demo users were able to log in and see the categories. So even though this fixes the issue we are having it's not the root cause. This now begs the question why does this solve the permission issue?
Comments
I am going to revert to before the update and do some testing on a test site and do what you have suggested. Once I get the process down ill update the main site and do the same
@R_J Is this clean database structure for the 2021.012 update or is this a clean database for 3.3?
Also one other note that I think shoudl be added to the update procedure is to turn on Debug mode when doing the update.. My system completely errored out without me recognizing it! Even if you capture it and display any errors after the update.
2021.12
I have similar problems with the users not being able to select categories. This is upgrade experience has been suboptimal :(
I upgraded from 3.3 to Vanilla 2021.012. Admin account works great, all other users can't select categories and post.
I've done a test vanilla 2021.012 installation with only two users and category selection works fine.
I've repeated installation on my original forum, disabled all plugins, and ran the sql queries suggested in this thread. Same result.
Any suggestions would be greatly appreciated.
Ugh, I've been running Vanilla for the last 5 years and have never this many problems after an upgrade.
Sorry that I can't help with that. The only thing I can advice is to update to PHP 7.4 and to avoid Lighttp, since that has helped already with this problem
If anybody would grant me full access to his server again, I would try again to find the reason for the problem
@R_J -- I think you still have full access to my scratch server? Or am I forgetting something?
Yes, I have. I just would have expected that you turned it off in the meantime. I'll try to find some hints again.
Thanks for responses, much appreciated. Ugh, after going round and round with my hosting company I have determined that they moved me to a Litespeed server when I requested access to the required version of MySql for the upgrade.
LiteSpeed V7.9 Cloudlinux 1.3
It's soooo close to working. Has anyone been able to make lightspeed work?
I found some fix for at least @pinchies Anybody else could try if this is improving your problems, too.
But I feel super uncomfortable with it, because the underlying problem is that the database that I had taken a look at is returning string values instead of integers. That needs to be fixed, but what you see below is just fixing the result in this case. Since I assume that the wrong data type is a general problem, other malfunctions may occur. You should really try to solve this on the server layer!
But to get you going again, please try the following: edit the following file:
/applications/dashboard/models/class.permissionmodel.phpSearch for the function
permissionsByRoleDband add this lines before the linereturn $permissions;:array_walk_recursive($permissions, function (&$item, $key) { if (is_numeric($item)) { $item = intval($item); } });It should look like that afterwards:
Since user permissions are cached in the user table, you need to run /utility/structure to clear the wrong permissions from the database.
But again: please check the PHP version, the MySql version and the MySql driver version. Some web servers come with their own PHP "module" which might cause issues, too.
If somebody knows how to debug that database behaviour, please give hints. I would love to be able to fix that misbehaviour by simply adding some connection options to the config.
THANKS! I'm testing this on a clean install of Vanilla 2021.12 with a clone of my production db. I'll report back.
OK, we're making progress and it's very close to working.
Member can now post. After making a comment they are not able to click back on the category link but I found a workaround.
They get the following error message:
Permission Problem
You don't have permission to do that.
From the navigation menu they can select discussions and categories. They can select the listed the discussions but if they click categories they get the permission problem error if they click anything listed.
I've gone into the category properties and selected "custom properties" and as a workaround.
@R_J If you want I can make a dev version of my installation and perform an upgrade on it so that you can play with the bug to test more?
Thanks for the offer, but I do not see any motivation to do anything further. From my understanding it could be solved with the correct PHP and MySQL version. I just wanted to give those people a chance who cannot change immediately, but as I stated above: it's only a dirty workaround and I wouldn't recommend it at all. The root cause could be fixed, so why not do that?
I'm just a little bit curious how a simple "SELECT SomeInteger FROM AnyTable" could return a string.
So I just ran my update again from 3.3 to 2021.012 and after I ran the
/utility/updateand get the success smile, I know this happened last time and I looked at my PHP logs and I am getting this error below. Is there anything you would like me to test why I am getting this error first?Okay so I have replicated the same issues as last time, I did have some bad table structures in my database because of my import and once I altered my database to conform to the proper structure Vanilla is looking for, I was able to get the Database Structure Utility to run and it properly updated my database. Now I am running into the same issues as others which is what @R_J fixed above. I was able to implement his fix to allow my a user to see the forum and post to the forum.
So why is my server then returning string data when it is stored as tinyint(4)
@R_J Any ideas what to look for here? You saw my phpinfo() before? I have this now running on my dev site and the fix has to be applied to test to see if that's the same issue for me and it seems like it is.
EDIT: Also to confirm @R_J findings I did a var_dump($permissions) before and after his code and the entire array beside a few nulls were all string values and after his code they are all int values
I appreciate the workaround and the help but it seems like a bigger problem for me. I'm running the correct version of PHP and MySQL. I specifically upgraded my hosting account to accommodate the requirements.
A blank db and clean install works as expected. It's only when I switch to my production db that the category and permission problems occur. I've been running Vanilla for a 5+ years and haven't had problems upgrading versions before. It seems to me that there's something not being done in the DB upgrade between 3.3 and 2021.
I'm in limbo. I don't like running old versions (3.X) but I don't have confidence that my 2021 version is stable right now.
@aawolverine I might do what you did and do a fresh install of 2012.012 and check to see if the permissions returned are in string value or are in int value, because that would them eliminate the database server and point it back to a code issue. I also want to compare the two databases to see if I can pinpoint the issue
Do you by chance have a .sql copy of your blank database?
@R_J I just did a fresh install of 2021.012 and did a
var_dump($permissions);on line 888 of/applications/dashboard/models/class.permissionmodel.phpand the $permissions array key values are in string format. I did testing and demo users were able to log in and see the categories. So even though this fixes the issue we are having it's not the root cause. This now begs the question why does this solve the permission issue?