Illegal String Offset in class-wp-roles.php:292
Table of Contents
WordPress has experienced a critical issue
We were recently asked to assist with fixing and migrating a prospective client off GoDaddy’s web hosting. Apparently GoDaddy had an issue with a server and suffered some database corruption in the client’s site. The client had backups, but the backups were over two years old. All recent work was inaccessible. The client couldn’t access the front end of the website, the WordPress Admin Login page, or the WordPress Admin Dashboard, and while the backups were restoring without issue, the restorations weren’t fixing the issue.
Symptoms
When the PHP Version was set to 7.4 and below, we were given this error: When the PHP Version was set to 8.0 and higher, we were given this error:
Troubleshooting Steps Taken
We looked into the files provided in the stack trace for abnormalities:
- /wp-config
- /wp-includes/class-wp-roles.php
- /wp-admin/admin.php
- /wp-admin/index.php
As expected, none were found. Oddly, though, re-installing WordPress’s core files[a] didn’t solve the issue either. Neither did deactivating the active WordPress theme, disabling all WordPress Plugins, or changing the PHP version. Even asking ChatGPT didn’t produce any results. However, an internet search did lead us to this post: https://wordpress.org/support/topic/php-fatal-error-wp_roles/
More Research was Requierd
User obulat posted the following reply to another WordPress user having the same issue:
One possibility is that the user roles and capabilities on your WordPress site have been manipulated incorrectly, possibly by a plugin or custom code. If your error log is still indicating that the problem is in the class-wp-roles.php file after trying all the steps you’ve mentioned, it could be an issue in your database, specifically within the wp_options table. The wp_user_roles row in the wp_options table might have been corrupted. This row contains all the user role definitions. Before proceeding, please make sure to back up your database. You can then try to repair the database. If you have phpMyAdmin in your hosting control panel, you can use it to repair the database. If that doesn’t work, you may need to reset your user roles. There are plugins like “User Role Editor” that can reset your roles to their WordPress defaults, but since you can’t access the dashboard, you might need to use WP-CLI (if your host provides it) or do it manually. To do it manually, you’d need to access your database (likely through phpMyAdmin) and find the wp_options table, then the wp_user_roles row. The default value of this row for a fresh WordPress install can be found in the wp-includes/class-wp-role.php file. You can replace the corrupted value with the default value from a fresh WordPress install. Keep in mind this advice assumes the database is the issue, it’s possible that the issue is still elsewhere.
Source: https://wordpress.org/support/topic/php-fatal-error-wp_roles/#post-16943221
Changing the wp_options table’s wp_user_roles row
We logged into the client’s database using phpMyAdmin and navigated to the wp_options table, and checked the wp_user_roles row. This row had around 11,000 characters, a far cry from the number of characters a default WordPress installation would have in the same row (around 3100). Having exhausted all other options, we decided to replace this row’s value with that of a default WordPress installation. (Code provided at the end of this article) Once the row value was updated, we attempted to access the client’s /wp-admin login page, and it came up. We were then able to log in, asked to do a WordPress Database update, and proceeded to the WordPress Admin Dashboard.
Backing Up and Performing Maintenance
The WordPress Admin Dashboard was working without issue, but the front end was still throwing the same errors. Having made it this far, we decided to make an off-site backup using our backup tool of choice, BlogVault. This would give us a snapshot we could update, restore, or migrate when needed. After the site was backed up to BlogVault, we updated all the plugins, and the Divi Theme. While it was great to have these updates done, the updates also failed to fix the class-wp-roles:292 issue on the front-end.
Divi Theme Builder Requirements Not Met
We decided to go to the Divi Support Center inside the WordPress Admin Dashboard (Divi > Support Center) to verify the site met the requirements for Divi. This was more of a sidequest than an end-goal, but if we were fixing the site, we wanted to make sure it was in an environment that wouldn’t be inhibitive to it running. Oh dear: NOTE: PHP: display_errors set to 1 was for our troubleshooting purposes, and can be set to 0 once troubleshooting is completed. To enable WordPress debugging, edit your wp-config.php file with the following lines:
- define( ‘WP_DEBUG’, true );
- define( ‘WP_DEBUG_LOG’, true );
Migrating the Site to Better Hosting
Turns out, the site wasn’t even in a hosting environment that’s good for Divi. That being seen, we proceeded to migrate the backup we created on BlogVault over to our hosting. We created an account and provisioned the space for the client, and let BlogVault do the rest. And what do you know, viola! Once on our hosting space, the site worked perfectly.
Conclusion
Solution Found, but Root Cause Still Unknown
While it’s unclear if it was ultimately the hosting environment, it definitely appears that the issue was at least in part due to the length of the data inside the wp_user_roles row. Changing that to a default value from another WordPress installation allowed us to access the WordPress Admin Dashboard and do some much-needed website maintenance[e]. Our solution may not work for everyone, but if it works for you, we’d love to hear from you in the comments section. Huge “Thank you” to Birds of ParaDice for allowing us the opportunity to fix, migrate, and host their eCommerce website! Check them out if you’re looking for some awesome dice for yourself or a table-top / Dungeons & Dragons lover in your life.
The Data Value We Put Into the wp_user_roles Row
DISCLAIMER: Ensure you have a good backup of your WordPress Database[f] prior to making any changes to the database. Use this data at your own risk. This row data was pulled from a fresh installation of WordPress and the consequences of using them on a production site are unknown. You may lose roles, custom roles, and users may be unassigned from their roles. Please use this at your own risk.
a:5:{s:13:"administrator";a:2:{s:4:"name";s:13:"Administrator";s:12:"capabilities";a:61:{s:13:"switch_themes";b:1;s:11:"edit_themes";b:1;s:16:"activate_plugins";b:1;s:12:"edit_plugins";b:1;s:10:"edit_users";b:1;s:10:"edit_files";b:1;s:14:"manage_options";b:1;s:17:"moderate_comments";b:1;s:17:"manage_categories";b:1;s:12:"manage_links";b:1;s:12:"upload_files";b:1;s:6:"import";b:1;s:15:"unfiltered_html";b:1;s:10:"edit_posts";b:1;s:17:"edit_others_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:10:"edit_pages";b:1;s:4:"read";b:1;s:8:"level_10";b:1;s:7:"level_9";b:1;s:7:"level_8";b:1;s:7:"level_7";b:1;s:7:"level_6";b:1;s:7:"level_5";b:1;s:7:"level_4";b:1;s:7:"level_3";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:17:"edit_others_pages";b:1;s:20:"edit_published_pages";b:1;s:13:"publish_pages";b:1;s:12:"delete_pages";b:1;s:19:"delete_others_pages";b:1;s:22:"delete_published_pages";b:1;s:12:"delete_posts";b:1;s:19:"delete_others_posts";b:1;s:22:"delete_published_posts";b:1;s:20:"delete_private_posts";b:1;s:18:"edit_private_posts";b:1;s:18:"read_private_posts";b:1;s:20:"delete_private_pages";b:1;s:18:"edit_private_pages";b:1;s:18:"read_private_pages";b:1;s:12:"delete_users";b:1;s:12:"create_users";b:1;s:17:"unfiltered_upload";b:1;s:14:"edit_dashboard";b:1;s:14:"update_plugins";b:1;s:14:"delete_plugins";b:1;s:15:"install_plugins";b:1;s:13:"update_themes";b:1;s:14:"install_themes";b:1;s:11:"update_core";b:1;s:10:"list_users";b:1;s:12:"remove_users";b:1;s:13:"promote_users";b:1;s:18:"edit_theme_options";b:1;s:13:"delete_themes";b:1;s:6:"export";b:1;}}s:6:"editor";a:2:{s:4:"name";s:6:"Editor";s:12:"capabilities";a:34:{s:17:"moderate_comments";b:1;s:17:"manage_categories";b:1;s:12:"manage_links";b:1;s:12:"upload_files";b:1;s:15:"unfiltered_html";b:1;s:10:"edit_posts";b:1;s:17:"edit_others_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:10:"edit_pages";b:1;s:4:"read";b:1;s:7:"level_7";b:1;s:7:"level_6";b:1;s:7:"level_5";b:1;s:7:"level_4";b:1;s:7:"level_3";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:17:"edit_others_pages";b:1;s:20:"edit_published_pages";b:1;s:13:"publish_pages";b:1;s:12:"delete_pages";b:1;s:19:"delete_others_pages";b:1;s:22:"delete_published_pages";b:1;s:12:"delete_posts";b:1;s:19:"delete_others_posts";b:1;s:22:"delete_published_posts";b:1;s:20:"delete_private_posts";b:1;s:18:"edit_private_posts";b:1;s:18:"read_private_posts";b:1;s:20:"delete_private_pages";b:1;s:18:"edit_private_pages";b:1;s:18:"read_private_pages";b:1;}}s:6:"author";a:2:{s:4:"name";s:6:"Author";s:12:"capabilities";a:10:{s:12:"upload_files";b:1;s:10:"edit_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:4:"read";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:12:"delete_posts";b:1;s:22:"delete_published_posts";b:1;}}s:11:"contributor";a:2:{s:4:"name";s:11:"Contributor";s:12:"capabilities";a:5:{s:10:"edit_posts";b:1;s:4:"read";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:12:"delete_posts";b:1;}}s:10:"subscriber";a:2:{s:4:"name";s:10:"Subscriber";s:12:"capabilities";a:2:{s:4:"read";b:1;s:7:"level_0";b:1;}}}
Triple-click the above code (it’s all one, connected line), then right-click and copy and replace the contents of the wp_user_roles element value. If you don’t know what any of that means, please ask a professional.
About the Author: Mark Bush
NOTE: Some links on this page may be affiliate links, and help support our business. These links do not alter the cost of the product, but provide a small percentage of the sale to us as the referral source.
0 Comments